A clean LiDAR deliverable arrives, opens correctly, looks right. Three months later the construction team notices that drainage modelled from the DTM doesn't line up with where the contractor actually excavated, by about 1.8 m. Nothing was wrong with the capture. The deliverable was processed in GDA94 and the construction team is working in GDA2020 — the offset is the datum shift, undetected because both numbers looked sensible. This is the canonical coordinate-transformation failure. There are six others that show up almost as often.
If you've ever traced an unexplained alignment error between a LiDAR-derived surface and ground reality — construction picked up against the wrong reference, drainage that doesn't drain, contour spot heights that don't match the survey crew's check — you've met the coordinate-transformation problem. The capture is fine. The processing is fine. The deliverable opened correctly. Something in the transformation pipeline between capture and use silently shifted the data, and the shift only surfaces when something physical fails to match the digital reference.
Coordinate transformations look like a solved problem — modern tools handle them automatically, EPSG codes exist, transformation parameters are well documented. In practice, LiDAR deliverables routinely pick up sub-metre to multi-metre offsets through the transformation chain, mostly because the chain has more steps than people realise and any step that defaults silently produces output that's wrong but plausible.
This article walks through the seven common transformation failure modes that show up in Australian drone LiDAR work, what each looks like in the deliverable, the validation steps that catch them, and the brief language that prevents the silent corruption.
Three structural reasons coordinate transformations slip through QA undetected:
1. Both inputs and outputs look reasonable. A point at (-37.81, 144.96) and the same point transformed to (321457, 5810240) both look like plausible coordinates. The transformation could be correct or wildly wrong; nothing in the numbers tells you which.
2. Errors are systematic across the deliverable. A wrong datum shifts every point by approximately the same amount. Relative geometry is preserved; absolute position is corrupted. Internal QA against the deliverable's own control points still passes.
3. The error is invisible until something physical needs to align. Construction picks up against the wrong reference. A new survey integrates with the old data and the seams don't line up. A change-detection analysis between cycles in different datums shows "movement" that's pure transformation artefact.
Catching transformation errors requires explicit validation against external truth, not just internal consistency checking.
(See AHD / GDA2020 article for the underlying datum background.)
The canonical Australian failure. GDA94 and GDA2020 differ by approximately 1.8 m horizontally at typical Australian locations due to plate movement since 1994. A deliverable produced in GDA94 and consumed in GDA2020 (or vice versa) is offset by 1.8 m everywhere.
What it looks like. Consistent ~1.8 m horizontal offset between the LiDAR deliverable and any other reference dataset. Vertical position approximately unchanged.
How it happens. Operator processes against a control network in one datum; consumer's downstream systems work in the other. Neither side flagged the datum in the manifest.
Validation. Cross-check a known feature (road intersection, building corner, persistent survey mark) against another reliable dataset in the consumer's datum. A 1.8 m systematic offset signals the mismatch.
Fix. Apply the official Australian transformation grid (NTv2 file from Geoscience Australia). Don't use simple 7-parameter transformations — they're approximate; the official grid is the standard.
LiDAR captures raw ellipsoidal heights from the GNSS solution. AHD (Australian Height Datum) is the engineering convention. The two differ by 20-30 m across Australia due to the gravitational geoid shape.
What it looks like. Consistent vertical offset of 20-30 m between the LiDAR surface and any AHD-referenced data. Sometimes survives QA because absolute residuals look "in the right ballpark" if the QA crew didn't notice.
How it happens. Operator delivers ellipsoidal heights without flagging; consumer assumes AHD; both teams use the deliverable for months before the offset surfaces.
Validation. Check delivered heights against any known AHD reference (RL on a survey mark, BoM weather station elevation, council benchmark). A 20-30 m offset signals the issue.
Fix. Apply the AusGeoid model (currently AUSGeoid2020) to convert ellipsoidal to AHD. The model is a raster lookup; tools like SCIM, Trimble Business Center and FME handle it natively.
Many mine sites, large infrastructure projects and some military installations use local site grids rotated from MGA. The rotation angle is documented in project surveying records.
What it looks like. Linear features (roads, pipelines, building edges) that are straight in reality appear consistently rotated by a small angle in the deliverable. Or perpendicular features that aren't perpendicular anymore.
How it happens. Operator processes against MGA control while the project expects local site grid; the rotation parameter wasn't applied. Reverse can happen too.
Validation. Cross-check linear features (straight section of road, known-perpendicular building edges) against site reference data. Small systematic rotations show up as parallel-but-offset features.
Fix. Re-export with the correct local-grid transformation applied. Sites with established local grids typically have a documented transformation matrix from MGA; apply it before delivery.
Tool-specific gotcha. Some formats default to longitude-latitude order (degrees), some to latitude-longitude. Some projected formats default to easting-northing, some to northing-easting. Z-axis orientation can be elevation-up or elevation-down depending on tool.
What it looks like. Data appears in completely wrong location (off by hundreds of kilometres if the swap involves projected coordinates). Or elevation appears inverted. Usually caught quickly because the error is so large.
How it happens. Export from one tool with one axis convention, import into another with a different convention, no explicit metadata specifying which.
Validation. Open the deliverable in two independent tools and verify the data lands in the same approximate location.
Fix. Re-export with explicit axis ordering; verify the format specification (LAS header specifies projection; PRJ sidecar for shapefiles; EPSG in metadata for most rasters).
Subtle but real. AHD is defined via a geoid model (currently AUSGeoid2020). Earlier models (AUSGeoid09, AUSGeoid98) differ by tens of centimetres from AUSGeoid2020 in places. A deliverable processed against one geoid version and validated against another picks up a vertical offset of those tens of centimetres.
What it looks like. Consistent small vertical offset (10-30 cm typically) that looks like acceptable accuracy but is structurally systematic.
How it happens. Operator's processing software uses an older geoid model by default; consumer's control was established against the newer model.
Validation. Compare delivered heights against AUSGeoid2020-validated control marks. Offsets in the 10-30 cm range that are systematic across the project signal a geoid mismatch rather than capture accuracy.
Fix. Re-process using AUSGeoid2020 (or whatever the current standard is at delivery time). Operators should specify their geoid model in the manifest.
MGA zones are 6 degrees wide; projects near zone boundaries (149°E, 144°E, 138°E etc.) sometimes cross between zones. A capture processed entirely in one zone but spanning a boundary will have increasing distortion approaching the far edge.
What it looks like. Subtle accuracy degradation that increases with distance from the central meridian of the working zone. Not usually a hard break but a gradient.
How it happens. Project area crosses a zone boundary; operator picks one zone for processing; the further edge of the project accumulates projection distortion.
Validation. Check residuals at control marks distributed across the project area. Distortion proportional to distance from central meridian signals a zone-edge issue.
Fix. Either process the project in zone- appropriate strips and join, or use a custom projection (e.g., site-specific Lambert Conformal Conic) for trans-zone work.
When multiple transformations chain together — WGS84 (capture) → GDA2020 (working) → MGA Zone 55 (projected) → local site grid (delivered) — each step has a small error, and the errors accumulate.
What it looks like. Overall offsets that are larger than any single transformation should produce, because three transformation steps each contributed.
How it happens. Routine processing chain through multiple tools, each applying its own transformation, no documented end-to-end validation.
Validation. End-to-end residual check: the delivered coordinates compared against survey control directly in the delivered coordinate system.
Fix. Minimise the number of transformation steps. Where possible, capture directly in the target datum and projection rather than transforming through several. Document the transformation chain in the manifest.
Four validation checks that should run before any LiDAR deliverable is signed off:
1. Cross-check against external reference. Pick a known feature (survey mark, road intersection, building corner) in the project area. Check its coordinates in the delivered dataset against an independent reference in the target coordinate system. Difference under spec = pass; systematic offset = transformation error.
2. Multi-control validation. Use 3-5 control marks distributed across the project area. Check each against the same external reference. Errors that are systematic (same offset everywhere) signal transformation issues; errors that vary with location signal capture or processing issues.
3. Independent-tool verification. Open the deliverable in two different GIS or CAD tools. Verify it lands in the same approximate location in both. Tool-specific axis convention issues surface immediately.
4. Manifest cross-check. Read the manifest's stated CRS / EPSG / datum / geoid against what the consumer's tools expect. Any mismatch is a problem before the data is even loaded.
(See residuals report article for the broader accuracy-validation pattern these checks fit into.)
Four sentences in the brief that pre-empt most transformation problems:
"Deliverable shall be in [specific datum + projection, with EPSG code, e.g., GDA2020 MGA Zone 55, EPSG:7855]. Vertical datum shall be AHD with AUSGeoid2020 geoid model. The captured coordinate system and any intermediate transformations shall be documented in the manifest including the official transformation grid used for any datum conversions. Cross-check against minimum three independent control marks in the delivered coordinate system shall be included in the QA pack."
That paragraph pins down the target coordinate system explicitly (no defaulting), names the specific geoid model, requires the transformation chain to be documented, and forces external validation in the delivered datum.
coordinate system
Sometimes operators deliver in their preferred working datum (often GDA2020) and consumers want something else (GDA94 for legacy compatibility, or a local grid). Three patterns:
1. Operator delivers two versions. Modest overhead; consumer picks the one they want. Cleanest if the project budget supports it.
2. Consumer applies transformation in-house. Workable if the consumer's tools are competent and validated. Risk that the transformation introduces an error the consumer doesn't notice.
3. Operator delivers in target datum only. Requires confirming the target datum at brief time and the operator using the right transformation chain. Cleanest workflow if specified upfront.
Worst pattern: deliverable arrives in datum A, consumer doesn't notice, integrates with their datum B data, alignment errors surface six months later. This is the canonical failure that explicit brief language prevents.
Three patterns we see when transformations go badly:
Defaulting to "GDA2020" without specifying the projection. GDA2020 is a horizontal datum; it needs a projection (MGA Zone NN) to produce projected coordinates. Specifying datum without projection is incomplete.
Specifying EPSG code without verifying the tool interprets it correctly. Different software versions sometimes have slightly different implementations of the same EPSG code. Verify against external reference, not just the EPSG match.
Treating transformation as a delivery formatting issue rather than a CRS issue. Re-projecting data to a new datum is not just a format conversion; it's a transformation of the positional reference frame. The validation has to happen in the new frame.
Coordinate transformations fail silently because inputs and outputs both look reasonable, errors are systematic across the deliverable, and the problem only surfaces when something physical needs to align.
Seven common Australian failure modes:
Four validation steps catch them: external reference cross-check, multi-control validation, independent-tool verification, manifest cross- check against consumer expectations.
Four-sentence brief language pre-empts the failure modes — specific datum + projection + EPSG, vertical datum + geoid model, documented transformation chain, multi-control external validation in delivered datum.
When operator and consumer want different datums: deliver two versions, consumer applies transformation, or operator delivers in target — worst pattern is silent datum mismatch that surfaces six months later.
Three common transformation mistakes: incomplete datum specification, EPSG-only validation, treating transformation as formatting.
If your project uses a local site grid, spans MGA zones, integrates with existing data in a different datum, or needs validated transformation to/from AHD vs ellipsoidal — worth talking through the transformation chain at brief time. The fix is cheap if planned; the silent six-month discovery is expensive.
The datum theory underlying the transformation failure modes in this article. Useful context for understanding why GDA94 and GDA2020 differ, and what AHD actually is.
The validation pattern that surfaces both accuracy issues and transformation issues. Systematic offsets vs distributed residuals tell different stories.