An annual capture programme exists to detect change. The capture lands, the difference layer renders, the map lights up with apparent ground movement, vegetation loss and asset shift. Half the change is real; half is noise. Distinguishing the two is the part of change-detection most operators don't talk about, because doing it properly requires methodology choices that have to be made before the second cycle ever flies.
If you've ever overlaid two annual LiDAR captures expecting to see clean evidence of last year's vegetation regrowth, the embankment that settled, the stockpile that moved, and instead seen a difference layer full of noise that obscures the real change, you've met the change-detection problem. The captures are individually accurate. Both QA packs passed. The problem is that two captures with ±20 mm RMSE each don't necessarily produce a ±20 mm difference layer — depending on how they're compared, the difference can be much larger than either capture's own error, and the genuine change can be invisible inside the residual noise.
The technique is sound, the literature is mature, the tooling is widely available. What's commonly missing is the methodology discipline that makes change-detection results defensible: matched processing chains across cycles, aligned baselines, appropriate differencing technique for the change type, and explicit characterisation of the noise floor against which change is being asserted.
This article walks through what's actually resolvable between repeat captures, the four common differencing techniques and when each is appropriate, the methodology constraints that determine signal-vs-noise, and the pitfalls that produce confident-looking false change.
Every capture has uncertainty. A typical engineering- grade drone LiDAR delivers about ±20 mm RMSE at independent control points. Two captures, each at ±20 mm RMSE, differenced point-by-point or surface-to- surface, produce a difference layer whose noise is not ±20 mm — it's the combined uncertainty of both captures, which adds in quadrature to roughly ±28 mm.
That's the best case. In practice the difference noise is larger because:
A realistic noise floor for "the same vendor doing the same site with the same workflow twice 12 months apart" is in the range ±40-80 mm vertical, larger horizontal. Change below that threshold isn't resolvable; change above it may be real.
The threshold is what most change-detection deliverables don't characterise. The map that shows everything that differs by anything is not a change-detection map; it's a noise map with the real change buried inside it.
(See residuals article for the underlying accuracy considerations and strip alignment article for the within-cycle alignment story.)
Concrete examples of change magnitudes vs typical noise floors:
Resolvable at ±40 mm vertical noise floor (good matched-cycle deliveries):
Resolvable at ±80 mm vertical noise floor (typical matched-cycle):
Marginal or non-resolvable:
For sub-noise-floor change, drone LiDAR is the wrong technique. Terrestrial laser scanning, InSAR, total station monitoring or fixed-position settlement plates will give you what cycle-over-cycle drone LiDAR can't.
The "how" matters as much as the "what". Four common methods, each with appropriate use cases:
The simplest approach: convert both captures to raster DEMs at the same resolution and alignment, subtract one from the other, render the result.
Best for: large-area change detection on bare or sparsely-vegetated surfaces. Earthworks volumes, stockpile movement, broad ground subsidence, coastal change.
Limitations: vertical-only (no horizontal change sensitivity), aggregates point cloud information into raster cells (loses fidelity), assumes ground surface is single-valued at each x,y (fails under canopy or overhangs).
Noise floor: dominated by underlying DEM accuracy plus interpolation artefacts; typically ±50-100 mm in practice.
Computes the closest-point distance from each point in cycle 2 to its nearest neighbour in cycle 1. Vector- valued (3D) so captures horizontal change as well as vertical.
Best for: detecting change on complex surfaces where DEM rasterisation loses information — building facades, vegetation structure, structures with overhangs, vertical cliff faces.
Limitations: confuses sampling-density differences between cycles with real change (sparser sampling finds further nearest neighbours). Needs careful density normalisation.
Noise floor: ±20-50 mm on well-sampled surfaces, higher where sampling density varies between cycles.
Currently the gold-standard technique for point-cloud change detection in research and high-end commercial work. Computes a local surface normal at each point, projects both clouds onto the normal at a local neighbourhood scale, and measures the difference along the normal direction.
Best for: any change detection where statistical significance matters. Civil monitoring, geological movement, engineering compliance, research-grade applications.
Strengths: distinguishes real change from sampling noise by computing local confidence intervals at each measurement; can flag where change isn't resolvable as well as where it is.
Limitations: computationally expensive, requires parameter tuning (search radius, normal scale, projection radius) per use case.
Noise floor: characterised explicitly per measurement point rather than as a single project number — the technique's primary value.
Divides the project volume into 3D voxels (typically 0.5-2 m cubes), counts point occupancy per voxel per cycle, and flags voxels where occupancy changed.
Best for: vegetation structure change, biomass estimation, canopy gap analysis, change detection in complex 3D environments where surface-based methods struggle.
Limitations: coarse-grained (resolution = voxel size), poor for small displacement signals, sensitive to point density variance.
Noise floor: depends on voxel size; typically only useful for changes larger than half a voxel dimension.
Six things that have to be true for cycle-over-cycle differencing to produce defensible results:
Same software version, same classification parameters, same ground extraction algorithm, same hydro- enforcement scope. Processing-chain drift between cycles introduces apparent change that's pure method artefact.
The practical implication: locking the processing chain at programme inception and keeping it stable for the life of the programme. The annual capture programmes article covers why this is one of the strongest arguments for multi-year vendor continuity.
Both cycles fit to the same set of ground control points, with consistent independent check points. A new control survey between cycles can shift the absolute reference even if the local survey is internally consistent.
For monitoring programmes, the convention is permanent ground control marks (concrete plinths with survey pin) that get re-occupied every cycle. The marks should sit on geologically-stable ground outside the change-of-interest area.
Before differencing, the two clouds should be co- registered using features that are known not to have moved between cycles. Building rooftops, road intersections, persistent rock outcrops, and large structures provide the rigid-body alignment baseline.
A co-registration that uses change-area features will fold the changed reality into the alignment and produce difference layers that under-state the change. Use stable features exclusively.
Bare ground supports tight change detection; dense canopy doesn't. Change-detection results should be reported per cover class, with explicit confidence bounds. A whole-project "RMSE = 50 mm" number doesn't capture that bare ground is at 20 mm and canopy is at 150 mm.
The implication for the brief: cover-class stratification in the QA pack is the basis on which change detection's per-area confidence can be computed.
Both cycles should have point density above the minimum required for the change being detected. Sub-canopy ground change at 50 mm requires at least 20-50 ground points per square metre; sparse captures (under 10 ppm² ground returns) can't resolve it regardless of absolute accuracy.
(See point density article for the density spec calculus.)
The change-detection deliverable should report not just where change is but how confident the detection is. A traffic-light map (red = change clearly above noise floor, amber = marginal, green = no resolvable change) is more useful than a continuous gradient that doesn't distinguish signal from artefact.
Specific patterns we see when change detection is done without methodology rigour:
1. Cycle-to-cycle vendor change. Two captures from two operators with different processing chains produce difference layers full of method artefact. Often misinterpreted as real change. Methodology fix: single vendor across cycles, or explicit calibration cycle where both vendors capture the same area for comparison.
2. Datum drift. Cycle 1 in GDA94, cycle 2 in GDA2020, manifest doesn't flag the shift. The 1.8 m datum offset shows up as apparent ground movement across the whole project. Fix: lock datum at programme inception; document explicitly per cycle.
3. Seasonal vegetation noise. Cycle 1 in winter (bare canopy), cycle 2 in summer (full canopy). The canopy difference is real but not "change" in the sense of long-term trend. Fix: schedule cycles in matched seasons.
4. Density-driven apparent surface roughness. Cycle 1 was 30 ppm², cycle 2 was 50 ppm². The denser cycle resolves micro-topography the sparser one smoothed over. Apparent ground roughness change is pure density artefact. Fix: match capture density across cycles.
5. Over-confident colour rendering. Difference maps rendered with full-saturation colour at every deviation make ±10 mm noise look like dramatic change. A two-tone "above threshold / below threshold" map is more honest than a continuous heat map. Fix: render with explicit noise floor in mind.
Five outputs that typically constitute a change- detection deliverable bundle:
1. The two source captures, both processed through the same chain, both with full QA packs.
2. Co-registration documentation — what stable features were used, the residuals of the co-registration, the transformation applied.
3. The differencing analysis — method used, parameters, noise-floor characterisation, raw difference output.
4. The interpreted change map — change features classified above the noise floor, with confidence bounds, presented in a way that makes the threshold explicit.
5. The reporting document — what changed, how much, with what confidence, what the implications are. The translation layer from technical analysis to decision-support output.
Change-detection from repeat LiDAR captures works only when the change exceeds the residual noise floor — which is typically larger than either individual capture's RMSE because uncertainties combine and processing artefacts add. Realistic noise floors for matched-cycle deliveries are ±40-80 mm vertical; sub-floor change isn't resolvable from drone LiDAR.
Four differencing techniques: DEM-of-Difference (large- area vertical), cloud-to-cloud distance (complex surfaces, 3D), M3C2 (statistically-rigorous, current gold standard), voxel differencing (vegetation structure and 3D environments). Each has appropriate use cases.
Six methodology constraints determine whether differencing produces defensible results: matched processing chains, shared control network, co- registration via stable features, cover-class- appropriate analysis, sufficient density, reporting with confidence.
Five pitfalls produce false change: vendor change between cycles, datum drift, seasonal vegetation noise, density-driven apparent roughness, over- confident colour rendering.
The change-detection deliverable should include both source captures, co-registration documentation, differencing analysis with noise floor, interpreted change map with confidence, and a translated reporting document.
Done with rigour, change detection from annual LiDAR is one of the most powerful applications of the technology. Done casually, it produces confident- looking false signals that get acted on.
If you're commissioning an annual capture programme specifically for change detection, the methodology decisions made at programme inception — control network, processing chain lock-in, density spec, differencing method — determine whether year 3's difference map is usable or noisy. Happy to walk through the design before the first cycle.
The programme-design article whose central technical promise — comparative analytics across cycles — is what this article makes operationally rigorous.
The single-cycle accuracy article whose noise budget directly determines the noise floor in change detection. Useful prerequisite reading for anyone evaluating change-detection deliverables.