Coordinate Reference Systems and the Shape of the Earth

Two datasets can each be perfectly accurate and still land in different places the moment they are stacked on the same map. A county survey crew hands over the coordinates of a property corner. A phone's GPS app records coordinates for that same corner. Both numbers are correct by their own rules, and both can sit ten or more meters apart on screen. The previous lesson covered the two ways a GIS stores the world: features built from points, lines, and polygons on one side, grids of cells on the other. Neither model means anything if the numbers inside it are not tied to an agreed frame. This lesson is about that frame.

A bare coordinate is not a location

The pair 40.7128, -74.0060 looks like a location, and it is one, somewhere in New York City. It only works because everyone reading it silently agrees on the rules behind those two numbers: which direction they count from, and what shape of the Earth they are measured against. Change either rule and the same two numbers can point somewhere else entirely, sometimes a city block away, sometimes an ocean away.

A coordinate reference system, shortened to CRS, is that set of agreed rules. It defines a model of the Earth's shape, an anchor tying that model to the real planet, and the units used to measure against it, degrees of latitude and longitude, or meters on a flat grid. A coordinate with no stated CRS is just two numbers with no meaning attached to them. Every well-built GIS file carries its CRS alongside the data for exactly this reason. A GeoPackage stores it in its own metadata table, a GeoJSON file assumes one by convention without writing it down, and a column in a PostGIS table records it as a numeric code next to every geometry. The coordinates travel, and the rulebook that explains them has to travel with them.

Most beginners meet one flavor of CRS first, because latitude and longitude are the coordinates almost everyone already recognizes. A geographic CRS places every point directly on a model of the Earth using angles: latitude for north-south position, longitude for east-west. There is no flattening involved and no flat grid, just angles measured outward from the center of the modeled Earth to its surface. That phrase, model of the Earth, is carrying more weight than it looks like.

The Earth is not a sphere

A classroom globe is a sphere, and treating the planet as one is close enough for a mental picture. It is not close enough for a coordinate that has to line up with a real fence line or a real flood gauge. The Earth spins, and that spin bulges the equator outward while flattening the poles slightly inward. The result is not a sphere. It is an ellipsoid: a shape like a sphere, squashed a little along its axis.

The squashing is small, a difference of roughly 21 kilometers between the equatorial radius and the polar radius on a planet about 6,371 kilometers across on average, but it is not small enough to ignore. A calculation that assumes a perfect sphere drifts from reality by hundreds of meters over a long distance. Every serious CRS defines its ellipsoid with two specific numbers instead: the length of the equatorial radius, and how much the shape flattens toward the poles. WGS84, the ellipsoid nearly all modern GIS work is built on, sets the equatorial radius at 6,378,137.0 meters and a flattening of about one part in 298.257.

An ellipsoid by itself is still just a mathematical shape floating in space. It has to be pinned to the actual, lumpy, mountain-and-trench planet underneath it, and that pinning is the job of a datum.

A datum ties the model to the ground

A datum is the specific choice of how an ellipsoid sits against the real Earth: which point or points on the actual surface anchor it, and how it is oriented. Two datums can share the exact same ellipsoid and still disagree about where that ellipsoid sits relative to real ground, which means one latitude and longitude value can point at two different real spots depending on which datum produced it.

WGS84, short for World Geodetic System 1984, is a global datum, originally developed by the US Department of Defense and refined over time as measurements of the Earth improve. It is anchored to the planet's actual center of mass, which makes it usable anywhere on Earth without a regional adjustment. NAD83, the North American Datum of 1983, is a regional datum built to fit North America specifically, anchored differently, and historically very close to WGS84 across the continental United States, typically within a meter or two.

The gap that actually surprises beginners shows up with an older datum: NAD27, the North American Datum of 1927, which predates satellite measurement entirely and was built by chaining ground surveys across the continent by hand. A coordinate recorded in NAD27 commonly sits somewhere between 20 and 100 meters away from the same real-world point expressed in WGS84, depending on where in North America it falls. Load an old NAD27 survey file next to a modern WGS84 basemap without reprojecting it first, and roads that should overlap sit noticeably offset, buildings land in the wrong yard, and a property line drawn to a real fence misses that fence by the length of a car.

EPSG codes name a CRS without spelling it out

Writing out an ellipsoid, its anchor point, and its units every time a dataset needs to state its CRS would be unworkable. GIS software instead uses EPSG codes: short numeric IDs maintained by a registry, originally kept by the European Petroleum Survey Group and now by the International Association of Oil and Gas Producers, where each number stands for one fully specified CRS.

EPSG:4326 is WGS84 in plain latitude and longitude, with no projection applied. It is the single most common code in GIS, the default assumption behind GeoJSON, and the coordinate system a raw GPS reading comes back in. EPSG:4269 is NAD83, geographic coordinates fit to North America. Typing "EPSG:4326" into QGIS, GeoPandas, or a PostGIS query is instant and unambiguous, where describing the same CRS in a sentence would take a paragraph and still leave room to get it wrong. A site like epsg.io looks up any code and shows exactly what it defines.

Software leans on these codes constantly. A GeoPandas GeoDataFrame carries its CRS as a crs attribute holding an EPSG reference. A PostGIS geometry column stores an SRID, the same kind of numeric code, right alongside every row. Reprojecting a dataset in Python is often one line once both EPSG codes are known:

import geopandas as gpd

parcels = gpd.read_file("parcels.gpkg")
print(parcels.crs)
parcels_wgs84 = parcels.to_crs(epsg=4326)

That single printed line tells an analyst the parcels file arrived in NAD83, not WGS84, before a single distance or overlay calculation runs against it. Skipping that check is exactly how two files that each look fine on their own end up misaligned the moment they are drawn together.

Datum and projection are not the same job

Two words get blurred together constantly in early GIS work: datum and projection. A datum, everything covered above, decides what model of the Earth a set of numbers is measured against, and where that model sits relative to the real ground. A projection, the subject of the next lesson, is a different job entirely: taking coordinates off the curved surface of that model and flattening them onto a flat plane, the kind of flat x and y a screen or a printed page actually needs.

A geographic CRS like EPSG:4326 has a datum, WGS84, but no projection. Its coordinates are still angles on a curved surface, degrees of latitude and longitude, not flat meters. A projected CRS, such as EPSG:3857, the Web Mercator projection behind most web maps, or a UTM zone used for local metric work, starts from a geographic CRS and applies a mathematical projection on top of it to produce flat coordinates in meters or feet. Every projected CRS depends on a datum underneath it. A datum on its own does not depend on any projection at all.

GPS, and the mistake almost everyone makes once

Every GPS satellite broadcasts its own position in WGS84, and every consumer GPS receiver, in a phone, a car, a fitness watch, computes and reports its fix in WGS84 by default. That is why WGS84 and EPSG:4326 show up everywhere in modern GIS work: it is the coordinate system the entire global satellite positioning network speaks natively, and most current data collection inherits it without anyone choosing it on purpose.

The mistake nearly every beginner makes at least once is assuming any two sets of latitude and longitude numbers are automatically comparable, just because they look like the same kind of number. A historical survey layer digitized from a 1960s paper map, a parcel boundary pulled from an older county records system, an aerial photograph georeferenced years ago: any of these can carry a datum other than WGS84, sometimes NAD27, sometimes a national datum from outside North America entirely, such as ED50 across parts of Europe or the Tokyo Datum still lurking in some older Japanese data. Two files that both name their columns "lat" and "lon" are not necessarily speaking the same language.

The fix is not complicated once the trap is known. An analyst checks the CRS a file declares before combining it with anything else, reprojects it to a shared CRS if it does not already match, and never assumes a coordinate pair is safe to compare against another just because the numbers fall in a familiar range. QGIS shows a layer's CRS in its properties panel and in the bottom right corner of the map canvas. GeoPandas exposes it through .crs. A PostGIS table exposes it through the SRID on its geometry column. The check costs one line or one glance. Skipping it costs an afternoon spent debugging a map where nothing quite lines up.

What carries forward

A coordinate reference system answers where a number sits on a model of the Earth. It does not yet answer how that number gets drawn on a flat screen or a printed page, which takes a separate step: a projection, a mathematical recipe for flattening a curved surface, and the tradeoffs baked into every one of those recipes. That is the next lesson.