DANGER MARK+: A Flood Map Is Not an Evacuation Plan

Turning CWC river data, terrain, population and roads into evacuation plans, backup routes and Hindi/English voice alerts, plus what broke on AWS.

Hrishita Singh

Published Oct 11, 2026

Last modified Oct 11, 2026

TL;DR: DANGER MARK+ turns flood data into evacuation decisions. It shows what the Yamuna is doing now using Central Water Commission observations, then simulates an escalation: who could be exposed, which roads may fail, where people should go, and what to do when no independent backup route exists. It's a Delhi–Yamuna pilot built by two students in one weekend, with English/Hindi support and spoken advisories, deployed on AWS.
﻿
Both of us love Project Hail Mary, and not really because of the space part. Every time the protagonist thinks he understands the problem, reality adds another constraint, and the response is always the same: figure out what is actually true, then solve the next problem. That turned out to describe building a flood-response system. At one point we had an 8.1 MB GeoJSON file, a Lambda function that refused to return more than 6 MB, and an AWS account that seemed to have turned into a different AWS account.
But the engineering was never the point. The problem it was built for was.
﻿
﻿
Why this is an environmental problemIn July 2023, after heavy rain in the river's upper catchment, the Yamuna at Delhi reached 208.66 metres, surpassing the previous record of 207.49 metres set in 1978. That is more than three metres above the 205.33 metre danger mark at the Old Railway Bridge, the threshold our project is named after. More than 25,000 people were evacuated ( Tribune ,  WION ).
The data to watch a flood develop already exists: river gauges, satellites, elevation models, population grids, road networks. What's missing is the step after the data. Which areas are most exposed? Which roads will fail? Where do people go, and who moves first? Environmental intelligence is only useful when it can become action. That's where many flood tools stop, and it's what DANGER MARK+ is built around.
What it does: two questions, kept separateLive Conditions: what is happening right now? The app opens here, with recent Central Water Commission observations for Delhi Railway Bridge, Dhansa and Mathura, shown against each station's warning and danger levels. We deliberately don't turn a gauge reading into an inundation polygon, because the gauge and our terrain model use different reference systems and we have no defensible calibration between them. The CWC source was blocked by CORS in the browser and timed out from Lambda, so a periodic ingestion job publishes a validated snapshot to S3, served through CloudFront. It never presents stale data as live.
Evacuation Simulation: if this escalates, what do we do? An illustrative flood scenario runs through a consequence-to-action pipeline: flood extent → population exposure → locality impact → road disruption → accessibility → candidate destination → primary route → independent backup route → priority → operational advisory. An operator can drill down to a single locality. The goal isn't a red polygon. It's: "This locality has high exposure. These roads are affected. This is the preferred route. Here is an independent backup. Capacity is not verified. Prioritize this area first."
Unknown stays unknownOne rule shaped the whole product. If we don't have a verified capacity for a destination, the interface says Capacity unknown. If the data can't defend an evacuation deadline, it says Deadline unavailable. If the router can't find a genuinely independent alternative, it says Backup unavailable. The dashboard looks slightly less magical and is far more trustworthy, because in an emergency false certainty can be worse than visible uncertainty.
The Delhi–Yamuna pilotThe real data was not neat. Coordinate systems and resolutions disagreed, and a resampled population raster can look detailed without containing any extra population information. A flood image isn't a classified flood mask, a mapped facility isn't a verified shelter, and a road on a map isn't automatically a safe route. The most important decision we made wasn't an algorithm. It was refusing to pretend these differences didn't exist.
Our illustrative scenario identified roughly 72,900 potentially exposed people and hundreds of candidate road-edge impacts. The planner generated primary routes for 12 localities. For 8, it found an independent backup. For 4, it didn't, and those display Backup unavailable. It's one of our favorite parts of the app, because sometimes the useful answer is not a prettier route. Sometimes it's: there isn't one.
To keep backups honest, the router removes the vulnerable dependencies of the primary path, including opposite-direction edges and mapped structures that likely represent the same physical crossing, and then recomputes. A backup that fails at the same bridge is not a backup.
﻿
From decision to alertEach recommendation becomes an operational advisory that authorities can preview as a written message, while Amazon Polly speaks the same information aloud. The whole interface switches between English and Hindi (EN | हि), because real emergencies don't happen in front of a big monitor in English. To be clear about the boundary: the prototype generates and previews advisories. It does not send SMS to citizens.
(Image 4: advisory preview with the Play Advisory button, ideally in Hindi)
﻿
Where AWS fought backOur plan was CloudFront + S3 → ECS/Fargate → ECR, but our project environment lacked the EC2/VPC access that path needed. We pivoted to API Gateway → Lambda running FastAPI and the evacuation engine from an ECR container image. Then the interesting failures started.
The 8 MB response. One road-impact GeoJSON response was 8,159,736 bytes, over Lambda's buffered response limit. Instead of deleting data, we tested gzip, and it fit. Then we decompressed the deployed response and compared it with the saved analysis byte for byte. No silently dropped roads.
The two-account mystery. ECR worked, but Lambda returned  SubscriptionRequiredException . IAM, region and credentials all looked right. Eventually we realized AWS's project-based login had put us in a separate project account. After authenticating into the correct one, we ran  aws lambda list-functions  and got:
JSON
{
  "Functions": []
}
One of the most beautiful empty lists we saw all weekend.
The cold start. The geospatial stack makes a first Lambda invocation take around 32 seconds, which can exceed API Gateway's practical limit. Warm requests are fast. A production version would cut initialization work, keep environments warm, and separate heavy analysis from the low-latency API. We'd rather document the limit than hide it.
No Kubernetes, no microservice sprawl, no database the prototype didn't need. Just infrastructure serving the problem.
What this is, and what it isn'tDANGER MARK+ is a working end-to-end prototype of environmental data becoming evacuation decision support. It is not a certified life-safety system, an official forecast, or a reconstruction of the 2023 flood, which is context for why the problem matters and not what the pilot replays. It doesn't claim a live gauge value maps onto our modeled flood extent, and its candidate destinations are not authority-verified shelters. Destinations and routes would need local validation before any operational use.
What's nextLive gauges, Hindi and voice are done. The harder problems are verified shelter data, a defensible gauge-to-inundation calibration, predicting when individual roads fail, production-grade data ingestion, and a field-ready interface connected to validated emergency communication systems.
Built withAWS: CloudFront · S3 · API Gateway · Lambda · ECR · CloudWatch · Polly
Frontend: React · TypeScript · Vite · Leaflet
Backend: Python · FastAPI · raster/vector geospatial processing · graph-based routing
Data: Copernicus GLO-30 DEM · WorldPop · OpenStreetMap · NRSC flood evidence · Central Water Commission
Try itLive app:  https://dq0ijb66nf6yb.cloudfront.net/  (If the first load is slow, wait a moment and refresh once; it's a serverless cold start.)
Source code:  https://github.com/Hrishita456/BharatBuilds 
Built by Hrishita Singh and Ayush Jha for Environmental Hacks — Bharat Builds Tour 2026.
Our Hail Mary was never the flood mapSatellites tell us where water might be. Terrain tells us where it can move. Population data tells us who may be exposed. Road networks tell us what connectivity remains. River gauges tell us what the river is doing now. But someone still has to combine those facts into what should we do next?
If DANGER MARK+ can eventually help make one evacuation decision clearer, earlier or safer, then every oversized GeoJSON and sleepless hour was worth it. The question was never can we build another flood map? It was can we build something that helps people get out of the way of the water?