FloodSense

FloodSense turns IMD and CWC flood data into ward-level AI predictions and multilingual voice, SMS, and WhatsApp alerts, giving residents life-saving minutes before water reaches their streets.

Comment

Inspiration

Every monsoon, Indian cities lose lives, property, and workdays to flooding that official systems saw coming — just not at a scale anyone could act on. IMD and CWC forecast rainfall and river levels accurately, but at basin or gauge-station resolution. That data dies in a municipal control room; it never reaches a specific street or the resident standing in it. And even where alerts exist, they assume a smartphone and a data connection — which a large share of at-risk residents don't have. We kept coming back to the same observation: the prediction problem is basically solved. The delivery problem to the last mile isn't. FloodSense exists to close that specific gap, not to reinvent flood forecasting from scratch.

What it does

FloodSense turns basin-scale, open government hydrological data into ward-level, block-granular flood risk scores, and pushes alerts through channels that don't require a smartphone. It ingests rainfall and river-telemetry from CWC's National Water Data Portal and India-WRIS, combines that with IMD nowcasts and elevation/drainage GIS layers, and runs it through a physics-informed hybrid model to produce a 0–100 risk score per ward with a time-to-impact estimate. Citizen reports (photo/text via a low-bandwidth form or missed-call trigger) validate and correct predictions in near real time. When a ward crosses a risk threshold, residents get voice calls, SMS, and WhatsApp alerts in the local language — and municipal officials get a live ward-wise risk map on a dashboard to prioritize response.

How we built it

We scoped FloodSense as a four-layer pipeline: Data → Hybrid Prediction → Validation → Multi-channel Alert.

  • Data layer: scheduled ingestion jobs (Airflow/cron) pull hourly rainfall and river-level telemetry from CWC/WRIS and IMD nowcast data, storing it in PostgreSQL + PostGIS alongside OpenStreetMap/SRTM elevation and drainage layers.
  • Prediction layer: a physics-informed hybrid model — a conceptual rainfall-runoff hydrological module constrains an LSTM/GRU network (PyTorch) — so the neural net learns only the nonlinear residual the physics equations miss, rather than modeling flood dynamics from scratch. scikit-learn handles the ward-level risk scoring on top.
  • Validation layer: a lightweight, low-bandwidth citizen reporting interface cross-checks predictions against ground reports and logs mismatches for recalibration.
  • Alert layer: Twilio/Exotel for automated voice and SMS, WhatsApp Business API for multilingual push alerts — tiered by risk severity.
  • Dashboard: React + Leaflet/Mapbox rendering a live ward-wise risk map for municipal disaster-management teams.
  • Deployment: Dockerized, running on cloud free-tier/student credits (GCP/AWS/Azure), FastAPI as the backend.

The physics-informed modeling approach and the low-bandwidth, voice-first alerting pattern weren't new territory for us — we adapted a modeling technique from a prior project (physics-informed digital twins) and an accessibility pattern from another (voice-first alerting for underserved users), rather than building both from zero.

Challenges we ran into

  • Resolution mismatch: CWC and IMD data is genuinely reliable, but it's built for basin/gauge-scale forecasting, not ward-level. Gridding telemetry to ward boundaries and merging it correctly with elevation and drainage layers so the output actually reflects street-level risk — not a diluted basin average — was the core technical problem to solve, not an afterthought.
  • Physics vs. learned residual: getting the split right between what the hydrological rainfall-runoff equations should explain and what the LSTM/GRU should learn on top, so the model stays physically plausible even on sparse training data, took real iteration — a pure black-box model would have been easier but less trustworthy with limited data.
  • Data quality and latency: telemetry update frequency and cleanliness vary by station, and the CWC portal isn't a clean API — some scraping and cleaning work is unavoidable before the pipeline is production-solid.
  • Reaching people without an app: designing alert delivery around voice/SMS/WhatsApp instead of defaulting to an app meant more integration work (Twilio/Exotel, WhatsApp Business API) than a typical mobile-first hackathon build, but it's the part that actually matters for the people the system is meant to protect.
  • Keeping crowdsourced input trustworthy: citizen reports are valuable for validation but need moderation/spam-filtering to avoid corrupting the model — a layer that's easy to underscope under deadline pressure.

Accomplishments that we're proud of

  • Designed a forecasting approach that's hyperlocal by construction — ward/block-level risk — instead of another basin-level dashboard repackaged as "urban" flood prediction.
  • Built the alert layer around actual reach, not convenience: voice call and SMS as first-class channels, not an app with SMS as an afterthought, so the system serves residents who own no smartphone or reliable data.
  • Grounded the entire system in open, verifiable government data (CWC National Water Data Portal, India-WRIS) — no proprietary datasets, no new sensor hardware, so it's realistically replicable in any Indian city with existing telemetry coverage.
  • Designed the model to be explainable and data-efficient by construction — the physics constraint means it doesn't need the volume of training data a pure deep-learning model would, which matters for a system meant to be calibrated city by city.
  • Positioned FloodSense correctly relative to IMD/NDMA — as an augmentation layer that closes a last-mile gap, not a competing authority — which keeps the deployment story realistic instead of adversarial.

What we learned

  • The bottleneck in disaster response systems is rarely the science — IMD and CWC already forecast well. It's almost always delivery to the specific person who needs to act, and that's a design problem as much as a technical one.
  • Physics-informed modeling is a genuine way to make a small team's ML model trustworthy on limited data — constraining a neural net with domain equations rather than trusting it to learn hydrology from scratch changed how we thought about the whole prediction layer.
  • Designing for non-smartphone users first forces better system design overall — voice/SMS alerting has to be simpler, clearer, and less dependent on visual UI, which sharpened the whole product.
  • Open government data is more usable than its reputation suggests, but "publicly available" and "clean API-ready" are different things — real engineering effort has to go into ingestion and preprocessing, not just modeling.

What's next for FloodSense

  • Pull CWC and India-WRIS telemetry into a working, automated ingestion pipeline and validate the physics-informed hybrid model against historical inundation records for an initial pilot city/ward set.
  • Build and test the crowdsourced validation loop, including a moderation/spam-filtering layer, so citizen reports genuinely improve accuracy rather than introducing noise.
  • Integrate and test the voice-call and SMS alert flow end-to-end (Twilio/Exotel, WhatsApp Business API) in the local language, including a real accessibility check with non-smartphone users.
  • Calibrate the model per-ward using historical flood/inundation data, since accuracy depends on local calibration, not just national-level training.
  • Build out the municipal dashboard (React + Leaflet/Mapbox) with historical accuracy tracking and alert-delivery status, so officials can trust and act on it operationally.
  • Explore partnerships or pilot conversations aligned with NDMA and the Smart Cities Mission for a real deployment testbed beyond the hackathon.
Share this project:

Updates