A flood forecast is only as useful as the warning it produces and the action that warning triggers. This chapter lays the physical and institutional groundwork for the rest of the book: what kinds of floods exist, how rain becomes a rising river, how water levels are compared against thresholds, how rare an "extreme" event really is, and how observation, forecasting, warning and response link into a single chain. At each step we point to the WIA-ENE-033 object or PHASE that will carry that idea into software.
"Flood" is a single word for several quite different physical processes. They differ in where the water comes from, how quickly it arrives, which observations give the earliest signal, and how much warning time a forecaster can realistically offer. A standard that tries to describe flood prediction across vendors therefore has to name the type of event explicitly, because the right data sources, models and alert wording all depend on it.
WIA-ENE-033 does this with an event-type field in the warning message. In the PHASE-3 alert schema (§7.2) the field event.type accepts four values: river-flood, urban-flood, coastal-flood and flash-flood. The TypeScript reference SDK declares the same four in its FloodEventType enum and adds a fifth, dam-discharge, which the specification text does not list. We return to that discrepancy at the end of this section; first, the four physical types.
A river flood occurs when the discharge arriving from upstream exceeds the capacity of the channel and its levees, so that water spills onto the floodplain or overtops the embankment. The cause is usually prolonged or widespread rainfall over a catchment, sometimes combined with snowmelt or releases from reservoirs. Because the water has to travel through the river network before reaching a given town, large rivers offer the longest natural warning times of any flood type: a crest observed at an upstream gauge can be routed downstream hours or days before it arrives. The dominant data sources are river-stage gauges, upstream rainfall and, where present, dam operating data.
Urban flooding, called 내수 침수 (interior flooding) in Korean practice, happens when intense local rain falls faster than the drainage system can carry it away. Sewers surcharge, pump stations reach their limit, and water ponds in underpasses, basements and low-lying streets — often while the nearby river is still well within its banks. An important variant is when a high river stage prevents storm drains from discharging into it, so that the two flood types interact. The decisive observations are short-duration rainfall intensity from gauges and radar, and the state of drainage infrastructure: pump capacity, sewer load and detention-basin levels. Warning times are short, typically measured in minutes to a few hours.
Coastal flooding is driven by the sea rather than by rain: storm surge pushed ashore by strong onshore winds and low atmospheric pressure, combined with the astronomical tide and waves. Estuaries and tidal river reaches are where coastal and river flooding meet, because a high sea level slows the river's outflow. The main inputs are tide predictions, sea-level gauges and meteorological forecasts of wind and pressure. Version 1.0 of ENE-033 includes the coastal-flood event type, but its release notes state that storm-surge coupling — the modelling needed to forecast coastal inundation properly — is a roadmap item for v1.1. Coastal events can be labelled and warned about under v1.0, but the standard does not yet define how a surge model feeds the prediction.
A flash flood is a rapid rise of water in a small, steep or urbanised catchment, arriving within a few hours of the causative rain — commonly defined as six hours or less. Mountain streams, dry channels and small urban creeks are typical settings. The water is fast, often debris-laden, and dangerous precisely because there is little time between the rain and the peak. Forecasting relies on radar-based rainfall nowcasts, soil-moisture state and threshold guidance for small catchments rather than on routing a wave from far upstream.
| Flood type | Typical onset | Dominant data sources | ENE-033 value |
|---|---|---|---|
| River (fluvial) | Hours to days; grows with basin size | River-stage gauges, catchment rainfall, dam operations | river-flood |
| Urban (pluvial, 내수) | Minutes to a few hours | Rain-gauge and radar intensity, drainage and pump status | urban-flood |
| Coastal | Hours; tied to tide cycle and storm track | Tide predictions, sea-level gauges, wind and pressure forecasts | coastal-flood (surge coupling planned for v1.1) |
| Flash flood | Within a few hours of rainfall (often under six) | Radar nowcasts, soil saturation, small-catchment thresholds | flash-flood |
The SDK's FloodEventType enum also contains DAM_DISCHARGE = 'dam-discharge'. A planned or emergency reservoir release is a real and important hazard for downstream communities, but physically it produces a river flood, and the PHASE-3 schema does not accept dam-discharge in event.type. Until the specification and SDK are aligned, a strict implementation should send river-flood and describe the release in the instructions and in the contributingFactors.damStatus data, rather than emit a value that a schema-validating consumer may reject.
Every flood forecast, whatever model it uses, tries to answer one causal question: given the rain that has fallen and the rain that is expected, how much water will pass a particular point, and when? Understanding the stages of that causal chain explains both what the standard's data objects contain and why forecast lead time has a hard limit.
Hydrologists describe a storm with a hyetograph, a plot of rainfall intensity against time. Two storms with the same total can have very different consequences: 100 mm spread evenly over a day is absorbed and drained far more easily than 100 mm concentrated in two hours. This is why ENE-033's PrecipitationData carries both a current intensity in millimetres per hour (observed.current) and accumulations over 1, 3, 6 and 24 hours (last1h … last24h), plus an hourly forecast array. The intensity describes the shape of the hyetograph; the accumulations describe its volume. Chapter 2 examines these fields in detail.
Not all rain becomes streamflow. Part is intercepted by vegetation, part infiltrates into the soil, part is stored in depressions, and part evaporates. What remains flows over the surface or through shallow soil layers toward streams. How much remains depends strongly on the antecedent condition of the catchment. A dry soil can absorb a large share of a storm; the same storm falling on soil already saturated by earlier rain produces far more runoff, because there is nowhere left for the water to go. Impervious surfaces such as roads and roofs behave like permanently saturated soil, which is one reason urban catchments respond so quickly.
ENE-033 captures this with the optional field contributingFactors.soilSaturation, expressed as a percentage, in the prediction result defined in PHASE-1 §5.2. It is optional because many operators do not observe soil moisture directly and instead estimate it from recent rainfall. When it is present, it is one of the most informative predictors a model can receive, because it modulates how every future millimetre of rain will translate into flow.
Runoff from the hillslopes gathers in tributaries and then in the main channel, and travels downstream as a flood wave. As the wave moves it is delayed and usually flattened: channel storage and floodplain storage temporarily hold water, so the peak arrives later and lower than it would if the whole volume moved as a block. Computing this movement is called flood routing. Simple methods treat each river reach as a storage element; hydraulic methods solve the one-dimensional Saint-Venant equations along the channel. PHASE-3 of the standard names the Saint-Venant approach for its 1D river model, and Chapter 5 explains those equations. For this chapter the key point is qualitative: the time between rain falling on a catchment and the peak passing a gauge is governed by catchment size, slope, land cover, channel shape and antecedent wetness.
Hydrologists use terms such as lag time (from the centre of rainfall to the peak flow) and time of concentration (the time for water to travel from the most distant part of the catchment to the outlet) to describe how quickly a basin responds. These quantities set a natural ceiling on warning time when a forecast is driven only by observed rain. If a catchment responds within two hours, then a forecast based on rain already on the ground can give at most about two hours of warning, however good the model is.
There are only two ways to extend lead time beyond the basin response. The first is to observe further upstream, so that the wave is detected earlier in its journey — this is why large river systems achieve long lead times. The second is to forecast the rain itself, using radar extrapolation for the next hour or two and numerical weather prediction for longer horizons. Forecast rainfall is much more uncertain than observed rainfall, so every hour of lead time gained this way is paid for with greater uncertainty. The README of ENE-033 reflects exactly this trade-off in its description of forecast horizons: short range (1–6 h) based on real-time rainfall radar, medium range (6–24 h) based on numerical weather models combined with AI, and long range (24–72 h) based on ensemble weather forecasts. The timeHorizon field of a prediction request (1h, 6h, 24h, 72h) is how a client chooses its place on that trade-off curve.
Operational flood warning is, in the end, a comparison: is the water level now, or will it soon be, above a level at which harm begins? That comparison needs clear definitions of what is measured and what it is compared against.
Stage (water level) is the height of the water surface at a gauge, in metres above a reference datum. Discharge (flow rate) is the volume of water passing the gauge per unit time, in cubic metres per second. Stage is cheap and continuous to measure with pressure transducers, float gauges, radar or ultrasonic sensors. Discharge is what hydrological models compute and what determines how much water must be accommodated downstream, but it is expensive to measure directly: field teams must measure velocity across the channel section, for example with current meters or acoustic Doppler profilers, and integrate it over the cross-sectional area.
In RiverLevelData.current, ENE-033 records both: waterLevel in metres, flowRate in m³/s and a representative velocity in m/s, together with the observation timestamp. A consumer should not assume that all three are independent measurements; at most stations the flow rate is derived from the stage.
The link between stage and discharge at a gauge is the rating curve, built by fitting a relationship to occasional paired measurements of both. A widely used form is a power law, Q = a (h − h0)b, where h is the stage, h0 the stage at which flow ceases, and a and b are fitted coefficients. Rating curves are local and change over time: scour and deposition alter the channel, vegetation changes roughness, and during rapidly rising and falling floods the same stage can correspond to different discharges (a hysteresis or "loop" rating). Backwater from a downstream confluence, a tide or a dam can also break the relationship. Two practical consequences follow: discharge values at extreme stages are often extrapolations beyond the measured range, and any exchanged discharge value is only as good as the rating used to compute it.
Operators attach a set of reference levels to each gauge so that a stage reading can be interpreted immediately. ENE-033 encodes these in the levels object of RiverLevelData as five values in metres: normal, attention, warning, danger and bankHeight. The first four are thresholds of increasing concern set by the operating authority; bankHeight is a physical property — the crest of the bank or levee — above which water leaves the channel. The companion field status.condition reports which of the four thresholds band the current stage falls into (normal, attention, warning or danger), and status.overflowRisk and status.estimatedTimeToOverflow express how close the river is to the bank crest.
The fragment below shows an illustrative threshold ladder. The numbers are an example, not values from any real station; every gauge has its own ladder, derived from channel survey, flood history and local decisions.
"levels": {
"normal": 2.0,
"attention": 3.5,
"warning": 4.5,
"danger": 5.0,
"bankHeight": 6.2
}
Two properties should hold for every ladder and are worth checking in validation code: the four thresholds must be strictly increasing (normal < attention < warning < danger), and none of them may exceed bankHeight. A ladder whose danger level is above the bank crest is almost certainly an error in data entry or datum. The ladder is also only meaningful in the same vertical datum as the stage reading — a subject Chapter 2 treats under data quality.
Floods and extreme rainfalls are described in terms of their rarity. Phrases such as "a 100-year flood" are common in engineering design and in public communication, and they are routinely misunderstood. Because ENE-033's PrecipitationData.statistics object carries a returnPeriod in years, a percentile and a boolean isExtreme, implementers need to use these terms precisely.
The return period T of an event of a given magnitude is the reciprocal of its annual exceedance probability. An event with a 100-year return period has a probability of 1/T = 1/100 = 1 % of being equalled or exceeded in any single year. It does not mean the event happens once every hundred years, nor that after one occurs the next is a century away. Each year is, to a first approximation, an independent draw with the same small probability.
Return periods are estimated by fitting a statistical distribution to a record of annual maxima (or peaks over a threshold) and reading off the magnitude for a chosen T. For rainfall, this is done separately for each duration, which is why intensity–duration–frequency (IDF) relationships exist: a 50 mm accumulation may be unremarkable over 24 hours and exceptional over one hour. A returnPeriod value in ENE-033 is therefore only interpretable together with the duration it refers to; an implementation should state in its documentation which accumulation window it evaluates.
The more useful question for planning is the probability of experiencing at least one such event during a period of n years — for example the lifetime of a building or the tenure of a flood-defence scheme. If each year has exceedance probability 1/T and years are independent, the probability of no exceedance in n years is (1 − 1/T)n, so:
P(at least one event in n years) = 1 − (1 − 1/T)^nWorked example: for T = 100 years and n = 30 years, (1 − 0.01)30 = 0.9930 ≈ 0.740, so the probability of at least one 100-year event in 30 years is about 1 − 0.740 = 0.26, or roughly 26 %. Over 100 years the same formula gives 1 − 0.99100 ≈ 0.63: even across a full century, a "100-year" event is more likely than not, but far from certain. The short function below reproduces these figures and can be used to annotate forecast reports.
function probabilityAtLeastOnce(returnPeriodYears: number, years: number): number {
if (returnPeriodYears <= 1) throw new Error('return period must exceed 1 year');
return 1 - Math.pow(1 - 1 / returnPeriodYears, years);
}
probabilityAtLeastOnce(100, 30); // ≈ 0.26
probabilityAtLeastOnce(100, 100); // ≈ 0.63
The three fields in PrecipitationData.statistics each answer a different question. returnPeriod answers "how rare is this magnitude, in years?" percentile answers "where does it sit within the historical record?" — a 99th-percentile hourly rainfall is exceeded by only 1 % of the hourly values in the reference record, which is not the same as a 100-year event, because the percentile is computed over all hours rather than over annual maxima. isExtreme is a boolean flag whose threshold the specification does not fix; it is a convenience for dashboards and alert rules. An operator should publish the rule behind it (for example, "isExtreme is true when the return period of the 1-hour accumulation is at least 50 years") so that consumers can interpret the flag consistently. That example threshold is illustrative only.
One caution applies to all three fields. Return periods estimated from historical records assume the climate that produced the record also governs the future. Where rainfall extremes are changing, a stationary estimate can understate present-day risk. Chapter 8 returns to non-stationary return periods and what they imply for this field.
A technically excellent forecast that nobody receives, understands or acts upon saves no one. This lesson, learned repeatedly in disaster after disaster, is why international practice treats early warning as an end-to-end system rather than as a forecasting problem alone. The World Meteorological Organization (WMO) and its partners describe effective multi-hazard early-warning systems in terms of four connected elements: knowledge of the disaster risk; detection, observation, monitoring, analysis and forecasting; warning dissemination and communication; and preparedness and response capabilities. A weakness in any one breaks the chain.
The Sendai Framework for Disaster Risk Reduction 2015–2030, adopted by UN member states, sets seven global targets. Target G calls for substantially increasing the availability of, and access to, multi-hazard early-warning systems and disaster risk information and assessments by 2030. PHASE-4 of ENE-033 lists the Sendai Framework among its references and names Sendai reporting as one of its regulatory crosswalks. That places the standard in the policy context where national reporting on early-warning coverage happens; it does not make ENE-033 itself part of the Sendai Framework.
The diagram below follows a single flood event through the operational chain — observe, forecast, warn, respond — and marks which part of ENE-033 governs each hop. Risk knowledge sits underneath all four as the foundation: threshold ladders, return-period statistics, shelter inventories and the like.
OBSERVE FORECAST WARN RESPOND
┌──────────────┐ ┌───────────────────┐ ┌──────────────────┐ ┌───────────────────┐
│ rain gauges │ │ forecasting node │ │ warning publisher│ │ municipalities, │
│ radar, river │ ──▶ │ 1D/2D hydraulics, │ ──▶ │ AlertCriteria, │ ──▶ │ responders, │
│ gauges, dams,│ │ AI, ensemble │ │ FloodAlert, │ │ residents, │
│ drainage │ │ │ │ CAP 1.2 feed │ │ shelters, routes │
└──────────────┘ └───────────────────┘ └──────────────────┘ └───────────────────┘
PHASE-1 objects PHASE-3 §6 models PHASE-3 §7 criteria, PHASE-2 evacuation
(Precipitation, PHASE-1 FloodPrediction- alert structure and routes/shelters,
RiverLevel, Dam, Result; PHASE-2 channels; PHASE-2 PHASE-4 reporting
Drainage); forecastQuery, warningPublish and evidence
PHASE-2 gaugeIngest simulationSubmit (CAP 1.2 required)
─────────────────────────────────────────────────────────────────────────────────────────
Risk knowledge: reference levels, return periods, shelter inventory, exposure dataTwo features of this chain shape the whole standard. First, each hop crosses an organisational boundary as often as a technical one. The gauge may belong to a water agency, the forecast to a river-basin authority, the warning decision to a disaster-management office and the response to a municipality. Interoperable messages are what allow these organisations to co-operate without bespoke integrations, which is why PHASE-2 requires the warning publication operation to emit CAP 1.2 alongside the WIA-native format. Second, the chain involves decisions that are not purely computational. PHASE-3's alert criteria distinguish conditions under which an alert may be raised automatically from conditions that require manual review, for example high uncertainty or threats to critical infrastructure. Chapter 5 examines those rules; the principle to hold now is that the standard supports human authority over warnings rather than replacing it.
Each link has its own measure of quality. Observation is judged by coverage, latency and data quality. Forecasting is judged by skill and by lead time — how early a correct forecast is available. Warning is judged by timeliness, reach and clarity: whether the right people receive an understandable message with enough time to act. Response is judged by what people actually do. ENE-033 provides data structures for several of these measures, such as delivery accounting in AlertDistribution.status (sent, delivered, failed, confirmed) and model-performance fields including lead time and false-alarm rate. The spec and README also state numeric design targets for some of them; those are goals, not measured results, and Chapter 7 treats them accordingly.
Readers deploying ENE-033 in Korea meet a vocabulary problem at once: the same Korean words are used by different institutions for different things. Keeping them apart is essential, because a warning that uses the wrong term can be misread by the public or collide with an official product.
In Korea, official river flood forecasts and warnings — 홍수특보, consisting of the flood watch 홍수주의보 and the flood warning 홍수경보 — are issued by the flood control offices (홍수통제소) for the major river systems. They are hydrological products tied to designated forecast points and their reference water levels. They carry legal and institutional weight; they are not generic labels that any system can apply to its own output.
Separately, the national disaster-management framework under the Framework Act on the Management of Disasters and Safety (재난 및 안전관리 기본법) uses four crisis alert levels: 관심, 주의, 경계 and 심각. These express the government's overall posture toward a disaster situation and drive the activation of response organisations. They apply to many hazards, not only floods.
ENE-033 defines five risk levels, LEVEL-0 to LEVEL-4. The SDK's formatRiskLevel helper labels them 정상, 관심, 주의, 경계 and 심각 in Korean, and Normal, Attention, Caution, Warning and Severe in English. Levels 1 to 4 therefore share their Korean names with the national crisis alert levels, and the level names 주의 and 경계 also resemble words used inside the flood-forecasting vocabulary.
The shared words do not mean shared definitions. An ENE-033 LEVEL-3 is the output of a particular forecasting system for a particular area and time horizon; it is not a declaration of the national 경계 crisis level, and it is not a 홍수경보. Conversely, the issuance of a 홍수주의보 at a forecast point does not automatically determine which ENE-033 level applies to a neighbourhood several kilometres away. The book adopts two rules, and recommends them to implementers:
| Vocabulary | Who issues it | What it describes | Relation to ENE-033 |
|---|---|---|---|
| 홍수특보 (홍수주의보 / 홍수경보) | Flood control offices (홍수통제소) | Official river flood watch / warning at designated forecast points | External input or reference; never a label for ENE-033 output |
| 위기경보 관심 / 주의 / 경계 / 심각 | Government disaster-management authorities | Overall national or regional crisis posture across hazards | Crosswalked through a documented table; same words, different meaning |
ENE-033 LEVEL-0 … LEVEL-4 |
The operator of an ENE-033 forecasting system | Forecast flood risk for an area and time horizon | Native RiskLevel enum; labels from formatRiskLevel |
| Gauge reference levels | Gauge operator / river authority | Stage thresholds at one gauge | RiverLevelData.levels and status.condition |
The last row adds a further subtlety. The gauge threshold names in levels (attention, warning, danger) do not line up one-to-one with the English risk-level labels (Attention, Caution, Warning, Severe), and the README's own level table ties the risk levels to gauge thresholds in a way that is offset by one step from the field names. Chapter 3 states an explicit mapping rule for that case; here it is enough to recognise that at least four vocabularies are in play and that each needs its owner and its definition written down.
WIA-ENE-033 is a WIA standard for flood prediction and early warning. It is not an ISO, IEC or WMO standard; rather, it references established work from those bodies and from OGC, OASIS and the IETF, and defines how the pieces fit together for exchanging observations, forecasts and warnings. Version 1.0 is marked Stable and is organised into four PHASE documents, each consolidating sections of an overarching specification.
| PHASE | Subject | Main content | Key external references |
|---|---|---|---|
| PHASE-1 | Data Format | Prediction request and result; precipitation, river-level, dam/reservoir and drainage data; schemas in JSON Schema 2020-12 | WMO HOMS, OGC WaterML 2.0, ISO 19156:2023, OpenAPI 3.1 |
| PHASE-2 | API Interface | Operation groups gaugeIngest, forecastQuery, warningPublish, simulationSubmit, evacuationRoute; discovery at /.well-known/wia/ene-033; CAP 1.2 emission for warnings |
RFC 8615, RFC 9457, RFC 6585, OASIS CAP 1.2 |
| PHASE-3 | Protocol | Gauge network → forecasting node → warning publisher → downstream consumer; AI, 1D/2D hydraulic and ensemble prediction; alert criteria, message structure and distribution channels | WMO HOMS, OGC WaterML 2.0, OASIS CAP 1.2, ISO 22315:2014 |
| PHASE-4 | Integration | Security and privacy; integration patterns; conformance levels and evidence packages; regulatory crosswalks including Sendai reporting | ISO/IEC 27001:2022, ISO/IEC 27018:2019, CycloneDX 1.5, Sigstore, Sendai Framework |
Alongside the PHASE documents, the repository contains a TypeScript reference SDK (types.ts for the data model, index.ts for the client and helper functions), a shell-based command-line tool and an interactive simulator. Where the SDK and the specification text differ — the fifth event type in Section 1.1 is the first example — this book points the difference out and recommends the behaviour that keeps an implementation interoperable. Several artefacts referenced by the PHASE documents, such as the machine-readable OpenAPI description and the published test-vector directories, are not yet present in the repository; later chapters say so where it matters.
The same identifier appears with two release dates in the source material: the README's change log lists version 1.0.0 with a 2025 date, while the release notes give a 2026 release date. This book refers simply to "v1.0 (Stable)".
The chapters follow the chain in Section 1.5, from data to decision to deployment:
FloodAlert message, its CAP 1.2 mapping, and evacuation shelter and route data.Readers who build data pipelines can go straight from this chapter to Chapter 2; those who build warning or public-communication systems may prefer Chapter 3 next; architects and auditors will find Chapters 6 and 7 most relevant. Whatever the route, the physical ideas of this chapter — flood types, basin response, rating curves, threshold ladders and return periods — are the background against which every later data field should be read.
dam-discharge value that strict implementations should avoid emitting.normal, attention, warning, danger, bankHeight) that must be increasing and in the same datum as the reading.