flow | Devpost

💡 Inspiration

Every day, space agencies capture terabytes of free satellite imaging data. Constellations like the ESA's Sentinel-1 provide open-access radar imagery that can see through any storm, day or night. Yet, when a catastrophic flood hits, first responders on the ground are forced to navigate submerged streets using outdated, static maps. It’s unacceptable that this massive wealth of free space data sits untapped while emergency crews navigate blind. Our inspiration was to bridge this gap by taking the ocean of free satellite data floating above our heads and putting it directly into the hands of the people saving lives.

💫 What it does

First-Responder Logistics Over Water (Flow) transforms raw satellite imagery into a dynamic navigation system for emergency rescue teams. It pulls in free, real-time Synthetic Aperture Radar (SAR) data to identify active flood boundaries, piercing through thick storm clouds and darkness. By overlaying this fresh flood data onto standard city grids, the platform maps out safe, navigable water channels. This allows first responders to see exactly which streets are submerged, helping them bypass hidden underwater hazards and route directly to stranded civilians faster.

🛠️ How we built it

We built the core of First-Responder Logistics Over Water in Python, utilizing Django to serve our web frontend. To get real-time visibility into disaster zones, we integrated the Copernicus Data Space Ecosystem API to pull free, high-quality Synthetic Aperture Radar (SAR) GeoTIFFs. Once we had the raw space data, our custom geospatial pipeline — powered by Rasterio, GeoPandas, and Shapely — went to work. We used OSMnx to fetch driveable city grids from OpenStreetMap, specifically filtering out bridges and permanent lakes to prevent false flood positives. To make our routing hyper-accurate, we broke the roads down into 20-meter segments, buffered them, and analyzed the water pixel density on each chunk. We even implemented custom logic to filter out radar "speckle" (isolated false readings under 40 meters). Finally, we converted these scored segments into optimized GeoJSON, transforming raw Copernicus satellite data into a dynamic, real-time flood map served seamlessly through our web app.

⛈️ Challenges we ran into

We set out to build a "real-time" routing platform, but we quickly ran into the limitation of satellite revisit times. While the Copernicus Data Space Ecosystem provides incredible free data, SAR satellites only pass over a specific region once every few days. We designed our systems to fetch the latest satellite imaging data but also acknowledging that true minute-by-minute tracking would require tapping into commercial satellite constellations in the future. Since our project required marrying a heavy, complex data-science backend (GeoPandas, Rasterio, OSMnx) with a Django web frontend, our version control took a hit. We ran into nasty Git merge conflicts when trying to sync our individual components. It forced us to take a step back and modularize our code so the changes could be integrated without overwriting each other's work.

🙌 Accomplishments that we're proud of

We are incredibly proud to have built a functional prototype with genuine, life-saving potential. Knowing that First-Responder Logistics Over Water tackles a real-world climate problem and could one day help emergency crews reach stranded civilians faster gives this project a profound sense of purpose. Getting all these different data sources and APIs to actually play nice together was a big win for us. We took raw SAR satellite imagery from the Copernicus API, processed it using Python libraries like Rasterio and GeoPandas, and cross-referenced it with OpenStreetMap to filter out things like bridges. Wiring that entire geospatial pipeline up to a Django frontend was challenging, but getting satellite-level imagery to accurately map onto street-level roads is the technical achievement we're most proud of.

📝 What we learned

Our biggest takeaway was learning how to actually stitch together distinct, massive services. It’s one thing to use Django, OpenStreetMap, or Copernicus satellite data on their own, but getting them to talk to each other in a single pipeline was a massive learning curve. Beyond just wrangling the APIs, we learned a hard lesson in version control. Our architecture required marrying a heavy geospatial backend with a web frontend, integrating everyone's individual code changes was incredibly difficult. We were constantly running into Git merge conflicts and accidentally breaking each other's work. It forced us to take a step back, learn how to properly decouple our code, and actually manage our branches so we could build concurrently without stepping on each other's toes.

🧭 What's next for FLOW

The most obvious next step would to be able to get fast and reliable real time SAR satellite data so that, during real emergencies, first responders can rely on our software to navigate through flooded terrain.