You load a Shapefile into QGIS and it appears somewhere in the Gulf of Guinea. You calculate the area of a park and get a number 30% bigger than the official figure. You send someone a GeoJSON and their code puts every point in the wrong city. These are all projection problems — and they happen to everyone, constantly. This is the explanation that actually helps you stop guessing.
The Earth is an oblate spheroid — flattened at the poles, bulging at the equator. But even that isn't quite right. The actual surface of the Earth (at mean sea level) is called the geoid, and it's an irregular lumpy shape driven by variations in the planet's gravitational field.
Because you can't do simple maths on a lumpy shape, geodesists define a smooth mathematical ellipsoid that best approximates it. The one most of the world uses today is GRS 80 (Geodetic Reference System 1980), with a semi-major axis of 6,378,137 metres at the equator and a flattening ratio of 1/298.257. WGS 84 uses a nearly identical ellipsoid. Older datums — like Clarke 1866 (used by NAD27) and Airy 1830 (used by OSGB36) — used different ellipsoids, which is why coordinates from those systems don't match modern ones without a datum transformation.
The key insight: coordinates are meaningless without knowing which ellipsoid and which datum they're referenced to. The numbers 51.5074, -0.1278 mean London — but only if you know they're in WGS 84. In OSGB36, those same numbers point somewhere completely different.
Every CRS (coordinate reference system) falls into one of two categories.
Defines positions on the 3D ellipsoid using angles. Coordinates are latitude and longitude in degrees. The Earth is three-dimensional, so technically a geographic CRS is not "flat" at all — it's a reference surface wrapped around a ball.
Key examples: EPSG:4326 WGS 84, EPSG:4269 NAD83, EPSG:4258 ETRS89.
Takes the ellipsoid and "projects" it onto a flat 2D plane using a mathematical formula. Coordinates are in linear units — metres or feet measured from an origin point. This makes distance and area calculations possible and straightforward, but every projection distorts something — shape, area, distance, or direction.
Key examples: EPSG:3857 Web Mercator, EPSG:32632 UTM zone 32N, EPSG:27700 British National Grid.
The most common mistake: performing distance or area calculations on coordinates in EPSG:4326. Degrees are not metres. The distance between two lat/lon points is not sqrt((x2-x1)² + (y2-y1)²). You will get nonsense. Always reproject to a suitable projected CRS before measuring.
EPSG stands for European Petroleum Survey Group, a now-defunct organisation that started maintaining a registry of geodetic parameters in the 1980s because oil companies drilling in the North Sea kept arguing about which datum their survey data was in. The registry is now maintained by the IOGP (International Association of Oil & Gas Producers), but the EPSG name stuck.
Every entry in the registry has a numeric ID. That's the EPSG code. When you see EPSG:4326, that's the registry entry for WGS 84 geographic CRS. When QGIS, PostGIS, GDAL, or any GIS tool asks you for a CRS, you give it an EPSG code (or a Proj4 string, or WKT — more on those below) and it knows exactly which ellipsoid, datum, and projection to use.
The full registry is at epsg.io and spatialreference.org. There are over 6,000 entries. You only need to know about 10 for most work.
EPSG:4326 is WGS 84, the geographic CRS used by GPS satellites, Google Maps, GeoJSON, KML, most web APIs, and essentially all data you will ever receive from an external source. It's the de facto global standard and has been since GPS was civilianised.
Coordinates are in decimal degrees: [longitude, latitude] in GeoJSON (note the order — longitude first), or (latitude, longitude) in most other contexts. The coordinate order inconsistency is a notorious source of bugs — a point at [51.5, -0.12] (lat first) is in the North Sea; at [-0.12, 51.5] (lon first) it's London.
WGS 84 is a datum as well as a CRS. The datum is tied to a set of ground stations whose positions are known to sub-centimetre accuracy and updated regularly. For practical purposes (accuracy better than a metre), WGS 84 and NAD83 are interchangeable — they differ by less than 1 metre everywhere in North America.
When to use it: storing data, exchanging data, APIs, GeoJSON files, GPS tracks, any time you need a universal format someone else can read without guessing.
EPSG:3857 is called "WGS 84 / Pseudo-Mercator" or Web Mercator. It's used by every web map tile service — Google Maps, OpenStreetMap, Bing, Mapbox, ESRI basemaps. You have looked at maps in this projection thousands of times.
The Mercator projection has one useful property: it is conformal — it preserves local shapes and angles. A bearing on the map equals a bearing on the ground, which is useful for navigation. The downside is severe area distortion at high latitudes. Greenland appears the same size as Africa on a Mercator map. Africa is 14× larger.
Web Mercator made things worse by treating the Earth as a sphere (same radius everywhere) instead of the correct oblate spheroid. This was done in 2005 by Google for computational simplicity and tile alignment. The error is small — under 0.7% — but it's technically incorrect, which is why the projection is called "Pseudo-Mercator" and why the US military explicitly refuses to use it.
The coordinates in EPSG:3857 are in metres, but they represent distances from the equator and prime meridian on this spherical Earth model, not the real Earth. The valid range is roughly ±20,037,508 metres in X and ±20,048,966 in Y (cutting off at about 85.06° latitude — beyond that the projection breaks down entirely).
Never use EPSG:3857 for: area calculations, distance calculations, or storing data for any purpose other than tile rendering. EPSG:4326 for storage, EPSG:3857 for tile display. That's the rule.
The Universal Transverse Mercator system divides the world into 60 vertical zones, each 6° of longitude wide. Within each zone, the projection is a Transverse Mercator with a scale factor of 0.9996, which keeps distortion under 0.1% across the entire zone width. It's arguably the best general-purpose projected CRS for most local and regional work.
Each zone has a central meridian — a vertical line running through the middle. Coordinates are in metres east (Easting) and north (Northing) from the zone's false origin. Northern hemisphere zones have a false origin at the equator and 500,000m west of the central meridian. Southern hemisphere zones add 10,000,000m to the northing to avoid negative values.
EPSG codes for UTM follow a pattern:
326XX where XX is the zone number (01–60)327XX where XX is the zone numberSo UTM zone 32 North (covering Germany and Italy) is EPSG:32632. Zone 10 North (covering the US Pacific coast) is EPSG:32610. Zone 55 South (covering eastern Australia) is EPSG:32755.
Finding your UTM zone: take your longitude, add 180, divide by 6, round up. Example: London (0°) → (0+180)/6 = 30 → zone 30. New York (74°W) → (-74+180)/6 = 17.67 → round up = zone 18.
| Location | Approx. Longitude | UTM Zone | EPSG |
|---|---|---|---|
| London | 0° | 30N | 32630 |
| Berlin / Rome | 9–13°E | 32N | 32632 |
| New York | 74°W | 18N | 32618 |
| Los Angeles | 118°W | 11N | 32611 |
| Tokyo | 139°E | 54N | 32654 |
| Sydney | 151°E | 55S | 32755 |
Most countries have a national projection optimised for their territory. Using the national projection keeps distortion minimal across the country and ensures compatibility with official datasets from that government. Here are the ones you'll encounter most often:
British National Grid (EPSG:27700) — Transverse Mercator based on the Airy 1830 ellipsoid and OSGB36 datum. Coordinates called Eastings and Northings in metres, running from 0 in the southwest to ~700,000m east and ~1,300,000m north. Every UK government dataset uses this. When you download Environment Agency flood risk data, ONS census data, or Ordnance Survey OpenData, it will be in EPSG:27700.
Lambert-93 (EPSG:2154) — France's national projection since 2001. Lambert Conformal Conic on GRS80. Two standard parallels at 44°N and 49°N optimise accuracy across continental France. Replaced the older Lambert Zone II Extended for official use.
RD New (EPSG:28992) — Netherlands. An oblique stereographic projection on the Bessel 1841 ellipsoid, centred on Amersfoort. Unique in being oblique (tilted) rather than polar or equatorial. Used in all Dutch government open data including BAG (addresses) and AHN (elevation).
SWEREF99 TM (EPSG:3006) — Sweden's national projection. A single Transverse Mercator zone covering the entire country, based on ETRS89. Simple and consistent for a country that's tall and narrow enough to fit in one zone.
The reason for national projections isn't just pride — global systems like UTM don't fit every country cleanly. Norway straddles multiple UTM zones. The UK's Airy ellipsoid fits British territory better than GRS80 (the BNG was designed before GRS80 existed). France is too wide east-west for a single UTM zone. A national Lambert Conformal Conic gives uniform accuracy across the whole country.
This is where coordinates go to the Gulf of Guinea.
When you load a file without a defined CRS, QGIS usually assumes EPSG:4326 or the project's CRS. If the file was actually in OSGB36 (coordinates like 531000, 181000 — Eastings and Northings in metres), QGIS will interpret those as decimal degrees and put everything in the ocean near 0°N, 0°E. That's the Gulf of Guinea. It happens to almost everyone at least once.
But datum shifts happen even when both files have defined CRS. NAD27 and NAD83 use different ellipsoids. Converting between them requires a grid shift file (.gsb) that contains the interpolated horizontal offset at every point in North America. In some areas, the shift is 10 metres. In others it's 100 metres. If your CRS transformation doesn't include the grid shift (which requires PROJ datum files to be installed), you'll get a rough polynomial approximation that can be off by tens of metres.
The fix: always define the CRS of your data. If you receive data without a CRS, ask the provider. If you can't ask, look for clues in the coordinate magnitude — Eastings around 400,000–700,000 and Northings around 0–1,300,000 in metres are almost certainly British National Grid. Eastings around 155,000 and Northings around 463,000 are Dutch RD New. Coordinates like 500000, 5400000 are almost certainly UTM.
There's no single right answer, but there are clear wrong answers.
| Use case | What you need | Good choices |
|---|---|---|
| Storing / exchanging data | Universal, widely understood | EPSG:4326 (WGS 84) |
| Web map tiles | Matches tile basemaps | EPSG:3857 (Web Mercator) |
| Local distance / buffer | Accurate metric distances | Local UTM zone or national projection |
| National-scale area analysis | Equal-area or low-distortion | National projection, Albers Equal Area |
| Global thematic map (print) | Visually balanced, equal area | Mollweide, Robinson, Winkel Tripel |
| Polar regions | Centred on pole | EPSG:3031 (Antarctic), EPSG:3413 (Arctic) |
| UK data | Matches official datasets | EPSG:27700 (BNG) |
| French data | Matches IGN datasets | EPSG:2154 (Lambert-93) |
The golden rule: use the projection your data came in, for that data. Only reproject when you have a specific reason — combining datasets in different CRS, needing metric measurements, or displaying on a web map. Every reprojection introduces a tiny rounding error, and unnecessary reprojections compound that error.
When you need to specify a CRS in software, you have three options: EPSG code, Proj4 string, or WKT.
EPSG code — the simplest. Just a number. Works in anything that has a CRS lookup database. 4326, 3857, 27700.
Proj4 string — a compact parameterised definition understood by the PROJ library, which underpins GDAL, QGIS, pyproj, PostGIS, and virtually everything open-source. Example for UTM zone 32N:
+proj=utm +zone=32 +datum=WGS84 +units=m +no_defs
The parameters: +proj=utm sets the projection algorithm, +zone=32 the UTM zone, +datum=WGS84 the datum, +units=m the output units. For British National Grid:
+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +datum=OSGB36 +units=m +no_defs
WKT (Well-Known Text) — a verbose, structured format used in Shapefiles (.prj files), SQL databases (PostGIS stores CRS as WKT), and OGC standards. It's human-readable but not human-friendly:
PROJCS["WGS 84 / UTM zone 32N",
GEOGCS["WGS 84",
DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563]],
PRIMEM["Greenwich",0],UNIT["degree",0.01745329...]],
PROJECTION["Transverse_Mercator"],
PARAMETER["central_meridian",9],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
UNIT["metre",1],AUTHORITY["EPSG","32632"]]
In Python, you work with Proj4 via pyproj.CRS.from_epsg(32632) or pyproj.CRS.from_proj4("+proj=utm ..."). In PostGIS, ST_Transform(geom, 4326) reprojects to WGS 84. In GDAL on the command line: ogr2ogr -t_srs EPSG:4326 output.geojson input.shp.
Search 30+ coordinate reference systems by EPSG code, name, country, or keyword. Copy Proj4 or WKT in one click.
Open GIS Projection Finder