Documenting a land cover legend change between annual editions
Someone on the environmental reporting side pulls cropland figures from the 2023 edition. Someone in planning pulls the same statistic from 2025. The numbers don't line up, and it isn't because land use shifted that much in two years. A class got split, a threshold moved, or a code got renamed somewhere in between. If nobody wrote that down, every downstream user has to rediscover it by comparing raw rasters by hand.
A legend change is normal. Classification schemes get refined as sensors improve, as a scheme owner adds a class the previous edition lumped into "other," or as a statistics office asks for a distinction (irrigated versus rainfed cropland, say) that the old legend didn't carry. The record of that change is what lets a GIS analyst five years from now reuse the data with confidence instead of guessing at what shifted.
What counts as a legend change
Most edits to a legend document are worth a formal crosswalk entry. A handful are cosmetic and don't touch comparability, but these are the ones that break year-over-year figures:
- A class splits. "Cropland" in edition N becomes "Cropland, irrigated" and "Cropland, rainfed" in edition N+1.
- Classes merge. Two sparse-vegetation subclasses collapse into one because the distinction wasn't holding up at the working resolution.
- A class gets renamed without changing definition. "Built-up" becomes "Impervious surface" and the boundary didn't move, just the label.
- A threshold or minimum mapping unit changes. Bare ground under 0.5 ha used to fold into the surrounding class; now it's mapped separately.
- A class gets retired or added outright, usually tied to a new sensor band or a new statutory reporting requirement.
Each of these needs a different crosswalk entry. Conflating them is where most legend documentation goes wrong.
Building the crosswalk table
The crosswalk is the deliverable, not the prose explaining it. At minimum it needs the old class code, the new class code, the relationship type, and a note.
Relationship type matters more than people treat it. A one-to-one rename is trivial to handle downstream: find and replace. A one-to-many split means anyone who wants a time series back past the split edition has to either accept the coarser old class or go back to source imagery and reclassify. Say that plainly in the table rather than letting someone assume the split can be undone from the output alone. A many-to-one merge loses information permanently going forward, which is worth flagging even when it was the right call.
A row might read: old_code 221, new_codes 221a/221b, relationship 1:many, note: irrigated/rainfed split introduced edition 2025 to match MAFF reporting requirement, pre-2025 editions cannot be disaggregated without re-running classification against archival imagery.
That last clause is the one people skip, and the one that saves someone three days of confused QA later.
Where this documentation lives
A legend crosswalk buried in a PDF nobody can find is functionally undocumented. It needs to sit next to the data it describes: as a dated entry in the metadata record for each edition, and as a standalone change log that accumulates year over year rather than resetting each release. Version the legend by edition year, not by an internal sequential number that means nothing to someone outside the production team. "Legend v3" tells a statistics office nothing. "Legend as published with the 2025 edition, revised from 2024" tells them exactly what to check before they cite it.
Keeping the crosswalk current is less work than the alternative, which is every department in the agency independently reverse-engineering what changed and arriving at three different answers. Write the entry at the point the legend changes, not when the question first comes in.
If your agency is weighing how much of this to build in-house, it's worth looking at what a single classified land cover layer delta-checked against last year's edition looks like when legend continuity is already part of the annual delivery rather than a separate task someone owns.