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?


5 Answers 5


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)

  • 9
    That doesn't mean that the standard is the best. My students get confused with the mix of lat/long...then you introduce easting and northing...then x/y. I would favour that one stick with the mathematical representation of coordinates, whether spherical or planar, x/y, easting/northing, long/lat...perhaps a movement could be afoot
    – user681
    Commented Feb 11, 2011 at 1:31
  • Melita -- you are spot-on that ISO 6709 IS the standard. But the ISO 6709:2008 revision "...additionally specifies representation of horizontal point location using coordinate types other than latitude and longitude." Could you please expand on those aspects of the standard for folks. Commented Feb 11, 2011 at 17:48
  • 1
    @Stuart, unfortunately I don't have access to the 2008 revision, and don't fancy paying 122 euros for the privilege! Someone here might have it; I'll see if I can find a copy. There's still copyright issues on how much I can post.
    – mkennedy
    Commented Feb 11, 2011 at 21:13
  • @Dan, oh, I agree completely, but the movement had taken place, and ended up getting revised to the current latitude, THEN longitude. On x,y: unfortunately, not everyone equates x = easting, y = northing! Esri has several enhancement requests to support changing the labels for axes, swapping order, etc.
    – mkennedy
    Commented Feb 11, 2011 at 21:17
  • 2
    @Stuart, I edited my answer to include some information from the standard.
    – mkennedy
    Commented Feb 11, 2011 at 23:24

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.

  • 2
    (+1) There is, however, a convention for orienting coordinate systems. According to this convention, for example, (x,y) is positive while (y,x) is negative. On the sphere, (lat,lon) is negative while (lon,lat) is positive (taking western longitudes and southern latitudes to be negative numbers, which seems to be universal). Therefore, if you want to use a consistent orientation for coordinate systems, you will use (easting, northing) on your maps and (lon, lat) on the sphere.
    – whuber
    Commented Jun 29, 2011 at 23:13

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


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


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.

  • I don't believe that the specifications are dictating storage order. They are dictating interchange/display order. It's a bit like quantum physics. You can't (don't need to) know what's happening until you observe the phenomenon. Agree on the wkt format. Esri has added support for axes order when working with servers, but not in the general software.
    – mkennedy
    Commented Sep 13, 2011 at 21:44
  • 1
    @mkennedy you're technically correct. In a shapefile, you could have any order you like. But as soon as you send that shapefile to someone and describe it as epsg:4326, you should make sure that the order is (lat, lon). I removed 'store' from the answer to make it more clear that the standard is about publishing data.
    – mkadunc
    Commented Sep 13, 2011 at 22:44

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

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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.