Short answer

Almost every handheld and phone GPS records geographic coordinates (latitude/longitude) in a WGS84-family reference frame, streamed as decimal degrees in the NMEA sentences. That is fine for storage, but it is angular, so you cannot measure a distance or area from it directly. For analysis you reproject a working copy to a projected CRS — the appropriate UTM zone or your national grid — while keeping the raw WGS84 points as the archive of record.

The two failures that bite field teams are (1) computing distances and buffers from raw lat/lon and getting nonsense, and (2) a metre-or-two offset between GPS points and the basemap caused by a datum/epoch mismatch, which people "fix" by dragging the layer instead of applying the right transformation. Both are avoidable with a deliberate coordinate chain.

What the receiver actually gives you

A GPS receiver computes a position in the reference frame of the GNSS constellation. For GPS this is a realisation of WGS84; modern receivers and corrections often align closely to ITRF (the International Terrestrial Reference Frame). In practice, the device hands your software lat/lon in decimal degrees plus an ellipsoidal height, exported to GPX or CSV.

Two consequences follow:

  • Units are degrees. One degree of latitude is ~111 km, but one degree of longitude shrinks with latitude (≈ 111 km × cos φ). Any tool that treats degrees as planar will mis-measure — badly away from the equator.
  • Height is ellipsoidal, not orthometric. GPS height is above the WGS84 ellipsoid, which can differ from height above mean sea level (the geoid) by tens of metres. If elevation matters, apply a geoid model (e.g. EGM2008) to get orthometric height.

WGS84 is a moving target: datum and epoch

"WGS84" is not one fixed thing. It has been realised several times, and the modern realisations track ITRF, a global, plate-motion-aware frame. National datums, by contrast, are often plate-fixed:

  • ETRS89 (Europe, EPSG:4258) is fixed to the stable part of the Eurasian plate.
  • GDA2020 (Australia, EPSG:7844) is fixed to the Australian plate.
  • NAD83 (North America) is fixed to the North American plate.

Because tectonic plates move (roughly 2-7 cm/yr depending on location), a coordinate measured today in ITRF/WGS84 drifts away from a plate-fixed national datum over time. In Australia the ITRF-to-GDA difference is on the order of ~1.8 m and growing; in Europe ETRS89 and ITRF diverge by a few centimetres per year. For sub-metre and RTK work you must therefore know both the datum and the epoch of your fix, and apply a time-dependent transformation. For consumer-grade GPS (a few metres of noise), the plate drift is inside your error budget, but the datum offset can still be the visible cause of a basemap mismatch.

This is exactly why nudging a layer to "line it up" is wrong: you are masking a systematic datum difference with an arbitrary shift that will be wrong elsewhere in the project.

The coordinate chain, step by step

  1. Import keeping the source CRS. Load GPX/CSV declaring EPSG:4326 (WGS84 lat/lon). If you only have a CSV of lon/lat, add geometry with the correct CRS — see CSV Coordinates to GIS Layers. Do not assign a projected CRS to lat/lon values.
  2. Confirm the basemap's datum. Identify whether your reference data is ETRS89, GDA2020, NAD83, OSGB36, etc. The offset you see against it is the datum difference, not a GPS bug.
  3. Reproject a working copy to a measurement CRS. For a small site, the local UTM zone (e.g. EPSG:32633 for UTM 33N) or your national grid (e.g. EPSG:27700 British National Grid). In QGIS, Reproject Layer; with GDAL: 
    ogr2ogr -t_srs EPSG:32633 -s_srs EPSG:4326 points_utm.gpkg points.gpx
    PROJ will pick the appropriate datum transformation; for high accuracy specify it explicitly with -ct (a PROJ pipeline) so the operation is reproducible.
  4. Measure in the projected copy. Distances, buffers, areas, snapping to terrain — all in metres now.
  5. Handle height separately. If you need orthometric elevation, transform ellipsoidal height through a geoid grid; do not assume GPS height equals DEM height.
  6. Document the chain. Record source CRS, datum, epoch (for RTK), the transformation used, and the output CRS in the project notes.

Worked example: a metre-and-a-half offset in PostGIS

Field points come in as WGS84; the national reference is ETRS89. Store them honestly and transform on read:

-- raw archive, EPSG:4326
ALTER TABLE field_pts ALTER COLUMN geom TYPE geometry(Point, 4326);

-- working copy in a metric grid (e.g. ETRS89 / UTM 33N = EPSG:25833)
SELECT id, ST_Transform(geom, 25833) AS geom_m
FROM field_pts;

Compute a distance the right way (metres, not degrees):

SELECT ST_Distance(ST_Transform(a.geom, 25833),
                   ST_Transform(b.geom, 25833)) AS metres
FROM field_pts a, field_pts b WHERE a.id = 1 AND b.id = 2;

If you instead ran ST_Distance on the raw 4326 geometries you would get a meaningless answer in degrees. ST_DistanceSphere/ST_DistanceSpheroid are acceptable for great-circle distances on lat/lon, but for site work the projected grid is clearer and consistent with buffers and areas.

Common pitfalls and why they happen

  • Buffering or measuring in EPSG:4326. Buffers come out as ellipses and areas are wrong, because degrees are not metres. Reproject first.
  • Dragging the layer to match the basemap. This hides a datum offset with a shift that is correct in one spot and wrong everywhere else. Apply the datum transformation instead.
  • Ignoring epoch on RTK data. Centimetre fixes tagged to the wrong epoch can be off by years' worth of plate motion. Carry datum + epoch and use time-dependent transforms.
  • Confusing ellipsoidal and orthometric height. GPS height vs DEM/sea-level height can differ by tens of metres. Apply a geoid model when elevation matters.
  • Assigning vs reprojecting. Assign a CRS only when the coordinates already are in it; reproject to actually move them. Mixing these up is the classic "everything jumped to the Gulf of Guinea" symptom (lat/lon mislabelled as a projected grid).

QA and validation

Overlay reprojected points on a trusted reference and check the residual is within expected GPS error, not a systematic shift. Measure one known baseline (a surveyed distance or a building edge) in the projected copy and compare. Confirm the layer's declared CRS matches the receiver's actual output. For RTK, verify the datum and epoch metadata travelled with the file. Keep an intermediate copy of the raw WGS84 import so the chain can be audited.

Bathyl perspective

We keep field GPS as a documented coordinate chain: raw WGS84 as the archive, a projected working copy for measurement, and an explicit record of the datum, epoch, and transformation used. That way an offset is diagnosed as a datum question rather than patched with a nudge that quietly breaks the rest of the project.

Related reading

Sources