Coordinate Systems

Every remotely sensed measurement has to answer two questions: what did the sensor record, and where on Earth does it belong? A coordinate reference system, or CRS, is what answers the second question. It is the agreed framework that turns a pair of numbers into a specific place on the planet, and it is what lets a grid of pixels become a map rather than an anonymous array. The georeferencing metadata introduced in Digital Imagery — a CRS plus an affine transform — is exactly this machinery. Because these ideas describe the data and the Earth rather than any tool, they stay true no matter which software you later use to open a file.

Geographic and projected coordinate systems

There are two broad families of coordinate reference system, and the difference between them matters constantly. A geographic CRS locates points by latitude and longitude — angles measured on a curved model of the Earth. It is natural for describing global position, but its units are degrees, not lengths, so a degree of longitude spans a very different ground distance near the equator than near the poles. That makes geographic coordinates awkward for measuring area or distance directly.

A projected CRS flattens the curved surface onto a plane so that positions can be given in linear units such as metres. This makes measurement, mapping, and regular pixel grids straightforward, at the cost of some distortion, because a sphere cannot be laid flat without stretching. Most analysis that involves distances, areas, or a pixel grid happens in a projected CRS; much global reference and data exchange happens in a geographic one. Knowing which family a dataset uses is the first thing to check, because mixing the two silently produces coordinates that look plausible but are wrong.

Datums and ellipsoids

Latitude and longitude are meaningless until you fix the model of the Earth they are measured against. That model has two parts. An ellipsoid is a smooth mathematical approximation of the planet’s shape — a slightly flattened sphere. A datum then anchors that ellipsoid to the real Earth, defining where its centre sits and how it is oriented, so that a given latitude and longitude correspond to a definite physical location.

Different datums place the same coordinates in slightly different spots, and the offset can reach tens or even hundreds of metres. Two datasets that both report “latitude and longitude” but rest on different datums will not line up, even though their numbers look directly comparable. This is one of the most common and most easily overlooked sources of misalignment, because nothing about the raw coordinate values reveals the discrepancy — only the recorded datum does.

Naming a CRS with EPSG codes

Because a full CRS definition — its family, projection, ellipsoid, datum, units, and origin — is long and error-prone to write out, coordinate reference systems are catalogued and referred to by short registry codes, most commonly EPSG codes. An EPSG code is simply a stable identifier for a fully specified CRS, so that naming the code names every parameter at once. Recording the exact code a dataset uses, rather than a loose description like “in metres” or “in lat/long”, is what makes its geometry reproducible and its alignment checkable by anyone who works with the data later.

Projection distortion and its tradeoffs

Because flattening a curved surface must stretch it somewhere, every map projection distorts at least one of four properties: area, distance, shape, and direction. No projection preserves all of them at once, so each is a deliberate compromise chosen for a purpose. An equal-area projection keeps area faithful — the right choice when you are measuring how much land burned or flooded — but it warps shapes. A conformal projection preserves local shape and angle, which keeps features recognisable and is useful for navigation, but it exaggerates area away from its centre. Others balance the errors without eliminating any.

The practical consequence is that a measurement can depend on the projection it is made in. An area computed in one projection can differ from the same area computed in another, and the gap grows with the size of the region and its distance from the projection’s zone of least distortion. Choosing a projection suited to the location and to the quantity you care about is therefore part of doing the analysis correctly, not a cosmetic detail.

Reprojection and resampling

When two datasets are in different coordinate reference systems, one must be reprojected into the other’s system before they can be used together. Reprojection recomputes where each location falls under the new CRS. For vector data — the points and lines distinguished in Raster vs Vector — this simply moves exact coordinates. For raster imagery it is more involved, because the pixels must be placed onto a new grid whose cells rarely coincide with the old ones. Filling the new grid requires resampling: estimating each output pixel’s value from nearby input pixels.

Resampling always changes the data slightly, and the method matters. Nearest-neighbour resampling copies the closest original value, preserving the exact measurements — important for categorical data such as land-cover classes, where averaging labels would be meaningless. Interpolating methods blend neighbouring values to give smoother continuous surfaces, at the cost of altering the original numbers. Every reprojection is therefore a small, deliberate trade between geometric fidelity and value fidelity, and because repeated resampling steps accumulate error, it is best done as few times as possible.

Pixel alignment and co-registration

Sharing a coordinate reference system is necessary but not sufficient. To compare imagery cell by cell — the foundation of building composites, tracking a Time Series, or measuring Change Detection — the images must also sit on the same pixel grid, with cells of the same size aligned to the same origin. Bringing images into that exact correspondence is called co-registration.

When alignment is even slightly off, a pixel in one image no longer covers the same ground as the pixel beneath it in another. Comparing them then mixes real surface change with a positional error, and the mistake is worst exactly where it is easiest to make — along edges, coastlines, and field boundaries, where neighbouring values differ most. A difference that looks like change can be nothing more than a half-pixel shift. This is why careful alignment is a precondition for stacking or comparing imagery, and why any workflow that combines multiple scenes or sensors has to confirm that they share not just a CRS but a common, well-registered grid before trusting a single comparison.