Floodintel

Inspiration

A flood map can show where water appeared, but it does not immediately answer which roads are exposed or which communities might lose access to a hospital.

I built FloodIntel around that gap: connecting satellite flood evidence to mapped infrastructure and access consequences, while keeping uncertainty visible.

What it does

FloodIntel takes a place or bounding box and a flood date, then:

• Finds before-and-after Sentinel-1 radar images from the same orbit.
• Estimates newly detected water, separating it from pre-existing water.
• Checks overlap with mapped roads, bridges, and buildings.
• Compares baseline road access with scenarios where potentially inundated links are removed.
• Generates an interactive dashboard, a situation report, and a portable incident package.

Selecting a feature reveals its supporting evidence, access status, and limitations. Radar-change debris candidates are shown separately and explicitly require inspection.

How we built it

I built a Python command-line pipeline that produces static HTML reports.

The water-segmentation model uses a U-Net with a ResNet34 encoder, trained on Sentinel-1 VV/VH imagery from Sen1Floods11. Inference runs on both satellite images, and pre-event water is subtracted to estimate new water.

Copernicus elevation data provides terrain checks. A date-locked, pre-event OpenStreetMap snapshot supplies infrastructure and the road network for graph-based access analysis.

I used Claude for planning and review, and OpenAI Codex to generate most implementation code and tests. I ran the pipeline and checked its outputs. The application itself makes no LLM calls.

Challenges we ran into

The hardest challenge was distinguishing missing information from actual flood effects.

A settlement without a mapped hospital route before the flood cannot honestly be labelled cut off afterward. In the Trishuli run, 54 settlements were uncertain because baseline routes were missing; none were classified as cut off.

The Trishuli case also exposed under-detection. Differences between training imagery and processed satellite inputs, terrain filtering, and the event’s debris-heavy characteristics need investigation. Their individual effects remain unverified.

Matching satellite orbits, checking OSM timestamps, and preserving provenance were also essential to making results traceable.

Accomplishments that we're proud of

I connected satellite acquisition, model inference, infrastructure checks, access analysis, and reporting into one reproducible workflow.

The repository includes 415 automated tests covering software behaviour such as timestamp verification, graph logic, uncertainty handling, and report traceability.

Most importantly, the report exposes weak evidence and data gaps instead of presenting every output as a confirmed finding.

What we learned

Water-segmentation performance does not establish reliable flood-change detection or access analysis.

I learned to separate exposure from structural damage, missing map data from isolation, and software correctness from real-world accuracy. Those distinctions shaped both the analysis and the interface.

What's next for FloodIntel

The priority is independent validation against confirmed flood extents and real access disruptions.

Next steps include investigating the imagery-processing gap, improving pre/post-event training, calibrating confidence, and incorporating road direction and vehicle restrictions into routing.

FloodIntel remains an educational prototype. Operational use would require substantially stronger validation.

Built With

• claude
• codex
• copernicus-dem
• github
• html
• hugging-face
• kaggle
• microsoft-planetary-computer
• openai
• openstreetmap
• python
• pytorch
• resnet34
• segmentation-models-pytorch
• sen1floods11
• sentinel-1
• u-net