Preferred order of writing latitude & longitude tuples in GIS services

Question

When dealing with GIS source code you often need to write latitude and longitude coordinate tuples.

E.g. in Google Maps links (123, 456):

http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865

Which is preferred order (and why?)

• latitude, longitude

• longitude, latitude

I have seen both being used in various systems and I hope to find some evidence to stick with other one.

Is there a standard practice, and if so, what is it / what are they?

Solution 1

EPSG:4326 specifically states that the coordinate order should be latitude, longitude. Many software packages still use longitude, latitude ordering. This situation has wreaked unimaginable havoc on project deadlines and programmer sanity.

The best guidance one can offer is to be fully aware of the expected axis order of each component in your software stack. PostGIS expects lng/lat. WFS 1.0 uses lng/lat, but WFS 1.3.0 defers to the standard and uses lat/lng. GeoTools defaults to lat/lng but can be overridden with a system property.

The GeoTools docs on the history and explanation of the problem are worth a read: http://docs.geotools.org/latest/userguide/library/referencing/order.html

Solution 2

The prefered order is by convention latitude, longitude. This was presumably standardized by the International Maritime Organization as reported here. Google also uses this order in its Maps and Earth. I remember this order by thinking of alphabetic order of latitude, longitude.

Solution 3

The correct order is longitude, latitude, in virtually all professional GIS applications, as it is in conventional math (ie, f(x ,y, z)). The GeoJSON standard is fairly typical and succinct:

The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a 
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).

The same is true of the primary Open Geospatial Consortium standards (WKT and WKB, and extensions like EWKB). Likewise Google may output the order in Lat/Lon to make it more familiar to users who grew up with that custom (ie from navigation standards like IMO, rather than computational ones.) But the KML standard itself is like virtually all other GIS systems:

The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).

Good rule of thumb: if you know what a tuple is and are programming, you should be using lon,lat. I would even say this applies if your end user (say a pilot or a ship captain) will prefer to view the output in lat,lon. You can switch the order in your UI if necessary, but the overwhelming majority of your data (shapefiles, geojson, etc.) will be in the normal Cartesian order.

Solution 4

ISO 6709 standardizes listing the order as latitude, longitude for safety reasons. Graham's explanation above sounds correct to me as well. Someone suggested this answer isn't related to the question--it absolutely is, and explains why the order is often given as latitude, longitude.

This is how it has been listed for however long navigators have been using the system; changing that now would be confusing, and as ISO suggests, potentially dangerous. GIS softwares, like ArcMap, list them the other way around because that is the typical convention for x,y coordinate pairs. Latitude is y, longitude is x, so that's how Arc lists them.

Solution 5

By convention in 'real-life', when giving a position, the latitude (i.e. North/South) is always given 1st, e.g. 20°N 56°W (although, this doesn't follow normal convention if thinking about a standard Cartesian grid); similarly, all co-ordinates on Wikipedia follow this convention (e.g. see location for Southampton: http://en.wikipedia.org/wiki/Southampton). To save confusion, especially when units aren't being included, I'd always recommend that the latitude is given 1st in a tuple.

View more solutions

Comments

[golimar]

instead of preferred order, you can check a compilation of cases: macwright.org/lonlat

[onmyway133]

It's latitude, longitude order

[Ian Turton]

see also gis.stackexchange.com/questions/293897/…

[Bob Stein]

Good reason for living west of 90°W (roughly the Mississippi River in the US), or east of 90°E (roughly Bhutan). Like finding out if a clock shows military time by waiting until the afternoon.

[TylerH]

I’m voting to close this question because it is not about programming but about geography. It is also an opinion-based question.

[Mikko Ohtamaa]

Thank you for your vote @TylerH - if you read the answers there are several technical specifications that answer the question. So while everyone is entitled to their opinion, there are standards the software industry should follow and then those standards have justifications why they picked one or another. The fact that making this thing opinionated or not about programming has caused a lot of bugs in the past and that's why it is better to stick to the standards.

[TylerH]

@MikkoOhtamaa The difference is that your question does not ask what the required order is for a particular technical specification (which would likely be just as off-topic as a request for off-site documentation information), but rather what the 'preferred' method is [in general]. What is preferred changes based on the person you ask and the purpose/context of the usage. As the answers here have shown, both orderings have a substantial following. Subsequently, the issue of programming relation is still entirely unaddressed.

[Mikko Ohtamaa]

I edited the question title. Happy now @TylerH?

[Mikko Ohtamaa]

@TylerH Geographic Information Systems (GIS) and Geographic Information Application (GIA) are a subset of computer science. It was there in the question since the beginning in the question body. It was there in tags. Here is a Wikipedia article for en.wikipedia.org/wiki/Geographic_information_system - I suggest you pay more careful attention to the problem domain in this question

[TylerH]

@MikkoOhtamaa I have no issue with GIS questions on Stack Overflow. This isn't a GIS question; it's a "how should I order latitude/longitude" question... there's not even a specific GIS application you're asking for. This question is still opinion-based (any question asking for "preferred methods" is opinion-based), too broad (what context, scenario, or application are you asking about? As the answers show, it's different based on those criteria), and not about programming (latitude and longitude are not programming terms but geography terms).

[Mikko Ohtamaa]

@TylerH How would you recommend methe question so that it satiesfies your criteria?

[TylerH]

@MikkoOhtamaa For future such questions, if there's a specific GIS application you're asking about, you should specify that in the question, and ask how it needs to be ordered, rather than what ordering is preferred. That way answers can be objective rather than subjective. But in this question's case, it's too late to edit it, as Stack Exchange policy is to not edit questions in such a way that they invalidate existing/established answers, and there are multiple answers already suggesting both orders.

[Mikko Ohtamaa]

I see some disagreement here :I TWo choices to pick - too many!

[Mikko Ohtamaa]

Finally a authoritative response :)

[Mikko Ohtamaa]

I rarely see as answer on SO.com which states why this well. Beats crap out of those "because MongoDB uses it" answers.

[Aaron McIver]

Your link disagrees with you; In the EPSG database, 4326 maps to a geographic CRS with (latitude, longitude) axis order. However, most software in the field understand EPSG:4326 as a geographic CRS with (longitude, latitude) axis order, because legacy OGC specifications were designed that way.

[Shane]

First two sentences from my answer: EPSG:4326 specifically states that the coordinate order should be latitude, longitude. Many software packages still use longitude, latitude ordering. Isn't that exactly the same?

[Wouter van Nifterick]

Except in KML files. There coordinates are stored as lng,lat,alt; probably because that can be translated to x,y,z

[theta]

So, if that's most intuitive way of thinking, why is Google Earth blog called Lat-Long Blog while they use lon-lat in KML?

[David]

Basically, it's that navigators have traditionally used the lat-lon ordering, so if you messed with that ordering you might screw up your navigations. So google is using the traditional for a blog and the 2D plane ordering for their data structure. @mkennedy answers this best in her answer to the same question: gis.stackexchange.com/questions/6037/…

[Turnerj]

If anyone else has issues with Google Maps and supplying a KML file to it, the order is Longitude/Latitude!! No documentation for the KML file says this!!

[jww]

I think he means programmatically and with a technical reference (but I could be mistaken). The history lesson was interesting, though.

[Mikko Ohtamaa]

This not related to the question, but definitely interesting. Thanks :)

[Antti Haapala -- Слава Україні]

But it does make sense, for if only map coordinates would be used, it would be without question that the order would be longitude, latitude, as in X, Y; the confusion only exists because of the hundreds of years of precedence of saying (and hearing) latitude, longitude everywhere.

[Daniel Antunes Pinto]

It's easily observable when you work with worldwide applications.

[Iain Collins]

Readers should note that ISO 6709 explicitly states you should always use [lat, lon] format in any UI and it's not - as might be inferred - merely a matter of personal preference.

[cazort]

Just type any pair of longitude and latitude coordinates into Google maps and you'll see it interprets it as (long, lat), not vice versa. That's an example of a very widely-used system.

[Terry]

@cazort For whatever reason, that doesn't happen here. For example, my hometown of Eugene, Oregon is at approximately N 44.1, W 123.1. If in maps.google.com I enter 44.1 -123.1, it goes to Eugene. If I enter -123.1 44, it tells me it can't find it. Interestingly, though, if I enter 123.1 W 44 N, it figures it out and goes to Eugene, so there is some flexibility. Also reference.com/technology/… appears to indicate tht lat/long is the preferred order. Also, for what it's worth, Google Earth uses lat/long.

[shi11i]

For the sake of conforming to a standard, imho Google and Apple are in the wrong here and should switch to (lng, lat). Here's a list of who uses what macwright.org/lonlat

[tmcw]

"No documentation for the KML file says this" is incorrect. developers.google.com/kml/documentation/kmlreference#point "A single tuple consisting of floating point values for longitude, latitude, and altitude (in that order)."

[Kevin Smith]

Just got caught out by this using MongoDB - docs.mongodb.com/manual/reference/operator/query/polygon/…

[Mzq]

I was looking for the order of Google Map coordinates, it is now latitude, longitude. @Turnerj, all these discussion make me confusing, so I doubled checked my address with gps-coordinates.net

[Dave X]

en.wikipedia.org/wiki/ISO_6709 says that if the order isn't specified, it should be assumed to be latitude, lon. The doc itself says it's Especially important in the UI. "The sequence of coordinates is critical. Historical conventional usage gives the latitude value before the longitude value. Users in the marine and air navigation fields, and involved with emergency response are used to seeing latitude and longitude given in this order. If the height or depth is also given, it follows longitude. Presenting coordinate values in another order has life-safety implications."

[geira]

The ISO standard specifically only applies to form inputs, not storage mechanisms, software or formats. This is a handy summary.

[geira]

Lots of other examples: WMS, WKT, OpenLayers, Mapbox, Shapefile, Redis, even Google KML (despite using lat/lon in their maps API).

[mheyman]

The great thing about standards is that there are so many of them... The OP asked of the "preferred order". ISO 6709 strings are not even tuples the OP seemed to wonder about (I've had to parse and produce ISO 6709 strings in the past and tuples are easier).

[Luís de Sousa]

The Simple Features, GeoSPARQL and GML specifications are clear in this regard: geometries are encoded with the axes order declared by the CRS. Although some exceptions exist, most software complies with these specifications.

[Luís de Sousa]

Axes order is not a matter of personal preference, it is a feature of the CRS. The specifications from the OGC/ISO are clear, it just happens that not all software packages follow them. You are also mistaken regarding Colon, not only wasn't the return from the Caribbean a major feat compared with other sea journeys of the time, the accuracy of longitude measurements in the XV century is well in display in the Cantino map.