ITRF2020 to NAD83(2011) converter

Why your drone or RTK positions are 1–2 m off your NAD83 control

A global correction service — PointPerfect, a PPP solution, a worldwide RTK network — gives you coordinates in ITRF2020, which most receivers report as “WGS84”. That frame is fixed to the whole Earth. NAD83, which your plans, your benchmarks and your county control are in, is fixed to the North American plate. The two are about two metres apart, and the plate has been moving under the global frame at roughly two centimetres a year since 1983. In Texas that works out to somewhere around one and a quarter metres of horizontal shift and a metre and a bit of ellipsoidal height — not a receiver fault, not a bad fix, just two different answers to “where is this?”. This tool converts one to the other.

Before you convert anything

• If your corrections came from TxDOT RTN, Leica SmartNet or Trimble VRS Now, your shots are already NAD83(2011) epoch 2010.0 — do not transform them.
• Rigid-plate transformation: valid at the centimetre level for stable North America; not for the west coast, Alaska, or across earthquakes.
• Ellipsoidal heights only in this step; NAVD88 needs the geoid step below.

NAVD88 elevations, via GEOID18

Tick the NAVD88 box and the converter subtracts NGS's GEOID18 undulation from the converted ellipsoidal height, giving you the orthometric elevation a plan or a permit actually asks for, in metres and in US survey feet. GEOID18 is the current CONUS model; the 2022 modernized NSRS (NAPGD2022) is not official yet.

The model is defined on NAD83(2011), so the tool will only apply it to NAD83(2011) heights — either the ones it just produced, or a file you declared was already in that frame. If your shots came from an RTN they are already NAD83(2011): pick it on both sides and the run makes no datum change at all, it just adds the State Plane, UTM and NAVD88 columns. Subtracting the model from an ITRF height would bury the whole frame difference, over a metre here, inside an elevation that looks perfectly ordinary, so that is refused rather than warned about. The grid shipped with this page covers Texas; shots outside it get a blank cell and a count, never a guess. CONUS tiles later.

What it accepts, and what it writes

RoboDot .sht files, the CSV export, and the GeoJSON export. The DXF export is local grid coordinates only — there is no datum in it to convert, so it is not accepted. Other delimited point files work too as long as a header row names the latitude, longitude and height columns.

In a CSV or a .sht nothing is replaced: the original latitude, longitude and height stay exactly where they were, and the converted frame arrives as new columns beside them — Lat NAD83(2011), Lon NAD83(2011), Ellip H NAD83(2011), the State Plane zone with easting and northing in US survey feet, the UTM zone with easting and northing in metres, and, when you ask for it, NAVD88 elevations. The one thing rewritten there is RoboDot's local Easting/Northing pair, which is derived from the coordinates rather than measured — leaving it computed from the old frame would make the file disagree with itself. A GeoJSON feature holds only one coordinate set, so nothing can be appended: in that format the coordinates and the heights — h_ant, gnd, ortho_gnd and the collection's heights label — are rewritten in the output frame. Either way the file you picked is never touched; what changes is only the new file you download. A comment line naming the frames, the epoch and the date is written after the header, where RoboDot's own reader skips it and the file still re-imports.

One column needs naming. If your unit had a geoid loaded, its CSV carries an Ortho Ground (GEOID18)(M) column that the device computed from its own ellipsoidal heights — in the frame you are converting out of — so after the datum change it is out by the same metre and a bit as everything else in that frame. The converter leaves the column exactly where it is, because deleting a column you collected is not its call, and names it in the report and in the comment line instead: use the NAVD88 H (m) column for elevations in the converted frame. In the GeoJSON export the same value lives in ortho_gnd, and there it is overwritten with the converted elevation rather than left behind.

Which epoch it uses

Each shot's own GPS time, read from the file. The transformation parameters change with time, and sixteen years of them is about twenty-five centimetres, so the epoch is not a detail. If a file has no readable time the tool refuses the run and asks you for the epoch rather than picking one.

Where the numbers come from

ITRF2020 → NAD83(2011) uses NGS's own 14-parameter time-dependent transformation (HTDP 3.6.0, published as EPSG:10334), reference epoch 2010.00. ITRF2014 comes in through the IERS ITRF2020 transformation parameters. The Texas State Plane zones are the SPCS83 definitions behind EPSG 2275–2279, and UTM is a sixth-order Krüger series. NAVD88 comes from the NGS GEOID18 CONUS grid, public domain, cut down to a Texas tile. In the test suite that ships with this site the State Plane, UTM and GEOID18 code is checked against the publishers' own worked values — the IOGP guidance-note example and NGS's own NCAT and GEOID18 services — while the Helmert transformation is graded against the caster's Go implementation, the same code that produces our base-station PPP results, and the ITRF2014 row only by a range test that it moves a point a few millimetres.