Crystal

Ins## Inspiration

When floods hit, the first question for responders isn't "where is the water?" It's "who is cut off, and who do we reach first?" Satellite radar can see flooding through clouds and at night, but raw imagery doesn't tell a rescue coordinator which village has lost its road to the nearest hospital. We built FloodOne to close that gap: turn radar flood signals into a ranked, explainable list of communities to prioritise.

What it does

FloodOne is a flood-response intelligence dashboard. It:

• Detects candidate flood extent from Sentinel-1 SAR change signals (specular radar backscatter anomalies).
• Finds severed roads by flagging road segments that exceed a submersion threshold, and separates them from the still-passable transit network.
• Identifies cut-off communities, meaning settlements with no usable route to emergency medical facilities.
• Ranks them in a Response Priority Queue using population, urgency and isolation, with a transparent ranking rationale for every score, so a coordinator can see why a place is ranked #1.
• Shows hospitals and relief shelters, lets you toggle each operational layer, and supports data import and export.

The demo runs on a clearly labelled synthetic practice scenario. It is an illustrative benchmark, not observed ground data, and the app says so on screen along with a "Scientific Caveats" panel.

How we built it

• Frontend: TypeScript + React with Vite, with a state store driving the map and the priority queue.
• Mapping: raster basemaps from CARTO on OpenStreetMap data, with custom layers for flood signal, severed and passable roads, settlements and facilities.
• Ranking logic: a scoring model combining population at risk, urgency and road isolation, returning both a score and a plain-language rationale.
• Backend and security: an Express server hardened with Helmet and a strict Content Security Policy.
• Deployment: Vercel. [Add: AI tools or other services you used, if the rules ask for it.]

Challenges we ran into

• Explainability over a black box. It would have been easy to output a single score. Making every ranking traceable to its inputs took more design effort but matters for trust in a real emergency.
• Honest data. We didn't have verified ground truth, so we built a synthetic scenario and labelled it prominently rather than implying real results.
• Basemap API changes. Partway through, CARTO began requiring an API key on its basemaps, which stamped a watermark on our tiles. We fixed our tile requests to send the key correctly.
• Deployment friction. Getting the build, environment variables and output directory configured correctly on Vercel took several iterations.

Accomplishments that we're proud of

• A full pipeline from radar signal to a prioritised, explainable rescue queue.
• A UI where a responder can click a community and immediately see why it ranks where it does.
• Being upfront about limitations instead of overselling.

What we learned

• In disaster response, trust and transparency matter as much as accuracy.
• SAR data is powerful for flood mapping, but flagged areas are only candidates until confirmed on the ground.
• Small infrastructure details, such as API keys, content security policies and build configuration, can block a working product.

What's next for FloodOne

• Replace the synthetic scenario with real Sentinel-1 scenes and validated flood events.
• Ingest live road and settlement data and incorporate ground reports from responders.
• Add routing for relief convoys and shelter capacity.
• Validate rankings with disaster-management practitioners. ## What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Crystal

Built With

• carto
• css
• express.js
• geospatial
• helmet
• leaflet.js
• node.js
• openstreetmap
• react
• sar
• sentinel-1
• typescript
• vite