Preferred order of writing latitude & longitude tuples in GIS services

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?

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

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.

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.

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.

So the preferred order depends on personal preference!

Latitude came first; the equinox has been known for millenia, as the days the "sun crosses the equator"; in March crossing from S to N and Sept from N to S.The only question might have been whether the Equator should have been 0 or 90 degrees. By taking 0 deg, the angle between vertical and the midday solar zenith on the equinox is the latitude of a location, everywhere on the planet. The prime latitude, or prime parallel effectively defined itself.

Longitude could only be by agreement. Britain put up a Longitude prize. Britain needed its ships to know where they were and needed better maps. Harrison (http://www.youtube.com/watch?v=T-g27KS0yiY) produced an accurate marine chronometer; they sent mapmaking voyaging journeys eg James Cook 1770's. Britain therefore claimed the Prime Meridian by using Greenwich as 000deg for their maps. After 100 years of their use, the Prime Meridian was accepted internationally, in 1884.

In Christopher Columbus time Latitude was the only number they had. The strategy was to traverse a parallel before turning left or right for destination; watching for clouds or birds. Measuring speed in knots every hour was common but did not account for currents. Perhaps Columbus's greatest achievement was getting back home from the West Indies four times. Without that, land he discovered could not be added to the maps.

Read "Longitude" by Dava Sobel (ISBN: 9780007214228)

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.

Personally I've never seen anything but latitude followed by longitude.

And, when using + and - instead of N and S, it's always been + is N and - is S.

I have observed variation when using + and - for E and W. Generally + has been E and - has been W. However, on older applications where they were dealing overhwlemingly with W longitudes, I've seen + be W and - be E.

Hopefully you'll not have to be dealing with applications that old.

Apart from GeoJSON spec, which others have already mentioned, there are other practical cases where longitude,latitide order is recommended, even mandatory - e.g.: geospatial indexing in MongoDB. If you get the order wrong there, your queries will return wrong results, as if performed again a transposed dataset.

Longitude then Latitude (lon, lat).

When projected to Mercator longitude defines the x direction and latitude defines the y direction. Most geometry libraries strictly uses this format of (lon, lat) as it is the most intuitive way to think of geographic coordinates in a 2D plane.