Datums in GIS: Coping With the Limits of Lat/Long
Recently, I gave a high-level overview of how coordinates are used in mapping, and now I’d like to take a closer look at datums, the second of three concepts discussed there.
When I first learned that latitude and longitude weren’t sufficient to uniquely identify locations, I was surprised and a little skeptical. In hindsight, it makes sense that different models of the earth’s shape, and different strategies for assigning (typically lat/long/height) coordinates to locations might be used in different regions, at different times, or for different purposes. A datum encompasses all of these concepts.
It’s important to know which datum (and projection) your map uses, so that you can relate it to real locations and know when it’s appropriate to combine or compare with other maps or data. For example, data in the NAD83 datum can’t be overlaid with data in NAD27; you need to convert the data into a common datum first. The process of converting data from one datum to another is called a datum shift; it’s also called a coordinate transformation (EPSG, OGC) or geographic transformation (ESRI).
There are quite a few algorithms for doing datum shifts (EPSG’s Guidance Note 7.2 has a comprehensive list complete with formulas and examples). One common class of datum shifts involves converting from lat/long/height in a source datum to X/Y/Z offsets in meters from the center of its ellipsoid, performing some kind of offset and/or rotation, and then converting back to lat/long/height relative to the target ellipsoid. More irregular cases are often handled by grid shift files; essentially these are look up tables with offsets or parameters which vary by location.
An interesting twist is that different software packages present the datum shift operation in different ways. ArcGIS follows the EPSG model and requires the user to pick the datum shift to use whenever one is required. This is the most general and expressive approach. While intuitively there is only one “right answer” for converting between any two datums, in reality there may be many options, with the correct choice resting on a number of factors including the target accuracy and use. This is another reason metadata is so important – downstream users will want to know how your data was created!
Other packages, like CS-MAP (the primary reprojection library used by FME), base their datum support on two ideas: (a) Each datum uniquely defines the datum shifts that will be used, and (b) Most datum shifts go via a “pivot datum” (typically WGS84; i.e. a conversion from Datum A to Datum B would be executed as A -> WGS84 -> B). This is great for usability in the common case – users are less likely to make incorrect or inconsistent choices – but adds complexity when multiple choices for datum shifts are legitimately required.
In addition to these two common approaches, there are (unsurprisingly) a few other variants you might encounter. For example, with the Gtrans reprojection library (Swedish link), you pick a named transformation instead of specifying a source or destination coordinate system or datum. Some other interesting examples merge the datum shift and projection steps, converting between two projected coordinate systems in different datums in a single step.
All told, correctly dealing with datums and datum shifts can be tricky, but the payoff is large: confidently combining and using more data – across jurisdictions, and across the legacy/modern mapping divide.
