Appearance
To handle coordinate systems and datums well, pick one documented working CRS for analysis, store an interchange copy in EPSG:4326, and record the exact transformation used for every layer you bring in. The mistakes that ruin historical GIS projects are almost never about the projection maths — they are about undocumented assumptions, silent datum shifts and CRS metadata nobody verified. A short checklist and a CRS register fix most of them.
What is the difference between a datum and a projection?
A datum is a model of the Earth's shape plus an origin: WGS84, OSGB36 and ED50 each place latitude and longitude slightly differently on the ground. A projection then flattens that curved model onto a flat plane so you can measure and print it. A full coordinate reference system (CRS) bundles a datum, an optional projection and the units, and is identified by an EPSG code such as EPSG:4326 or EPSG:27700.
The practical consequence: two datasets can both say "latitude 51.5" and still be 100 m apart on the ground if one is OSGB36 and the other WGS84. The number is the same; the datum underneath it is not.
Which CRS should I store historical data in?
Use a two-CRS discipline:
- Interchange / storage:
EPSG:4326(WGS84 geographic). Web maps, gazetteer links and most published datasets expect it. - Working / analysis: a local projected CRS in metres, chosen for your region —
EPSG:27700for Britain,EPSG:2154(RGF93 / Lambert-93) for France, a relevant UTM zone elsewhere.
Never compute area, length or buffers in geographic degrees: a degree of longitude is about 111 km at the equator but only about 70 km at 51° N, so degree-based measurements are silently wrong.
How do I reproject without losing the datum shift?
The dangerous step is the datum transformation, not the projection. GDAL/PROJ pick a default, but the default is sometimes the crude one. Be explicit:
bash
# Reproject WGS84 GeoJSON to British National Grid
ogr2ogr -t_srs EPSG:27700 -s_srs EPSG:4326 \
parishes_bng.shp parishes_wgs84.geojson
# Inspect what PROJ will actually do (which pipeline / grid shift)
projinfo -s EPSG:4326 -t EPSG:27700 -o PROJIf projinfo reports a "ballpark" transformation, you are getting a 1–2 m (or worse) approximation because the proper NTv2 grid-shift file (OSTN15 for Britain) is missing. Install the proj-data package so the accurate grid is available.
Why do my georeferenced maps drift by tens of metres?
A consistent offset of roughly 100 m across all of Great Britain is the classic signature of a skipped OSGB36→WGS84 datum shift. Check three things, in order:
- The source's declared CRS — is the
.prjpresent and correct? - Whether your tool applied a datum transformation or assumed the datums were identical.
- The control-point residuals from georeferencing, separately from any systematic shift.
A systematic offset is a CRS bug; scattered residuals are a georeferencing-accuracy issue. Diagnose them separately.
A working CRS checklist
| Step | Action | Why it matters |
|---|---|---|
| 1 | Identify each layer's declared CRS (EPSG code) | Avoids "assumed WGS84" errors |
| 2 | Verify it by overlaying a trusted reference layer | .prj files lie |
| 3 | Choose one projected working CRS | Consistent measurement |
| 4 | Reproject with an explicit transformation | Forces the datum shift |
| 5 | Record EPSG codes + transform in a register | Defensible provenance |
| 6 | Re-check residual offset after reprojecting | Catches silent drift |
How do I record CRS provenance?
Keep a plain CSV or table — the CRS register — committed next to the data:
text
layer, source_crs, working_crs, transform, residual_m, notes
parishes_1881, EPSG:4277, EPSG:27700, OSTN15, 0.1, OS source
tithe_award, EPSG:4326, EPSG:27700, OSTN15, 2.3, georef from rasterWhen a reviewer asks why a feature sits where it does in two years' time, this table answers it. Memory does not.
Key Takeaways
- A datum places coordinates on the Earth; a projection flattens them — the EPSG code captures both.
- Store an
EPSG:4326copy for interchange, analyse in a projected CRS measured in metres. - The expensive bug is a skipped datum transformation, not a wrong projection.
- A consistent ~100 m offset in Britain means a missing OSGB36↔WGS84 shift.
- Never measure distance or area in geographic degrees.
- Verify
.prjmetadata by overlay; never trust it blindly. - Keep a committed CRS register with EPSG codes, transforms and residuals.
Frequently Asked Questions
What is the difference between a datum and a projection?
A datum (e.g. WGS84, OSGB36) defines the model of the Earth and the origin of coordinates; a projection (e.g. British National Grid) flattens that model onto a plane. A full CRS, identified by an EPSG code, bundles a datum, a projection and units together.
Which CRS should I store historical point data in?
Store master coordinates in EPSG:4326 (WGS84 lon/lat) for interchange and web maps, and reproject to a local projected CRS for any area or distance measurement. Never measure distances on geographic degrees.
Why do my georeferenced maps drift by tens of metres?
Usually a missing or assumed datum shift. A coordinate labelled OSGB36 but treated as WGS84 lands roughly 100 m off in Great Britain because the datum transformation was skipped.
What EPSG code does Great Britain use?
EPSG:27700 (OSGB36 / British National Grid) for projected eastings and northings. The associated geographic datum is EPSG:4277 (OSGB36 lat/lon).
How do I record CRS provenance for a project?
Keep a short CRS register: for every layer record its EPSG code, the source's stated datum, the transformation used to bring it into your working CRS, and the residual error. Store it alongside the data, not in someone's memory.
Can I trust the CRS metadata in a downloaded shapefile?
Not blindly. A .prj file can be wrong or missing. Verify by overlaying a known reference layer; if features land in the wrong place by a consistent offset, the declared CRS is likely incorrect.