Short answer

A geographic coordinate reference system (CRS) describes positions as latitude and longitude in angular units (degrees) on a curved ellipsoid. A projected CRS takes that curved surface and flattens it onto a plane, so positions are expressed in linear units such as meters or feet. The practical consequence: you can render data in either, but you should measure distance, area, buffers, and most terrain quantities in a projected CRS whose distortion is small over your project extent.

If your areas, lengths, or buffers look wrong, the usual cause is that a planar tool was run against geographic (lon/lat) coordinates, or against a global display projection like Web Mercator that is never meant for measurement.

Geographic CRS: angles on an ellipsoid

A geographic CRS is defined by a datum (an ellipsoid plus its tie to the Earth) and an angular coordinate system. WGS84 (EPSG:4326) is the most common: latitude from -90 to +90, longitude from -180 to +180, units in decimal degrees. ETRS89 (EPSG:4258) and NAD83 (EPSG:4269) are regional equivalents on different datums.

The key property is that the units are angular, not metric, and the ground distance represented by one degree is not constant:

  • One degree of latitude is roughly 111 km everywhere (the meridians are great circles).
  • One degree of longitude is about 111 km at the equator, ~78 km at 45 degrees, and approaches 0 at the poles, because it scales by cos(latitude).

So a "1 unit" buffer in EPSG:4326 is a 1-degree buffer that is wildly anisotropic and latitude-dependent. That is why a circular buffer drawn on lon/lat data renders as an ellipse and why areas computed planar-on-degrees are meaningless.

Projected CRS: meters on a plane

A projected CRS applies a map projection (a defined mathematical transformation) to the ellipsoid so coordinates become eastings and northings in linear units. Each projection trades off distortion among area, shape, distance, and direction; none preserves all of them.

Common families a geoscience team meets:

  • UTM (e.g. EPSG:32601-32660 north, 32701-32760 south for WGS84): transverse Mercator in 6-degree zones. Conformal, with scale error kept under about 1 part in 1,000 within a zone. Excellent default for project-scale work that fits in one or two zones.
  • National grids such as British National Grid (EPSG:27700) or the European LAEA grid (EPSG:3035), the latter being equal-area and the right choice for continental area statistics.
  • State Plane (US) and other local systems tuned to minimize distortion over a small region.
  • Web Mercator (EPSG:3857): conformal, used by virtually all web basemap tiles, and severely area-distorting away from the equator. Treat it as a display CRS only.

The rule of thumb: pick the projected CRS whose area of use contains your data and whose preserved property matches your task (equal-area for area stats, conformal/UTM for general measurement and terrain).

Worked example: a buffer and an area, done right

Suppose you have observation points in points_4326.gpkg (WGS84 lon/lat) somewhere in central Europe, and you need a 500 m buffer and the area of each catchment polygon.

Reproject to UTM zone 33N (EPSG:32633) with GDAL:

ogr2ogr -t_srs EPSG:32633 points_32633.gpkg points_4326.gpkg
ogr2ogr -t_srs EPSG:32633 catchments_32633.gpkg catchments_4326.gpkg

Now buffer in QGIS Processing (native:buffer) using Distance = 500 — the units are meters because the layer CRS is metric. In PostGIS the same logic is explicit:

-- transform once, then measure in meters
SELECT id, ST_Area(ST_Transform(geom, 32633)) AS area_m2,
       ST_Buffer(ST_Transform(geom, 32633), 500) AS buf_500m
FROM catchments;

If you must stay in WGS84, use the geodesic path instead of planar tools. PostGIS exposes the geography type, which computes on the ellipsoid:

SELECT id, ST_Area(geom::geography) AS area_m2   -- returns square meters
FROM catchments;

QGIS does this automatically when its project "Ellipsoidal measurement" option is on: the measure tool and $area then return geodesic meters even when the layer is in degrees. Confirm that setting before trusting on-the-fly numbers.

On-the-fly reprojection is display, not analysis

QGIS, ArcGIS Pro and web frameworks reproject layers on the fly so that data with different CRSs overlay correctly in one view. This is purely a rendering convenience. The stored coordinates do not change, and Processing/geometry tools operate on the layer's native CRS unless you reproject first or set an output CRS. Many "my area is wrong" tickets trace back to assuming that a correct-looking overlay means a correct measurement context.

Assigning vs reprojecting: a critical distinction

These are not the same operation and confusing them silently corrupts data:

  • Assign / define CRS (gdal_edit.py -a_srs, ArcGIS "Define Projection", ST_SetSRID) only changes the label. Use it when the coordinates are already in CRS X but the file says "unknown" or carries the wrong tag.
  • Reproject / transform (ogr2ogr -t_srs, gdalwarp -t_srs, ArcGIS "Project", ST_Transform) actually recomputes coordinate values from the source CRS to the target.

If a layer plots in the ocean off west Africa (the 0,0 null-island symptom) or is offset by tens of meters, decide first whether the metadata is missing (then assign the true CRS) or wrong values (then reproject). Assigning a CRS to "make it move" is the classic way to bake in a permanent error.

Datum transformations and the offset you cannot see

Reprojecting between CRSs on different datums (e.g. NAD27 to NAD83, or an old national datum to WGS84) requires a datum transformation, and there is often more than one available with differing accuracy. Choosing a null/identity transform where a real grid shift (NTv2) is needed produces offsets of several meters to over 100 m — small enough to pass a casual glance, large enough to break a parcel boundary or a borehole collar. In QGIS, check the transformation chosen in the coordinate operation dialog; with PROJ you can inspect candidates via projinfo -s EPSG:4267 -t EPSG:4326.

Vertical units are a separate axis

A 2D projected CRS says nothing about elevation. DEM heights may be ellipsoidal or orthometric (geoid-based), in meters or feet, and the difference between an ellipsoidal and an orthometric height can exceed 30 m. If your workflow combines XY in EPSG:32633 with Z from a DEM, confirm the vertical reference explicitly; mixing them is a common, invisible source of error in volume and slope work.

QA / validation checklist

  • Print the CRS and units of every layer before analysis (gdalsrsinfo, layer properties, ST_SRID).
  • Confirm the target projected CRS area of use contains your full extent, not just the center.
  • Validate one known control distance or a polygon of known area against the computed value.
  • For area statistics over a large region, prefer an equal-area CRS (EPSG:3035, EPSG:6933) over UTM.
  • Inspect the datum transformation actually used, and the vertical reference of any elevation data.
  • Record source CRS, processing CRS, output CRS, and transformation in project notes.

Bathyl perspective

We treat the coordinate chain as part of the deliverable, not a hidden setting. A map can look perfect and still carry a quiet 50 m datum offset or a Web Mercator area error of 2x. Documenting which CRS was used for display versus measurement, and which datum transformation was applied, is what lets another analyst reproduce and trust the numbers months later.

Related reading

Sources