Disaster Response

Disaster response is the domain where the value of an image is measured in hours, and where the analyst is rarely the person who acts on the result. A flood or a wildfire produces a decision backlog — evacuations, road closures, crew tasking, aid requests, insurance reserves — long before it produces a clean map, and the people holding those decisions work from partial information under time pressure. This page is about the domain rather than the method: who needs the maps, on what clock, and what turns a technically correct extent into something a response can actually use. The mechanics live elsewhere on this site — Flood Mapping is the workflow for where water is sitting that should not be, and Burn Severity Mapping is the workflow for how hard a fire changed the ground. Read those for how; read this for for whom, on what clock, and what makes the answer usable when it arrives.

The decisions these maps are actually feeding

“Disaster response” is not one audience, and the same flood or burn map serves several with conflicting needs. Incident command and emergency management want a common operating picture now — where the hazard is, what it threatens, and where crews and evacuation orders should go in the next operational period. Humanitarian and civil-protection agencies want population exposure: how many people, which settlements, which routes, so that shelter, water, and access can be planned and, in an international disaster, so a formal charter activation can be justified. Insurers and recovery funders want a defensible footprint and a damage estimate to set reserves, triage claims, and release payouts. Infrastructure and utility operators want to know which specific assets — substations, pumping stations, road segments, rail — fall inside the affected area so they can dispatch inspection and restoration. These audiences report on different units, tolerate different errors, and above all run on different clocks; naming which one the map is for is what keeps a project from producing a faithful extent that arrives after the decision it was meant to inform.

The response clock, and why latency beats accuracy early

The defining feature of the domain is that the value of a map decays with time, and steeply. In the first hours of a flood or the active phase of a fire, a rough extent delivered while crews are still being positioned is worth more than a meticulous one delivered after the operational period it belonged to has closed — the same trade the agriculture domain frames around phenology, except here the window is measured in hours rather than weeks. This inverts the usual instinct to refine. A response product runs on a clock set by the event and by the incident-action-planning cycle, not by the analyst’s sense of completeness, and being right after the tasking meeting is indistinguishable from being wrong. It also means the sensor that can see the event at all often beats the one that would see it best on a clear day: the storms that cause floods also fill the sky with cloud, so a workflow that can only wait for an optical pass may have nothing to offer during the peak — which is why radar carries so much of the acute phase, as Flood Mapping works through. Latency here is not just processing time; it is revisit, tasking, downlink, and delivery combined, and it is the number most worth optimising.

Activation-time mapping versus post-event assessment

Two jobs hide under the word “response”, and conflating them produces bad products. Activation-time mapping is the acute phase: fast, coarse, good-enough extent to direct crews, evacuations, and access decisions while the event is still unfolding. Post-event damage assessment is the recovery phase: slower, more careful work that quantifies what was lost, feeds insurance and reconstruction funding, and establishes a baseline for monitoring recovery — the very distinction between initial and extended severity that Burn Severity Mapping is careful to separate, seen from the response side. The two want different things from the imagery: the first prizes speed and coverage and tolerates a rough edge; the second prizes a defensible, well-validated footprint because money and legal exposure hang on it. A product designed for one is usually wrong for the other, and stating which phase you are serving is the first honest thing a disaster map can do.

What makes a product usable in a response

Four things separate a map a response can act on from one that merely describes the event. The first is the reporting unit: responders act on communities, road segments, parcels, service areas, and administrative wards, so an extent that is not already summarised into exposure by those units pushes the hardest work onto the person with the least time. The second is a plain confidence statement — where cloud forced a gap, where the estimate is thin, where a class boundary is uncertain — because a responder who cannot tell a firm result from a guess will either over-trust it into a bad evacuation call or discard it entirely. The third is delivery format and channel: a result that cannot reach the incident’s mapping system, the field tablet, or the situation report in a form it can ingest is, operationally, not delivered. The fourth, and the one most specific to this domain, is the asymmetry in the cost of being wrong. Missing real impact and overstating it are not symmetric errors: a missed inundated neighbourhood or a missed high-severity slope can cost lives or leave people unwarned, while a false positive wastes a crew and erodes trust in the next map. Which error to prefer is a deliberate domain judgement — often erring toward flagging possible impact in the acute phase and tightening the footprint for the recovery assessment — not a default inherited from a threshold.

Where the domain stays hard

Validation is scarce exactly when it matters most: ground truth during an active disaster is fragmentary, dangerous to collect, and often arrives after the decisions have already been made, so acute-phase maps are trusted with far less field confirmation than any analyst would like. Cloud, smoke, and the timing of an overpass can mean the imagery simply does not exist for the hours that matter, and no amount of processing conjures an observation that was never captured — the honest response to a gap is to say so, not to fill it. Urban and vegetated settings hide the signal: water under a canopy or among buildings, and damage beneath an intact roof, are hard to see from above, so a clean extent can quietly understate the human impact. And the last mile is organisational, not technical: a correct map that does not reach the right desk, in the right format, inside the operational period, changes nothing — the discipline of getting a good-enough answer to the decision on time is the actual product.

Where to go next

The workflow mechanics live in Flood Mapping, which walks the extent-and-change question from framing to a reproducible result, and Burn Severity Mapping, which does the same for fire effect. Both lean on the multi-temporal reasoning the Change Detection concept develops, on the Cloud Masking discipline that keeps a shadow from reading as impact, and — in the cloud-covered acute phase — on the all-weather sensing the SAR Basics concept explains. As with the rest of this site, none of this framing depends on a particular tool: a browser environment like Google Earth Engine is one convenient way to run an event, and a Python stack (rasterio, xarray, geopandas) is another, and the decision the map has to serve, on the clock the event sets, is what decides whether either was worth pointing at the disaster.