Displaying coordinates and inputs as LatLon or LonLat?

Question

I'm trying to get a sense if this is an issue for others or every input/output should be labeled so user is not confused and just go with it?

I think almost everyone pronounces it as "LatLon".

Who started it?

Is it because it's in alphabetical order compared to "LonLat"?

Mapping Lat and Lon to Cartesian plane Lon is "x" and Lat is "y" so since we say "(x,y)" it should be said as "LonLat". And now for display of information.

Should the status bar on a mapping application display La,Lo or Lo,Lat?

Should it just be labeled as one way and let user deal with it?

And same with input, what's the right way to order the fields?

KML's format is Lon,Lat,Altitude. While other apps is Lat,Lon and so have to be very vigilant about when converting formats.

Is there a standard?

Answer 1

You should take a look at the ISO standard 6709. Here's the wikipedia entry: ISO 6709

The main item is that order should always be latitude longitude.

Latitude comes before longitude

[edit now that I have a copy of 6709:2008]

For data interchange, use DD, but for backwards compatibility, sexagesimal is valid.

There's a section called "Latitude and longitude coordinates are not unique" complete with picture.

There is very strong wording about the coordinate order for display (not interchange). It says that navigators have traditionally used latitude longitude order and to change the order could compromise safety. Use sexagesimal, direction symbols rather than +/-, etc. Z values follow longitude. Grid/planar values should use the order specified in the CRS definition.

34°05'09.76"N 117°02'01.23"W 829.1m

(Hah! I started to write out a sample and automatically wrote the longitude value first)

Answer 2

Representing a position on a globe requires not two, but three values, which on earth are generally represented by (latitude, longitude, elevation). Computers generally work in Cartesian spaces, as do our paper maps, which are easier to understand as (x,y) coordinates, hence the conflict.

The ordering followed some historical convention for spherical coordinates, which map onto geographic coordinates as follows:

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

The common ordering of (r, θ, φ) (an ISO standard in the physics community, though not not settled elsewhere) simplifies to (θ, φ) when you assume we're working on a unit sphere, and hence (latitude, longitude).

Because a GIS is implemented in an environment which uses cartesian coordinates are used throughout the rest of the system, we're left with a bit of a conflict. I think the key issue is to be clear what you're using, and stick to it.

I personally prefer the Cartesian units because of their commonality elsewhere, and while the academic connections to spherical coordinates aren't to be forgotten, it isn't the pragmatic choice when implementing new systems. The (x, y) form is used internally in most spatial file formats such as WKT, Shapefiles, GeoJSON and the like -- but if you're presenting data to a lay audience, then what's right depends on what's easiest for them to understand.

Answer 3

The previous two answers already cover the history, here's just my two cents about standards:

For the purpose of data exchange, the order of coordinates is determined by the choice of CRS, as promoted by OGC in their Axis Order Policy Guidance Note.

If you look closely, any EPSG CRS specifies the order of the axes, which should be respected in any payload marked to use the CRS. For example, anything that publishes data in epsg:4326 (WGS 84 geographic 2D) should have coordinates expressed as (lat, lon). You can check the EPSG registry yourself (search for code 4326 and look under Ellipsoidal CS / Axes).

Another widely used way of specifying CRS is the Projection WKT (section 7; also available here), which also prescribes the order. For example

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

The AXIS parameters are optional however, and the defaults, according to this specification, are

AXIS["Lon",EAST],AXIS["Lat",NORTH].

this makes the whole issue quite confusing, because it means that a lot of the .prj files out there referencing epsg:4326 (e.g. the one on spatialreference.org) which do not explicitly specify the same axis order as EPSG, but nevertheless reference the EPSG code, are in conflict with the OGC guidance note.

Answer 4

This is a common problem, here is another previous discussion:

• Why some coordinate systems define x-axis as northings and some as easting?

There is a very exhaustive discussion at http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick provided the above information as a comment to a duplicate question

Answer 5

This posed a big problem for me for years on AutoCAD 2D compounded by the fact that autocad reads angles anticlockwise with 0 degrees starting at the 90d position. For a while I liked to believe I had solved it by changing the UCS such that x became northing and y easting. As long as I continued to produce 2D property plans I never really got to face my error: the z axis was pointed the wrong way.

Of course my dimension text were usually reading right to left but I felt it was a small price to pay for correct angle reading and more to the point, putting x and y in their intuitive places (as per Northing/Easting, Lat./Lon. conventions). Then I graduated to Autocad Civil 3d and tried to perform the trick again and came face to face with the bottom line: y is north/lat and x is East/long. Accept that.