Short answer

If you compute area or distance directly from coordinates that are in EPSG:4326 (WGS84 longitude/latitude), the number you get is almost always meaningless. The reason is simple but easy to forget: longitude and latitude are angles measured in degrees, not lengths measured in meters. A "square degree" is not a fixed amount of ground. The fix is either to reproject into a suitable projected, equal-area CRS before measuring, or to use a geodesic measurement that integrates over the curved surface of the ellipsoid.

What actually goes wrong

A planar area formula (the shoelace formula, for instance) sums signed trapezoids from vertex coordinates and returns the result in the square of whatever unit the coordinates use. Feed it decimal degrees and it dutifully returns an answer in square degrees — a quantity with no consistent physical size.

The deeper problem is that a degree of longitude and a degree of latitude do not represent the same ground distance, and the longitude case is not even constant:

  • One degree of latitude is roughly 110.6 km everywhere (it varies only slightly with the ellipsoid, from about 110.57 km at the equator to 111.69 km at the poles).
  • One degree of longitude is about 111.32 km at the equator, but it scales by the cosine of latitude. At 45° N it is roughly 78.8 km; at 60° N about 55.8 km; near the poles it collapses toward zero.

So a 1° × 1° "box" near the equator covers roughly 12,300 km², but the same box at 60° latitude covers closer to 6,200 km² — about half. If your code multiplied degree differences and scaled by a single fixed "111 km per degree" constant, you would overstate the high-latitude polygon by nearly 100%. This error is systematic, not random, and it grows with latitude.

Why distance has the same disease

The identical logic breaks Euclidean distance. sqrt((Δlon)² + (Δlat)²) in degrees treats a degree of longitude and a degree of latitude as equal, which is only approximately true at the equator. Anywhere else, east–west distance is overstated. This is why buffers built in EPSG:4326 come out as ellipses that look squashed north–south, and why a "1000-unit" buffer means nothing.

The two correct approaches

1. Planar measurement in an equal-area projected CRS

Project the geometry into a CRS whose units are meters and whose projection preserves area, then measure planar. The key word is equal-area: Web Mercator (EPSG:3857) is the wrong choice here because it is conformal, not equal-area — it inflates area massively away from the equator (Greenland looks larger than Africa). Good choices include:

  • A national or regional equal-area grid where one exists.
  • Lambert Azimuthal Equal Area centered on your area of interest — the basis of EPSG:3035 (ETRS89-LAEA) for Europe.
  • Albers Equal Area Conic for mid-latitude regions with a primary east–west extent (used by many US national datasets).

A UTM zone (e.g. EPSG:326xx / 327xx) is transverse Mercator, which is conformal, not equal-area — but its area distortion within a single 6°-wide zone is small (well under 0.1% near the central meridian), so UTM is acceptable for area on local extents that fit inside one zone. For anything spanning multiple zones or a continent, use a true equal-area projection.

2. Geodesic measurement on the ellipsoid

Geodesic area integrates the polygon over the curved WGS84 ellipsoid surface using algorithms such as Karney's (implemented in GeographicLib, which PROJ and GDAL rely on). You feed it longitude/latitude directly and get correct square meters back. This is the most robust option for large or global extents because it never depends on choosing a projection.

Worked example — QGIS

In QGIS the field calculator behaves differently depending on project settings, which trips people up constantly.

  • Open Project → Properties → General and set the Measurements ellipsoid (e.g. WGS 84). With an ellipsoid set, the $area expression returns geodesic area in the project distance units regardless of layer CRS.
  • To force planar area in the layer's own units, use area($geometry) after reprojecting the layer, or set the ellipsoid to "None / Planimetric".

The cleanest, most auditable route is explicit reprojection. Run Vector → Data Management → Reproject Layer (Processing algorithm native:reprojectlayer) into an equal-area CRS, then compute $area. Now the number, the CRS, and the units all agree.

Worked example — PostGIS

PostGIS makes the distinction explicit through the geography and geometry types.

-- WRONG: planar area on lon/lat degrees -> square degrees, meaningless
SELECT ST_Area(geom) FROM parcels;            -- geom is EPSG:4326

-- RIGHT (geodesic): cast to geography -> square meters on the ellipsoid
SELECT ST_Area(geom::geography) AS area_m2 FROM parcels;

-- RIGHT (planar, equal-area): transform first, then measure
SELECT ST_Area(ST_Transform(geom, 3035)) AS area_m2   -- ETRS89-LAEA, Europe
FROM parcels;

ST_Area(geometry) returns units of the SRID — degrees-squared for 4326. ST_Area(geography) always returns square meters computed geodesically. If your geometry lacks an SRID, set it first with ST_SetSRID(geom, 4326) (this only labels the data; it does not move coordinates).

Worked example — GDAL / ogr2ogr

To reproject a vector layer to an equal-area CRS on disk before any measurement:

ogr2ogr -t_srs EPSG:3035 parcels_laea.gpkg parcels_4326.gpkg

Then any downstream planar area tool will return correct square meters.

Common pitfalls and why they happen

  • Using Web Mercator (EPSG:3857) to measure area. It is the default basemap projection, so it feels "neutral," but it is conformal and grossly area-distorting. The reason this slips through is that small local features look fine; the error only becomes obvious at high latitude or large extent.
  • Applying a single "111 km per degree" constant. This ignores the cosine-of-latitude shrinkage of longitude and is only valid in a narrow band near the equator.
  • Confusing ST_SetSRID with ST_Transform. Setting the SRID relabels; transforming moves coordinates. Measuring after a SetSRID-only "fix" still measures degrees.
  • Mixing geodesic and planar results in one report. A geodesic geography area and a planar UTM area can differ by a fraction of a percent locally and by tens of percent globally; never tabulate them together without noting the method.

Validation

  • Pick one polygon of known size (a surveyed parcel, a 1 km × 1 km sample tile) and confirm your pipeline returns the expected value to within a tolerance you state.
  • Compare geodesic area against equal-area planar area for a few features; for local extents they should agree to a few tenths of a percent. A large disagreement means a wrong CRS somewhere.
  • Sanity-check the unit: an answer like "0.0023" for a city block tells you that you are still in square degrees.

Bathyl perspective

We treat every area or length figure as carrying an implicit method: which CRS, planar or geodesic, which ellipsoid. A deliverable that reports hectares should also make that method recoverable, so a reviewer can reproduce the number rather than trust it. Equal-area projection choice is part of the data product, not an afterthought at export time.

Related reading

Sources