GeoRescue AI — Satellite-Powered Flood Intelligence

GeoRescue AI uses satellite imagery and AI to map potential flood damage, identify exposed infrastructure, and flag settlements at risk of losing road access to help responders prioritize relief.

Comment

Inspiration

In August 2026, a glacial lake outburst flood tore through the Trishuli corridor in Nepal. Villages were cut off. Roads disappeared. Rescue teams had no clear picture of where to go first.

Satellite data exists. Sentinel-1 and Sentinel-2 image Nepal every few days. But nobody turns that data into something a rescuer can act on within hours.

That's what I wanted to build. Not another research paper. Something a relief coordinator could open on a phone and use to decide which village to check first.

What It Does

GeoRescue AI answers three questions after a flood:

Where did the flood hit? — Compares Sentinel-1 radar before and after the event.

What was affected? — Counts buildings, roads, and bridges inside the flood areas using pre-event OpenStreetMap.

Who is cut off? — Builds a road network and finds villages that may have lost road access to a hospital or town.

Every number is computed in Python. An AI copilot writes a one-page situation report and answers rescuer questions — grounded strictly on the evidence, never inventing a number.

How I Built It

Data access — Downloads Sentinel-1 from Copernicus, pre-event OSM from ohsome, DEM tiles from AWS.

Processing — Terrain correction with Sarsen, alignment, slope masking, and backscatter ratio change detection to map candidate flood extent.

Analysis — Intersects flood polygons with OSM buildings, roads, and bridges. Builds a NetworkX road graph. Finds settlements that lose access under a flood-disruption scenario.

Reporting — Builds an evidence object with 12 computed metrics. Generates a deterministic situation report. Optionally uses Gemini for an LLM-written narrative, with every number validated against the evidence.

Dashboard — Ten sections: overview, map, flood mapping, infrastructure, access disruption, situation report, copilot, provenance, export.

If Gemini is unavailable, the system falls back to a deterministic report. It never breaks.

The AI Component

Every number the LLM produces is checked against the evidence. If one number doesn't match, the entire response is rejected and a rule-based answer is used instead.

A rescuer cannot act on a hallucinated number. The validator makes the AI trustworthy.

The copilot also produces output in both English and Nepali.

Challenges

Monsoon clouds. Sentinel-2 was completely blocked. I relied entirely on Sentinel-1 radar, which sees through clouds.

OSM coverage. OpenStreetMap is incomplete in remote Nepal. The system reports honestly when a layer is empty instead of pretending it has data.

Evaluation honesty. My Syapru Besi result had a low overlap with EMSR927 — IoU 0.007. The reason is that EMSR927 maps landslides, not floods. I reported the low number honestly instead of tuning the algorithm to match it.

Deployment. Full analysis downloads 2.4 GB. Free Streamlit tier has no persistent storage. The deployed dashboard shows a pre-computed case study. The full pipeline runs locally.

What I Learned

Honest AI beats impressive AI. A system that says "I don't know" is more useful than one that guesses.

Grounding matters more than model size. Gemini with strict evidence grounding beats a larger model without it.

A validator is a feature. Rejecting unsupported numbers made the copilot trustworthy.

What's Next

Flood-path tracing (optional bonus, not implemented).

A trained flood-segmentation model using Kuro Siwo or Sen1Floods11.

Live re-run from the cloud with persistent storage.

Built With

  • copernicus-dem-30m
  • folium
  • geopandas
  • google-gemini
  • networkx
  • nominatim
  • openstreetmap-(ohsome-api)
  • pydantic
  • python
  • rasterio
  • sarsen
  • sentinel-1
  • sentinel-2
  • streamlit
Share this project:

Updates

Submission history