Short answer

NAD83 and WGS84 are not the same datum, even though they share essentially the same ellipsoid (GRS80 vs the WGS84 ellipsoid, which differ by fractions of a millimetre). NAD83 is anchored to the stable interior of the North American tectonic plate and moves with it; WGS84 is kept aligned with the global ITRF reference frame. Because North America drifts ~2-2.5 cm/year, the two frames — which agreed to within a metre in the late 1980s — now differ by roughly 1-2 metres in the contiguous US, more toward Alaska. Whether that matters depends entirely on your tolerance: invisible on a state-wide thematic map, unacceptable for cadastral, engineering, or precise GNSS work. The fix is to track the datum explicitly and apply a real transformation, not to assume the two are interchangeable.

Why they drift apart

A geographic datum is a realization of a reference frame: a set of station coordinates plus a model of how the Earth's surface relates to an ellipsoid.

  • WGS84 is maintained by the US NGA and successive realizations (G730, G1150, G1674, G1762, G2139…) are aligned to the ITRF, an Earth-centred frame that does not co-rotate with any single plate. A point on the ground in Kansas therefore changes its WGS84 latitude/longitude slowly over time as the plate carries it.
  • NAD83 (specifically NAD83(2011) and the older NAD83(CORS96), HARN, etc.) is defined so that the stable North American plate is, by construction, motionless. A monument in Kansas keeps essentially the same NAD83 coordinate decade to decade.

So the offset between them is not a fixed bias — it grows. This is also why "WGS84" alone is ambiguous: a 1990s WGS84 dataset and a current one differ. The forthcoming US NATRF2022 will replace NAD83 and be explicitly plate-fixed relative to ITRF, formalizing this relationship.

When the difference matters (and when it doesn't)

It matters when:

  • You combine survey-grade GNSS (often delivered in ITRF/WGS84 or NAD83(2011) with an epoch) with cadastral or engineering layers. A 1-2 m shift can move a boundary across a fence line.
  • You are stacking authoritative data — county parcels (State Plane NAD83) against a WGS84 GPS track — and computing intersections or distances.
  • You work in Alaska or near plate boundaries, where the offset and its rate are larger.

It usually does not matter when:

  • The output is a small-scale overview map where 1-2 m is far below symbol width and line weight.
  • All your data already shares one datum and you never mix in raw WGS84/ITRF observations.

The danger is silent: most North American basemaps are Web Mercator (EPSG:3857, WGS84-based), so WGS84 data "snaps" visually to them while NAD83 data is shifted by a metre or two — easy to miss at zoom-out, costly at survey scale.

The right transformation

The mistake is letting software apply a null transformation (treating NAD83 ≈ WGS84 as identical). For sub-metre work, use a published datum transformation.

In PROJ / QGIS, when you reproject from NAD83 to WGS84, QGIS offers a list of available operations with their accuracy. Pick one with a stated accuracy rather than the "ballpark" identity. The transformation pipeline for NAD83(2011) to a current ITRF/WGS84 realization uses a time-dependent (14-parameter) Helmert transform — which is why the epoch of your data matters.

In PostGIS, reproject explicitly and be aware that a plain ST_Transform between 4269 (NAD83) and 4326 (WGS84) may apply only a null transform unless a more specific pipeline is requested:

-- Naive: may treat NAD83 and WGS84 as identical
SELECT ST_Transform(geom, 4326) FROM parcels;

-- Explicit pipeline (PostGIS 3.4+ / PROJ) for control
SELECT ST_TransformPipeline(geom,
  'urn:ogc:def:coordinateOperation:EPSG::<op_code>', 4326) FROM parcels;

Check epsg.io for the specific EPSG codes: EPSG:4269 = NAD83 geographic, EPSG:4326 = WGS84 geographic, EPSG:6318 = NAD83(2011) geographic.

Worked example: choosing an analysis CRS

You receive parcel data in State Plane (NAD83) and a field GPS track logged in WGS84 lon/lat, and you must compute the area of overlap.

  1. Identify the declared CRS of each layer before touching geometry. Confirm State Plane zone (e.g. EPSG:2229, California Zone 5, US survey feet) and that the GPS track is EPSG:4326.

  2. Decide the analysis CRS by the measurement task and extent. For a county-scale area you want a projected CRS in metres or feet whose zone matches the AOI — the parcels' State Plane NAD83 zone, or UTM NAD83 (e.g. EPSG:26911 for UTM 11N) if the area spans State Plane zones.

  3. Reproject both layers into that one CRS, applying a real datum transformation for the WGS84 track:

    ogr2ogr -t_srs EPSG:26911 -s_srs EPSG:4326 track_utm.gpkg track.gpkg
ogr2ogr -t_srs EPSG:26911 parcels_utm.gpkg parcels.gpkg

  4. Verify units. Confirm the CRS uses metres (or US survey feet — never mix the two; US survey foot vs international foot differs by ~2 ppm, which matters over State Plane distances).

  5. Validate. Measure a known fence length or parcel dimension and compare to record; overlay against ortho imagery and confirm alignment within tolerance.

  6. Document the source CRS, the analysis CRS, the transformation used (and its accuracy), and the data epoch in the project notes.

Common pitfalls and why they happen

  • Assuming NAD83 == WGS84. True in the 1980s, false now — the plate has moved. Software defaults to a null transform because it is "good enough" for display, which trains people to ignore a real offset.
  • Using Web Mercator (EPSG:3857) for measurements. It is a global pseudo-Mercator with severe area/distance distortion away from the equator; it exists for tile rendering, not analysis.
  • Assigning a CRS to "move" a layer. Assigning (defining) a CRS only labels existing coordinates; it is correct only when the coordinates truly are in that CRS. To change positions you reproject. Conflating the two is the classic "my layer jumped" bug.
  • Ignoring the US survey foot vs international foot. State Plane historically uses the US survey foot; picking the wrong foot quietly biases every coordinate.
  • Dropping the epoch. With dynamic frames, a coordinate without a date is incomplete for precise work.

QA and validation

  • Confirm every layer's declared CRS and datum (not just "GCS").
  • Check the chosen transformation's stated accuracy; reject silent null transforms for sub-metre work.
  • Overlay against high-accuracy reference imagery and a known control point.
  • Verify horizontal and vertical units; elevation often hides a separate vertical datum (NAVD88 vs ellipsoidal).
  • Record source CRS, analysis CRS, transformation, units, and epoch.

Bathyl perspective

We treat the coordinate chain as part of the deliverable, not an afterthought: source datum, the exact transformation applied (with its accuracy), the analysis CRS, units, and epoch all travel with the data. In North America the NAD83/WGS84 distinction is small enough to ignore on an overview map and large enough to break a boundary survey — so the only safe default is to make the datum explicit and let the tolerance of the task decide.

Related reading

Sources