TRINETRA

Inspiration## Inspiration

After a disaster, responders need to decide where to check first, often before reliable ground reports arrive. A satellite image alone cannot tell them whether a bridge has failed or a road is safe. We built TRINETRA to connect what a satellite can observe with what a field team needs to verify, while showing where the evidence runs out.

What it does

TRINETRA processes a selected pre- and post-event Sentinel-1 radar pair, maps suspected flood evidence, and keeps unsupported terrain visibly unknown. It combines those layers with historical OpenStreetMap roads, bridges, buildings, and settlements in an interactive dashboard. The system highlights mapped infrastructure intersecting candidate areas, calculates conditional car and foot access to fixed town or medical destinations, and exports a one-page situation report, detailed results, and a traceable ZIP.

The access analysis gives two bounds: one assumes unknown road segments remain open; the other assumes they are closed. These are planning scenarios, not claims that a road is damaged or safe.

How we built it

Our pipeline combines Sentinel-1 preprocessing, a conservative baseline, an experimental flood-AI checkpoint, optional terrain-based HAND screening, historical OpenStreetMap extracts, and road-network analysis. A Python/FastAPI backend connects these steps to a React/TypeScript map dashboard. Exports record source scenes, timestamps, hashes, method settings, data availability, and limitations so a reviewer can trace the result.

What we demonstrated

For the saved Trishuli case, the completed Experimental AI + HAND run produced 0.6702 km² of candidate evidence. Candidate areas intersected 26 mapped road features, 5 bridges, and 84 buildings. Conditional car access showed 3–11 disconnected settlements among 11 assessed; foot access showed 0–12 among 12 assessed. The wide ranges matter: only 6.46% of the area was assessable by the selected method, and unsupported terrain was retained as unknown.

We also compared frozen outputs with the EMSR927 Bidur reference maps for spatial context. Those reference polygons describe landslides and mass movement, so we do not present the comparison as flood-detection accuracy.

Challenges, learning, and next steps

The hardest problem was preventing a polished map from implying more certainty than the data supports. Satellite revisit time, terrain effects, incomplete mapped roads, and provisional model thresholds all affect interpretation. We made uncertainty, source availability, and conditional access explicit in both the interface and reports.

TRINETRA is a field-triage prototype, not a minute-ahead warning system or a certificate of road safety. Next, we would validate it against more event-specific flood labels and field observations, calibrate scores, and test the full workflow across additional regions and dates.

Data and model credits: Copernicus Sentinel data and Copernicus DEM; © OpenStreetMap contributors (ODbL), with historical extracts via HeiGIT ohsome; Kuro Siwo training data (Bountos et al., NeurIPS 2024); and Copernicus Emergency Management Service EMSR927 reference products.

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for TRINETRA

Built With

• copernicus-dem
• esa-snap
• fastapi
• geojson
• maplibre-gl-js
• networkx
• ohsome-api
• openstreetmap
• python
• pytorch
• react
• sentinel-1
• typescript
• vite