FloodLens

Inspiration

FloodLens was built for WeatherWise Hack 2026 around a simple emergency question: if water is rising near this place, what should someone do first?

Many weather tools show maps, numbers, or alerts, but they often leave a normal person to interpret the risk alone. I wanted FloodLens to start with the decision: local risk, source trust, first preparedness action, and then the visual proof.

What it does

FloodLens is a flood-awareness and preparedness PWA for desktop and mobile.

It combines public flood, terrain, weather, alert, radar, rainfall, and disaster-context data into a clear local status screen. The app shows:

a Decision Cockpit with risk, confidence, first action, and source health;
AR / 3D water-height context when a physical basis is available;
terrain and map views for desktop inspection;
Live Warnings with source details;
a mobile flow that keeps the main decision readable on a phone;
honest labels for real, advisory, unavailable, and demo-assisted states.

FloodLens is not an official evacuation system. It is preparedness guidance that keeps official channels and source limits visible.

How I built it

I built FloodLens as a React + Vite PWA with a client-first architecture and local/serverless API adapters.

The frontend uses React for the decision interface, MapLibre for maps and terrain context, and Three.js for AR / 3D flood visualization. The data layer integrates multiple public sources:

NOAA NWPS for US gauge stage and datum;
Open-Meteo Elevation, Flood, and Forecast APIs;
NWS alerts for official US alert context;
USGS Water Services for gauge cross-checks;
GDACS for global disaster alerts;
RainViewer for radar context;
NASA POWER for recent precipitation context;
OpenFEMA for historical US flood disaster declarations.

A key design rule was data honesty. FloodLens does not convert river discharge directly into local water depth. It only treats a water-height visualization as physical when the needed terrain, stage, and datum basis exists. Otherwise it labels the state as advisory or unavailable.

Challenges

The hardest part was keeping the product useful without overstating the data.

Flood data is uneven across regions. NOAA stage and datum data can support a stronger physical estimate in some US locations, while global discharge data is useful but not the same as local flood depth. I had to design the product so missing coverage is shown as a truth boundary, not hidden as a failure.

Another challenge was presentation. The first version explained too much and showed too little, so I rebuilt the demo to show both the desktop website overview and the smartphone flow with real actions.

What I learned

I learned that disaster UX needs restraint. A flood app should not just look dramatic; it must explain what is known, what is estimated, what is unavailable, and what action is safe to take next.

I also learned how important source provenance is. Judges and users should be able to see where the risk signal came from and why the app is allowed to make a certain claim.