floodcast-gurugram

Floodcast-Gurugram is a civic-tech flood forecasting web app for Gurugram (Gurgaon), India. It exists to answer one narrow question that ordinary weather apps and lists of flood-prone spots do not: given the live rainfall forecast, will a given route flood in the next few hours, when exactly does the flooding start, and when does it clear. Rather than a bare risk score, it always attaches a time window to each verdict. What it does - Time-windowed risk: live hourly rainfall is compared against each of 73 registered flood points to compute when a point floods and when it clears, using IMD-style warning bands plus explicit start and clear times. - Route verdicts: two place names are resolved and hotspots within a 1.5 km buffer of the straight line between them are found; the app reports the worst point and worst window. - Hourly timeline: users can scrub forward through the forecast and watch the map, verdict and register re-read at that hour. - Rainfall simulator: since Gurugram is dry most of the year, users can ask what happens at 20, 35 or 55 mm/hr and watch the register respond through the same engine as the live verdict. - Citizen reports: a camera photo, a GPS fix with its accuracy, and an observed depth. Reports are stored on the device first, and moderated before public display. - CPCB National AQI: the Indian 0-500 scale computed from a 24-hour pollutant mean, instead of a vendor 1-5 index. Data provenance is treated as a product feature. Of the 73 registered points, 39 are sourced: 4 named in MCG's Zone 1 hotspot list, 26 recurring in two or more independent news reports from 2022 to 2025, and 9 from dated, on-record institutional sources for the current monsoon season. The remaining 24 are described as plausible but unconfirmed watchlist entries, and 10 are reconstructed placeholders kept only to preserve MCG's official 36-point count. The README states plainly that expanding the register diluted average confidence relative to the original 36, and that a What's real tab in the app exposes the tiers, with marker fill encoding certainty on the map. All 73 rows are flagged as having unverified coordinates; a script audits them against OpenStreetMap and writes a report but never edits the data. Route matching is explicitly straight-line corridor matching, not turn-by-turn routing, and this is disclosed in every route answer. The learning loop Reported places within 500 m of each other are treated as one place. A place is promoted to a flood point in its own right after 3 reports across 2 separate days, drawn separately and never merged into the 73 researched rows. A measured threshold for a point is published only after 2 separate days at knee-deep or worse with over 1 mm/hr of rain behind it; the published figure is the lightest rain ever actually seen to flood that place. Open-Meteo supplies the rainfall that fell before each approved report. Reported counts, calibration pairs and observed thresholds are writable only by database triggers, enforced by column grants, so a moderator cannot hand-type a measurement. Architecture and stack The app is a static site: React 19 with TypeScript, built with Vite (rolldown) and rendered with Leaflet, shipped as an installable offline-first PWA and deployed on static hosting. The hotspot register (62 KB of static rows) is baked into the bundle, so the map and list render before any network request. Scoring is pure arithmetic over those rows and runs on the device. The only always-on call is Open-Meteo, which needs no API key and allows cross-origin access, so it is called from the visitor's own IP; Nominatim is used only as a fallback for places not in the register. Supabase is optional: without it the forecast tool still works fully and reports stay on the device. The README documents a prior FastAPI-on-a-container version whose cold start measured 42.7 seconds and whose forecast calls were permanently rate-limited, motivating the all-client redesign; the total bundle is stated as about 160 KB gzipped. Data pipeline There is no trained model. Four deterministic Python generators with fixed seeds build the register in stages (36 rows frozen to MCG's structure, then 36 to 64, then 64 to 73), followed by an export step that emits the JSON the app ships and an integrity check. Continuous integration regenerates all stages on every push and fails if output differs from what is committed; contributors are directed to edit generators, not CSVs. GMDA's published drainage network (4,701 mapped stream segments, 10 watersheds) was fetched for catchment areas, but that data is deliberately excluded from any risk score, and a test enforces this. Notably, the README reports that median catchment size does not correlate with severity tiers, and this negative result is published. No overall accuracy figure is claimed, since no ground-truth flood log exists; the README instead reports a response curve (10 mm/hr floods nothing, 20 mm/hr hits the 10 worst chowks, 35 mm/hr reaches 44 of 73 points, 55 mm/hr sustained covers the whole register) and a sourcing rate of 53 percent. Caveats for prospective users All coordinates are approximate placements rather than geocoded positions; thresholds began as engineering estimates by severity tier, not measurements, and are only replaced as citizen evidence accumulates; route analysis uses a straight-line corridor rather than real roads; and the register, while sourced in part, is not an official government dataset. A live demo, an MIT licence, and dedicated provenance documentation accompany the project.