BATO – Satellite Road-Access Intelligence for Floods

Radar maps of which roads a flood blocked, which ones the satellite couldn't see, and which villages may have lost road access, plus an AI copilot that answers in English.

Comment

Inspiration

On 26 August 2026, part of a glacier in northern Nepal collapsed and sent a flood of water, mud and debris down the Bhote Koshi–Trishuli valley. Reading about it, one question kept coming back to us: when roads and phone lines are gone, how does a rescue team know which villages they can still reach? Satellites pass over every valley, but a raw radar image doesn't answer that question. We wanted to build something that does, and is honest about what it can't see. We called it BATO, which means "road" in Nepali.

What it does

BATO takes Sentinel-1 radar images from before and after a flood and the OpenStreetMap road network as it was before the event, and gives every road one of three states:

  • Blocked: the radar shows new open water on the road.
  • Observed open: the radar could see the road and found no flood signal.
  • Unobservable: steep slopes, radar shadow or layover hid the road, so we don't know.

It then checks which settlements can still reach a town, hospital or road out of the valley, and separates confirmed results from unverified ones. For the Trishuli case study:

  • 30 road segments in 9 stretches are blocked (1.2 km).
  • 463.7 km of road was observed open.
  • About 2,942 km was unobservable, because 91.2 % of the scene couldn't be assessed, mostly due to steep terrain.
  • Of 265 settlements, 1 is connected on observed roads and 163 have unverified access. None is confirmed cut off, and 101 had no mapped road even before the flood.

Every number in the dashboard links back to hash-verified evidence: you can click a blocked road and see the three radar passes behind it.

Our AI component is a SITREP Copilot. Rescuers can ask questions in English or Nepali ("How many settlements have unverified access?"), and Gemini answers using only our verified results. The server checks every number in the answer against the evidence it cites; if a number isn't there, the answer is withheld. Questions our data can't answer, like population or casualties, are declined. The English one-page situation report is a fixed template with no AI. The Nepali version is an AI translation, accepted only if every number and attribution line matches the English source.

How we built it

  • Data: Sentinel-1 GRD images from the Copernicus Data Space (29 June, 16 August and 28 August 2026, all from the same orbit track so they can be compared pixel by pixel), Copernicus DEM GLO-30 for terrain, and a pre-event OpenStreetMap snapshot (25 August) from the ohsome API.
  • Processing: ESA SNAP for calibration, speckle filtering and terrain correction, then our own Python pipeline for a rule-based change-detection flood map, road blockage and three-graph settlement access analysis.
  • Dashboard: a plain JavaScript and MapLibre map that runs offline on a local terrain basemap, now also hosted on Render.
  • Copilot: a Python server that calls Gemini, keeps the API key away from the browser, and checks every answer before showing it.

Challenges we ran into

  • Mountains are hard for radar. Most of the valley is so steep that the satellite simply can't see the roads. We decided early that "can't see" must never become "safe", and the whole design follows from that.
  • Debris doesn't look like water. We built an experimental debris detector, tested it against a control scene with pre-registered criteria, and it failed. So we rejected it and left it out of the official result instead of keeping a nicer-looking number.
  • Not overclaiming. It was tempting to call 163 settlements "cut off". They aren't confirmed cut off; they're unverified, so that's what BATO says.
  • Keeping the AI honest. Making sure the language model never invents a number took more work than calling the model itself.

Accomplishments that we're proud of

  • An end-to-end chain from raw radar data to a responder-facing answer, with an evidence trail behind every claim.
  • An honest comparison with the official Copernicus EMSR927 maps, done only after the results were final, under a protocol we froze before computing any metric.
  • A copilot that can say "our data doesn't support that" instead of making something up.

What we learned

Saying "we don't know" clearly is often more useful to a rescuer than a confident guess. We also learned a lot about SAR geometry, OSM data quality and how much careful checking an AI answer needs before you can trust it.

Limitations

  • Our flood thresholds are provisional and the system is not validated.
  • Radar picks up open water, not mud, debris or structural damage. Compared with EMSR927 (used only for evaluation), we missed most of the damaged roads, and flood metrics couldn't be calculated because EMSR927 has no flood class.
  • Sentinel-1 passes only every few days, so BATO maps the state after an event; it can't warn ahead of a sudden glacier collapse.
  • We don't predict damage to buildings or bridges, and we don't use Sentinel-2 yet.
  • Access results depend on how complete the pre-event OpenStreetMap is.

What's next

Adding a descending radar pass to see more of the steep terrain, using Sentinel-2 when the sky is clear, building a debris signal that passes its control test, and validating on more events.

Attribution

  • Contains modified Copernicus Sentinel data 2026.
  • Produced using Copernicus WorldDEM-30 © DLR e.V. 2010–2014 and © Airbus Defence and Space GmbH 2014–2018 provided under COPERNICUS by the European Union and ESA; all rights reserved.
  • © OpenStreetMap contributors.
  • Evaluation reference only: European Union, Copernicus Emergency Management Service data (EMSR927).
  • Kuro Siwo: Bountos et al., 2024 (used only for preliminary, non-official model tests).

Built With

Share this project:

Updates

Submission history