Burn Severity Mapping

Burn severity mapping asks a focused question of the imagery: where a fire has passed, how much did it change the surface, and how confident are we in that estimate unit by unit. The canonical measurement is the differenced Normalized Burn Ratio (dNBR), computed by comparing pre-fire and post-fire imagery, but the number only means something inside a full workflow — from framing the assessment to interpreting the classified map. As with any concept-first workflow, the reasoning lives in the imagery and in the decisions you make about it, so it holds on whatever platform you compute with: a browser environment like Google Earth Engine is one convenient way to try each step, and a Python stack (rasterio, xarray, geopandas) is another, but neither changes what the workflow is doing or why.

Frame the assessment question first

A severity map is only as good as the question it answers, and that question fixes every later choice. Decide the burn perimeter and area of interest, the pre-fire reference window (a clear, representative period before ignition), and the post-fire window (soon after containment for initial severity, or a season later for extended effects once delayed mortality appears). Name the severity classes the project actually needs — unburned, low, moderate, high — and who consumes them: a rehabilitation team, a watershed hazard assessment, or a recovery-monitoring baseline. Writing these down turns a vague “map the fire” into a testable specification, because initial and extended severity answer different questions and a threshold that is honest for one is misleading for the other.

Acquire suitable pre- and post-fire imagery

The Normalized Burn Ratio uses near-infrared and shortwave-infrared reflectance, so the first practical step is choosing an optical sensor that carries a usable NIR and SWIR band with the spatial detail and revisit your perimeter needs. The tradeoffs are exactly those the Resolution concept lays out: a finer pixel resolves small stands and edges but narrows coverage and often lengthens revisit, while a coarser sensor maps a large fire quickly but blurs mixed-severity patches. The severity signal lives in the NIR and SWIR response the Spectral Bands concept describes — healthy vegetation is bright in NIR and dark in SWIR, and burning inverts that — so confirm both bands are present. Prefer calibrated surface reflectance over raw digital numbers, following the Digital Imagery concept, so a value means the same thing on the pre-fire and post-fire dates, and try to hold season and sun geometry as close as the archive allows to avoid confusing phenology with fire effect. In practice that means Sentinel-2 for a recent fire, and Landsat when the pre-fire reference has to reach further back than the newer archives go. A perimeter is usually a small part of each scene it falls in, so this is a workflow that rarely needs whole frames: fetching just the burned window is the read pattern cloud-optimized GeoTIFFs exist to support, and it is what keeps re-running the pair for extended severity a season later cheap.

Prepare the imagery before you measure

Preprocessing is where most severity errors are actually prevented. Clouds, cloud shadow, lingering smoke, and snow all corrupt an optical measurement, and an unmasked cloud edge is a classic source of fake severity — so apply a quality or cloud mask to both dates before computing anything, following the Cloud Masking concept. Confirm the two dates share a coordinate reference and are aligned to the same grid, as the Coordinate Systems concept requires; a half-pixel misregistration manufactures a bright ring of false change at every sharp boundary. Where terrain is steep, be aware that topographic shadow shifts between two dates with different sun angles and can imitate burn signal. The goal of this stage is a pre/post pair that is directly comparable — same footprint, same calibration, same masking rules — so any later difference reflects the fire and not the processing.

Compute NBR and difference it to dNBR

The Normalized Burn Ratio is the normalised difference of near-infrared and shortwave-infrared reflectance, NBR = (NIR - SWIR) / (NIR + SWIR), and it works because fire drives the two bands in opposite directions: combustion removes the NIR-bright canopy and exposes SWIR-bright char, ash, and bare soil, so NBR falls sharply over burned ground. Compute NBR the same way — same bands, same reflectance product — for the pre-fire and post-fire dates, then take the difference dNBR = pre-fire NBR - post-fire NBR. A higher dNBR indicates greater burn severity: unburned surfaces change little and sit near zero, while a high-severity stand loses most of its NBR and produces a large positive difference. This differencing is the multi-temporal reasoning the Change Detection concept develops — severity is not a property of one image but the departure between two — and computing both dates identically is what keeps the result a measure of fire rather than a change of method.

Classify severity into interpretable bands

A continuous dNBR image is data, not yet an answer. Turn it into the severity classes your question named by applying thresholds, which is the labelling step the Classification Basics concept covers. Published break points (for example the widely used USGS/CBI severity ranges) are a reasonable starting scheme, but they are not universal: fuel type, ecosystem, and sensor all shift where a boundary honestly falls, so calibrate the thresholds to local field observations of composite burn index where you have them rather than treating any single table as ground truth. Some workflows also apply a relativized dNBR to reduce the influence of pre-fire vegetation amount, which helps compare severity fairly across a mosaic of dense and sparse cover. Whatever scheme you choose, record the exact break points, because the classified map is only reproducible if the thresholds travel with it.

Separate real fire effect from confounders

Not every large dNBR is fire. Before believing the map, rule out the ordinary explanations: normal phenology between two seasonally offset dates, agricultural harvest, water and its variable level, exposed soil, snow, and step changes introduced by switching between sensors mid-record. Terrain shadow is the classic severity confounder — a slope that fell into shadow on only one date reads as change that has nothing to do with the fire — and residual cloud or smoke the mask missed does the same. The Cloud Masking and Time Series concepts both matter here, because a thin or seasonally-biased set of clear observations can bias the pre-fire baseline on its own. Treat a severity patch as a hypothesis and check whether it survives the obvious confounders before it is escalated for planning.

Produce outputs, interpret, and make it reproducible

The deliverables of a severity run are usually a set: a classified severity map, a table of burned area by class, and summaries rolled up to the units the project cares about — management unit, slope class, vegetation type, or watershed — so a stakeholder can rank and act on the result. Interpret them with domain context and state the uncertainty plainly: which areas were thin on clear pixels, where the cloud or terrain mask was doing heavy work, and how far the local calibration was trusted. Finally, make the run reproducible, the outcome that separates a durable workflow from a one-off. Record the perimeter and area of interest, the exact pre-fire and post-fire dates and sensor, the masking and reflectance products, the NBR/dNBR definition, the classification thresholds, and the summary units. With those written down the same assessment can be re-run for extended severity next season, audited by someone else, or ported from one platform to another without quietly changing what it measures — which is the whole point of a concept-first workflow.