What Does the Fastest Route Miss When It Rains? Building DrainTwin for Central Delhi
A study prototype that connects rainfall scenarios, waterlogging hotspots, route comparison, and explanations through AWS’s Strands Agents SDK.
Imagine choosing a route across Delhi just as the rain starts.
One option takes fewer minutes. Another follows different roads. Your map can compare their estimated driving times, but what would help you compare their exposure to places where water might collect?
A rainfall forecast gives you an amount. A road map gives you a route. The missing connection is what that rain could mean across the landscape between your starting point and destination.
That question shaped DrainTwin, which I built for Environmental Hacks, part of the WeMakeDevs × AWS Bharat Builds Tour.
DrainTwin is a study prototype for the Central Delhi region. You choose a rainfall scenario, explore modelled waterlogging susceptibility, inspect hotspots, and compare driving routes against the same scenario.
It is an exploration tool. The map shows relative susceptibility, not confirmed flooding or road closures. That distinction guided the way I built it.
Start with a journey
The easiest way to understand DrainTwin is to follow a journey through it.
Choose a starting point and destination on the map. Set the rainfall amount, or load a forecast to supply a 24-hour scenario. Then compare three preferences:
- Fastest: prioritise estimated driving time.
- Balance time & risk: consider both time and modelled exposure.
- Lower risk: prioritise lower modelled exposure within an extra-time budget.
The route planner puts travel time and modelled exposure beside each other so the trade-off is visible.
The extra-time budget matters. A person willing to consider a five-minute detour is asking a different question from someone willing to spend fifteen minutes.
Sometimes the fastest route still wins. Sometimes there is only one useful alternative. Sometimes a route leaves the study area, where the model cannot assess its entire exposure.
The interface needs to explain those outcomes as clearly as it explains a different recommendation.
Before comparing roads, understand the ground
Picture pouring the same amount of water onto a paved courtyard and a patch of open ground.
Some water can soak into the ground. More can run off the paved surface. Now add a shallow depression, surrounding higher ground, and differences in slope. The same rainfall can produce different behaviour in different places.
DrainTwin represents a simplified version of those differences.
Its data preparation combines:
Information | The question it helps answer |
|---|---|
Elevation and slope | Where is the ground lower or flatter? |
Approximate flow accumulation | Where might terrain concentrate upstream contributions? |
Land cover | How much of the surface is likely to generate runoff? |
Mapped waterways | How far is a cell from a mapped drainage-related feature? |
These layers become a 64 × 64 analysis grid covering the Central Delhi study rectangle.
The cells are roughly a few hundred metres across. This makes the prototype practical to explore interactively, but it also sets a boundary: a detailed street map does not turn the underlying model into street-level flood prediction.
Different geographic layers answer different questions. Rainfall activates their combined response.
Permanent-water cells are masked from the susceptibility output. Existing water bodies should not become waterlogging hotspots simply because they contain water.
Giving rainfall a meaningful response
A useful scenario model needs more than a slider that makes the map progressively redder.
DrainTwin first estimates local runoff using the SCS Curve Number method. In plain language, it relates rainfall to an assumed surface response: more permeable ground can absorb more before runoff begins, while built-up surfaces generate runoff more readily.
The model then combines that rainfall response with four location-specific signals:
- Runoff convergence.
- Local depression.
- Flatness.
- Distance from mapped drains or waterways.
The result is a relative index between zero and one hundred.
The calculation is transparent. Its feature weights, runoff assumptions, and thresholds can be inspected in the source. They are hand-set assumptions awaiting stronger calibration.
That transparency lets someone challenge a result. If a hotspot appears, there should be a traceable explanation of why the model placed it there.
A red dot should come with a reason
Click a hotspot and DrainTwin shows the local evidence behind its score.
A location might sit below its surrounding neighbourhood. It might have more built-up cover than the study-area median. It might show stronger terrain-derived convergence.
Hotspots are entry points into the model’s reasoning, rather than labels to accept without inspection.
Candidate hotspot locations remain fixed as rainfall changes. Their scores and active status can change, but their identities stay consistent.
This makes the rainfall slider useful for comparison. You can follow the same location through different scenarios and ask when it crosses the display threshold.
The model also repeats its calculations across 100 variations of selected parameters. The displayed stability percentage tells you how often a candidate remains above the hotspot threshold under those variations.
It describes sensitivity to the tested assumptions. It does not mean that the location has that percentage chance of flooding.
That difference is small enough to miss in a dashboard and large enough to change how someone interprets the entire project.
Turning a coloured map into a route comparison
A road route is a line. The susceptibility model is a grid. DrainTwin connects them by sampling each route along its geometry.
The browser requests road alternatives and estimated driving times from OSRM, then compares those alternatives with the scenario returned by the backend.
It considers:
- Distance-weighted susceptibility exposure.
- Distance through higher-scoring cells.
- Active hotspots within 300 metres of the route.
- Estimated driving time.
- Coverage inside the study boundary.
DrainTwin can also request additional waypoint-based detours around selected hotspots encountered by the fastest route.
Duplicate alternatives and routes that are slower without improving the exposure measures are filtered out. The remaining candidates are ranked using the user’s preference and extra-time budget.
This is a comparison of available candidates. It does not search every possible road path or know which roads are currently flooded.
The recommendation therefore has a specific meaning: among the routes examined, this one best fits the selected preference under this modelled scenario.
Where AWS Strands fits
A numerical result still leaves a reader with questions.
Why does this hotspot stand out? Which local factor matters most? Why would a permeable surface be relevant here, while a retention intervention is worth exploring elsewhere?
DrainTwin includes an optional advisory layer using AWS’s Strands Agents SDK to help explain the existing hotspot evidence in prose.
The responsibilities stay separate:
The engine supplies numerical evidence. The advisory layer helps readers interpret it.
The current provider options include local Ollama and Gemini. Using Strands here is an AWS open-source integration; it does not mean the application or model is hosted on AWS.
The advisory feature is optional because the main workflow should remain usable when a provider is unavailable. An offline briefing remains available, and a fallback should be labelled as offline rather than presented as a successful AI execution.
This separation also keeps the model from becoming the source of numerical claims. Susceptibility scores and intervention values come from the deterministic engine.
AI prose still needs review. Guarding numerical output does not establish that every generated sentence is correct.
What if we changed the place itself?
Route comparison asks how to travel through the scenario. Intervention simulation asks how a local change might affect it.
DrainTwin lets users explore:
Intervention | What changes in the model |
|---|---|
Improve drainage | Selected drainage, convergence, and runoff-related inputs |
Add permeable surface | Estimated imperviousness |
Build retention basin | Selected convergence and runoff-related inputs |
The assumed effects are applied around a selected hotspot, and the engine recalculates its index.
This creates a connection between an explanation and a possible planning direction. If built-up cover is a strong contributing signal, users can explore a permeability scenario and inspect the difference.
The result remains an illustrative comparison. A lower score does not establish the size of a basin, the capacity of a drain, the cost of construction, or the reduction in real flood depth.
Those questions require measurements and engineering analysis beyond this prototype.
The hardest part is deciding what the map proves
A coloured map can look convincing long before its accuracy has been established.
DrainTwin includes source-linked historical candidate locations and a workflow for reviewing their coordinates. Finding a named waterlogging location in a report does not automatically produce a reliable point on the map.
Coordinates require verification. Event dates matter. Historical observations also need rainfall context before they can support event-specific evaluation.
The interface therefore withholds performance figures when fewer than ten verified, in-area points are available.
The project also distinguishes parameter stability from predictive accuracy, forecast rainfall from observed road conditions, and geographic waterway proximity from actual drainage capacity.
These distinctions help define the work still needed.
What would make DrainTwin better - Future Improvements Planned
The next major improvement is stronger evidence.
Verified, event-linked waterlogging observations would support calibration and evaluation on events the model has not been tuned against. Genuinely higher-resolution terrain, road elevations, and a verified drainage network would improve the physical detail.
Rainfall intensity over time, drain capacity, and blockage information would help represent behaviour that a daily total cannot capture. Confirmed closures and more complete road-network routing would strengthen route assessment.
Intervention estimates would become more useful with measured infiltration, storage, and capacity parameters.
The current prototype has a narrower achievement: it connects rainfall, geography, travel choices, and local interventions in one inspectable workflow.
Try changing one assumption
If you explore DrainTwin, start with a route.
Choose two points, set a rainfall scenario, and inspect the recommended option. Then change one thing: the rainfall, the extra-time budget, or the route preference.
Watch what changes and what stays the same.
Select a nearby hotspot and follow the evidence behind it. Try an intervention. Read the briefing. Ask which assumptions you would want to verify before using the result for a real decision.
That is the kind of exploration I wanted DrainTwin to make possible.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article