Beyond Rainfall: How We Built NIRNAY, a Traffic-Aware Flood Response Engine for Delhi
Rainfall alone can’t tell you where to send a pump. See how NIRNAY adds live traffic, hospital corridors and a small neural network to rank Delhi’s 15 flood hotspots, then optimises pump dispatch before the storm arrives.
The problem
Every monsoon, Delhi’s low-lying underpasses fill within 30 to 45 minutes. Minto Bridge, Zakhira, Pul Prahladpur and Tilak Bridge close, buses stall, and ambulances heading to LNJP and AIIMS get stuck in the gridlock that follows.
The usual response is reactive. Mobile pumps are dispatched after the water has already accumulated, by which time the traffic is stranded. We asked a simple question: what if a control-room engineer could test a rainfall scenario before the storm arrives and know where every pump should go?
What NIRNAY does
NIRNAY (“decision” in Hindi) is a pre-storm scenario simulation and resource allocation engine for 15 critical Delhi hotspots. An operator sets a rainfall scenario, or loads a live forecast or a historical replay. NIRNAY then:
- Simulates time-to-alert and time-to-closure for every hotspot in under 5 ms.
- Allocates a limited fleet of mobile pumps and crews to minimize total vehicle-hours lost.
- Quantifies uncertainty with 200 Monte Carlo runs and reports P10, P50 and P90 bands.
- Lets operators question the plan in plain English through an AWS-powered agent.
For example, at a simulated 100 mm deluge, the model puts Minto Bridge at 0.53 m depth. Time to alert is 1.5 hours, time to closure is 1.6 hours, and the closure lasts 2.8 hours. At that scenario the map shows 6 hotspots closed, 4 on alert and 5 clear.
Architecture
- Frontend: Next.js and React with Tailwind CSS and Leaflet maps, hosted on AWS Amplify Hosting with CI/CD from GitHub.
- Backend: FastAPI (Python) serving the hydrology engine, optimizer, ANN, and weather endpoints.
- Agent: AWS Strands Agents SDK with Amazon Bedrock (Claude 3.5 Sonnet), grounded in tool outputs from the engine.
- Serverless and data layer: AWS Lambda and SAM for deployment (
infra/sam-template.yaml), with DynamoDB, S3, and SQLite for scenarios and data.
- Open data: Copernicus DEM GLO-30 (via AWS Open Data), IMD archives, OpenStreetMap, and Open-Meteo.
The hydrology engine
Each hotspot is modeled as a sunken underpass with a catchment. We use textbook methods: the Rational Method for runoff and an Euler step through a storage balance, with inflow from rainfall and outflow from drainage and pump capacity. Copernicus 30 m terrain elevations give each underpass its geometry. Depth thresholds define the status:
- Clear: depth below 0.15 m
- Alert: 0.15 to 0.20 m
- Closed: above 0.20 m (submerged)
The result is time-to-alert, time-to-closure, and closure duration for each hotspot. The whole 15-hotspot simulation runs in under 5 ms, which is what makes interactive what-if exploration possible.
The optimiser
Given N mobile pumps and M crews, the question is where each one should go to minimize the total vehicle-hours lost. This is a resource allocation problem, so we solve it with dynamic programming in the style of a knapsack. Each hotspot has a loss curve that depends on how many pumps it gets, and the solver finds the allocation with the lowest total loss.
Because every input is uncertain, we then run 200 Monte Carlo iterations, varying runoff by plus or minus 15% and pump efficiency by plus or minus 20%. This gives P10, P50 and P90 bands on the outcome and a recommendation stability score. In the July replay, the recommended allocation held in 88% of runs, and the plan saved over 98,000 vehicle-hours.
Why rainfall alone is the wrong signal
Early on, we ranked hotspots mostly by hydrological hazard. That fails in a specific, common case. Suppose Minto Bridge sees 75 mm and Zakhira sees 80 mm. A rainfall-based system sends the pump to Zakhira. But Minto carries roughly 4,500 vehicles per hour, runs at 88% congestion in our scenario, and sits on the route to LNJP Hospital. If Minto chokes, New Delhi gridlocks.
Risk is hazard times exposure, and rainfall measures only the hazard.
The traffic-aware ANN
To capture exposure, we trained a two-layer feedforward neural network (a multilayer perceptron) that scores each hotspot from 0 to 100.
- Inputs (4): micro-rainfall in mm, live route traffic congestion in %, catchment storage, and a hospital-corridor priority flag.
- Hidden layer: 8 neurons with ReLU activation.
- Output: one sigmoid unit, scaled to a priority score.
Sorting hotspots by score produces a step-by-step dispatch sequence:
- Minto Bridge: 3 pumps, 88% congestion, score 99.7
- South Extension Ring Road: 3 pumps, 88% congestion, score 98.2
- Dhaula Kuan: 2 pumps, 85% congestion, score 91.4
- Zakhira Flyover: 2 pumps, 55% congestion, score 86.1
Zakhira ranks below Minto despite higher rainfall because far fewer vehicles depend on it and it has no hospital corridor. The model is exposed through
POST /api/v1/ml/ann-predict .
Dataset and training
The first question any judge asks about a model is where the data came from, so we built the dataset deliberately. It has 1,350 records drawn from four sources:
- Delhi PWD drainage baselines
- Delhi Traffic Police volume counts
- IMD historical storms: July 2026, May 2025, July 2023 and September 2021
- Health department hospital corridors
Training is a standalone script,
scripts/train_ann_traffic_model.py . It runs 600 epochs of back-propagation, prints the MSE loss as it converges, and reports a validation R² above 0.94.One caveat. The training labels come from a priority formula we defined across these four pillars, so the network learns to approximate that policy and generalize it smoothly. It does not discover ground truth about floods. We think saying so plainly is better than overselling the model.
Traffic exposure in the loss function
Each hotspot now carries attributes grounded in Delhi Traffic Police audits: traffic volume in vehicles per hour (for example 4,500 at Minto Bridge, 5,200 on the Ring Road, 4,200 at Zakhira), a 35 to 45 minute detour penalty, a traffic density class, and a hospital-route flag with the hospital name (AIIMS, LNJP, Safdarjung, ESI). The optimizer’s loss function is:
Vehicle-hours lost = (closure duration / 60) x traffic volume (vph) x (detour delay / 60)
The map popups, sidebar cards and hotspot grid all show this live traffic data.
Live micro-weather
Initially, we used a single forecast point at city center for the whole city, which is wrong when storms are localised. We replaced it with Open-Meteo forecasts fetched at the exact coordinates of all 15 hotspots (
GET /api/v1/weather/forecast ). A modal in the UI shows the forecast and has a one-click button that loads it as a storm scenario into the simulator.Resilience: the fail-safe engine
During testing, we found that the Recommender Modal sat empty whenever the backend was unreachable, which is the worst possible failure for a decision tool. We added a calibrated local engine that runs in the browser. If the API is offline or slow, the user still gets the full ANN dispatch sequence, vehicle-hours saved cards and Monte Carlo bands. A status badge distinguishes “Live FastAPI” from “Calibrated Engine”, so operators always know the source of the numbers.
Explainability with an AWS agent
Operators can ask questions in natural language, such as “Why did NIRNAY assign 3 pumps to Minto Bridge before Zakhira?” The AWS Strands agent calls the engine’s tools and answers from their actual outputs, so the explanation is grounded in the computed numbers instead of generated from nothing.
Lessons learned
- Exposure matters as much as hazard. Adding traffic and hospital data changed the dispatch order more than any tuning of the hydrology.
- Build the fallback early. A decision tool that goes blank offline is worse than one that degrades gracefully.
- Show your limits. The claims table made our demo more credible, not less.
What’s next
- Replace modeled traffic with live feeds
- Retrain the ANN on observed closure and dispatch outcomes
- Model interactions between neighboring hotspots
- Extend beyond the first 15 hotspots
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article