Spatial data becomes far more valuable when it is not tied to specific applications, formats, or databases. At Safe, our focus is on breaking down exactly these barriers to give you access to your data where and how you need it.
One important thing to specify when exchanging coordinates is axis order: Is it X followed by Y, east followed by north, or latitude followed by longitude followed by ellipsoid height? There are all kinds of options, and this information coupled together with other metadata – together a coordinate reference system – allows you to associate each coordinate with a specific location on earth. Axis order is an important thing to get right; misinterpreting it typically makes your data appear in a nonsensical location with the wrong orientation.
Getting axis order right seems like a simple problem: Simply specify it, along with any other needed metadata, somewhere useful (along with the data, in the specification for a data format, as a parameter in an interface, etc.). In recent history, however, there have been a few heated disagreements about the order to use in various situations. This can lead to ambiguity about how to interpret axis order, e.g. in a data format or in the results returned from a web service. In turn this ambiguity leads to serious interoperability challenges.
So how did we get here?
There are many ways to use coordinates to identify locations on Earth, and most of the common ones are carefully detailed in the EPSG dataset, which is created and maintained by the International Association of Oil & Gas producers. Given this resource, many formats directly or indirectly reference the EPSG dataset when specifying the coordinate reference system associated with data. Although the EPSG specifies an axis order for each coordinate reference system, typically latitude followed by longitude for geodetic systems, the majority of GIS formats ignore this one aspect and use longitude followed by latitude instead. While less expressive, this is simple and doesn’t pose interoperability problems as long as the slight of hand is clearly documented, e.g. as GeoJSON has done.
In a series of decisions, the Open Geospatial Consortium (OGC) has decided that going forward their formats will respect the authority’s axis order, which led to a painful transition for WMS and WFS. Also interesting is the case for the Simple Features WKT and WKB geometry formats, which have not been updated since the latest policy statement. All known implementations of these formats use longitude followed by latitude for geodetic data. Even Informix’s Geodetic DataBlade, which internally uses latitude/longitude, reads and writes WKB as longitude/latitude. When Microsoft introduced spatial support in SQL Server, their geodetic type briefly read WKT and WKB in latitude/longitude order, which led to lively discussion, a retraction, and eventually a five pound box of chocolates. It will be interesting to see what happens when and if these standards are updated.