ITRF2020 to NAD83(2011) converter

Why your 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”, and 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 instead, and the plate has been moving under the global frame at roughly two centimetres a year since 1983. In Texas that works out to about 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?”.

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.
• The transformation keeps the input coordinate epoch. It does not model station motion. Later observations may approximate epoch-2010.0 control in stable areas; this tool does not establish that agreement. Check against control appropriate to your site.
• 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. The model is defined on NAD83(2011), so the tool will only apply it to NAD83(2011) heights — subtracting it from an ITRF height would bury the whole frame difference inside an elevation that looks perfectly ordinary. The grid covers the contiguous US and a run fetches only the tile its own shots fall in, about 1–2 MB; Alaska, Hawaii and Puerto Rico are not covered, and shots outside the coverage get a blank cell and a count, never a guess.

What it accepts, and what it writes

RoboDot .sht files, the CSV export, and the GeoJSON export. Delimited input needs a header row naming latitude, longitude and height. Use decimal degrees and ellipsoidal heights in metres. Height columns without a unit label are interpreted as ellipsoidal metres. In a CSV or a .sht nothing is replaced — the coordinates you collected stay exactly where they were and the converted frame arrives as new columns beside them. GeoJSON downloads use WGS84 coordinates. For NAD83(2011) or ITRF output, use CSV or .sht. Either way the file you picked is never touched; what changes is only the new file you download.

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. The Texas State Plane zones are the SPCS83 definitions behind EPSG 6578, 6582, 6584, 6586 and 6588, UTM is a sixth-order Krüger series, and NAVD88 comes from the NGS GEOID18 CONUS grid, public domain. The test suite that ships with this site checks that code against the publishers’ own worked values.