About Hyderabad Water Intelligence
An open-source water intelligence platform for Indian cities, built to make public data accessible and actionable.
Sections are collapsed by default. Click any heading to expand it.
What we track for Hyderabad
Hyderabad is governed by Hyderabad Metropolitan Water Supply and Sewerage Board with civic services under Greater Hyderabad Municipal Corporation (300 wards). Estimated daily city demand: ~2628 MLD.
Water sources tracked daily
Reading this dashboard
How “Days of Water Left” Works
We compute three scenarios based on current reservoir storage, daily consumption, and inflow patterns:
What each page shows for Hyderabad
Home / dashboard
Hyderabad has the richest daily supply feed of any city on this platform. HMWSSB publishes, every day, not just the level and storage of each of its six sources but how much it actually drew from each in million litres and how much flowed in. Most utilities publish a design capacity and leave the rest to inference. That means the water-runway figure here is divided by a measured number rather than an assumed one, and the three rainfall scenarios are all computable - Mumbai's dashboard has to collapse them into one line because its feed carries storage only.
The archive runs daily from 1 January 2014, so the chart spans twelve and a half years. Two things in that record are worth knowing. The board's own summary row is labelled "Total(1 to 5)" but does not sum rows 1 to 5 - it silently includes the Godavari source added later - so we recompute the total from the individual rows. And on 1 July 2026 the published capacity of Osman Sagar and Himayat Sagar changed by about a tenth and a seventh respectively, overnight and without notice. We detected it by bisecting the archive. The cause is not established and we do not describe it as siltation.
Those reservoir numbers no longer rest on a single publisher. The Telangana Irrigation & CAD Department publishes its own daily storage record, and five of the eight sources appear in both feeds. The capacities agree: Nagarjuna Sagar, Srisailam and Yellampally match exactly, Singur differs by 0.007 TMC and Akkampalli by 0.001. Osman Sagar, Himayat Sagar and Manjira are absent from the irrigation feed by design - they are HMWSSB drinking-water reservoirs rather than irrigation projects - so the cross-check covers the transferred Krishna and Godavari sources, not the local twins.
Still absent: population served, and a single headline figure for treatment capacity. Population-served numbers exist only in news reporting and contradict each other. Treatment is a narrower gap than we first described - the pollution board does publish every plant with its capacity, and that is now shown on the rivers page - but the AMRUT programme's split between commissioned and under-construction plants is still unpublished, so no forward-looking total is given.
Water bodies
Three instruments count Hyderabad's lakes and none of them is a complete inventory, so the page shows all three rather than picking a winner. OpenStreetMap contributes 669 mapped polygons totalling about 10,599 hectares - the geometry. HMDA's gazetted register contributes 2,978 lakes with their legal notification status - the boundary. The 2023 Jal Dharohar census contributes 3,116 enumerated points across Hyderabad and Rangareddy districts - the enumeration. A lake can be gazetted and unmapped, or mapped and never notified.
The register is the accountability layer. Every lake is meant to have its Full Tank Level fixed twice - a preliminary notification, then a final one after objections. All 2,978 have the preliminary; only 1,352 have the final. Until the final issues there is no boundary a court can be pointed at. The gap is worst exactly where development pressure is highest: Rangareddy, the Outer Ring Road corridor, holds 891 lakes and has 34.5% finally notified, against 68.0% in Siddipet.
What we do not have is the shape of those legal boundaries. HMDA publishes a survey sheet per lake carrying the FTL elevation, tank area and perimeter, but they are scanned raster PDFs with no extractable text, so no machine-readable polygon exists. Recovering them means optical character recognition over ~3,000 title blocks - a planned job, not a shipped one.
Groundwater
Point observations from the Central Ground Water Board network via India-WRIS, which for Hyderabadis live - telemetric readings run to June 2026, where Delhi's equivalent network stopped in September 2025.
481 wells, with 10,724 monthly readings and a median depth of about 8.7 metres below ground level. Ranga Reddy contributes 192 and Medak 173, so the metro core alone carries around 240 - a denser network than we expected and comparable to Delhi's.
We show the wells as points and deliberately do not interpolate a continuous depth surface between them. Partly because there is no public ward geometry to interpolate onto, and partly because this is Deccan hard rock - granite and gneiss, where water sits in weathered zones and discrete fractures rather than a continuous water table. A smooth surface drawn between two wells a few kilometres apart would assert groundwater that may not be there.
One handling note that matters: the national database returns depth with a sign that depends on which programme installed the station, and Hyderabad mixes them - the telemetric recorders report one way and the older manual wells the other. We derive the convention separately for every station from its own record rather than assuming it, because taking absolute values would erase genuine readings of water standing above the sensor.
Rivers
The Musi and its tributary the Esi, plus the Manjira on the supply side. Two honest caveats. First, OpenStreetMap maps the Musi under three different names, which we merge - without that it renders as three rivers. Second, and more important, the Esi is represented by a single 10-kilometre way against the Musi's 244, even though Himayat Sagar impounds the Esi exactly as Osman Sagar impounds the Musi. That is a gap in the public map, not a fact about the river, and the page should not be read as saying the Esi is minor.
River quality IS now shown, and the reason it took a while is worth recording plainly: we had the wrong hostname. An earlier version of this page said the national monitoring data sat behind a host that refuses connections from outside India. One CPCB host does; the board serves everything on another that answers in under a second. The page now carries eleven monitoring stations across six annual editions, 2019 to 2024, read from the published tables directly.
Two things to know before quoting the numbers. They are annual minimum-maximum ranges, not monthly readings, so a reading here is a range and we invent no midpoint. And very low dissolved-oxygen values should be read as at-or-below the programme's reporting floor rather than as exact concentrations: in nine of fifty-one station-years the annual minimum equals the annual maximum, which cannot describe a real twelve-month range, and seven of those nine sit at exactly 0.3 mg/L. That is why this site says the Musi is anoxic through the city rather than quoting a concentration.
The same page carries a treatment-and-discharge view that joins the pollution board's per-plant effluent monitoring to those river stations - two datasets from two bodies that were never designed to be read together.
Flood risk
GHMC's own layers: 96 named nalas (storm-water drains) running about 245 kilometres, 23 designated major water-logging locations, and the wider canal and drain network.
The most important thing on this page is an absence. GHMC's nala layer defines the fields the flooding debate needs - encroachments per drain, separated into government, private and religious, with a count of how many are in court - and publishes all five as zero for all 96 drains. In a city that created HYDRAA in 2024 specifically to demolish encroachments, that is an unfilled column rather than a clean record, so we strip those fields rather than render them. We flag it here because the schema already specifies exactly what to ask for.
Tanker
Hyderabad is the one city where the tanker market is run by the utility itself and reported. HMWSSB publishes monthly bookings and deliveries for each of its 201 operational sections - 1.32 million bookings between January 2022 and February 2024. Bengaluru's equivalent page rests on household surveys because that market is private and unreported.
We looked for a fulfilment gap and there isn't one: 99.95% of bookings were delivered, and the worst of 201 sections still ran at 98.4%. So the page reports demand instead, which is where the signal is. Bookings triple between October and June, and the heaviest demand is not in the old city but in Madhapur, Kondapur, Hafeezpet, Gachibowli and Manikonda - the IT corridor.
We used to describe that as tanker dependence tracking where the city outgrew its pipes rather than where residents are poorest. That reads more into the data than it can carry, and the page now says so. These tankers are paid for and need storage to receive, so the pattern measures where households can afford and accommodate a tanker at least as much as where the network falls short. A section with almost no bookings is not demonstrably well served; it may simply not be buying.
The page also carries HMWSSB's billing ledger, which uses the same division and section units - 198 of the 201 tanker sections join exactly. That gives bookings per piped connection, and it is the reason the caution above is stated before the table rather than after it. The billing record is also the utility's own answer on revenue: it collected 69.5% of what it billed over fifty-four months.
Two gaps, both upstream: the published series stops at February 2024, and December 2022 is missing entirely - the file exists but is empty at source. Neither month is interpolated. Sections are HMWSSB's own operational units and no public boundary file exists for them, so this is a ranked table rather than a map.
Rainfall
Hyderabad is measured far better than any other city here. The Telangana Development Planning Society publishes daily rainfall from individual automatic weather stations with their own coordinates, and 161 of them sit inside the city. Every other city on this platform infers rainfall from a single 0.25-degree grid cell about 28 kilometres across. For a city whose flooding is intensely localised, that is the difference between seeing a storm and averaging it away.
Note a count discrepancy we have not resolved: the network's own summary page reports 185 stations inside Greater Hyderabad, the station map exposes 162, and 161 resolve to coordinates. We publish what we can place on a map and say so. The station endpoint returns only the latest reading with no archive, so the series accumulates from the day we started collecting; the long history sits in annual bulk files that are a separate job.
What is missing, and why
My Ward is not available.A gazette notification on 25 December 2025 replaced Greater Hyderabad's 150 wards with 300, and on 11 February 2026 the corporation was split into three - GHMC, Cyberabad and Malkajgiri. The geometry for those 300 wards is not public. The only ward boundaries available are the superseded 150-ward set, which would attribute data to boundaries that no longer exist. There is also currently nobody to attribute it to: the corporations are run by a Special Officer pending elections, so there are no sitting councillors.
Water, notably, was not divided with the corporations. HMWSSB continues to serve the whole Core Urban Region, which is why this remains one water story under three municipal governments - and why Hyderabad is modelled here as a single city rather than as a region of independent corporations the way Mumbai is.
Intelligence & AI narratives
Daily AI briefings, longer-form weekly narratives, and per-ward AI profiles are pending for Hyderabad- the underlying summary stores aren't yet multi-city. Until those land, the page surfaces raw data without an AI commentary layer.
Cascade reconstruction methodology - Hyderabad
Hyderabad's tanks were once organised into chained cascades (system kanmoi): water from upper tanks overflowed through feeder channels into lower tanks, which fed the next, and so on. Most cascade channels are now broken by encroachment. The cascade overlay surfaces a terrain-derived hypothesis of how the cascade structure should have been organised, given the actual elevation and flow direction of the land.
See cascade health scores: The Catchments view on the water-bodies map → ranks every documented and auto-derived cascade by fragility + priority, with citations and court / restoration anchors where known.
What you are seeing
- Sky-blue circles (428 tanks): one per OpenStreetMap water-body polygon at least 1 ha in size. Size encodes cascade depth (deeper-in-the-chain tanks render larger).
- Sky-blue lines (411 edges): predicted tank-to-tank cascade links. Each upstream tank has at most one outflow.
- Amber lines (11 outflows): tanks whose flow direction points to a river within ~2 km, modelling the river itself as the terminal sink.
Inputs
- Tank polygons: OpenStreetMap
water=*features.water_typein{river, canal, stream, drain, ditch, wastewater}is excluded so river segments don't get treated as tanks. - Elevation:
WWF/HydroSHEDS/03CONDEM- HydroSHEDS conditioned DEM at 3 arc-second (~90 m) resolution. "Conditioned" means sinks have been pre-filled so flow routing behaves predictably. - Flow direction:
WWF/HydroSHEDS/03DIR- the corresponding ESRI D8 flow-direction raster. Each pixel encodes which of its eight neighbours water drains to. - River barriers: the
{city}-rivers.geojsonwe already use on the map.
Algorithm (per tank)
- Compute centroid; sample DEM elevation and D8 flow direction at that point in a single batched Earth Engine call.
- Find all other tanks within 3 km whose elevation is lower.
- Reject candidates that fall outside ±67.5° of the upstream tank's flow-direction bearing - terrain-aware directionality, not just "is downhill".
- Reject candidates whose straight-line edge would cross a mapped river segment - water doesn't flow across rivers.
- Pick the single steepest remaining candidate (elevation drop / distance) as this tank's outflow.
- For tanks with no tank-to-tank outflow but a flow direction pointing to a river within 2 km: mark
drains_to_riverand draw an amber arrow to the nearest in-cone river point.
What this is NOT
- Not a registry of historical channels.We don't claim that any specific cascade link historically existed; we claim the terrain would have organised water this way.
- Not full hydrological flow accumulation.A stricter approach would trace flow paths pixel-by-pixel through the DEM. We use a "downhill within a flow-direction cone" heuristic that's correct for most obvious cases but can miss subtle terrain features that aren't river-mapped.
- Not a real-time water transport model. Edge existence does not imply current water flow.
- Not a model of any inflow that isn't tank-to-tank. Reservoirs receive water from at least four sources that this graph cannot represent: (a) direct rainfall on the lake surface, (b) catchment runoff via unmapped channels and overland flow, (c) the river the reservoir dams (rivers are deliberately excluded from cascade nodes), and (d) engineered canals, pipelines, and trans-basin diversions. A reservoir showing 0 cascade inflows here is not isolated in real life - Chembarambakkam Lake, for example, is fed by all four kinds of inflow (its 71.6 km2 Adyar catchment, the upper Adyar itself, plus Krishna water via the Kandaleru-Poondi canal and Cauvery water from Veeranam) yet none of those appears in this layer. The cascade graph is solely about tank-to-tank structure derived from terrain.
Known limitations
- DEM resolution ~90 m. Adequate for district-scale cascade structure; may miss very small channels. In flat terrain (e.g. coastal Chennai) elevation differences often round to the same integer metre, so the flow-direction cone does most of the work.
- Single outflow per tank (default). Real tanks often have one feeder channel and one separate surplus channel; the V1 algorithm models only the steepest candidate edge per upstream. A per-district
allow_multi_outflowopt-in relaxes this and keeps near-tied candidates (within 30% of the best score by default), modelling tanks with both feeder and surplus. Off by default for Hyderabad; we plan to enable it for plateau-geography districts where terrain gradients are weaker and multi-branch cascades are documented in the historical record. - River-coverage gaps. The river-crossing barrier is only as complete as the OSM river polylines. Where the polyline is sparse, edges may slip through.
- Edges are labelled
predictedonly. A future iteration will cross-check predicted edges against OSMwaterway=*tags and Sentinel-1/2 monsoon imagery, then label each edge asintact / partial / broken / encroached. - OSM
water_type=reservoiris ambiguousin this region. In Madurai roughly 87% of cascade nodes carry that tag, including many traditional kanmoi tanks that historically fed downstream cascades. The algorithm therefore does NOT auto-classify reservoirs as terminal sinks. A per-district curation hook (terminal_sink_osm_ids) exists for marking specific known engineered reservoirs (large dams whose outflow is via spillway / canal rather than via gravity to another tank); it is currently empty pending validation against TN PWD / DHAN inventories.
Reading cascade_position = 1: headwater, not source
Tanks at cascade_position = 1have no tank-to-tank inflow in this graph. They are the shallowest nodes in the network, not the literal source of water in the basin. Real inflow into these tanks comes from rainfall on the lake surface, surface runoff from the surrounding catchment via channels not in OpenStreetMap, and (in dammed basins) the river itself - none of which are modelled here.
We call these headwatertanks rather than "sources" to avoid implying the cascade graph accounts for where water actually originates. A reservoir with cascade_position = 1 is not isolated from rainfall and runoff; it just sits at the top of whatever tank-to-tank chain the terrain organises.
Edge confidence
Each predicted edge carries a confidence field bucketed by its score_m_per_km (elevation drop normalised by edge length). Thresholds:
- HIGH(≥ 5 m/km): a clear downhill gradient unambiguous even given HydroSHEDS 90 m elevation noise.
- MEDIUM(1-5 m/km): plausible cascade link with moderate confidence. Most kanmoi-cascade edges fall here.
- LOW(< 1 m/km): below 0.2 m drop per 200 m. Near the noise floor of the conditioned DEM; the edge may be terrain noise as much as real flow.
For Hyderabad: 321 high (78%), 81 medium (20%), 9 low (2%).
Isolated tanks: why each one is isolated
A tank is "isolated" in this graph when it has no tank-to-tank inflow, no tank-to-tank outflow, and no river sink. The pipeline re-walks the candidate-evaluation gates for each such tank and stamps it with one of these reasons, surfaced in the on-map hover tooltip:
elevation_sampling_failed- the HydroSHEDS DEM returned no value at the tank's centroid, so the algorithm has nothing to compare against. Usually data-coverage at the DEM's 90 m resolution boundaries.no_neighbors_in_range- no other tanks within the 3 km radius the cascade window uses. Real geographic effect, common on the rural fringe of the district.all_neighbors_uphill- in-range tanks exist but every one of them is at a higher elevation. The tank sits at a local basin low; water has nowhere downhill to go through the tank network in this window.all_neighbors_out_of_cone- downhill tanks exist in range, but all sit outside the ±67.5° cone aligned with the upstream tank's D8 flow direction. The terrain wants water to go somewhere other than where the nearest downhill tank is.all_neighbors_river_blocked- downhill, in-cone, in-range tanks exist, but every edge to them would cross a mapped river LineString. May indicate either real river-cut isolation or a gap where the OSM river polylines are over-segmented relative to ground truth.unknown_isolation- defensive fallback. Should be empty in practice.
What you can use it for today
- Spot likely historical hubs: tanks with high in-degree are where multiple terrain-driven flow paths converge. For Hyderabad: Amber Cheruvu has 8 predicted upstream feeders. Maximum cascade depth in Hyderabad is 9.
- Surface river-front tanks: anything with an amber outflow is a tank that drains directly into a river - useful for restoration prioritisation since the ecological functions differ from internal-cascade tanks.
- Identify isolated tanks: tanks with neither inflow, outflow, nor river sink carry an
isolation_reasonfield distinguishing genuine basin orphans from data-coverage gaps. See the bucket-by-bucket breakdown above.
Lake catchment atlas methodology - Hyderabad
The cascade overlay answers "which tank drains into which". The catchment atlas answers the prior question: where does each lake's water come from. Every lake sits at the bottom of a catchment - the land whose rain drains toward it. Click any lake on the Catchments view and we draw its area of influence: the catchment polygon, the feeder streams inside it, the tanks upstream and downstream, and where its overflow finally reaches a river.
What you are seeing
- Orange (solid): the lake's own / direct catchment - the land that drains straight into it before reaching any other tank.
- Amber (dashed): the inherited basin upstream - catchment that drains in via other tanks. Own + inherited = total upstream basin.
- Blue lines: feeder streams, width graded by Strahler order (trunks thicker than first-order rills).
- Violet dotted line: the downstream flow path- how the lake's overflow actually runs through the channel network, lake by lake, until it reaches a river.
Inputs
- Elevation:FABDEM (Forest And Buildings removed Copernicus DEM) at 30 m. This is a bare-earthsurface - buildings and tree canopy are removed - so water routes over the real ground rather than over rooftops, which matters in dense urban terrain. (The cascade graph uses coarser 90 m HydroSHEDS; the atlas deliberately uses the finer DEM.)
- Lake polygons: OpenStreetMap
water=*features, the same set the water-bodies map uses. - Buildings: Overture Maps building footprints, for the rooftop-harvest estimate.
- Rainfall: India Meteorological Department (IMD) long-period annual normals for the district.
How the catchment is delineated
- Mosaic FABDEM over the district (buffered so edge catchments close), then condition it with WhiteboxTools
breach_depressions_least_cost(preferred over fill in cities - it preserves channels running under roads and culverts). - Compute D8 flow direction and flow accumulation; extract a stream network and assign Strahler order; vectorise the streams and smooth them (Chaikin corner-cutting) so they trace the natural curved channels rather than blocky raster steps.
- For each lake, trace the contributing area upstream from its footprint. The own (direct) catchment is the upstream trace that stops at the next water body - the land draining to this lake before any other tank intercepts it. Removing that barrier gives the total upstream basin; the difference is the inherited area. This is threshold-free: there are no impound-vs-transit tuning knobs.
- Downstream:from the lake's outlet (its highest-accumulation boundary cell) follow the channel by always stepping to the highest-accumulation neighbour until it enters another water body; chaining those hops along the cascade gives the full downstream flow path to the river.
- Rooftop harvest: clip Overture footprints to the own catchment, then
rooftop area × annual rainfall × 0.8(0.8 runoff coefficient), reported in million litres per year.
Naming the lakes and rivers
- OpenStreetMap names many water bodies but leaves a large share unnamed (in Hyderabad the OSM gap is substantial). Where an authoritative open dataset exists - for Bengaluru, the ATREE/CSEI named-lake census published on OpenCity - we attach the real toponym by polygon overlap and tag it
name_sourcewith a match confidence. OSM-native names are never overwritten, and a small pond sitting inside a large lake's outline is notgiven that lake's name (a wrong name is worse than a blank one). - The river a lake drains into is named by snapping its downstream flow path to the nearest mapped river (within 0.5 km). Lakes whose path stays far from any named river - because they flow off the edge of our coverage - honestly show no named river rather than a guess.
What this is NOT, and known limits
- Not a substitute for a surveyed catchment.A 30 m bare-earth DEM resolves urban catchments well but misses sub-cell culverts, storm drains, and engineered diversions that move water against the natural terrain.
- Bounded by our map extent. A lake near the edge can drain to a reservoir or river outside the area we model (for example a southern Bengaluru tank flowing toward the Krishnagiri reservoir, which is off-map). We trace the flow path correctly but cannot name a sink we do not hold.
- Rivers are conduits, not catchments. Named rivers/canals are excluded as lakes; very elongated polygons with a huge catchment-to-area ratio (river segments mis-tagged as water bodies) are filtered out.
- Rainfall is a long-period normal, not the actual rainfall of any given year, so rooftop-harvest figures are a typical annual potential, not a measured yield.
- Backfilled names are a join, not ground truth. They carry a source tag and a match confidence; treat low-confidence matches as provisional.
Data sources for Hyderabad
All operational data is collected by the Python pipeline and supporting scripts that power the dashboard. Raw source data and Earth Engine summaries are upserted into Supabase (PostgreSQL) and then exposed as small, readable product signals.
Reservoir & weather
Free, no-auth daily weather data: precipitation, temperature, humidity, ET0, wind. ECMWF / ERA5-Land base. For cities with the provisional-rainfall layer, its archive API also fills the months IMD's gridded series hasn't published yet - rendered as asterisked provisional months that IMD supersedes automatically.
India Meteorological Department 0.25-degree gridded rainfall, 1970-present. Used for monsoon-context overlays.
Groundwater
Daily and seasonal manual + telemetric (DWLR) groundwater readings from the Central Ground Water Board's National Hydrograph Network.
Annual block-level Dynamic Groundwater Resource Assessment (Safe / Semi Critical / Critical / Over Exploited).
Water bodies & restoration
Base geometry for water-body polygons and the rivers polyline.
Rivers & pollution
Flood & civic infrastructure
Satellite & remote sensing
Base geometry & AI
AI city narratives and per-ward profiles. Live for Chennai; pending for Hyderabad.
Data quality & limitations
How we classify river health
CPCB publishes two parallelriver-water-quality classification systems, and they don't always agree. Knowing which one we use - and why - matters for reading our river status badges honestly.
Designated Best-Use classes (A-E)
Computed from current dissolved-oxygen, BOD and coliform thresholds at each NWMP station. Updates every reading. Class A = drinking with disinfection only; Class B = outdoor bathing; Class C = drinking with conventional treatment; Class D = fisheries/wildlife; Class E = irrigation only. Below E = practically dead.
Polluted River Stretch (PRS) Priority I-V
A historical, multi-yearstretch-level designation reflecting cumulative pollution. Slow to update; once a river stretch is on the Priority list it tends to stay there even if recent readings improve. Priority I = worst (BOD > 30 mg/L sustained); Priority V = least bad of the polluted stretches.
Our status badges ("dead", "severely degraded", "degraded", "stressed", "healthy") are computed from current readings via the Designated Best-Use thresholds- not from the PRS Priority list. We take the worst classification across a river's monitored stations and surface that as the river-level status.
Practical consequence: a river on CPCB's PRS Priority list (e.g. the Madurai-Manamadurai stretch of the Vaigai is Priority III) won't automatically render as "severely degraded" here. If the underlying NWMP readings show only Class C/D conditions, the badge reflects that. The PRS designation belongs in the river description as historical context, not as the live status.
Status thresholds follow CPCB's published Designated Best-Use criteria; readings are from CPCB NWMP annual River Water Quality reports.
Known Limitations
- Estimates are approximations. Actual water availability depends on factors not modeled (groundwater extraction, Krishna water transfer, distribution losses, industrial use).
- Utility-published feeds may occasionally be stale (weekends, holidays, portal outages). Each surface shows a freshness indicator, and the freshness registry names any feed that has stopped updating.
- Groundwater data from OpenCity may lag by months. The map always shows the most recent available period.
- Forecasts use ARIMAX (AutoARIMA with inflow/outflow as exogenous regressors) and work best with 2+ years of daily data.
- Risk scores are relative indicators for comparison between wards, not absolute measures of water safety.
- Satellite spread is a summary of surface water extent, not a direct measure of storage volume, water quality, or inflow source. A lake can look broad and still hold less usable water than expected.
- Reservoir catchment polygons are reviewed operational geometries for rainfall context, not official legal boundaries. This matters especially in Chennai's managed canal and transfer system.
- Current satellite context relies on optical Sentinel-2 observations. During persistently cloudy periods, some water bodies may temporarily lose this insight until a radar fallback is added.
About the project
Disclaimer
Not an official government tool. Neer Vazhvu is an independent, open-source project. It is not affiliated with, endorsed by, or connected to any water utility, municipal corporation, pollution control body, or other government agency whose published data it cites.
Informational purposes only. All data, estimates, and forecasts are provided “as is” for general awareness. Always refer to official CMWSSB advisories for critical decisions.
No personal data collected. Neer Vazhvu does not collect, store, or process any personal information. There are no user accounts, cookies, or analytics trackers.
Open Source
Neer Vazhvu is fully open source. The code, data pipeline, and methodology are transparent and available on GitHub. Contributions, bug reports, and data corrections are welcome.
View on GitHubSupport this project
Neer Vazhvu is free and open source. If you find it useful, consider supporting us on Patreon to help cover satellite data, hosting, and API costs.
Support on Patreon