Coordinate reference systems (CRSs) are the source of more GIS bugs than any other single topic. They're also explained badly in most documentation, which mixes up datums, projections, and ellipsoids until even experienced users get them wrong. This article tries to fix that.
The two questions a CRS answers
A coordinate reference system answers two questions:
- What shape is the Earth? (the datum and ellipsoid)
- How do we squash that shape onto a flat map? (the projection)
If you only get one thing from this article: those are independent decisions. Two maps using the same projection but different datums can show the same point in slightly different places — usually a few metres, sometimes a kilometre. Two maps using the same datum but different projections look completely different.
WGS 84 — the global reference
WGS 84 (World Geodetic System 1984) is the datum used by GPS satellites. It defines an ellipsoid (a slightly flattened sphere — the Earth bulges at the equator) and ties it to the actual Earth via a network of monitoring stations. When you read a coordinate off your phone, it's in WGS 84.
WGS 84 by itself is not a projection — it's a geographic CRS where coordinates are latitude and longitude in decimal degrees. That CRS has the EPSG code 4326. When you see EPSG:4326, that's WGS 84 lat/lon.
For showing a point on a globe or storing data for global distribution, WGS 84 (EPSG:4326) is the right choice. GeoJSON's RFC 7946 mandates it.
The problem with lat/lon
Latitude and longitude work fine for declaring where things are. They are terrible for measuring distances or areas.
Why? Because longitude lines converge at the poles. A degree of longitude at the equator is about 111 km; at 60° latitude it's 55 km; at the poles it's zero. So if you compute the distance between two points with sqrt(dx² + dy²) using lat/lon in degrees, the answer is meaningless unless you happen to be near the equator.
More subtly: if you compute the area of a polygon in lat/lon, the result is in square degrees — a unit that doesn't correspond to any real surface area.
The solution is to project the coordinates onto a flat plane where distances and areas are meaningful.
UTM — the workhorse projected CRS
UTM (Universal Transverse Mercator) is a family of 60 projected coordinate systems, each covering a 6° wide strip of the Earth. Strip 1 runs from 180°W to 174°W; strip 32 covers western Europe; strip 33 covers central Europe. Each zone has its own EPSG code: 32632 is WGS 84 / UTM zone 32N (northern hemisphere), 32733 is UTM zone 33S.
Within a UTM zone, distances and areas are accurate to roughly 1 part in 2500 — for a 1 km road, that's 40 cm of error. Good enough for nearly all practical work.
The catch: UTM only works within its zone. Try to use UTM 32N for data in California and your coordinates will be wildly wrong. For multi-zone or global datasets, UTM is the wrong projection.
When working with regional data:
- Central Europe (Germany, Austria, Switzerland, northern Italy): UTM 32N (EPSG:32632) or 33N (EPSG:32633).
- British Isles: British National Grid (EPSG:27700) — UTM-like but custom.
- California, Western US: UTM 10N (EPSG:32610) or 11N (EPSG:32611).
- Australia: GDA2020 MGA zone for your region (UTM-style, different datum).
Web Mercator — the projection that's everywhere
EPSG:3857 (Web Mercator, sometimes called Spherical Mercator or Pseudo-Mercator) is the projection used by Google Maps, OpenStreetMap, Mapbox, and effectively every web map you've ever seen. It's a Mercator projection on a sphere (not an ellipsoid), which makes the maths easy at the cost of small accuracy errors.
The distinctive feature of Mercator is that it preserves angles — a north-south line is always straight up. This is great for navigation, terrible for showing relative country sizes. Greenland looks roughly the size of Africa on a Mercator map. Africa is in reality fourteen times larger.
Web Mercator is the right choice for base map tiles and rendered web maps. It is the wrong choice for analysis — never compute areas in EPSG:3857, the results are meaningless except very near the equator.
EPSG codes — the universal language
The EPSG (European Petroleum Survey Group) database is a numbered catalogue of CRSs. Every common CRS has a four- or five-digit code:
- 4326 — WGS 84 geographic (lat/lon)
- 3857 — Web Mercator
- 4269 — NAD83 geographic (US/Canada)
- 27700 — British National Grid
- 25832 — ETRS89 / UTM zone 32N (Germany, etc.)
- 25833 — ETRS89 / UTM zone 33N (eastern Germany, Austria, etc.)
- 32632 — WGS 84 / UTM zone 32N
- 2154 — RGF93 / Lambert-93 (France)
- 28992 — Amersfoort / RD New (Netherlands)
Learn the codes for the regions you work with. Every tool — QGIS, GDAL, PostGIS, Mapbox — accepts them as a CRS identifier.
Datum vs projection — why your data is 200 m off
A classic bug: you load a dataset that claims to be in EPSG:4326 and overlay it on a Google Maps base layer. Everything looks aligned except some features are systematically offset by 100–300 metres.
This is almost always a datum mismatch. The data is probably actually in NAD27, NAD83, or a regional datum that uses lat/lon coordinates similar to WGS 84 but with a different ellipsoid and origin. Without a proper datum transformation, the offset stays.
Fix it: identify the true source datum (ask the supplier or check metadata), then reproject properly:
ogr2ogr -s_srs EPSG:4267 -t_srs EPSG:4326 output.geojson input.shpGDAL will apply the datum shift automatically.
When to reproject — and when not to
Reproject when:
- Your data is in a regional CRS but the destination tool requires WGS 84 (e.g., GeoJSON for the web).
- You need to compute distances or areas accurately.
- You're combining data from multiple sources in different CRSs.
Don't reproject when:
- The data is already in the right CRS for your downstream use.
- You're doing high-precision survey work — every reprojection introduces small floating-point errors. Convert once, keep the source.
- The destination tool will reproject on the fly (modern QGIS, web maps with on-the-fly tiling).
The CRS workflow that saves your sanity
For every new dataset:
- Check the CRS the moment you open the file. In QGIS, look at the bottom right. In
ogrinfo, look at theOGRSpatialReferenceblock. - If the CRS is unknown, ask the supplier. Don't guess. Wrong CRS guesses produce data that looks right but is off by hundreds of metres.
- If the file is for the web, reproject to EPSG:4326 before exporting to GeoJSON.
- If you need to measure distances or areas, work in a projected CRS appropriate to the region.
- Always include the `.prj` file when distributing Shapefiles.
A short reprojection guide walks through a common Central European case. For other zones, swap the EPSG codes — the workflow is identical.
A final caution
CRS handling is the area of GIS where 'looks right' is most misleading. A polygon plotted in the wrong CRS often looks plausible — it's in roughly the right country, the shape is approximately correct. The error only surfaces when you measure distances, compute areas, or overlay data from a different source.
When in doubt, project everything to a known accurate CRS, do the analysis there, and project back for distribution. Two reprojections cost almost nothing in compute time and save weeks of debugging.