Polygon drift between annual mangrove extent deliveries: what to do about it

Every project developer who has stacked two years of mangrove extent polygons on top of each other has had the same moment: the edge that was supposed to hold steady has shifted ten or fifteen meters in places where nothing on the ground actually changed. Before you write that off as loss, or worse, report it as loss, it's worth understanding where the drift comes from.

Why the boundary moves even when the canopy doesn't

Polygon drift is almost never one cause. It's usually three or four small ones stacking up.

Different scenes, different tide stage. A mangrove canopy at the inundated edge reads differently depending on water level at capture time. If last year's extent was digitized from a scene shot near low tide and this year's came from a scene closer to high tide, the fringing edge will shift even with zero real canopy change.

Different sensors, different ground sample distance. A 2 m pixel and a 0.5 m pixel will draw the same real edge in slightly different places just because of how each one averages reflectance at the boundary. Swap providers or satellites between reporting years and you've built in a mismatch before anyone touches a digitizing tool.

Different hands, different judgment calls. If a different analyst, or a different outsourced team, drew this year's polygon, their threshold for "is this pixel canopy or shadow" won't match last year's exactly, especially along degraded or sparse fringe. This is the quiet one: nobody flags it because nothing looks obviously wrong, the line is just two meters off in a hundred small places.

Rectification and georeferencing error. Compounding on top of the above, even small shifts in how each scene was orthorectified will nudge the whole polygon a few pixels one direction.

None of this is a methodology failure. It's what happens when an extent layer gets rebuilt from scratch each year instead of carried forward on a consistent baseline.

Reconciling the mismatch before it hits the registry report

A registry reviewer doesn't want to see raw year-over-year polygon mismatch presented as loss or gain. They want to see that you've separated real change from the noise around the edge. A few steps that hold up under review:

Overlay both years and buffer the stable interior. The core canopy, the part well inside the fringe, rarely drifts at all. If your interior polygons agree, you've confirmed the mismatch is an edge artifact, not a systemic problem with either delivery.

Label anything inside one pixel-width of either imagery's GSD as uncertain. If last year's imagery was 2 m and this year's is 1 m, a sliver 1.5 m wide along the boundary falls within the combined margin of both products. That band is measurement noise, so hold it out of the loss or gain tally and report it as boundary revision instead.

Keep a change log alongside the final polygon. Registries increasingly want to see the reasoning behind a boundary revision, not just the updated shape. Note the imagery source, acquisition date, and tide stage for each year's delivery, and note where the revision is attributable to data differences versus observed change. This is the record that saves you a back-and-forth with a verifier eighteen months from now when nobody remembers why the edge moved.

Reconcile drift every cycle instead of letting it pile up unexamined. If you carry forward a boundary that's drifted 2 to 3 percent each year without reconciling it, you'll eventually report a "loss event" that is five years of unexamined edge noise catching up with you at once.

The fix is upstream

All of this reconciliation work exists because the extent layer gets rebuilt from a different starting point every year: different provider, different cloud-free scene, sometimes a different person doing the digitizing. The cleanest way to cut polygon drift is to stop introducing new sources of it, which means sourcing extent from an annual layer, tied to a fixed cadence and a consistent spectral and resolution baseline, rather than whatever scene happened to be usable that season. That's the premise behind a dated, sourced extent delivery built around a project's reporting cycle, rather than a fresh hand-digitized map redrawn each year from scratch.

If you're staring down this year's delivery against last year's and trying to figure out which lines are real, it might be worth seeing what a consistent annual baseline would have looked like instead.