From Rainfall to Road Risk: Building a Localized Waterlogging Early-Warning System for Gurugram
A localized waterlogging early-warning system for Gurugram that combines rainfall, historical flood hotspots, terrain, drainage, and road data to estimate high-risk areas, evaluate route exposure, and provide safer travel recommendations during heavy rain.
Student
Introduction
For millions of people living and working in fast-growing Indian cities, heavy rain is not just a weather event. It can determine whether a school bus reaches its destination, whether an employee makes it to work, whether an ambulance can pass through an underpass, or whether a normally routine commute turns into hours of congestion.
Gurugram is a strong example of this challenge.
During intense monsoon rainfall, the city has repeatedly experienced waterlogging on important roads and intersections. In July 2023, heavy rain led to waterlogging at locations including Rajeev Chowk, Subhash Chowk and the stretch towards Hero Honda Chowk, while the district administration advised residents to avoid unnecessary travel.
The problem continued in 2024. After three hours of heavy rain on August 8, significant congestion and waterlogging were reported around Narsinghpur, Basai, Golf Course Extension Road and NH-48. The city recorded 23 mm of rainfall during the three-hour period.
In another event that month, 53 mm of rainfall was reported by 8:30 AM, with water accumulation affecting several roads and subways.
These incidents reveal an important gap.
A weather application can tell a commuter that heavy rainfall is occurring across Gurugram. What it usually cannot answer is:
Which particular areas are most vulnerable to waterlogging, which parts of my route may be exposed, and should I travel now or consider another route or departure time?
Our project attempts to address this gap.
The Problem We Are Solving
Traditional weather forecasts operate mainly at the weather level.
They answer questions such as:
How much rain is expected?
Urban commuters, however, need a different kind of information:
What might that rainfall mean for the road I am about to use?
The same amount of rainfall does not necessarily produce the same impact everywhere.
A relatively elevated location with effective drainage may handle rainfall differently from a historically waterlogged, low-lying road section.
This means rainfall alone is not enough.
Urban waterlogging risk emerges from the interaction between rainfall, local terrain, drainage characteristics, historical vulnerability and current conditions.
The challenge is that these datasets exist at completely different spatial and temporal scales.
Weather data may describe several kilometres of area. A historical waterlogging survey may consist of individual latitude-longitude points. A commuter route is a line running across several neighbourhoods. Terrain and drainage information may exist in yet another geographic format.
Our central engineering challenge therefore became:
How do we transform all these different datasets into a common representation that a risk model can understand?
Our Approach: A Common Spatial and Temporal Language
We use a concept we describe as harmonization to a common anchor.
Instead of trying to predict risk directly for every individual GPS coordinate, Gurugram is divided into approximately 500-metre hexagonal cells.
Each cell becomes a small analysis unit with its own identifier such as:
GGM_0001 , GGM_0002 , GGM_0003 , and so on.For each cell, we attempt to associate relevant evidence such as historical waterlogging proximity, rainfall conditions, terrain vulnerability and drainage vulnerability.
The system also organizes dynamic conditions into operational time windows so that a location can have one risk estimate now and a different one later as rainfall conditions change.
This converts a collection of unrelated datasets into a structure similar to:
Location + Time + Rainfall + Historical Susceptibility + Terrain + Drainage → Waterlogging Risk The result is a common spatial-temporal feature table that can support both transparent rule-based models and machine-learning experiments.
Historical Waterlogging as Local Evidence
One of the most important data sources in the project is historical waterlogging information from Gurugram Metropolitan Development Authority spatial services.
GMDA operates GIS services containing a flood survey layer with fields describing survey type, waterlogging type, survey information and geographic features. GMDA also exposes mapped waterlogging-site layers through its spatial infrastructure.
These historical points provide valuable evidence, but they create an engineering problem.
A point represents one recorded location. It does not automatically describe an entire neighbourhood.
If we only marked the exact coordinates, most of Gurugram would have no historical information.
Instead, our feature-engineering process measures the proximity of every grid cell to nearby historical hotspots.
A cell close to several recorded waterlogging locations can therefore receive a higher historical susceptibility value than a cell far from all known hotspots.
However, we deliberately treat this as a susceptibility proxy.
No recorded complaint does not necessarily mean that flooding has never happened there. It may simply mean that no event was recorded in the source dataset.
That distinction is important because machine-learning systems can easily confuse absence of evidence with evidence of absence.
Rainfall: Dynamic Information That Changes the Risk
Historical vulnerability tells us where problems have happened before.
Rainfall tells us when those vulnerabilities may become important.
Our project uses rainfall information expressed in physical units such as millimetres wherever possible.
Open-Meteo provides historical weather and forecast interfaces that expose precipitation variables with timestamps. Its historical weather service is based on weather reanalysis products, while its historical forecast service provides archived model forecasts.
For longer historical analysis, ERA5 is also an important reference dataset. ERA5 is a global atmospheric reanalysis product distributed through the Copernicus Climate Data Store and provides hourly historical atmospheric information.
Reanalysis is particularly valuable when direct weather-station observations are incomplete because it combines observations with numerical modelling to create spatially and temporally consistent historical estimates. It is important, however, to identify it correctly as reanalysis rather than treating it as a direct rain-gauge measurement.
For machine learning, rainfall should ideally be represented through meaningful temporal features such as recent one-hour rainfall, accumulated three-hour rainfall and antecedent rainfall over longer periods.
This matters because 40 mm of rain spread across an entire day can have a very different urban impact from 40 mm falling in a short intense period.
Local Terrain and Drainage
Rainfall tells us how much water is arriving.
Terrain and drainage help describe what may happen after that water reaches the ground.
Our current dataset includes features such as a terrain-depression proxy and a drainage-choke proxy.
These features are useful because low-lying locations and drainage-constrained areas may be more susceptible to accumulation.
However, our architecture explicitly distinguishes measured physical features from proxies.
A terrain proxy should not be presented to users as an exact elevation measurement. Likewise, a drainage vulnerability score should not be interpreted as a live measurement of drain capacity.
This distinction makes the system more transparent and prevents a common machine-learning problem: giving a derived number more authority than its source data justifies.
Preparing the Dataset for XGBoost
The machine-learning component of the project uses XGBoost, a gradient-boosted decision-tree framework introduced by Tianqi Chen and Carlos Guestrin. XGBoost is widely used for structured tabular datasets because it can model nonlinear relationships and interactions between multiple variables.
A typical record in our current feature-engineering pipeline can contain fields such as:
precipitation_mm , historical_score , hotspot_count_750m , terrain_depression_proxy , drainage_choke_proxy , along with the grid ID, date and derived indicators.For our first defensible model, we intend to favour a compact set of interpretable predictors:
Rainfall amount, describing the dynamic weather stress.
Historical susceptibility, describing whether the location has evidence of past waterlogging vulnerability.
Nearby historical hotspot count or influence, representing surrounding recorded vulnerability.
Terrain-depression proxy, representing whether a location is relatively susceptible to accumulation.
Drainage-choke proxy, representing available information about drainage vulnerability.
We intentionally avoid feeding every available engineered column into XGBoost.
For example, if
rain_intensity_normalized is simply calculated from precipitation_mm , both variables represent nearly the same information.Similarly, features such as runoff accumulation, drainage stress or an overall hazard-exposure index may already be calculated from rainfall, terrain and drainage.
Including both the original features and several mathematical combinations of them can make interpretation difficult and may create circular relationships.
The most serious leakage would occur if the flood label itself were generated using those engineered risk indices and those same indices were then supplied to XGBoost.
The model could appear extremely accurate simply because it had learned the formula that created its training labels.
For this reason, our feature-engineering strategy prioritizes raw or near-raw explanatory features over composite risk scores.
Why Data Splitting Matters
Urban data contains strong spatial and temporal relationships.
If records are randomly divided into training and test sets, the same geographic cell may appear in both.
That can make the model look better than it actually is because it has already seen the location during training.
Our validation strategy therefore needs to account for geography and time.
For synthetic spatial experiments, records belonging to the same grid cell should remain together during splitting.
For genuine historical forecasting evaluation, the stronger approach is chronological validation: earlier periods are used for training and later periods are held out for testing.
This is important because an early-warning model should demonstrate that it can predict events it has not already indirectly seen.
From Cell Risk to Commuter Route Risk
Localized risk becomes more useful when connected to actual travel decisions.
For routing, our project uses road geometries that can be obtained through the Open Source Routing Machine. OSRM is an open-source routing engine built around OpenStreetMap road data and provides route, map-matching and distance services.
A commuter route may pass through many of our 500-metre cells.
We therefore intersect the route geometry with the grid and divide the journey into smaller sections.
For example, most of a route might pass through lower-risk areas while one short underpass or junction passes through a much higher-risk cell.
Instead of ignoring that bottleneck, our route-exposure calculation considers both average exposure and higher-risk segments.
The goal is not simply to say:
Route A is shorter.
It is to eventually say:
Route A is shorter, but Route B has lower estimated waterlogging exposure under the current rainfall scenario.
This makes the system directly relevant to commuter decision-making.
What the User Sees
The public-facing system is deliberately simpler than the engineering pipeline behind it.
A commuter should not need to understand XGBoost parameters, correlation matrices or geospatial joins.
The interface can instead communicate:
Current localized waterlogging outlook
Risk level for the selected area
Higher-risk sections along candidate routes
Recommended travel action
Data freshness and limitations
A technical or administrative dashboard can separately expose feature values, weather sources, model version and data-quality information.
This two-layer design allows the system to remain useful to ordinary commuters while preserving transparency for technical users.
Why This Matters
The value of the project is not that it predicts rain.
Weather services already do that.
The value comes from attempting to translate rainfall into localized urban consequences.
Real events demonstrate why this distinction matters.
In June 2024, around 30 mm of rainfall was associated with severe waterlogging at multiple Gurugram locations and disruption along NH-48.
In September 2024, waterlogging was again reported around Narsinghpur, Sohna Road, Golf Course Extension Road, Basai, Hero Honda Chowk and the Southern Peripheral Road.
The location-specific nature of these incidents shows why a single city-wide statement such as "heavy rain expected" is not sufficient for mobility decisions.
Current Limitations
This project is intentionally presented as an early-warning and decision-support prototype, not as a certified flood forecasting system.
Historical waterlogging records are sparse and may contain reporting bias.
Some physical features are currently proxies rather than direct measurements.
City-level rainfall may need to be broadcast across grid cells when high-resolution local rainfall observations are unavailable.
Most importantly, an XGBoost model is only as credible as its target labels.
If flood labels are synthetically produced from a predefined risk formula, the model can be useful for testing the software architecture and scenario behaviour, but its performance must not be presented as real-world flood prediction accuracy.
Our next major validation milestone is therefore to align independently observed, timestamped waterlogging events with historical rainfall and geographic features.
That would allow genuine out-of-sample testing.
Future Scope
The architecture is designed so that better data can improve the system without rebuilding everything.
Future versions can incorporate more spatially resolved rainfall data, actual digital elevation models, detailed storm-water drainage GIS, verified live standing-water reports, historical event labels and ensemble weather forecasts.
The same framework can also support uncertainty analysis.
Instead of pretending that a single rainfall forecast is certain, multiple plausible rainfall scenarios can be evaluated to determine whether the same route recommendation remains stable.
Eventually, this could allow the platform to communicate not only where risk is estimated to be high, but how robust that recommendation is under forecast uncertainty.
Conclusion
Urban flooding is not only a rainfall problem.
It is a rainfall + geography + infrastructure + mobility problem.
Our Gurugram Urban Flood & Waterlogging Early Warning System brings these dimensions together by harmonizing historical waterlogging evidence, rainfall, local vulnerability features and road routes into a common spatial-temporal framework.
The system divides the city into manageable geographic units, estimates localized waterlogging susceptibility and dynamic risk, evaluates commuter routes and turns technical data into understandable travel guidance.
The long-term objective is simple:
When heavy rain begins, a commuter should not only know that Gurugram is receiving rainfall. They should have useful evidence about which parts of their journey may be more vulnerable and what they can do about it.
That is the gap this project is designed to address.
References
- Gurugram Metropolitan Development Authority. Flood Survey GIS Service and Flood_survey_v2 Layer. GMDA OneMap spatial services.
- Express News Service. Heavy rain leaves Gurgaon roads waterlogged, once again. The Indian Express, 5 July 2023.
- Express News Service. All schools in Gurgaon, Faridabad shut amid heavy rain; administration advises work from home. The Indian Express, July 2023.
- Dhankhar, L. Waterlogging triggers traffic jams after heavy rainfall in Gurugram. Hindustan Times, 8 August 2024.
- Dhankhar, L. Heavy rain inundates key Gurugram roads, brings parts of city to standstill. Hindustan Times, 6 September 2024.
- Open-Meteo. Historical Weather API Documentation. Historical precipitation and weather reanalysis interface.
- Open-Meteo. Historical Forecast API Documentation. Archived numerical weather forecasts.
- Copernicus Climate Change Service / ECMWF. ERA5 Hourly Data on Single Levels from 1940 to Present. Climate Data Store.
- Copernicus Climate Change Service. What is ERA5 Reanalysis? Overview of observations, modelling and gap-filled climate reanalysis.
- Chen, T., & Guestrin, C. (2016). XGBoost: A Scalable Tree Boosting System. Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 785–794.
- Open Source Routing Machine Project. OSRM API Documentation.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article