What should I check on a CRS checklist before GIS analysis?

Inventory the declared CRS of every layer, separate missing metadata from wrong metadata, choose a single metric processing CRS suited to the project extent, confirm horizontal and vertical units, watch for datum-shift transformations, and validate against a known control distance before running analysis.

What is the difference between assigning and reprojecting a CRS?

Assigning (defining) a CRS only writes a label and moves no coordinates — use it solely to fix missing or wrong metadata when the coordinates are already in that system. Reprojecting actually recomputes coordinates from a known source CRS to a target. Assigning when you needed to reproject leaves data in the wrong place.

Why is Web Mercator (EPSG:3857) bad for measurement?

Web Mercator is a conformal projection that grossly inflates area and distance away from the equator (scale error grows with latitude), so buffers, areas, and lengths computed in EPSG:3857 are wrong. It is for web display only; measure in an equal-area or local projected CRS instead.

How do I pick the right projected CRS for an analysis?

Match the CRS to the task and extent: a local UTM zone or national grid for distance and buffering, an equal-area projection (e.g. an Albers or Lambert Azimuthal) for area statistics, and confirm its area of use covers your data. Avoid reusing a basemap's display CRS for measurement.

CRS Checklist Before GIS Analysis

Short answer

Most "the numbers are wrong" and "the layers don't line up" problems trace back to coordinate reference system (CRS) mistakes made before any analysis ran. The fix is a short, repeatable checklist: inventory the declared CRS of every layer, separate assigning from reprojecting, choose one metric processing CRS appropriate to your extent and task, confirm units (horizontal and vertical), watch for datum transformations, and validate against a known distance or reference layer. Run it every time and projection work stops being guesswork.

The checklist, step by step

1. Inventory the declared CRS of every layer

Before changing anything, record what each layer claims to be. In QGIS, Layer Properties > Information shows the CRS; on disk a shapefile's CRS lives in its .prj sidecar (no .prj means undefined). From the command line:

gdalsrsinfo data.shp        # vector
gdalinfo dem.tif | grep -A2 "Coordinate System"   # raster

A layer can be known (CRS present and trustworthy), missing (no CRS metadata), suspicious (CRS present but data plots in the wrong place), or unsuitable (a display-only CRS for an analysis task). Classify each before proceeding.

2. Separate assigning from reprojecting — the highest-risk distinction

These are different operations and confusing them silently breaks data:

Assign / define (QGIS: Set Layer CRS; GDAL: -a_srs; PostGIS: ST_SetSRID) only writes a label. No coordinate moves. Use it only when coordinates are already in that system but the metadata is missing or wrong.
Reproject / transform (QGIS Processing: Reproject layer; GDAL: gdalwarp -t_srs / ogr2ogr -t_srs; PostGIS: ST_Transform) recomputes coordinates from a correct source CRS to a target.

If a layer is genuinely in UTM 31N but tagged WGS84, you assign the correct source first, then reproject. If you reproject from a wrong source label, you transform from a lie and the data lands somewhere plausible-looking but wrong. Diagnose by checking the extent: lat/long data has coordinates roughly in −180..180 / −90..90; projected data has large eastings/northings (hundreds of thousands of metres).

3. Choose one processing CRS matched to the task

Do not analyse in whatever CRS the first layer happened to use, and never in a basemap's display CRS. Pick deliberately:

Distance, buffering, length, nearest-neighbour: a local projected CRS — the relevant UTM zone (e.g. EPSG:32631 for UTM 31N) or a national grid (e.g. EPSG:27700 British National Grid). These preserve local distance and shape well within their zone.
Area statistics over a wide region: an equal-area projection (e.g. an Albers Equal Area or Lambert Azimuthal Equal Area parameterised for your region), because UTM and conformal projections distort area.
Confirm the CRS's area of use (see epsg.io) actually covers your data — using a UTM zone two zones away inflates distortion.

Reproject all analytical layers into that one CRS so every geometric computation shares a consistent metric.

4. Confirm units — horizontal and vertical

A geographic CRS (WGS84, EPSG:4326) measures in degrees; a projected CRS in metres or feet. Computing a buffer in a layer whose units are degrees gives a "1" that means one degree (~111 km at the equator), not one metre. Check vertical units too: a DEM may be in metres or US survey feet, and slope/volume work breaks if you assume the wrong one. State both the horizontal and vertical units explicitly in your notes.

5. Watch for datum transformations

Reprojecting between datums (e.g. NAD27 ↔ NAD83, or ED50 ↔ ETRS89) is not just a formula change — it shifts coordinates by tens to hundreds of metres and may require a specific transformation grid. QGIS and PROJ will prompt for or default to a transformation; the highest-accuracy option sometimes needs a downloadable grid (proj-data). Accepting a default null transformation when a real one is needed introduces a constant positional bias that is easy to miss because everything still "lines up" internally.

6. Validate before you trust it

Run two cheap checks: a visual overlay against a trusted reference (a known coastline, road network, or control points) to catch gross placement errors, and a measurement check — measure a feature of known length or area and compare. If a 1 km baseline measures 1.27 km, you are almost certainly measuring in Web Mercator.

Why Web Mercator (EPSG:3857) ruins measurements

Web Mercator is the default of slippy basemaps, so it feels familiar — and that is the trap. It is a conformal cylindrical projection whose scale factor grows with latitude (roughly 1/cos(latitude)), so at 60° N distances and areas are inflated by about a factor of two, and the distortion is non-uniform across a single map. Buffers, areas, and lengths computed in EPSG:3857 are wrong by amounts that increase toward the poles. Display in Web Mercator if you must, but reproject to a metric CRS for any measurement.

Common pitfalls and why they happen

Measuring in Web Mercator. Cause: it is the basemap default and looks normal. Scale error grows with latitude; switch to UTM/national grid for measurement.
Assigning instead of reprojecting. Cause: the two operations sit next to each other in the menus and both "set" a CRS. One labels, one moves coordinates — using the wrong one strands data.
Trusting on-the-fly reprojection for analysis. Cause: layers display together so they seem aligned. The display transform does not change the stored coordinates analysis reads; reproject the data itself.
Ignoring datum shifts. Cause: accepting the default transformation. A wrong/null datum transform adds a constant offset of tens of metres.
Buffering in degrees. Cause: not checking units. A geographic CRS makes "buffer 100" mean 100 degrees, not metres.

QA and validation

Before exporting, confirm: every source layer's CRS was inventoried and classified; analytical layers are all in one metric processing CRS; horizontal and vertical units are documented; any cross-datum reprojection used the correct transformation (not a silent null); a known distance/area validated within tolerance; and the project notes record source CRS, processing CRS, output CRS, and transformation choices so the chain is auditable.

Bathyl perspective

Bathyl treats the coordinate chain as part of the deliverable, not a hidden assumption. Every analytical layer records its source CRS, the metric CRS it was processed in, and any datum transformation applied, so another analyst can reconstruct exactly how a measurement was produced and judge how far to trust it.