FloodLens AI — Mapping Flood Damage from Space
FloodLens AI turns satellite imagery into an actionable disaster map.
Instead of stopping at “where did the landscape change?”, FloodLens connects space-based evidence to infrastructure and accessibility:
Sentinel-1A before/after imagery → VV/VH change detection → candidate flood/change extent → roads & bridges → road-network analysis → potentially isolated places → evidence-backed AI brief
The problem
During major floods, responders need more than a satellite image. They need to know:
- Where is the strongest candidate flood/change signal?
- Which roads and bridges may be affected?
- Which mapped places could lose road access?
- What evidence supports the conclusion?
- What is still uncertain?
FloodLens is designed to answer those questions from a reproducible geospatial pipeline.
Live demonstration
Live app: https://floodlens-ai.vercel.app
The deployed demonstration analyzes a real historical flood event around Lokoja, Kogi State, Nigeria (2022).
The production dataset uses compatible Sentinel-1A acquisitions from:
- Before: 19 September 2022
- After: 13 October 2022
- Observation gap: 24 days
- Relative orbit: 30
- Polarizations: VV + VH
- Processing grid: 512 × 512 at approximately 10 m
The application currently reports a 10.11 km² candidate flood/change extent, 60 potentially affected road segments, 2 potentially affected bridges, and 1 mapped OSM place that may be isolated under the modeled road-network scenario.
These are intentionally described as candidate/potential impacts, not ground-truth claims of flooding or structural failure.
How it works
1. Find compatible satellite observations
FloodLens searches the Copernicus Data Space catalogue for Sentinel-1 GRD scenes matching the area, acquisition mode, polarization and orbit characteristics needed for a meaningful before/after comparison.
2. Process Sentinel-1 radar evidence
VV and VH radar measurements are retrieved through the Sentinel Hub Processing API.
FloodLens computes change in radar backscatter between the two observations. Pixels showing sufficiently strong decreases in both polarizations become candidate flood/change pixels.
The thresholds are configurable and exposed as part of the analysis provenance.
3. Clean the candidate change mask
Small connected components are removed to reduce isolated speckle and produce a more useful spatial candidate layer.
The resulting candidate extent is exported as geospatial data and displayed directly on the map.
4. Connect the satellite signal to infrastructure
OpenStreetMap data provides the road, bridge and mapped-place context.
FloodLens overlays the candidate change layer against roads and bridges to identify potentially affected infrastructure.
5. Go beyond pixel detection with network analysis
This is a key part of FloodLens.
The road graph preserves the full OSM node sequence along road ways, including intermediate intersections. Potentially affected road segments are removed from a copy of the network.
For each mapped place, FloodLens tests whether a route remains to the surrounding road-network boundary.
This converts a satellite change signal into a practical accessibility question:
“Could this place still have a modeled road connection out of the affected area?”
The result is presented as potential isolation, not confirmed real-world isolation.
6. Generate an evidence brief
An optional Gemini-powered explanation layer summarizes the computed measurements and separates:
- satellite observations,
- geospatial overlays,
- network inference,
- and uncertainty.
Gemini is not used as the core flood detector. The underlying candidate mask and connectivity result come from the deterministic geospatial pipeline.
If the Gemini API is unavailable, FloodLens uses a deterministic evidence summary so the demonstration remains functional.
Why this is different
Many flood demos stop at an image segmentation result.
FloodLens asks what that result means operationally.
The key chain is:
Space → Change → Infrastructure → Connectivity → Human impact
That makes the system useful for disaster-response triage, infrastructure monitoring and prioritizing areas for field verification.
Responsible interpretation
Sentinel-1 backscatter change can have multiple causes. A decrease in radar backscatter is not, by itself, proof of standing water, building destruction or road failure.
OSM coverage can also be incomplete or outdated.
For that reason FloodLens uses language such as:
- candidate flood/change
- potentially affected road
- potentially affected bridge
- potentially isolated place
The system is intended to prioritize investigation and response, not replace field verification.
Technical architecture
Frontend
- Next.js
- React
- TypeScript
- MapLibre
- Tailwind CSS
Geospatial / analysis
- Python
- Rasterio
- GeoPandas
- Shapely
- NetworkX
- NumPy
Satellite
- Copernicus Data Space
- Sentinel-1A GRD
- Sentinel Hub Processing API
- STAC metadata
Infrastructure data
- OpenStreetMap
- Overpass API
AI
- Google Gemini as an evidence-reasoning/explanation layer
Deployment / automation
- GitHub Actions
- Vercel
Reproducibility
The real-data analysis is automated in GitHub Actions. The workflow installs the geospatial dependencies, runs the test suite, authenticates to Copernicus using GitHub Secrets, retrieves compatible Sentinel-1 scenes, processes the imagery, queries OSM, performs network analysis, generates the web dataset and persists the resulting evidence for the deployed application.
The public repository contains the implementation and documentation:
https://github.com/peterkehinde673/FloodLens-AI
Impact
Flood response is time-sensitive. A system that can rapidly transform satellite observations into an interpretable map of candidate impact and possible access loss can help responders decide where human verification may be most valuable.
FloodLens is deliberately designed as an evidence pipeline rather than a black-box prediction: every major conclusion can be traced back to satellite change, geospatial overlap or network analysis.
Future work
The next research steps include:
- U-Net or other learned segmentation for stronger flood-boundary discrimination
- multi-date Sentinel-1 time series rather than a single before/after pair
- Sentinel-2 optical evidence when cloud conditions permit
- building-level exposure analysis
- richer road criticality and alternative-route scoring
- improved place-name disambiguation
- field-verified validation datasets
- uncertainty calibration against known flood extents
Built for Multimodal AI Hackathon 2026 — Track B
FloodLens demonstrates how multimodal reasoning can sit on top of real satellite, geospatial and network evidence to produce an actionable disaster-intelligence workflow.
Built With
- copernicus-data-space
- geopandas
- github-actions
- google-gemini
- maplibre
- networkx
- next.js
- openstreetmap
- python
- rasterio
- react
- sentinel-1
- typescript
- vercel