ITRF2020 Explained: The Coordinate Frame Behind Modern GNSS

What ITRF2020 is, how it relates to WGS84 and national datums, and what it means for your drone data.

What ITRF2020 actually is

The International Terrestrial Reference Frame is the scientific answer to a deceptively hard question: where, exactly, is anything? ITRF2020 is its latest realization — a global set of station coordinates and velocities computed from decades of VLBI, SLR, GNSS, and DORIS observations, maintained by the IERS. It is the frame in which satellite orbits are expressed, which makes it the native frame of every GNSS-derived position on Earth. When a PPP engine converges, its coordinates are ITRF2020 at the observation epoch — not an approximation of some national grid, but the reference those grids are themselves defined against.

Two properties matter operationally. ITRF2020 is global and self-consistent: a coordinate in Chile and a coordinate in Mongolia live in the same frame with no seams. And it is epoch-tagged: because tectonic plates move (centimetres per year), a rigorous ITRF coordinate always carries its date.

ITRF vs WGS84: the distinction that rarely matters

WGS84 — the frame GPS broadcasts — is maintained in alignment with ITRF at the few-centimetre level; for practical purposes modern WGS84 realizations and ITRF2020 coincide. So when documentation says a receiver outputs WGS84 and a service says ITRF2020, they are describing the same thing at drone-mapping accuracy. The distinction that does matter is between these global, plate-independent frames and the national datums your deliverables use.

National datums: fixed to a moving plate

Most countries pin their datum to their tectonic plate so that local coordinates stay put: NAD83 in North America, ETRS89 in Europe, GDA2020 in Australia, JGD2011 in Japan. The plate carries the datum along; ITRF watches it drift. The consequence is a growing, well-defined offset — Australia moves roughly 7 cm per year relative to ITRF, so a GDA2020 coordinate and an ITRF2020 current-epoch coordinate of the same peg differ by tens of centimetres and counting. This is not error; it is bookkeeping, resolved by standard time-dependent transformations built into survey software from Trimble Access to Emlid Flow to QGIS.

Trouble arrives only when the bookkeeping is skipped: data captured in ITRF current epoch, imported as if it were the national datum, and the crew burns an afternoon chasing a 40 cm “GPS error” that is actually plate motion.

A clean workflow from capture to delivery

Capture in the native frame: let the base converge in ITRF2020, fly, process — everything stays consistent. Record metadata: frame and epoch alongside antenna height in the project notes; one line prevents the entire class of confusion. Transform once, at export: apply the documented ITRF2020→target transformation (GDA2020, NAD83(2011), ETRS89, or a projected CRS on top) in your processing or GIS software. Validate: shoot a known local monument as a checkpoint after transformation — agreement to a few centimetres confirms the parameters. The anti-pattern is transforming mid-pipeline or, worse, nudging data by eye until layers align; both destroy the audit trail that makes coordinates defensible.

For datum-level context on why this pairs naturally with self-positioned bases, see absolute vs relative accuracy — an ITRF-anchored base is what makes every subsequent visit land on the same frame automatically.

Why the industry is converging on ITRF-native workflows

Correction services made the choice first: Trimble CenterPoint RTX, CHCNAV PointSky, and L-Band PPP services deliver ITRF-frame positions because that is what satellite orbits permit. Multinational projects followed — one frame across borders beats stitching national grids. And machine ecosystems benefit quietly: a construction site whose base, drones, and excavators all reference ITRF2020 through one RTCM stream has no internal datum seams at all (how sites run it). National datums are not going away — legal and cadastral work will always be delivered in them — but they are becoming an export format rather than a working frame. The working frame is the one your GNSS already speaks.

Epochs in practice: the 7-centimetre-per-year country

Australia makes the abstraction concrete. GDA2020 fixed the national datum to the plate's position at epoch 2020.0; the continent has since carried it north-east at about 7 cm per year. A base converging in ITRF2020 at epoch 2026.5 therefore sits roughly 45 cm from the GDA2020 coordinates of the same ground — exactly as designed, resolved by the standard time-dependent transformation every serious package ships. Crews that internalize this stop reporting datum offsets as equipment faults, and start writing epoch into filenames. North America (NAD83, ~1–2 cm/yr differential motion) and Europe (ETRS89) tell the same story at gentler rates; New Zealand and Japan add deformation models where earthquakes have torn the simple plate picture.

One habit covers it all: every export carries frame, epoch, and transformation name in its metadata. Ten seconds of typing; years of ambiguity avoided.

How correction services choose frames — and why you inherit them

Your coordinates' frame is decided by whoever computed the corrections. Network RTK inherits the network's datum — often the national one, which is convenient domestically and a trap across borders. PPP services inherit the orbit products' frame: Trimble CenterPoint RTX, CHCNAV PointSky, and the L-Band service behind UAV Mate all deliver ITRF-family current-epoch coordinates because the satellites do. Neither choice is wrong; mixing them unknowingly is. A site running machine control on network RTK (national datum) while drones map from a PPP base (ITRF) will discover a systematic offset that is pure frame arithmetic — apply one transformation and unity returns. The robust pattern is one correction source for the whole site, one frame, one documented export transformation.

Glossary in thirty seconds

Frame: the physical realization of a coordinate system (ITRF2020). Datum: often used loosely for the same idea; national datums are plate-fixed frames. Epoch: the date a coordinate refers to, essential where plates move. Transformation: the documented mathematics between frames — 7- or 14-parameter, sometimes with a deformation grid. Projection: flattening a datum onto a plane (UTM, State Plane, MGA) — applied after the datum question is settled, never instead of it. Keep the layers separate and every “wrong coordinates” ticket resolves into one of them.

One-line takeaway

Work in ITRF2020 with an epoch attached, transform once at delivery with documented parameters, and every dataset you ever capture will overlay every other — datum confusion is a bookkeeping failure, not a GNSS one.

A five-minute site briefing you can reuse

For crews who need the operational summary without the geodesy: our base computes its position in the global frame ITRF2020, tagged with today's date. That frame moves relative to the national grid by a few centimetres a year because continents drift, so a fixed transformation converts our data to the client datum at export — the parameters are in the project file, applied once, never eyeballed. If any layer looks shifted by tens of centimetres, suspect a missing or doubled transformation before suspecting the equipment, and check the epoch in the filename first. That paragraph, read aloud at induction, prevents more datum tickets than any software setting.

Frequently asked questions

Is ITRF2020 the same as WGS84?

At drone-mapping accuracy, effectively yes — modern WGS84 realizations are aligned with ITRF to a few centimetres. Treat them as one global frame, distinct from plate-fixed national datums.

Why do my coordinates disagree with the local grid by ~50 cm?

Almost certainly plate motion between ITRF current epoch and your plate-fixed datum (NAD83, GDA2020, ETRS89). Apply the standard time-dependent transformation; the disagreement is expected, not an error.

What epoch should I record?

The observation date. ITRF coordinates without an epoch are incomplete; with one, any surveyor can transform them decades later.

Can I deliver directly in ITRF2020?

If the client's systems accept it, yes — engineering and mining increasingly do. Cadastral and legal work still requires the national datum via documented transformation.