Flood Scope

Inspiration

Disaster response and emergency management frequently suffer from fragmented information silos. During flood emergencies, authorities and analysts typically need to juggle multiple disparate tools just to understand the scope of a crisis: satellite imagery catalogues, terrain elevation models, and infrastructure maps are rarely found under a single roof. The vision behind FloodScope was inspired by the need to bridge this gap between raw geospatial data and actionable disaster-response intelligence. Rather than treating flood assessment as an isolated mapping task, the goal was to build a cohesive prototype that connects satellite-scene discovery, radar change screening, infrastructure exposure, road accessibility, and terrain tracing into a unified analytical environment.

What it does

FloodScope is a geospatial dashboard prototype that brings several flood-related analysis functions into one unified interface. Specifically, it: Discovers Sentinel-1 and Sentinel-2 satellite scenes to retrieve scene metadata. Identifies candidate surface changes using prepared radar imagery and threshold-based change analysis. Estimates infrastructure exposure by calculating spatial intersections between user-provided flood polygons and mapped geographic features. Explores road connectivity and terrain-derived drainage paths using network analysis and digital elevation models (DEM). Compares prediction polygons with independent reference data (such as the EMSR927 Trishuli flood dataset) using Intersection over Union (IoU) metrics. Generates PDF reports to document analytical findings, inputs, and limitations.

How we built it

FloodScope was engineered as a comprehensive geospatial dashboard prototype combining a responsive frontend interface with a robust Python backend. Backend & API: Powered by FastAPI to serve clean endpoints handling imagery discovery, geographic analysis, road accessibility, terrain tracing, polygon validation, and report generation. Geospatial Processing Stack: Leveraged industry-standard Python libraries for spatial computation and raster/vector handling, including Rasterio, Shapely, NumPy, NetworkX, SciPy, and PyProj. Data Integration & Services: Integrated external services such as the Copernicus Data Space Ecosystem for satellite-scene metadata and the ohsome historical OpenStreetMap analysis service. Core Data Sources: Utilized Sentinel-1 SAR radar imagery, Sentinel-2 optical imagery, Copernicus DEM elevation data, OpenStreetMap networks, and EMSR927 reference data.

Challenges we ran into

Building a geospatial platform introduces unique technical and methodological hurdles:Data Alignment & Preprocessing Complexity: Ensuring that Sentinel-1 Synthetic Aperture Radar (SAR) scenes had compatible acquisition geometry required rigorous calibration, terrain-correction, co-registration, and spatial alignment before any comparison could take place. Distinguishing Change from Flooding: Threshold-based radar screening identifies areas of backscatter reduction, but these changes are not inherently guaranteed to be caused by flooding and require independent verification. Separating Prediction from Validation: Maintaining strict methodological integrity required ensuring that reference flood maps and post-event data were strictly reserved for independent validation and never leaked into the prediction generation phase. Scope Definition: Balancing the ambition of a full-scale automated mapping pipeline with the realities of a prototype meant carefully defining boundaries—acknowledging that the current version focuses on structural organisation and discovery rather than trained AI damage classification or hydraulic wave propagation.

Accomplishments that we're proud of

Unified Analytical Workflow: Successfully integrated satellite-scene discovery, radar change screening, infrastructure exposure analysis, road-network assessment, terrain exploration, polygon comparison, and reporting into a common geospatial interface. Rigorous Methodological Separation: Maintained clean architectural boundaries where reference maps and post-event edits are strictly reserved for validation rather than biasing prediction generation. Transparent Prototype Framing: Explicitly documented system limitations, uncertainties, and assumptions, ensuring the tool is positioned as an exploratory prototype rather than an unverified operational system.

What we learned

Unified Workflows Matter: Bringing disparate spatial tools into a single dashboard dramatically streamlines the exploratory workflow, allowing users to move fluidly from satellite scene discovery down to infrastructure exposure and PDF report generation. The Importance of Rigorous Validation: Quantitatively measuring spatial overlap using metrics like Intersection over Union ($\text{IoU}$) highlighted how crucial independent reference data is for grounding computational models in reality:$$\text{IoU} = \frac{\text{Area of Overlap}}{\text{Area of Union}} = \frac{P \cap R}{P \cup R}$$ where $P$ represents the predicted flood polygon and $R$ represents the reference dataset. Transparency in Limitations: Developing FloodScope reinforced the principle that scientific prototypes must clearly document their assumptions, algorithmic limitations, and sources of uncertainty rather than overstating unverified results.

What's next for Flood Scope

Automated Satellite Preprocessing: Moving toward automated image acquisition, calibration, and terrain-correction directly within the pipeline. Improved Candidate Classification: Enhancing flood-candidate classification and uncertainty estimation to better distinguish actual flood events from other surface changes. Independent Validation (EMSR927): Completing full quantitative evaluation using the Trishuli flood event and EMSR927 reference data to establish actual system performance and calculate empirical IoU scores. Advanced Machine Learning Integration: Exploring dedicated machine-learning models using permitted training data and independent testing for enhanced damage and flood boundary detection.