About Neer Vazhvu

What you are seeing

• Sky-blue circles (720 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 (430 edges): predicted tank-to-tank cascade links. Each upstream tank has at most one outflow.
• Amber lines (50 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_type in {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.geojson we already use on the map.

Algorithm (per tank)

1. Compute centroid; sample DEM elevation and D8 flow direction at that point in a single batched Earth Engine call.
2. Find all other tanks within 3 km whose elevation is lower.
3. Reject candidates that fall outside ±67.5° of the upstream tank's flow-direction bearing - terrain-aware directionality, not just "is downhill".
4. Reject candidates whose straight-line edge would cross a mapped river segment - water doesn't flow across rivers.
5. Pick the single steepest remaining candidate (elevation drop / distance) as this tank's outflow.
6. For tanks with no tank-to-tank outflow but a flow direction pointing to a river within 2 km: mark drains_to_river and 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 km² 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 Chennai; 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 predicted only. A future iteration will cross-check predicted edges against OSM waterway=* tags and Sentinel-1/2 monsoon imagery, then label each edge as intact / partial / broken / encroached.
• OSM water_type=reservoir is 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 Chennai: 126 high (29%), 248 medium (58%), 56 low (13%).

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. Maximum cascade depth in Chennai is 6.
• 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_reason field distinguishing genuine basin orphans from data-coverage gaps. See the bucket-by-bucket breakdown above.

Parameter rationale + sensitivity

Each tunable parameter was chosen with a stated rationale. The sensitivity tables below show how each output statistic responds when the parameter is varied. Generated by the cascade pipeline's sensitivity stage; raw data at public/data/cascade/chennai-cascade-sensitivity.json.