Urban Flood Nowcasting System (Drainage and Rainfall Coupling)

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   Stormwater network topology and pipe capacities are held by municipal corporations and are not public, so the graph at the centre of this system has to be invented — and a hydraulic model of a fictional drainage network predicts fiction

2. It gets worse

   Metre-scale urban terrain is equally unavailable, and the freely available elevation data cannot resolve the difference between a road and the drain beside it, which is the entire question

3. Still reading?

   Depth in centimetres is a very precise claim to make from invented inputs, and presenting it that way invites exactly the scrutiny the model cannot survive — grade the risk instead

4. And the finisher

   Coupled surface-network hydraulics is a specialist discipline and a naive implementation will produce plausible-looking but physically wrong results that nobody in the room can check

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  2/5

  You have picked a fight with physics, procurement, or both. One of them always wins.

  The statement's central mechanism is a graph of the city's stormwater network with per-pipe hydraulic capacity, and that data is held by municipal corporations and is not published — without it the drainage half is a graph you invented, and the metre-scale terrain the surface routing needs is equally unavailable for Indian cities.

• Innovation scope

  3/5

  Mildly interesting. The novelty will not carry the room; the build has to.

  The coupled architecture, the graph representation of the drain network and the surface routing approach are all specified, leaving the hydraulic solver choice and the coupling scheme between surface and network as the genuinely open decisions.

• Clarity

  5/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  Among the most precisely specified statements in this block — it fixes the lead time, states the output as water depth in centimetres at street level, defines the drainage representation down to what the nodes and edges are, and specifies both the dashboard and the routing API.

• Acceptance potential

  2/5

  The numbers do not like you. Bring something the numbers cannot see.

  The drainage graph is the explicit core of this statement and it is not obtainable for any Indian city, so submissions will synthesise the network and then demonstrate a model of a drainage system that does not correspond to the one under the streets — producing authoritative-looking depth maps with no basis.

• Effort

  Massive

  A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

  Surface routing over a fine terrain model, a hydraulic network solver on a city-scale graph, the coupling between them, a live dashboard and a routing API is five components, and coupled surface-network hydraulics is a specialist engineering discipline in its own right.

• Demo-ability

  Medium

  Demoable, if you rehearse it. Nobody rehearses it.

  Predicted flooded junctions checked against locations actually reported waterlogged on a documented day is honest and persuasive, but the map's credibility rests entirely on the terrain and drainage data beneath it and a judge will ask about both.

• Data

  None supplied

  No dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.

  Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.

The demo they will have already seen 🪞

Somewhere around 140–330 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• The graph representation of the drain network is genuinely the right abstraction and is elegantly stated — modelling surcharge and backflow as capacity violations on edges is both correct and computationally tractable
• Established open hydraulic modelling engines exist for exactly this coupled surface-network problem, so you can build on validated hydraulics rather than writing a solver
• Crowd-reported waterlogging locations from documented flood days are findable, giving you at least a qualitative validation target for which junctions flood even without measured depths