AHD, GDA2020 and the Australian datum story

If you've ever opened two spatial datasets that should line up and watched them appear several metres apart, you've met the Australian datum landscape. The numbers in each file are technically correct. The disagreement isn't an error in either dataset — it's the unavoidable consequence of mixing data from different datum epochs without transformation.

This article is the engineering reference. AHD, the GDA94 to GDA2020 transition, the MGA zone system, the AVWS replacement that's coming, and how to specify datum correctly so the LiDAR delivery overlays your design rather than confounding it.

Two datums, two halves of the answer

Every spatial coordinate sits on two independent reference systems:

• A horizontal datum plus map projection, defining where (X, Y) is on the surface of the earth
• A vertical datum, defining where Z is relative to some agreed reference level

In Australia for most of the 2000s and 2010s, the working pair was GDA94 + AHD, with MGA94 as the projected coordinate system. From 2020 onwards the working pair is shifting to GDA2020 + AHD with MGA2020, and the vertical datum AHD itself has a planned replacement on the horizon (AVWS, more on which below).

Both halves matter independently. Getting horizontal right doesn't fix a vertical mismatch, and vice versa. Both are sources of quiet project errors.

AHD — the vertical reference

AHD — Australian Height Datum was established in 1971 via a network of 32 tide-gauge stations around the Australian coast. The mean sea level recorded at each gauge between 1966 and 1968 was assumed to be zero. The interior of the country was then levelled from these coastal anchors using precise spirit levelling.

A few practical consequences of the way AHD was established:

• The 32 tide-gauge zeros aren't actually at the same level — they differ by up to ~50 cm due to variations in mean sea level around the continent (warm currents, wind setup, salinity differences). AHD is the agreed compromise, not the true sea level at any one location.
• AHD does not perfectly represent the geoid (the gravity-defined surface that water would settle to). In some areas of Australia, AHD differs from the geoid by several decimetres.
• AHD is realised through a network of permanent benchmarks surveyed and re-surveyed over decades. The published height of any benchmark is the AHD reference for that location.

For most engineering work, AHD is fine — every other Australian survey uses it, council datasets use it, the regulatory environment uses it. The fact that AHD isn't the true mean sea level doesn't matter as long as everyone references the same working surface.

The fact that AHD will eventually be replaced (by AVWS — see below) matters in the long term, but the transition will be gradual.

The horizontal datum — GDA94, GDA2020 and what changed

GDA94 — Geocentric Datum of Australia 1994 was Australia's working horizontal datum from 1994 to ~2020. It was a realisation of ITRF92 at the epoch 1994.0 — meaning the coordinates fixed in 1994 reflect where the Australian tectonic plate was at that moment.

The catch: the Australian tectonic plate moves about 7 cm per year north-east. By 2020, the Australian plate had moved roughly 1.5–1.8 metres from its 1994 position. A coordinate captured by GNSS in 2020 and recorded against GDA94 was either:

• Forcibly transformed back to the 1994 frame (introducing 1.5+ m of pseudo-displacement), or
• Recorded against GDA94 as if no movement had occurred (creating data that disagrees with newer captures by 1.5+ m)

Most surveying software handled this internally; many GIS workflows didn't. Long-running datasets accumulated 1–2 metres of horizontal inconsistency over the GDA94 era.

GDA2020 is the new working datum, realised on ITRF2014 at epoch 2020.0. The transformation from GDA94 to GDA2020 is approximately:

• Roughly +1.5 m east and +1.0 m north across most of Australia
• The exact shift varies with location due to small local distortions in the GDA94 network
• The transformation is non-linear — a single shift parameter doesn't work everywhere

Geoscience Australia publishes a distortion grid file (NTv2 format) for converting between the two. Any reputable spatial tool — QGIS, ArcGIS, Civil 3D, FME — supports the grid transformation natively. The result is a properly-warped conversion that respects local distortion.

If you're working on a project that combines a 2010 GDA94 dataset with a 2024 GDA2020 dataset and they appear 1.5 m apart, the disagreement isn't an error — it's the consequence of mixing datum epochs without transforming.

MGA — the map projection

GDA94 and GDA2020 are geodetic datums expressed in latitude / longitude. For practical engineering work, coordinates are projected to a planar coordinate system — MGA — Map Grid of Australia — that uses easting + northing in metres.

MGA is a Universal Transverse Mercator (UTM) projection split into eight zones covering Australia and offshore territories:

| Zone | Central meridian | Coverage | | ------ | ---------------- | --------------------------------- | | MGA49 | 111°E | Far western WA, Christmas Island | | MGA50 | 117°E | South-west WA, Cocos Island | | MGA51 | 123°E | Central WA | | MGA52 | 129°E | NT, central interior | | MGA53 | 135°E | SA interior, central NT, eastern WA | | MGA54 | 141°E | Western Vic, western NSW, far west Qld | | MGA55 | 147°E | NSW, Vic, eastern Qld, Tas | | MGA56 | 153°E | Coastal NSW, south-east Qld |

The relevant zone for any project is the one whose central meridian is closest. Projects that span a zone boundary have a choice: use one zone throughout (introducing some distortion at the far side of the project), or split the deliverable across zones (clean projection, awkward downstream handling).

Each zone exists in both GDA94 and GDA2020 versions — MGA94 zone 55 vs MGA2020 zone 55, etc. — and the coordinate values are different.

The coming replacement — AVWS

AVWS — Australian Vertical Working Surface is Geoscience Australia's planned replacement for AHD. It's a geoid-based vertical reference that better matches the actual mean sea level surface than AHD does.

The differences from AHD:

• AVWS is derived from precise gravity modelling rather than spirit levelling from tide gauges
• AVWS more accurately represents where water would settle on a uniform surface
• The shift from AHD to AVWS is significant — up to ±1 m in some inland regions, smaller near the coast

For the next several years, AHD remains the working reference for most engineering and regulatory work. AVWS adoption will be gradual, starting with new survey-grade GNSS workflows and spreading from there. For now, captures and deliverables should specify AHD as the working vertical datum unless a project explicitly asks otherwise.

How to specify datum correctly on a project

The clean datum specification for any Australian LiDAR project includes four things:

1. Horizontal datum — GDA94 or GDA2020 (preferred for new captures)
2. MGA zone — usually the one nearest the project central meridian
3. Vertical datum — AHD (default) or AVWS (uncommon currently)
4. Capture epoch — the date the GNSS observations were captured

A clean specification reads:

"Horizontal datum GDA2020, projected to MGA2020 zone 55, vertical datum AHD, capture epoch 2026.4."

That sentence eliminates 90% of the downstream datum confusion that costs projects time at integration. The remaining 10% comes from edge cases — multi-zone projects, transformation between GDA94 legacy data and GDA2020 current data, AVWS-eligible projects.

Common datum mistakes

Three patterns that show up in marginal projects:

Mixing GDA94 and GDA2020 datasets without transformation. The legacy dataset and the new capture appear roughly 1.5 m apart in the GIS. Half a day of debugging later, someone runs the NTv2 grid transformation and the alignment fixes itself. Avoidable by checking the datum tag in every layer's metadata at ingest time.

Wrong MGA zone for a multi-zone project. A project that crosses, say, 153°E gets captured in zone 55 throughout because the contractor's templates default to zone 55. Eastern third of the project carries scale-factor distortion of several metres per kilometre. Avoidable by checking zone selection against project extent at scoping.

Confusing geodetic latitude/longitude with projected easting/northing. Less common since most software handles the conversion internally, but still occurs in CSV exports and custom data exchanges. Easting/northing in metres should be ~6-digit numbers; latitude/longitude in degrees should be small numbers. If they're swapped, the data lands in the wrong ocean.

The gotchas at integration

When a LiDAR capture lands with the design or asset management team, the integration step is where datum mismatches surface. Three things worth checking at handover:

1. All datasets in the project use the same horizontal datum and zone. Lay the new capture over the existing design surface in the engineering tool. If they appear offset, datum is almost always the culprit.

2. Vertical datum is consistent. AHD-tied LiDAR alongside AVWS-tied control will appear vertically offset by the local AHD-AVWS difference. Less common today, will be more common as AVWS adoption proceeds.

3. All datasets reference the same realisation epoch. GDA94 data from 2010 has aged differently from GDA94 data from 2018 — both are correctly tagged as GDA94 but represent slightly different epochs of the moving plate. For most engineering work this is sub-decimetre and not worth correcting; for precise applications, it matters.

TL;DR

Two datums per project: horizontal (GDA94 vs GDA2020, with MGA zone) and vertical (AHD currently, AVWS coming). A new capture should specify all four (datum, zone, vertical datum, capture epoch) explicitly to eliminate downstream confusion.

The biggest source of datum mismatch is mixing GDA94 legacy data with GDA2020 current data without running the NTv2 transformation grid. The data isn't wrong — it's just from different epochs of a moving continent. Modern spatial tools handle the conversion natively; the trick is remembering to do it.

For LiDAR scoping, the cleanest project specification reads something like "GDA2020, MGA2020 zone 55, AHD, capture epoch 2026.x" — and the QA pack should report tie residuals against control marks in the same datum/zone/vertical reference.