GeoTIFF vs shapefile for your annual mangrove extent layer

If you're assembling the extent section of a monitoring report, the format question comes up every cycle: does the verifier get a GeoTIFF, a shapefile, or both. Both, because each file is carrying a different piece of the evidence, and a report that only has one of them makes someone redo work later.

What the GeoTIFF is actually for

A GeoTIFF is a raster. Every pixel carries a value, georeferenced to a coordinate system, and for an extent layer that value usually encodes a classification: mangrove canopy, open water, bare mudflat, upland, cloud. This is the file that shows your evidence. A verifier who wants to see why a pixel got called "loss" rather than "canopy" can open the GeoTIFF in QGIS, zoom to a hectare, and look at the actual reflectance pattern underneath the call. It's the audit trail.

It's also the wrong format for area math. You can calculate hectares from a raster (count pixels, multiply by pixel area), but it's clunky, and it doesn't give you clean boundaries you can dissolve, clip, or compare against a project boundary polygon. For that you need vectors.

Why the vector layer carries the report

A shapefile, or increasingly a GeoPackage (same idea, fewer of the old shapefile's quirks like the 2 GB cap and the field-name truncation), turns that classified raster into polygons: a canopy boundary polygon, loss polygons, regrowth polygons, each one dated and each one with an attribute table you can actually query. This is the layer that goes into your GIS and gets clipped to the project boundary, dissolved by class, and run through a straightforward area calculation. It's also the layer a registry's own reviewer is most likely to drop next to last year's boundary and eyeball for drift along the tidal edge, the part of a mangrove extent that moves the most and gets argued about the most.

Vector is also what lets you track change year over year without re-digitizing. If this year's loss polygon overlaps last year's canopy boundary cleanly, that's a defensible story in the narrative section of your report. If the overlap looks ragged, that's usually a projection mismatch, not real change on the ground, and it's the kind of thing a reviewer will catch in about thirty seconds if your boundary and your basemap aren't in the same CRS.

Deliver both, keyed to the same date

"Show me the source" is a raster question. "Show me the hectares and where the edge moved" is a vector question. A monitoring report that only has one or the other makes someone redo work: either someone's re-digitizing a boundary from a raster by hand, or someone's trying to defend a polygon with no underlying imagery to point to.

What this means for delivery is less about which format wins and more about keeping them in sync. The GeoTIFF and the vector extent layer should come from the same classification pass, carry the same acquisition date, and sit in the same projection, so a reviewer moving between the two isn't reconciling two slightly different stories of where the edge was that year. That's the part that's easy to get wrong when the extent layer gets redrawn by hand each cycle from whatever scene happened to be cloud-free, and the boundary logic shifts slightly from one analyst to the next.

That's the pairing an annual extent layer built around a single reporting cycle is meant to hand over directly: a GeoTIFF for the evidence, a vector canopy boundary with loss and regrowth polygons for the area math, both dated to the same pass and ready to sit in the monitoring report appendix without a rebuild.

If you're staring down this year's extent section, it's worth seeing what that pairing looks like before you start digitizing from scratch.