Inspiration

During floods, knowing where water may have spread is only part of the problem. Emergency responders also need to understand which roads, bridges, and buildings may be affected and whether communities can still reach essential services such as hospitals.

We built FloodRescue to connect satellite-based flood mapping with infrastructure exposure and road-network accessibility analysis. Our goal is to turn geospatial data into actionable insights that can help responders identify locations requiring closer attention.

What it does

FloodRescue is a geospatial disaster-assessment prototype focused on Syapru Besi, Rasuwa, Nepal.

  • Detects potential flood extent: Analyses before-and-after Sentinel-1 radar imagery to identify changes that may indicate flooding.
  • Maps potentially exposed infrastructure: Overlays the flood extent with OpenStreetMap data to identify buildings, roads, and bridges that may intersect the affected area.
  • Analyses hospital accessibility: Simulates disruptions to flood-intersecting road segments and identifies settlements that may lose road-network connectivity to mapped hospitals.
  • Supports reference comparison: Provides a workflow for comparing the local flood map with an external flood-extent dataset over a common geographical area.

FloodRescue identifies potential risks, not confirmed infrastructure damage or actual road closures. Its results require independent verification before operational use.

How we built it

We combined satellite remote sensing with open-source geospatial data and network analysis.

  • Sentinel-1: Used radar imagery from before and after the event for flood-related change detection.
  • Python geospatial processing: Processed raster imagery, generated a candidate flood mask, and converted the results into geographic flood-extent data.
  • OpenStreetMap: Retrieved mapped buildings, roads, bridges, settlements, and hospitals for spatial analysis.
  • Geospatial overlay: Identified infrastructure features intersecting the candidate flood extent.
  • Network analysis: Represented roads as a graph and simulated the removal of potentially affected road segments to examine settlement connectivity to hospitals.
  • GeoJSON outputs: Stored analysis results in reusable geographic formats for mapping and further evaluation.
  • Spring Boot and React: Form the Java backend and web frontend of the project.

Challenges we ran into

One major challenge was transforming satellite imagery into a useful flood map. Radar backscatter changes do not always indicate flooding, so the detected extent must be treated as a candidate flood area rather than absolute ground truth.

Another challenge was processing large volumes of OpenStreetMap infrastructure data and connecting the spatial flood analysis to a road-network model.

We also learned that a road intersecting a flood polygon is not necessarily impassable. We therefore treat road removal as a simulated disruption scenario rather than a confirmed closure.

Finally, comparing our local study area with a much larger official reference map introduced a geographical mismatch. A fair evaluation requires clipping the reference data to the same study boundary and checking that the datasets represent a comparable event.

Accomplishments that we're proud of

  • Built a working geospatial workflow that connects satellite-based flood detection with infrastructure exposure analysis.
  • Generated geographic outputs for potentially affected buildings, roads, and bridges.
  • Extended flood mapping into a network-connectivity analysis focused on settlements and access to hospitals.
  • Integrated multiple data sources into one disaster-assessment approach.
  • Identified the limitations of automated flood detection and the importance of geographical consistency during validation.

Our main accomplishment is connecting where flooding may occur with which infrastructure and essential-service connections may be at risk.

What we learned

We learned that disaster mapping becomes more useful when flood extent is connected to infrastructure and accessibility rather than viewed in isolation.

We also gained practical experience with satellite raster processing, coordinate systems, GeoJSON, spatial intersections, OpenStreetMap data, and graph-based network analysis.

Most importantly, we learned to distinguish potential exposure from confirmed damage and simulated connectivity loss from actual road closures. Reliable disaster decision-support systems require transparent assumptions, suitable reference data, and independent validation.

What's next for FloodRescue

  • Validate the flood extent against an appropriately matched official reference dataset using the same geographical boundary.
  • Improve flood-detection thresholds and assess uncertainty in the generated flood mask.
  • Develop a clearer interactive dashboard for exploring flood extent, infrastructure exposure, and potentially disconnected settlements.
  • Incorporate verified road-closure information and more detailed travel-time analysis.
  • Add population exposure and alternative-route analysis to help prioritise locations for assessment.
  • Generate concise situation reports in English and Nepali using verified analysis outputs.
  • Explore additional satellite observations and more frequent data updates while clearly communicating satellite revisit and processing limitations.

Our long-term goal is to make FloodRescue a practical, transparent decision-support tool that helps disaster-response teams identify potentially vulnerable infrastructure and communities that may need further investigation.

Built With

Share this project:

Updates

Submission history