The short answer

Choose by extent. For distances within a region small enough to fit one zone, reproject to that zone's projected CRS — a UTM zone (EPSG:326xx/327xx), a national grid such as British National Grid (EPSG:27700) or Lambert-93 (EPSG:2154), or a custom transverse Mercator centred on your site. For long lines, routes that cross zones, or anything global, do not trust a single projection: compute the geodesic distance on the ellipsoid (QGIS ellipsoidal measurement, PostGIS geography, or Vincenty/Karney algorithms). Never measure planar distance directly in WGS 84 degrees.

Why distance distorts

Every projection has a linear scale factor that varies across the map. Distance error is the integral of that scale factor along your line, so a measured distance is only as good as the scale behaviour over the path. Three projection families matter:

  • Conformal (Mercator, UTM, Lambert Conformal Conic): scale is equal in all directions at a point but changes with position. Excellent for short distances near the standard line, worse far from it.
  • Equidistant (Azimuthal Equidistant, Equidistant Conic, Plate Carrée): scale is true along specific lines only — radial lines from the centre for azimuthal, the standard parallels for conic. Distances measured along other directions are still distorted.
  • Geographic (EPSG:4326): not a planar projection at all. Computing Euclidean distance on lon/lat treats degrees as metres, which is wrong everywhere and badly wrong away from the equator.

There is no projection that gives a true distance between every pair of points. That is precisely why geodesic computation exists: it solves the distance on the ellipsoid directly, bypassing the projection entirely.

UTM: the default for local distance

Within a single 6°-wide UTM zone, the scale factor runs from 0.9996 on the central meridian to roughly 1.0010 at the zone edges. That is a worst-case error of about 1 m per km, and far less near the centre. For survey traverses, infrastructure spacing, drone flight planning, and most field geology, UTM is the right tool: planar geometry you can do simple maths on, with negligible distortion.

Identify the zone from longitude: zone = floor((lon + 180) / 6) + 1. A site at 2.3°E falls in zone 31, so northern-hemisphere data uses EPSG:32631. Reproject before measuring:

ogr2ogr -t_srs EPSG:32631 lines_utm.gpkg lines_4326.gpkg
ogrinfo -dialect SQLite -sql \
  "SELECT ST_Length(geom) AS metres FROM lines_utm" lines_utm.gpkg

The limitation is the zone boundary. A line spanning two zones cannot be measured correctly in either single zone's projected CRS — the half in the foreign zone accumulates large scale error. For those, go geodesic.

Geodesic distance: the cross-zone and long-line answer

Geodesic distance is the length of the shortest path on the reference ellipsoid. Modern implementations (Karney's algorithm, the default in PROJ/GeographicLib) are accurate to nanometres and valid for any two points on Earth.

In QGIS, enable ellipsoidal measurement in Project ▸ Properties ▸ General ▸ Measurements (ellipsoid set to WGS 84). The measure tool and the length($geometry) expression then return geodesic length regardless of the project CRS.

In PostGIS, the geography type triggers geodesic computation automatically:

-- geom is EPSG:4326 geometry
SELECT ST_Distance(a.geom::geography, b.geom::geography) AS metres
FROM stations a, stations b
WHERE a.id = 1 AND b.id = 2;

ST_Distance on geography returns metres on the spheroid; ST_Length(geom::geography) does the same for a line. This is the method to prefer when a single, defensible answer is needed across an arbitrary extent.

Worked comparison

Measure the distance between two points ~300 km apart, one near a UTM zone edge:

  1. Planar in EPSG:4326 — returns a value in "degrees", or if naively scaled, an error of several percent. Discard.
  2. Projected in the central UTM zone — accurate for the portion near the central meridian, but the point near the edge contributes ~1 m/km of overstatement; total error a few hundred metres.
  3. Geodesic via geography — the reference answer; treat the projected result as acceptable only if it falls within tolerance of this.

For a 300 m line entirely inside one zone, all three sensible methods (UTM, geodesic) agree to well under a metre, so the simpler projected workflow is fine.

Common pitfalls and why they happen

  • Measuring in the basemap CRS (Web Mercator). EPSG:3857 inflates distance by 1/cos(latitude) — about 41% at 45° — because it is built for tiles, not measurement. Analysts measure in it because it is the default project CRS.
  • Treating an equidistant projection as true everywhere. Azimuthal Equidistant is exact only along radii from its centre; a chord between two off-centre points is still distorted. The name misleads.
  • Cross-zone UTM measurement. Splicing data from neighbouring zones into one projected layer reintroduces large scale error at the seam.
  • Forgetting to enable ellipsoidal measurement in QGIS. Without it, $length returns planar length in the layer CRS, silently wrong for geographic data.

QA and validation

  • Cross-check the projected distance against the geodesic distance; flag any disagreement beyond your tolerance.
  • Confirm the projected CRS's area of use covers the whole line, not just its midpoint.
  • For routes, prefer geodesic length and document the algorithm (Karney/Vincenty).
  • Verify the source CRS declaration before measuring — a wrong declaration corrupts both methods.

Bathyl perspective

Our rule is extent-driven: site-scale distances stay in the local UTM zone or national grid; anything regional or cross-zone is reported as geodesic length on WGS 84. We record the method alongside the number, because "12.4 km" without its measurement basis is not a reproducible result.

Related reading

Sources