Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

[this might be a wiki question since I don't really expect to have a right answer, but maybe get a consensus of best practices or a discussion going]

share|improve this question
Well personally, I do say Lat/Lon but I always enter X/Y. When I am working with data and receiving it from clients or scraping it off of websites, probably about 90% of the time I get X/Y. – Tac194 Feb 10 '11 at 19:38
ahh this sure brings back memories ...… – Kirk Kuykendall Feb 10 '11 at 20:55
Converting this to Wiki as it doesn't have a single correct answer, but hopefully does generate some useful discussion. – scw Feb 10 '11 at 21:57
2… – axk Feb 13 '11 at 15:12

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.

[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)

share|improve this answer
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 – Dan Patterson Feb 11 '11 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. – V Stuart Foote Feb 11 '11 at 17:48
@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 Feb 11 '11 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 Feb 11 '11 at 21:17
@Stuart, I edited my answer to include some information from the standard. – mkennedy Feb 11 '11 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.

share|improve this answer
(+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 Jun 29 '11 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 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.

share|improve this answer
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 Sep 13 '11 at 21:44
@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 Sep 13 '11 at 22:44

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

There is a very exhaustive discussion at

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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