A map tells you what is there. A change feed tells you what happened. The second is usually the more valuable product, and it is much harder to build honestly.
Most spatial systems answer questions about state: how many buildings are in this district, where do the roads run, what is the land cover. Change detection asks what differs between the survey taken then and the survey taken now. That sounds like a subtraction. Run it as a subtraction and it produces nonsense on the first attempt and, worse, plausible nonsense on the second.
The difficulty is not the comparison. It is that two surveys of the same place disagree for many reasons, and only one of those reasons is that the place changed.
Why change carries more information than state
State is expensive to consume and mostly redundant. Re-reading a full description of a city every month to find the handful of things that moved puts the burden of comparison on every consumer, and the payload is large: a metropolitan survey is gigabytes, while a month of genuine change is usually a few thousand records.
Change is also where the decisions live. Nobody dispatches a crew because a building exists. They dispatch because a building appeared where planning permission said it should not, or because a road that was open is now closed. Insurance repricing, infrastructure inspection, retail expansion, and humanitarian response are triggered by deltas rather than levels.
The catch is that all the error in both surveys concentrates into the change feed. Two datasets that are each largely correct can produce a difference that is mostly wrong, because the correct parts cancel and the errors do not.
The identity problem
Take two building footprint files for the same city, one from last year and one from this year, and ask which buildings are new. If the two files do not share identifiers, the naive answer is that every building in the old file was demolished and every building in the new file was constructed. Total demolition, total rebuild, in twelve months. That is the default outcome of comparing two independently produced datasets.
The obvious fix is to use identifiers, and it does not work as well as expected, because identifiers are rarely as stable as their names suggest. In a volunteer-edited map, an object deleted and redrawn gets a new identifier even though the thing on the ground never moved, and splitting a way at a junction produces two identifiers where there was one. A footprint dataset regenerated by running a model over new imagery assigns fresh identifiers on every run, because the model has no memory of the previous run. A dataset keyed on address rekeys the building when the address changes and merges two buildings that share one.
Underneath that sits a harder question, which is that identity is a decision rather than a fact. A building that gains a rear extension: same building, or a new one? A shop that changes owner, name, and fit-out but not walls: same premises, different business, and which is the object being tracked? A road resurfaced, rerouted around a new roundabout, and renamed: how much of that can happen before it stops being the same road?
There is no universally correct answer, only a rule that has been written down and applied consistently. Systems that handle change well are the ones where somebody decided that a footprint whose overlap with its predecessor exceeds a stated fraction is the same building, and put that in the documentation. Systems that handle it badly are the ones where the rule is implicit in a threshold buried in a matching script.
Matching objects across surveys
Given that identifiers cannot be trusted, matching has to be reconstructed from geometry and attributes. The first stage is candidate generation: build a spatial index over one survey, then for each object in the other retrieve the objects falling within a generous search window. That reduces the problem from millions of comparisons to a handful per object.
The second stage is scoring. Each candidate pair gets a similarity score built from several components:
- Overlap. For polygons, intersection over union is the workhorse. It penalises both a small object matched to a large one and two objects that merely touch.
- Centroid distance, normalised by object size. Absolute distance misleads, because five metres is nothing for a warehouse and everything for a kiosk.
- Shape similarity: perimeter, principal axis orientation, rectangularity. Two footprints of the same building extracted by different methods differ in vertex count but agree on gross shape.
- For linear features, buffer overlap and a directed distance computed in both directions. A resurveyed centreline sits within a couple of metres of its predecessor along its length, which a buffer test catches and a vertex comparison does not.
- Attribute agreement. Matching names, house numbers, or classifications raise confidence sharply, and disagreement should lower it rather than veto it.
Then assignment, which is where most implementations go wrong. The tempting approach is greedy: for each object take its highest-scoring candidate and call it a match. In sparse areas that is fine. In dense areas it cascades, because the first object claims a partner that fitted the second better, which then claims a partner belonging to the third, and one bad decision at the start of a terrace propagates down the row. Solving the assignment globally, so total score across all pairs is maximised rather than each pair decided locally, removes an entire class of systematic error at very little cost.
The tolerance tradeoff
Every matcher has a threshold, and that single number decides how much change the system reports.
Set the tolerance loose and genuine change disappears. A building demolished and replaced by a slightly different building on the same plot will match its predecessor and be reported as unchanged. Two adjacent structures merged into one will match whichever overlaps more, and the other silently vanishes.
Set it tight and the feed fills with change that never happened. A survey that improved its digitisation quality shifts every footprint by a metre or two, and every object in the city is reported as having moved. The feed is technically accurate and useless, because what it detected was a change in mapping precision.
No threshold is correct everywhere. Object size matters, density matters, and class matters, because a road centreline tolerates lateral movement in a way a property boundary does not. Use relative rather than absolute measures, so tolerance scales with the object, and set per-class thresholds rather than one global number, recording what they were: a change feed produced under one set of thresholds is not comparable with one produced under another.
Better still, do not collapse the score to a boolean at all. Emit the match score alongside the change record and let the consumer apply their own cutoff. A logistics user who needs certainty and a monitoring user who needs early warning want different cutoffs, and neither wants the producer choosing for them.
The distinction that decides everything: the world changed, or the map did
This is the most important idea in the topic and the one most consistently skipped.
When a change feed shows four hundred new buildings in a district over one week, there are two candidate explanations. Four hundred buildings were built. Or somebody mapped four hundred buildings that had been standing for years. A mapping party is not construction. An import is not construction. A model rerun is not construction. A coverage expansion is not construction.
The same applies to commercial pipelines. A new imagery vintage yields more detected objects. A retrained model finds structures the previous one missed. A vendor extending coverage into a new region produces an enormous burst of appearances that correspond to nothing physical.
The signatures are distinguishable, and the separation is worth doing properly.
- Metadata is the strongest signal and the most often ignored. Edit timestamps, contributor identity, source tags, imagery capture dates, and model versions carry the answer directly. If four hundred buildings share one editing session or one extraction run, that is not four hundred independent observations of the world.
- Spatial signature. Mapping activity respects the boundaries of the mapping process: task grids, tile edges, administrative units. Change that stops abruptly along a straight line is almost always an artefact, because construction does not respect a tile boundary.
- Temporal signature. Real construction has a sequence. Ground is cleared, access is laid, a footprint appears, the roof closes. Mapping appears fully formed in a single step.
- Corroboration. If night lights, address registration, or a second imagery source show nothing, the map moved and the world did not.
The reverse error matters just as much. Absence of change in a map is not absence of change on the ground. In an area nobody has surveyed for three years the feed is empty, and an empty feed reads as stability. That is the failure mode that puts a decision maker on a road that no longer exists.
The practical rule is to keep the two kinds of change in separate fields and never sum them. A record should say what changed and, separately, what the evidence says about why the record exists. Unknown is a legitimate value there. Merging them into one count produces a number nobody can interpret.
Seasons, shadows, and the illumination trap
Where change is detected from imagery rather than from vector surveys, a second family of false positives appears, and it is entirely optical.
Vegetation is the obvious one. A leaf-on capture and a leaf-off capture of the same street look like different streets. Crop cycles turn fields from bare soil to dense cover and back. Water levels move shorelines by tens of metres seasonally on some rivers. Snow rewrites everything.
Illumination is subtler and catches more people. Sun angle changes with season and time of day, so shadows lengthen, shorten, and rotate, and a pixel-level comparison reads the displacement as change at the base of every tall object. Wet tarmac has a different reflectance from dry tarmac, so a road can appear to have been resurfaced by a rain shower. View geometry compounds it: imagery captured off-nadir shows tall buildings leaning away from the sensor, and two captures from different flight paths lean them in different directions, so the naive comparison sees every tall building as having moved sideways. Nothing did.
There are three ways out, in increasing order of robustness. Compare like with like, matching season and sun geometry. Normalise radiometrically and work with derived indices less sensitive to illumination than raw bands. Or extract objects from each capture independently and compare the objects rather than the pixels. Object-level comparison inherits the extraction model's errors, but it is immune to shadow displacement and reflectance drift in a way pixel differencing never will be.
Registration error and the false positive floor
Two rasters of the same place are never perfectly aligned. Orthorectification depends on an elevation model whose own error translates into horizontal displacement growing with terrain slope and off-nadir angle.
Sub-pixel misalignment produces a characteristic artefact in any pixel difference: bright ringing along every high-contrast edge. Building outlines, road edges, field boundaries, and shorelines all light up. This is the worst possible distribution of false positives, because those edges are precisely where the objects of interest are. A change map dominated by edge ringing looks, at a glance, like one full of real detections around buildings.
The mitigations are unglamorous. Co-register the pair explicitly rather than trusting the supplied georeferencing. Impose a minimum area so one-pixel-wide edge effects are dropped. Require change to be coherent across several bands rather than accepting a difference in one. And where possible, compare objects rather than pixels.
Whatever combination is used, the residual is a floor. There is a level of apparent change below which the system cannot distinguish signal from misalignment, and that floor belongs in the documentation rather than being discovered by a user.
Designing a change feed that cannot be misread
A change record is consumed by people and by automated callers, neither of whom will read a caveat living in a separate document. The schema has to carry the honesty.
- Type the change explicitly. Appeared, disappeared, geometry modified, attribute modified, split, merged. Split and merge are real events, common in resurveys, and most schemas omit them, forcing them to be encoded as a simultaneous disappearance and appearance that no consumer reconstructs correctly.
- Separate observation from inference. That an object in survey A has no match in survey B is an observation. That it was demolished is an inference. Those are different claims with different reliability.
- Carry a cause channel with at least three values: evidence points to a real world change, evidence points to a change in mapping or extraction, cause unknown.
- Give an interval, not an instant. A change found between a March survey and a September survey happened somewhere in that window. Stamping it with the September date is a lie that ends up on a chart and is read as a September event.
- Never report a disappearance outside the intersection of the two surveys' coverage. If survey B did not cover the area, the object did not disappear, it was not looked at. Coverage-limited absence reported as demolition is the most common falsehood in change feeds.
- Attach the evidence: the match score, the components that drove it, the source of each survey. A change record that cannot be regenerated identically from the two inputs is a record nobody can audit.
The failure that ships
The change detection system that reaches production is rarely the one tested hardest. It is the one whose monthly counts looked plausible. Somebody plots new buildings per month, the line is smooth, nobody investigates, and the pipeline is declared working. Then the vendor extends coverage, or a volunteer runs an import, and the line spikes. The spike is real in the data and meaningless in the world, and by then the chart is in a deck justifying a decision.
The discipline that prevents it is one question asked before any change figure is published. There are three explanations for a difference between two surveys: the world changed, the map changed, or the comparison was misaligned. If two of the three cannot be ruled out with evidence that is in the record, what has been produced is a diff. A diff is a useful engineering artefact and not a statement about the world, and the distance between those two things is where the damage happens.