CS-MAP, a leading open source coordinate reprojection library, is becoming more standards compliant. In its upcoming v13 release (and current development branch), CS-MAP’s approach to datum transformation and axis ordering more closely matches EPSG’s. I think this is a good thing for interoperability and wanted to take a moment to reflect on the changes.
Why Does Coordinate Reprojection Matter?
The most fundamental problem in computer mapping is associating real world locations with coordinates, a prerequisite for everything from map display to complex analysis. In general, every map has a coordinate system which captures how this was done. There are a huge number of coordinate systems in use, and there is a need to convert between them e.g. to combine data or present it appropriately. FME uses CS-MAP for this purpose by default, and also works with a number of alternatives including ArcGIS, some national software packages, and includes an extension framework to plug in others.
Datum Shifts: More Choice, No More WGS84 Pivot
A coordinate system is typically comprised of a projection (how to flatten the map) and a datum (how to model the earth and map real locations to e.g. latitude/longitude), and it’s this second part that is most challenging to account for when converting between coordinate systems. As previously discussed, there are a number of different approaches, and traditionally CS-MAP has used the concept of a pivot datum: Each datum defines a single conversion to/from WGS84 (the GPS datum) and every datum transformation goes via WGS84. While simple and great for usability, this breaks down when (a) it isn’t appropriate to use WGS84 as an intermediate datum, or (b) when there are multiple ways to transform to between two datums that are valid in different situations. CS-MAP is changing to use a model closer to EPSG and ArcGIS, and will no longer depend on the WGS84 pivot nor force the selection of a single transformation for each pair of datums.
Axis Order: Juggling De Facto and De Jure
There is an interesting tension in the GIS industry around axis order. Most GIS software and formats assume geographic coordinates will be recorded exclusively as longitude/latitude, while the relevant standards implicitly (and increasingly explicitly) require conformance with latitude/longitude definitions. A common example: GIS software might refer to a coordinate system as EPSG:4326 (lat/long WGS84) but store coordinates as (long/lat).
CS-MAP continues to follow the long/lat convention — essential to maintain interoperability — but will now include information about the standards-compliant axis orders. This will make it easier to work with CS-MAP in conjunction with those formats that have made the switch, e.g. WMS, WFS, and GML.
While CS-MAP is only one of a number of options, these updates highlight an ongoing, slow trend towards standardization. More interestingly, the datum shift changes suggest the industry may be moving from “just do the right thing” (choose the datum shift for me) to “the details matter” (force me to pick the right datum shift) experiences for coordinate reprojection.
What do you think? If you work with data in different coordinate systems, are you using user interfaces that try to “do the right thing” and stay out of your way? Or, are you using interfaces that force (allow) you to consider the details? (Hybrids, where an expert configures software once and then others users see limited options, also exist.) I can imagine success or disaster stories resulting from either approach; why don’t you share yours?