opinionated software is only cool if you have cool opinions - Tom MacWright
Here’s a list of which software packages expect longitude first and which other ones expect latitude first . Which is correct is a matter of opinion.
My opinion is that longitude should be first. If you need to represent a position as an ordered pair, the order should be
Data formats are harder and slower to change than software, and almost every geospatial format puts longitude first.Once you put a specification out there, releasing a new version of that specification is fraught; most formats are published once and never modified. The only geospatial formats I know of that put latitude first are the ‘simple’ version of GeoRSS 1 and the Google Encoded Polyline algorithm. 2 Simple GeoRSS is incredibly rare: the non-simple type of GeoRSS uses GML as its geographic encoding, and GML doesn’t have a coordinate ordering. Encoded polylines encode coordinates in text, so it’s hard to say that they even have an ordering or if that’s just an implementation detail.
Longitude, latitude ordering is sometimes chalked up as something weird that the new GeoJSON format does. Longitude-first has been the case ever since the ancient WKT format , it’s the ordering in the industry-standard Shapefile , and also the order in that user-friendly KML format you use with Google Maps.
Almost all open source software uses longitude, latitude ordering.The only current exception is Leaflet 3 , which owes its ordering decision to the early-on goal of being very similar to the Google Maps SDK.
If you include altitude in your position, then latitude-first gives you YXZ, which is nonsense. Similarly, latitude, longitude is the equivalent of YX ordering, which is the opposite of what an ordered pair in mathematics is by default. Similarly width × height is the more popular way to make measurements.
If you’re deciding which order to store coordinates in, choose longitude, latitude. With our powers combined, we can finally standardize on the one true ordering.