Sometimes it’s appealing to ignore the curvature of the earth. For example, a building blueprint may have an origin that’s associated with a known location and orientation, with everything else expressed relative to that. If you then want to view the building in the context of other data — say the surrounding city blocks — you’d need a way to georeference that blueprint, associating its coordinates with real-world locations.
Thus, there are two competing goals: a need for simple, local maps with true (enough) distances and angles, and a need to combine these maps to gain a common, regional or global perspective. This post summarizes four common responses to this tension.
This issue shows up when asking local (world is flat) questions of geodetic (world is round) data and visa-versa. Examples include:
- Given a 3D model of a building (in meters, with a known lat/long origin and axis orientation), transform it to fit a georeferenced coordinate system for combination with other data.
- Given a line or area expressed in UTM coordinates, determine what the corresponding measured lengths, areas, or angles would be.
- Given a point or area expressed in a lat/long coordinate system, buffer it by 100 meters, keeping the result in the same lat/long coordinate system.
Option 1: Use a Projected Coordinate System
The simplest response to these challenges is to use an existing projected coordinate system, e.g. UTM or state plane. The whole point of projected coordinate systems is to flatten a round earth onto a flat map, and so this seems promising at first glace. In fact, this is how PostGIS handles some round-earth operations, like the buffering example above.
The biggest limitation of this approach is that scale can differ by position, both horizontally and vertically. For example, near the central longitude of a UTM coordinate system, distances measured in terms of map coordinates are about 0.4% smaller than distances measured on the ground. Similarly, scale changes with elevation: Most projections ignore elevation, converting between x/y and lat/long independently of z, and yet two lat/long coordinates become farther apart the higher they are.
Option 2: Use a Local Coordinate System
Another approach is to define a local coordinate system. A projection and parameters can be chosen to tie a local origin to a known lat/long position and, if necessary, orientation and scale (e.g., to account for average local elevation).
There are many variations on this strategy. For example, one practice is to determine projected (e.g. state plane) coordinates for a project origin, and then measure other positions relative to that using “ground coordinates”. Ground coordinates aren’t meaningful in the original projection; rather, they are specific to the local coordinate system implicitly or explicitly defined for that project.
Option 3: Use a Low Distortion Projection
A weakness of local coordinate systems is that there can be arbitrarily many of them, and the associated parameters are not always carefully maintained or available in a consistent form.
Some jurisdictions (e.g. Wisconsin) have designed coordinate systems that compensate for these issues over moderately-sized areas (e.g. one or two counties) by taking into account the geographic extents, location of urban centers (where higher accuracy is warranted), and average local elevation (relative to the ellipsoid). Coordinates in these systems can be used as though they were ground coordinates in many situations.
Option 4: Don’t Approximate
Over time, technological advances make simplifying assumptions like these less and less relevant (e.g., few use log tables for multiplication). The endgame (IMO) is software that tracks all coordinates in a common, global, geocentric coordinate system and allows users to interact with it however they need: Showing data in context, and calculating and accepting areas, lengths, and angles either according to their true form or warped over the earth’s surface. Together with GPS (which makes the necessary measurements possible), these solutions do exist today, but they are not yet ubiquitous.
The interesting question remains: Will our systems and practice get to the point where we don’t bother with local approximations, or will existing approaches live on for all but the most accuracy-demanding applications? How you are dealing with locally-flat data in a round world?