Inspiration

On 26 August 2026 a glacier collapse in northern Nepal sent ice, mud and debris down the Bhote Koshi–Trishuli corridor. Roads, bridges and phone lines failed, and ground sensors were swept away. Rescuers needed to know three things fast: where the damage is, what was hit, and which villages are cut off. Free Sentinel satellites cover every Himalayan valley, and radar sees through monsoon cloud. We wanted to turn that raw data into answers quickly enough to matter.

What it does

FloodScope takes an area and a flood date and answers three questions:

  1. Where did the flood hit? It maps flooded and debris-covered ground by comparing Sentinel-1 radar images from before and after the event, fusing Sentinel-2 optical water detection when the sky is clear.
  2. What was damaged? It overlays pre-event OpenStreetMap buildings, roads and bridges on the flood mask and flags which were hit.
  3. Who is cut off? It removes flooded roads and bridges from the road network and lists settlements with no remaining route to a town or hospital.

A Streamlit map dashboard shows all layers, and the system writes a one-page situation report in English and Nepali. Every number in the report is read from the map outputs, never generated by a language model.

How we built it

  • Data: Sentinel-1 and Sentinel-2 from the Copernicus Data Space, Copernicus DEM, and a pre-event OpenStreetMap snapshot (27 July 2026) via the ohsome API.
  • Flood mapping: same-orbit-track SAR change detection (log-ratio, Otsu threshold, speckle filtering), Sentinel-2 NDWI with cloud masking, and a DEM slope filter to remove steep false positives.
  • AI component: a U-Net (ResNet34) flood segmentation model trained on Kuro Siwo and tested on held-out scenes. Held-out IoU: [FILL].
  • Damage and cut-off analysis: GeoPandas spatial intersection, then a NetworkX road graph connectivity test.
  • Situation-report copilot: templated English and Nepali reports and question answering that look up numbers from facts.json.
  • Validation: we compared the Trishuli case study with Copernicus EMS activation EMSR927. IoU [FILL], precision [FILL], recall [FILL]. EMSR927 was used only to check results, never as an input.

Challenges

  • Radar images from different orbit tracks cannot be compared pixel by pixel, so the system only pairs same-track images about 12 days apart.
  • Steep valleys cause radar shadow and layover, which produce false water detections that the DEM filter only partly removes.
  • OpenStreetMap is incomplete in remote valleys, which limits the damage and cut-off results.

What we learned

Trustworthy disaster tooling means keeping the language model away from the numbers. Every figure has to trace back to a map layer.

Limitations

Sentinel satellites revisit an area only every few days, so FloodScope cannot warn of a glacier collapse ahead of time. Flooded roads are treated as impassable, which is not verified on the ground. Detection thresholds need tuning per scene. This is an educational prototype, not an operational tool, and no images of victims are used.

What's next

Flow-path tracing from any upstream point using the DEM, better debris detection, and field validation.

Data and attribution

Contains modified Copernicus Sentinel data 2026. Produced using Copernicus WorldDEM-30 © DLR e.V. 2010–2014 and © Airbus Defence and Space GmbH 2014–2018 provided under COPERNICUS by the European Union and ESA; all rights reserved. © OpenStreetMap contributors. Training data: Bountos et al., 2024 (Kuro Siwo). Reference check: European Union, Copernicus Emergency Management Service data (EMSR927).

Built With

Share this project:

Updates

Submission history