What CRS metadata must I verify before delivering a GIS dataset?

At minimum: the authority code (e.g. EPSG:25831), the geodetic datum, horizontal axis order and units, the vertical datum and units if elevation is present, and the specific transformation pipeline used for any reprojection. Record all of these in a sidecar file or the dataset metadata.

How do I tell a missing CRS from a wrong CRS?

A missing CRS means the file has no declared system but the coordinates are real numbers in some projection; you must identify and assign the correct one. A wrong CRS means a system is declared that does not match the coordinates, which usually shows as data landing in the ocean or far from the project area.

Why does my data line up on screen but measure wrong?

On-the-fly reprojection aligns layers for display only. If you run a buffer, length, or area calculation while the layer is in a geographic CRS like EPSG:4326, the result is computed in degrees, not meters, and is meaningless for distance.

What is the difference between assigning and reprojecting a CRS?

Assigning sets the declared CRS without moving any coordinate values, and is only correct when the existing coordinates already belong to that CRS. Reprojecting mathematically transforms coordinates from a known source CRS into a target CRS.

CRS Metadata Checklist for GIS Consultants

The short version

Before any spatial deliverable leaves your machine, you should be able to state, for every layer, six things: the authority code (such as EPSG:25831), the geodetic datum, the horizontal axis order and units, the vertical datum and units if elevation is involved, the transformation pipeline used for any reprojection, and the CRS's official area of use. If you cannot fill in all six from the file's own metadata, the deliverable is not ready, no matter how good the map looks.

The reason consultants get burned by CRS is that the failure is silent. A layer with a wrong or missing system still draws, still styles, still exports. The error only surfaces downstream when a pipeline corridor measures 4% short, a regulator overlays your fault traces on a different datum, or a colleague reopens the project two years later and cannot reproduce a single number. This checklist exists to make the coordinate chain auditable end to end.

What a CRS actually pins down

A coordinate reference system is the contract that ties the numbers in your file to positions on the Earth. It has three parts that consultants routinely conflate:

The datum, which defines the shape and origin of the reference ellipsoid and how it is fixed to the Earth. WGS84, ETRS89, NAD83, and the various national datums are not interchangeable. Between WGS84 and ETRS89 the divergence is now roughly 0.8 m and growing about 2.5 cm per year because of plate motion, so for cm-level work the datum and its epoch matter.
The coordinate system and projection, which decide whether coordinates are angular (longitude/latitude in degrees) or planar (easting/northing in metres or feet), and how the curved surface is flattened. UTM zones, national grids like the British National Grid (EPSG:27700), and Lambert Conformal Conic systems each have a valid extent.
The axis order and units, which are a constant source of swapped coordinates. EPSG:4326 is officially defined as latitude, longitude, yet GeoJSON (RFC 7946) mandates longitude, latitude. Software that does not honour the authority definition will flip your points.

Geographic systems use degrees; projected systems use linear units. This is the single most important practical distinction, because distance, area, and buffer operations are only valid in a projected system whose distortion is acceptable over your project extent.

Why "it lines up" proves nothing

QGIS and ArcGIS both perform on-the-fly (OTF) reprojection: they transform every layer into the project/map CRS for display. This is what makes a mismatched stack appear correct. OTF does not change the stored coordinates, and most processing algorithms operate on the stored geometry, not the displayed one.

So a parcel layer stored in EPSG:4326 will draw perfectly over your UTM basemap, but $area in the field calculator returns square degrees, and a 500 "metre" buffer is actually a 500-degree buffer that wraps the planet. The map is honest; the analysis is not.

The metadata checklist

Run this before delivery, for every layer.

1. Identify the declared CRS without touching anything

For rasters and vectors, inspect the actual declared system rather than trusting the layer name:

gdalsrsinfo -o epsg dem_aoi.tif
ogrinfo -so contacts.gpkg contacts | grep -i srs

In QGIS, Layer Properties > Information shows the CRS and its WKT. Record the authority code, not just "WGS84 / UTM zone 31N".

2. Separate missing from wrong

If the file reports no CRS (a shapefile with no .prj, a raster with an undefined SRS), the metadata is missing. Open the coordinate values: numbers near ±180/±90 suggest geographic degrees; six- or seven-figure values suggest a projected grid. Identify the true system and assign it. If the file declares a CRS but features land in the wrong place, the metadata is wrong and you must find the real source CRS before reprojecting. Never assign a CRS to "make a layer move" — that corrupts the coordinate-to-place contract.

3. Reproject analytical layers deliberately

Pick a projected CRS suited to the extent and task (a single UTM zone, a national grid, or an equal-area system if you are summing areas across a large region). Make the transformation explicit:

ogr2ogr -t_srs EPSG:25831 -s_srs EPSG:4326 out_25831.gpkg in_4326.gpkg
gdalwarp -s_srs EPSG:4326 -t_srs EPSG:25831 -r bilinear dem_4326.tif dem_25831.tif

In PostGIS, keep the SRID honest: use ST_SetSRID(geom, 4326) only to label geometry that is already in 4326, and ST_Transform(geom, 25831) to actually convert it. A common bug is ST_SetSRID(geom, 25831) on lat/long data, which mislabels rather than transforms.

4. Check the transformation pipeline, not just the endpoints

Reprojection between datums (e.g. NAD27 to NAD83, or any local datum to WGS84) can use several different transformation paths with metre-level differences. PROJ will pick a default and may warn about "ballpark" accuracy when no grid shift file is available. Note which pipeline was used:

projinfo -s EPSG:4267 -t EPSG:4269 -o PROJ

For high-accuracy work, install the relevant NTv2/HARN grid shift files rather than accepting a 7-parameter approximation.

5. Verify vertical units and datum separately

Horizontal and vertical references are independent. A DEM can be horizontally in EPSG:25831 but vertically referenced to EGM2008, EGM96, or a national levelling datum, with values in metres or feet. Orthometric (geoid-based) and ellipsoidal heights can differ by tens of metres. If elevation feeds any analysis, record the vertical datum explicitly; do not assume "metres above sea level".

6. Confirm the area of use

Every projected CRS has a bounding extent where distortion is bounded. Using EPSG:25831 (UTM 31N) on data in zone 30 inflates scale error; using Web Mercator (EPSG:3857) for measurement near the poles is grossly wrong. Check the area of use on epsg.io or via projinfo.

Worked example: a corridor that measured short

A client delivered a proposed pipeline as a shapefile with no .prj. The coordinates were six-figure eastings and seven-figure northings — clearly projected, not geographic. We did not guess: overlaying on a known UTM 31N basemap, the line fell exactly on the alignment, so we assigned EPSG:25831. Length came to 18,420 m. The previous consultant had loaded the same file with the project defaulting to EPSG:4326, computed length in degrees, multiplied by a hard-coded 111,320 m/degree, and reported 18,050 m — a 2% error from ignoring the cosine-of-latitude correction. Assigning the correct projected CRS and using ST_Length on the transformed geometry removed the discrepancy.

QA before sign-off

Reproject a known control point (a survey monument, a building corner with a published coordinate) and confirm it lands within tolerance.
Measure a feature of known length (a runway, a section line) in the delivery CRS and compare to the published value.
Inspect the corners of the project extent, not just the centre, where distortion is largest.
Open the dataset in a second tool (load the GeoPackage in QGIS and query it in PostGIS) to confirm the SRID survives the round trip.

Bathyl perspective

We treat the CRS chain as part of the deliverable, not metadata trivia. Every Bathyl spatial product ships with a stated source CRS, processing CRS, output CRS, vertical datum, and the transformation pipeline used, so a third party can reproduce any measurement we report. A defensible coordinate record is what separates a map that looks right from one that can be audited.

CRS Metadata Checklist for Consultants