Flood Mapping

Flood mapping asks the imagery a time-critical question: where is water sitting now that is not normally there, and how sure are we of the extent unit by unit. The workflow is distinctive because the best sensor depends on the weather — storms that cause floods also fill the sky with cloud, which blinds optical imagery exactly when it is needed, so radar often carries the event while optical imagery carries the calm baseline. This page walks the whole path, from framing the mapping question to interpreting a flood-extent result, rather than treating water detection as a single button press. 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 mapping question first

A flood map is only as good as the question it answers, and that question fixes every later choice. Decide the area of interest, the event window (the days of peak inundation versus a specific date), and whether you need maximum extent across the event or a date-specific snapshot — a receding flood looks very different depending on when you sample it. Name the reporting units the result must feed: communities, parcels, road segments, cropland, or watersheds. And fix the comparison explicitly: flood water only means something relative to a normal-conditions baseline, because a river channel that is always wet is not a flood. Writing these down turns a vague “map the flood” into a testable specification and decides, up front, which sensing approach the next step should reach for.

Choose a sensing approach and understand the trade-off

The central decision in flood mapping is optical versus radar, and each answers water differently. Optical sensors detect water through water indices such as NDWI and MNDWI, which contrast a green or near-infrared band against near-infrared or shortwave-infrared reflectance so that open water — dark in the infrared — stands out from land; these build on the same vegetation-and-surface response the Spectral Bands concept describes. Their weakness is fatal during storms: optical imagery cannot see through cloud, so the flood peak is often hidden. Synthetic aperture radar solves exactly that problem. As the SAR Basics concept explains, radar is an active microwave sensor that supplies its own illumination and passes through cloud, rain, and smoke, day or night — so it can image a flood while the storm is still overhead. Radar detects water by its backscatter: a calm water surface acts like a mirror, reflecting the pulse away from the sensor, so open water returns almost nothing and appears strikingly dark against rougher, brighter land. The honest framing is that neither sensor is “the” flood tool — radar carries cloud-covered peaks and vegetated or urban floods poorly, optical maps clear-sky extent cleanly — and many workflows use both.

Acquire baseline and event imagery

With the approach chosen, acquire two comparable observations: a baseline that represents normal conditions and an event image at or near peak inundation. For a radar workflow, prefer scenes from the same relative orbit and viewing geometry so backscatter is comparable date to date; for optical, hold season and sun angle as close as the archive allows. Match the spatial detail to the reporting units, using the trade-offs the Resolution concept lays out — a finer pixel resolves individual parcels and narrow inundation but narrows coverage, while a coarser, more frequent sensor captures a fast-moving event over a large basin. Prefer calibrated products over raw digital numbers, as the Digital Imagery concept advises, so a value means the same thing on the baseline and the event date and any later difference reflects the water rather than the processing. Where the workflow takes the optical route, that pair usually comes from Sentinel-2. Whichever sensor you settle on, finding the two dates is a STAC catalog query rather than a manual browse, which is what makes a narrow event window tractable at all. The deadline constrains that step as much as the weather does: an extent map is wanted within hours, and staging whole scenes across a basin spends most of that budget on transfer, so flood work leans hard on the cloud-native habit of reading only the windows the map needs out of imagery left where it is.

Prepare the imagery before you delineate

Preprocessing differs by sensor, and skipping it is where false floods are born. For optical imagery, mask cloud, cloud shadow, and haze on both dates before computing any index, following the Cloud Masking concept — an unmasked cloud shadow is dark in the infrared and reads as fake water. For radar, apply speckle filtering to tame the grainy noise inherent to coherent imaging, and use radiometrically calibrated, terrain-corrected backscatter so slopes are not mistaken for bright or dark returns. Either way, confirm both dates share a coordinate reference and are aligned to the same grid, as the Coordinate Systems concept requires; a half-pixel misregistration invents change at every shoreline. The goal of this stage is a baseline/event pair that is directly comparable — same footprint, same calibration, same masking rules — so the delineation step measures the flood and nothing else.

Delineate water extent against the baseline

Now identify water on the event image and, crucially, subtract what is normally there. On optical data, threshold NDWI/MNDWI to separate open water from land; on radar, threshold the low-backscatter returns that mark smooth water. But a one-date threshold alone confuses flood with permanent water, so compare the event against the baseline: the new water — present at the event, absent in normal conditions — is the flood, and this differencing is the multi-temporal reasoning the Change Detection concept develops. Turning continuous index or backscatter values into a water/not-water label is the same labelling step the Classification Basics concept covers, so record the exact thresholds and baseline definition — the map is only reproducible if they travel with it. Distinguishing flood water from the permanent river, lake, or reservoir is not optional cleanup; it is the core of an honest flood extent.

Separate real flooding from confounders

Not every dark radar pixel or high water index is a flood. Radar mistakes other smooth, low-backscatter surfaces for water — dry roads, sand, tarmac, and radar shadow behind terrain and buildings all return little energy — and it struggles where water hides under vegetation or among buildings, so a double-bounce urban flood can even appear bright rather than dark. Optical water indices are fooled by terrain shadow, dark soils, and any cloud shadow the mask missed. Both approaches must exclude the permanent-water baseline, and the SAR Basics and Time Series concepts both matter here, because a single event scene with a thin baseline can manufacture apparent inundation on its own. Treat a mapped flood patch as a hypothesis and check whether it survives these confounders — and where possible a second sensor or date — before it is escalated for response.

Produce outputs, interpret, and make it reproducible

The deliverables of a flood run are usually a set: a flood-extent map, an area table by reporting unit, and an exposure summary for the communities, roads, parcels, or cropland the question named, so responders can rank and act on the result. Interpret them with domain context and state the uncertainty plainly: where cloud forced a gap in the optical record, where the radar was blind to water under canopy or in the urban core, which areas were thin on clear observations, and how far the thresholds were trusted. Finally, make the run reproducible, the outcome that separates a durable workflow from a one-off. Record the area of interest, the event and baseline dates and sensors, the masking and calibration or speckle-filter settings, the water index or backscatter threshold, the baseline definition, and the reporting units. With those written down the same analysis can be re-run for the next event, 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.