AquaResilience: Open Water Data to Flood & Drought Decisions

Explainable flood and drought resilience for cities: live open data, early warnings, what-if scenarios and AI briefings.

Comment

Inspiration

European river cities are increasingly exposed to flash flooding, yet most municipalities still rely on fragmented tools: one dashboard for rainfall, another for river gauges, a third for weather forecasts, and no single place that turns all of it into an actionable picture. For Track 6 - Resilience Informatics, we set out to build what a city's emergency and planning teams actually need: one platform that ingests real environmental data, scores flood risk honestly, warns early, and explains why in plain language - starting with a live deployment for Toulouse Métropole and architected from day one to scale to any city in Europe.

What it does

AquaResilience (OneAquaHealth) is a multi-city flood-resilience monitoring platform built around a Command Center dashboard:

Live environmental signals - water level, precipitation, temperature, humidity, wind, pressure and UV, pulled from real connectors (Open-Meteo for weather, national hydrology APIs such as Norway's NVE HydAPI and Austria's eHYD for river gauges), scoped per city and per river. A deterministic risk engine - a transparent, explainable P2 scoring model (not a black box) that produces a current risk score and a predictive trajectory, with honest "insufficient data" states instead of fabricated numbers for cities that aren't fully live yet. Early warnings that trigger automatically when risk crosses a threshold, independent of and never dependent on the AI layer. An AI Situation Brief - an LLM-generated natural-language summary of the current situation per city, with recommendations, confidence, and language-mismatch detection, generated on a fair round-robin schedule across every live city within a single fixed daily budget (so cost stays predictable no matter how many cities are added). A Scenario Simulator and a Resilience Map for exploring "what-if" flood scenarios geographically. Role-based access, source-health monitoring, and a settings area for admins to manage languages, data sources, and AI configuration - all translated into 9 languages (English, French, Spanish, Portuguese, Norwegian, Greek, German, Italian, Dutch).

How we built it

Backend: FastAPI + SQLAlchemy + Alembic on PostgreSQL/PostGIS, with a connector framework that normalizes readings from heterogeneous national APIs into one schema, a scheduler for ingestion and AI-brief rotation, and Redis for rate-limiting and caching. Frontend: Vue 3 + TypeScript + Vuetify, with Pinia stores for city/auth/UI state and a fully reactive multi-city dashboard. AI layer: a provider-agnostic intelligence service (OpenAI-compatible) that builds a per-city environmental snapshot, prompts for a structured brief, and persists it - deliberately decoupled from the deterministic risk engine so the AI can fail, be disabled, or run out of budget without ever affecting flood warnings. Infrastructure: Docker Compose for dev and production, with a hardened nginx reverse proxy (TLS via Let's Encrypt or self-signed, HSTS, security headers) as the only public entry point, Postgres/Redis kept fully internal, and an HTTP-only deployment path for fast demo-subdomain rollouts before a certificate is ready. Testing: 138+ backend tests (pytest) covering connectors, risk scoring, the AI brief lifecycle, and city-scoping, plus TypeScript type-checking, ESLint, and production builds gating every change.

Challenges we ran into

Real APIs are messy. Norway's NVE HydAPI, for example, doesn't always return the nearest station first - we had to fix station selection to pick the one closest to each city center rather than trusting API order, then turn that fix into a self-healing Alembic migration so it applies automatically on every deployment, dev or prod. Keeping AI costs bounded while being fair across cities. Early on, the AI Situation Brief was hardcoded to one city. Redesigning it to serve every city meant building a round-robin scheduler that always analyzes whichever live city has gone longest without a fresh brief - without changing the platform's fixed daily LLM request budget. Being honest about missing data. Rather than showing fake numbers for cities without a live connector yet, every endpoint was built to degrade gracefully and say so clearly, in the UI and in the AI's own language. Internationalization at scale. Every user-facing string - including dynamically generated ones like "Water Level - Garonne" - needed to work correctly across 9 languages and across cities with entirely different river names, not just a single hardcoded city. Production hardiness without losing demo speed. Balancing a fully hardened HTTPS deployment (Let's Encrypt, HSTS, internal-only databases) against the practical need to stand up a working public demo on a new subdomain in minutes.

Accomplishments that we're proud of

A platform that treats flood risk honestly - deterministic where it must be, AI-assisted where that adds real value, multi-city from the architecture up rather than bolted on, and already production-deployable behind a real reverse proxy with automated certificate renewal.

What we learned

That resilience software lives or dies on its handling of the unhappy path - a missing API key, a city with no connector yet, a budget-exhausted AI provider - and that building those states in from the start, rather than patching them in later, is what makes a monitoring tool trustworthy enough for an emergency team to actually rely on.

What's next for AquaResilience

Expanding real connector coverage to more European cities, white-labeling the platform for individual municipalities and consortium partners, and deepening the AI layer with multi-day forecasting narratives.

Try it

Judges: sign-in credentials are provided privately in the "Additional info" section of this submission.

Built With

Share this project:

Updates

Submission history