Every flat map of the Earth is wrong, and not because cartographers have not tried hard enough. The wrongness is mathematically necessary. A curved surface cannot be laid flat without stretching, tearing, or compressing it, and no amount of cleverness in the formula removes that.
What a projection does is choose which errors to accept. It is a decision about what to preserve and, by unavoidable consequence, what to sacrifice. Every projection ever devised is that decision made differently, which is why there are hundreds of them and why the question "which projection is best" has no answer without the question "for what".
The practical problem is not that people pick the wrong projection. It is that most pipelines never pick one at all. The data arrives in something, the map library defaults to something else, and numbers get computed in whichever one happens to be current at the moment somebody calls an area function.
The impossibility is a theorem
A sphere and a plane have different intrinsic curvature, and curvature is a property that survives bending without stretching. Wrap a sheet of paper into a cylinder or a cone and nothing on it distorts: distances along the surface are unchanged, angles are unchanged. That works because a cylinder and a cone have the same intrinsic curvature as a flat sheet. A sphere does not, and no mapping from a sphere to a plane can preserve all distances.
The everyday demonstration is an orange peel. Remove it in one piece and try to flatten it. It tears, or it has to be stretched. The tearing is the map's projection error made physical, and no cutting pattern eliminates it, it only redistributes it.
This is why projection is a matter of allocation. The total distortion cannot be reduced to zero, so the designer decides where to put it: concentrated at the edges and minimal in the center, spread evenly across the whole map, zero for one property and unbounded for another, or minimized on average with no property perfectly preserved anywhere.
Four properties, and which can coexist
Projections are classified by what they preserve.
- Area. An equal area projection keeps the ratio of areas correct everywhere. A square centimeter of map is the same number of square kilometers of ground no matter where it falls.
- Shape, more precisely local angle. A conformal projection preserves angles at every point, so small features keep their shape and directions are locally correct. Large features still distort, because conformality is a local property only.
- Distance. Some projections keep distances true along specific lines, usually from a single point or along particular meridians. No projection preserves all distances between all pairs of points.
- Direction. Azimuthal projections keep bearings from a central point true, which is what makes them right for range rings, radio coverage, and anything radiating outward from one place.
The important constraint: area and local shape cannot both be preserved. A projection is conformal or equal area, never both. The reason is direct: preserving angles requires that scale be identical in every direction at a point, and preserving area requires that when scale increases in one direction it decreases in the perpendicular one. Those two conditions can only both hold if scale is uniform everywhere, which is the flat case that a curved surface rules out.
Everything else is compromise. Many well known world projections preserve nothing exactly and simply keep all the errors moderate, which for a general reference map is often the right choice. What matters is knowing which kind is in use, because a compromise projection is unsuitable for measurement in exactly the same way a conformal one is.
The web default, and what computing in it costs
Online maps standardized on a spherical Mercator variant. The reasons are engineering ones and they are good: the projection is conformal, so north is up everywhere and local shapes look correct at any zoom; the world maps onto a square that subdivides cleanly into a quadtree of tiles, which is what makes seamless zooming and tile caching work; and the transformation is a couple of cheap operations.
The price is area. Mercator's scale factor grows with latitude, and it grows without bound toward the poles, which is why the projection is normally truncated well short of them. Near the equator, area is close to true. Through the mid latitudes, features are visibly enlarged. At high latitudes the exaggeration becomes extreme, producing the familiar impression that northern landmasses rival entire continents.
For drawing pixels this is understood and acceptable. For computation it is not, and the reason is the shape of the error rather than its size. It is not a constant offset that can be subtracted, nor a constant factor that can be divided out. It is a multiplier that varies continuously with latitude. Any quantity computed in this projection therefore has geography baked into its error.
The consequences follow mechanically:
- Areas computed in web Mercator are inflated by a latitude dependent factor. Two identical parcels at different latitudes report different areas.
- Buffers of a fixed projected radius correspond to different ground distances at different latitudes, so a fixed radius catchment is larger on the ground in one place than another.
- Densities computed as count over projected area are understated at high latitude, in a smooth gradient that resembles a genuine geographic pattern.
- Comparisons across latitude are the worst case, because the error is precisely correlated with the variable being compared.
There is a secondary issue worth knowing. The web variant treats the Earth as a sphere while the coordinates fed into it are ellipsoidal. This is a deliberate simplification that keeps tile math simple, and it introduces a small latitude dependent shift, irrelevant for display and not irrelevant for precise work.
The rule is short: the display projection is for display. Nothing numeric should come out of it.
Equal area, for anything involving quantity
The moment an analysis involves how much, the projection must be equal area. Land cover proportions, population density, hazard exposure area, agricultural yield per unit area, habitat extent, deforestation change: all of these are ratios with area in the denominator or the numerator, and all of them are corrupted by an area distorting projection.
Several families are standard. For a country or region in the mid latitudes with greater east to west extent, a conic equal area projection with standard parallels placed inside the region is the usual choice. For a region roughly circular or centered on a point, an azimuthal equal area projection centered on that point works well. For a whole world statistical map, one of the pseudocylindrical equal area projections gives an honest area comparison across continents at the cost of shape distortion toward the edges.
Two details make the difference between a correct result and an approximately correct one. The parameters matter: a conic projection with standard parallels chosen far from the data has more distortion than one with parallels placed properly, even though both are equal area, because equal area guarantees correct area and says nothing about how badly shapes and distances are stretched. And equal area on a sphere is not the same as equal area on an ellipsoid, so for careful work the ellipsoidal formulation matters.
The alternative to projecting at all is to compute on the ellipsoid directly, using geodesic area and distance functions. Modern libraries support this, and for global analyses it avoids the problem of choosing a projection that suits every region at once, which nothing does. It costs more per computation and it is usually the better answer when the study area spans continents.
Local systems and zone based grids
For work within a limited area, the practical answer is a local projected system, and most of the world already has one.
A global zoned system divides the planet into narrow longitudinal strips, each with its own transverse conformal projection tuned to that strip. Within a zone, distortion is small enough for engineering work, coordinates are in meters, and ordinary planar geometry applies. The catch is the zone boundaries: a project spanning two zones has to pick one and accept the growing distortion outside it, or handle the transition explicitly. Data unknowingly mixed from two zones produces coordinates that are numerically similar and geographically far apart.
National grids follow the same pattern with parameters fitted to the country, which is why they generally perform better inside their borders than any global system. They are also tied to national datums, so using one correctly means handling the datum as well as the projection.
For distance from a single origin, an azimuthal equidistant projection centered on that origin is the right tool. Distances measured from the center are correct in every direction, which is what a coverage radius, a service catchment, or a range ring actually needs. Distances between two other points on the same map are not correct, which is the constraint that comes with it.
A decision procedure
The choice can be made mechanically in most cases.
- Determine what is being computed. Area or any ratio involving area: equal area. Angles, bearings, or shape sensitive work: conformal. Distance from one origin: azimuthal equidistant centered there. Display only: whatever the map library uses.
- Determine the extent. A single city or site: a local grid or national system. A country or region: a conic or azimuthal projection with parameters set for that region. Global: either a pseudocylindrical equal area projection or, better for numbers, geodesic computation on the ellipsoid with no projection at all.
- Set the parameters to the data, not to the default. A projection is a family, and the family member matters. Center it on the study area.
- Project for the computation, then return to a geographic system for storage and exchange. Never store in a local projected system data that will travel outside its zone.
- Record the projection used with the result. A figure whose projection is unknown cannot be compared with anything.
A useful sanity practice: compute a known quantity two ways. Take a feature whose true area is documented, compute it in the chosen projection and again geodesically, and compare. If the two disagree by more than a fraction of a percent, the projection is wrong for the task or the parameters are wrong for the region.
Reading distortion instead of guessing at it
Distortion is measurable, and the standard tool is a small circle drawn on the globe and transformed onto the map. On a conformal projection it remains a circle everywhere, growing in size where scale grows, which shows shape preserved and area distorted. On an equal area projection it becomes an ellipse of constant area, flattened in one direction and stretched in the other, which shows the opposite trade. On a compromise projection it becomes an ellipse whose area also changes, showing that neither property is held.
Plotting a grid of these across a map makes the trade visible instead of theoretical, and it makes the case for a specific choice far better than an argument. It also exposes the parameter problem quickly: the same projection with badly chosen standard parallels shows visibly worse distortion over the study area than one with parallels placed correctly.
For a working pipeline, the same idea reduces to a test. Take a set of reference polygons spread across the study area, compute their areas in the working projection, compare against geodesic areas, and assert that the maximum relative error stays inside a stated tolerance. That test is cheap, it runs in continuous integration, and it fails loudly when someone changes a default.
The failure that ships
The one that reaches production over and over is an area computed in the display projection because that is what the data happened to be in.
The sequence is always similar. A team builds a map. The tiles are web Mercator, so the front end works in web Mercator, so the geometries get stored in web Mercator to avoid transforming on every render. Later, somebody needs the size of the polygons a user drew. The geometry is right there, in projected meters, and the library has an area function that returns a number in square meters. It runs. It returns a plausible figure. Nobody transforms anything, because the units already say meters.
The result is inflated by a factor that depends on latitude, silently, with no warning and no unit mismatch to catch it. In a single city the factor is roughly constant, so internal comparisons still rank correctly and everything appears consistent, which is exactly why the bug survives. It surfaces when the same system is used in a second city at a different latitude, and the two sets of figures are placed in one table.
By then the numbers are in reports, in dashboards, and in decisions. The fix is trivial and the cleanup is not.
Two habits prevent it entirely. Store geometry in a geographic system and treat any projected copy as a rendering artifact with a short lifetime. And make every measurement function in the codebase require an explicit projection or geodesic mode, with no default, so that the question has to be answered by whoever is asking for the number rather than by whatever the data happened to be in.