Flood & hydrological forecasting and early warning

Floods are the costliest natural hazard in Europe, and warning time decides how much can be saved. Classic process models (e.g. LISFLOOD, HBV, Delft-FEWS chains) are now complemented by data-driven models, mainly LSTM-based rainfall-runoff networks trained on thousands of catchments, which forecast river discharge several days ahead, also in places without gauges. The forecasts feed official warning centres, utilities, insurers and humanitarian anticipatory action. The warning decision itself stays with accountable authorities.

Problem & value

• Today: flood forecasting in Europe is run by national and regional hydrological services (in Germany the Länder flood forecast centres, shown jointly on the Länderübergreifendes Hochwasserportal [8]) using calibrated process models, supported at EU level by EFAS, the Copernicus European Flood Awareness System, which gives probabilistic warnings up to 10 days ahead to national hydrological services and the EU emergency response centre but is not distributed to the public [1]. Many catchments, small rivers and most of the world have no calibrated model or gauge.
• AI value: one model can be trained across thousands of catchments and then transfer to ungauged ones; inference is cheap, so large ensembles and many scenarios are affordable; forecasts can be extended to countries with little infrastructure. Google reports its Flood Hub covers river basins in 150+ countries with forecasts reaching about 2 billion people, riverine floods up to 7 days ahead [2].
• Policy anchor: the EU Floods Directive 2007/60/EC requires preliminary risk assessment, hazard and risk maps and flood risk management plans on a 6-year cycle [4]; the UN "Early Warnings for All" initiative aims at universal coverage by 2027 and, as of 2024, 108 countries report some multi-hazard early-warning capacity [9].
• No cost or lives-saved figures are quoted here because they depend heavily on region and event; evaluate on your own historic events (see KPIs).

Variants

• Public flood-warning services: national/regional forecast centres, civil protection, EFAS partners.
• Municipal and water-board operations: gate/pump/barrier control, retention basins, urban drainage.
• Utilities and industry: hydropower and reservoir inflow forecasting, water supply intakes, plant and logistics site protection, inland-waterway navigation (low and high water).
• Insurance and finance: event-triggered parametric cover, claims-surge preparation (see PRED-036).
• Humanitarian anticipatory action: forecast-triggered release of pre-agreed funds and early action by IFRC/Red Cross, UN agencies and NGOs, where thresholds (probability, lead time) are defined in advance in early-action protocols; for crisis forecasting beyond floods see PRED-040.
• Private use: residents and farmers read official apps/portals (Flood Hub, LHP, warning apps such as NINA/KATWARN); they do not run models themselves.
• Flash floods and pluvial (urban) flooding: needs radar nowcasting and high-resolution hydrodynamics; Flood Hub lists urban flash floods only up to 24 h ahead [2]. Harder and less mature.

How it works

1. observations (gauges, radar, satellite) + weather forecast ensembles
2. data assimilation / quality control (gap filling, rating curves, outlier removal)
3. hydrological model(s): data-driven LSTM | conceptual/process model | hybrid
4. ensemble post-processing (bias correction, calibration, uncertainty)
5. threshold & return-period analysis
6. inundation maps (scenario library or hydrodynamic model)
7. expert review by duty hydrologist
8. warning decision & dissemination
9. feedback/verification

• Data-driven core: sequence models (LSTM, in newer work also Transformers and graph networks) receive meteorological forcings plus static catchment attributes and output discharge for each lead time; trained jointly on many basins so that they generalise to ungauged ones. Google's current production model is a Mean-Embedding-Forecast-LSTM; an open reimplementation exists [5].
• Hybrid approaches keep the water balance of a conceptual model and let a neural net learn parameters or residuals; useful where physical consistency and extrapolation matter.
• Data assimilation nudges states with recent gauge readings; open code supports it for the Mean-Embedding model [5].
• Human in the loop: the duty hydrologist validates, overrides and approves; the decision to issue a warning, close roads or evacuate always remains with the competent authority.

Data preparation

Needed are gauge and discharge time series, rainfall and weather forecasts, radar data, terrain and land-use models, catchment data and historic flood events. In an authority or SMB these data live in agency portals (DWD, state flood centres, Copernicus), sensor loggers, GIS file shares, Excel sheets and paper flood protocols. Typical gaps are gauge outages and drift, short histories for rare events, differing coordinate systems and time resolutions, missing event labels and unclear licences or access rights for sensor data.

Preparation steps: inventory data sources and licences (PREP-001, PREP-002); build automatic ingestion via APIs (PREP-005); clean and gap-fill time series, align time zones and units (PREP-011); digitise historic flood marks and logbooks (PREP-006, PREP-008); define event labels with hydrologists (PREP-018, PREP-020). Tools are Python (xarray, GeoPandas), QGIS, PostGIS and TimescaleDB. Readiness check via GUIDE-003. Expect roughly 50-60 percent of the effort in data work, mostly on long, consistent series.

Implementation paths

Which path for whom

• smb: A, because commercial flood-risk and warning services plus free Copernicus/EFAS products cover site protection without own modelling.
• enterprise: B, because insurers and utilities combine cloud forecast APIs with their own asset and exposure data.
• developer: C, because open hydrological models and open weather data run on HW2 and give full control for new products.
• public: C, because authorities need sovereign, auditable operation of warning systems on EU/German infrastructure with open-source models.

Path A — Buy (off-the-shelf)

• Free public services (use first): Google Flood Hub and its Flood Forecasting API, free of charge and licensed CC BY 4.0, access via waitlist and for listed countries only [2][3]; EFAS/CEMS-Floods for authorities and partners [1]; German LHP portal for official warnings [8].
• Operational platforms: Deltares Delft-FEWS (Dutch, EU), used in nearly 70 countries, with a recent feature for direct import of Google Flood Hub forecasts [7]; vendors such as DHI (Denmark, MIKE products), KISTERS (Germany, WISKI/hydrological forecasting) and Hydrologic modelling consultancies provide turnkey forecast systems and consulting.
• Choose A when: you are an authority, utility or company that needs reliable forecasts without a modelling team. Check licence terms, EU hosting, and whether the supplier is accountable for warnings.

Path B — Build on cloud APIs

• Pull forecasts from the Flood Forecasting API [3], ECMWF open data (IFS/AIFS ensemble) and DWD Open Data (ICON), combine with own sensors in a streaming pipeline, add site-specific thresholds, alert logic and dashboards.
• An LLM layer is useful for plain-language situation reports and multilingual warning drafts, not for the numerical forecast. Keep it behind human approval.
• Choose B when: you operate a site, network or portfolio and need site-specific alerts and integration into operations or claims systems.

Path C — Self-host (open source)

• Models/tools: NeuralHydrology (PyTorch, BSD-3-Clause) [5a], Google's OpenHydroNet reimplementation of the production forecast LSTMs (Apache-2.0, not an officially supported Google product) [5], the Caravan community dataset of forcings, attributes and discharge for catchments worldwide [6], ECMWF Anemoi for training data-driven weather models if you need your own forcing model [10], and the Delft-FEWS platform for operations [7].
• Hardware: training on a few thousand catchments fits a single 16-32 GB GPU (HW2); inference is light (CPU is enough for hundreds of gauges). Hydrodynamic 2D inundation runs are the heavy part.
• Ops effort: a data engineer plus a hydrologist; the hard work is data quality, real-time ingest and verification, not the model code.

Path D — Custom training

Worth it for your own catchments, reservoirs or river reaches where regional models are weak (snowmelt, karst, regulated rivers, small flashy catchments). Needs long, quality-checked gauge histories (ideally 20+ years), catchment attributes, regulation/operation records and hindcasts of the weather forecast used operationally. Fine-tune a pre-trained multi-basin model rather than start from scratch; verify on held-out basins and extreme events, which are rare in the data.

State of the art (2026)

• Multi-basin LSTMs have been the benchmark approach since Kratzert et al. 2018-2019. Nearing et al. (Nature, 2024) showed global forecasting of extreme riverine events including in ungauged basins; this underlies Flood Hub [2][5]. (The paper itself could not be retrieved in this review; figures are therefore not quoted.)
• Operational convergence: AI forecasts are being integrated into established systems, e.g. Delft-FEWS importing Flood Hub forecasts [7], while EFAS keeps its process-model ensemble based on LISFLOOD [1]. Expect ensembles of both model families.
• AI weather models (ECMWF AIFS and others, see PRED-017) improve the forcing; tooling such as Anemoi is open [10].
• Open data and reproducibility: Caravan, Google's reanalysis/reforecast dataset (global discharge 1980-2023) and inundation history (1999-2020) enable benchmarking [3][6].
• Limits and failure modes: extreme events lie outside the training distribution; regulated rivers, dam releases and karst behave non-naturally; snowmelt and ice-jam floods need dedicated data; flash floods in small catchments are hard at coarse forcing resolution; gauge data are noisy at high flows (rating-curve extrapolation); prediction of inundation depth and extent needs terrain and hydrodynamic models on top of discharge. Forecast skill degrades with lead time and with forecast-rainfall error. Over-confident probabilities cause missed or false alarms.

Shared resources & combinations

• Time-series stack (time-series, streaming): shared with PRED-007 (energy/renewables, including hydropower inflow), PRED-017 (weather forecasts as forcing), PRED-042 (air quality).
• Remote sensing (SAR flood extent, soil moisture): shared with agriculture and PRED-036 (natural-catastrophe risk), PRED-013 (yield).
• Downstream: PRED-036 (climate/nat-cat exposure and portfolio impact), PRED-033 (network failure and renewal: water, drainage), PRED-046 (bridge scour and structural monitoring), PRED-040 (humanitarian anticipatory action beyond floods), SCI-010 (earth-system modelling, climate scenarios for design floods).
• Hardware: a single HW2 GPU server can also host other forecasting models; a shared data lake of NetCDF/Zarr weather and discharge data serves all related use cases.

Effort, cost & KPIs

• Path A: weeks for onboarding public services; commercial platform projects typically months.
• Path B: 2-4 months for a site-specific alert system with integration.
• Path C: 4-9 months to an operational, verified system; main cost is people and data work.
• Path D: 6-12 months incl. hindcast verification and parallel operation with the existing system.
• KPIs: probability of detection and false-alarm ratio per threshold; lead time of warnings at detection; discharge skill (Nash-Sutcliffe / Kling-Gupta efficiency) and peak-timing error on extreme events; reliability of probabilistic forecasts; share of gauges and catchments covered; for operations: avoided damage, response time, number of warnings acted on.

People & change

Involve management or the mayor's office for accountability, the department lead (water management, civil protection) as process owner, data owners of gauges and GIS, IT and IT security (warnings are critical infrastructure), legal for liability of warnings, and the affected population via clear communication. A works or staff council is usually not triggered since no employee monitoring occurs, but in public bodies inform the Personalrat when on-call or control-room processes change (§90(1) no. 3 BetrVG analogue under BPersVG). Personal data is rarely involved; involve the DPO if citizen contact data or crowd-sourced reports are used, and conclude an AVV with cloud processors.

AI literacy (Art. 4 AI Act): train control-room staff on forecast uncertainty and model limits. Run the system in shadow mode next to the existing procedure for one flood season as pilot (GUIDE-009). Typical concern: false alarms or missed events; address with transparent uncertainty bands, and ensure that warnings are always released by a human decision maker. See GUIDE-008, GUIDE-011 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: depends. A purely informational forecast is typically minimal risk. AI used as a safety component in the management and operation of critical infrastructure, including the supply of water, gas, heating or electricity, falls under Annex III point 2 (high risk) [11]; this may apply to automatic control of dams, gates or pumps. Pure public-warning support usually does not. Assess per deployment; if high risk, obligations of Arts. 9-15 (risk management, data governance, logging, human oversight, accuracy) apply. AI-generated public text may need Art. 50 labelling.
• Public-authority liability: warnings are a sovereign task; wrong or missing warnings create liability. Keep official thresholds and decision authority with the responsible body, use AI as a second opinion until verified over several seasons.
• GDPR: hydrological data are not personal. Exposure and evacuation planning with population or address-level data, or alert-by-location apps, can be; use aggregated data and legal-basis review.
• Sector law: EU Floods Directive and national water law (in Germany WHG and Länder water laws) [4]; NIS2 and the Critical Entities Resilience Directive for utilities; DORA/Solvency II context for insurers using the forecasts.
• Mitigations: probabilistic output with transparent uncertainty, back-testing on past floods, monitoring of sensor outages, fallback to process models, redundancy and manual override.

Getting started

1. Inventory what exists: which official forecasts (LHP, EFAS partners, Flood Hub) cover your rivers and which decisions you need to support.
2. Collect 10-20+ years of gauge data and site thresholds; compare official forecasts with past events.
3. Request Flood Forecasting API access and test it against your gauges [3]; do not rely on it alone.
4. Prototype a multi-basin LSTM with NeuralHydrology or OpenHydroNet on Caravan plus your own basins [5][6].
5. Define alerts, human approval and a verification routine; run in shadow mode for at least one season.

Sources

1. European Flood Awareness System (EFAS), overview incl. operators, lead time, users — https://en.wikipedia.org/wiki/European_Flood_Awareness_System
2. Google Flood Forecasting initiative — coverage, lead times — https://sites.research.google/floodforecasting/
3. Google Flood Forecasting API developer page (data licence, access) — https://developers.google.com/flood-forecasting
4. Floods Directive 2007/60/EC — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32007L0060
5. google-research/flood-forecasting (OpenHydroNet riverine flood forecasting) — https://github.com/google-research/flood-forecasting 5a. NeuralHydrology — https://github.com/neuralhydrology/neuralhydrology
6. Caravan community dataset — https://github.com/kratzert/Caravan
7. Deltares Delft-FEWS — https://oss.deltares.nl/web/delft-fews
8. Länderübergreifendes Hochwasserportal (LHP) — https://www.hochwasserzentralen.de/
9. Early Warnings for All (WMO/UN) — https://earlywarningsforall.org/site/early-warnings-all
10. ECMWF Anemoi core — https://github.com/ecmwf/anemoi-core
11. EU AI Act Annex III — https://artificialintelligenceact.eu/annex/3/
12. Nearing et al., "Global prediction of extreme floods in ungauged watersheds", Nature 2024 — https://www.nature.com/articles/s41586-024-07145-1 (not retrievable in this review)