A History of the Order of X, Y and Z – and Why It's Important
By Sam Bacharach
January 28, 2009
Classified Ads:
If you are still wondering which mobile GPS you should buy for your GIS data collection and mapping projects: Download our white paper to see how our MobileMapper 6 GPS beats the competition with better accuracy and lower price. Visit Magellan ProfessionalThe devil, as the old saying goes, is in the details.
As more and more users and developers of geospatial services and
content come from non-geo backgrounds, the geo-professional's attention
to those details becomes extremely important. Arguably the oldest and
most important of these "details" in our industry is the method of
defining location itself.
Mankind has been making maps for millennia, but only in the last 236
years (since John Harrison invented the marine chronometer) have we
actually been able to do so covering large areas over water and
retaining accuracy. Prior to that, only latitude (north and south)
could be measured with great accuracy. Not until the 1770s was a mobile
timepiece able to keep accurate enough time to allow calculation of
longitude (east and west). The key point is that geographers (and
cartographers and geodesists) measured latitude first and that is why
they express location in terms of latitude and longitude, in that
order, when applied to coordinates.
A two-axis system of east-west and north-south was defined using the algebra coordinate system created by mathematician René Descartes in the 1600s. In this Cartesian coordinate system, the tradition is to use (x, y) as the order of the coordinate pair locating a point on a plane. But when north is up - the predominant (though not only) pattern for maps since Ptolemy made maps of ancient Egypt - x measures east-west and y measures north-south. That is, the latitude–longitude order favored by geographers is y, x. So the axis confusion we deal with today has, itself, a longstanding history dating back to the first efforts to relate two different reference systems with two methods of defining the axes. As long as people communicate clearly and accurately the characteristics of the axis-systems in use - "truth in advertising" - the confusion is minimized.
When geodesists connect coordinate systems to the Earth by specifying a datum (locations on the Earth for the axes), we in OGC call that a Coordinate Reference System (CRS). The equator was a natural for a worldwide datum on the east-west axis and over time the Greenwich Meridian, running through Greenwich, U.K., has become the most common location for the north-south axis.
Geodesists, who came into their own in the Age of Exploration, include a third axis in their descriptions of location. They deal with latitude, longitude and altitude, in that order, and call them x, y and z. And thus confusion increases.
Moving to the use of computers for mapping, we can add two more sets of axes. The first has to do with computer output devices: printers and monitors which start at the top and print or display line by line to the bottom. That is, the y-axis for these devices has no negative region and is positive going down. (And we won't even address the fact that some printers print left to right, while others print right to left.)
The second computer-related set of axes has to do with the formats for data storage. Digital Elevation Models (DEM) and Digital Terrain Elevation Data (DTED) have an origin in the lower left corner, traverse up, drop to the bottom of the second column and go up, and so on. Satellite data are typically formatted, like the output devices, with the origin in the upper left, providing yet another case; however, various ways of encoding the multiple readings from a single ground location have been used. A single row of points may represent all measurements for one part of the spectrum (say blue), and the next row may be the measurements for those same ground locations for another part of the spectrum (say green). Another format involves storing all measurements for one part of the spectrum in one file, and all measurements for another part of the spectrum in another file.
Thus the answer to the question posed in the title is that computer mapping projects probably involve four or five sets of axes. While any transformation to move data from one set of axes to another is straightforward, care is needed to keep from accidentally transposing axes.
In the transition from paper maps to computer mapping, people who programmed computers were much more likely to be versed in the traditions of mathematics and x, y than in the traditions of geography with latitude before longitude, and thus computer mapping and its more-sophisticated offspring, Geographic Information Systems, are subject to axis confusion.
And with that as background, we arrive at OGC standards! Since the point of IT standards is to have computer programs and data interoperable, in the early days of computer mapping, graphics programmers were in the trenches writing the first standards, and they ordered the coordinates x, y in the mathematical tradition. But OGC standards developed by the membership are for the benefit of developers and users in many fields of study. As such, we need to abide by international best practice, harmonize with standards defined in other standards organizations, and meet the requirements of the community.
Early on, the OGC members recognized the need to be able to specify and use more than one coordinate reference system (CRS). Why, you ask? Because the mathematical description for any given CRS used to describe the shape of the earth (called an ellipsoid) is not precise enough to be highly accurate all over the globe.
To simplify OGC work on specifying CRS, the OGC members agreed to use the CRSs as defined by an existing standards body: the European Petroleum Survey Group (EPSG), now the International Association of Oil & Gas producers (OGP). In the EPSG database, each projection explicitly specifies its own axis order. OGC's initial work on the Web Map Service interface standard used WGS 84 as the CRS example of choice. WGS 2d is EPSG code 4326 and specifies the axis-order latitude, then longitude. The OGC, however, used the EPSG 4326 name and then reversed the order to x, y - not a good thing for a standards organization to take a "standard" and then be the only guy in the world who uses it in a non-standard way! So, in a very real sense, the OGC created additional confusion! In June 2005, the OGC members formally agreed that for new standards, coordinate values shall be listed in the axis order of the specified coordinate reference system (CRS). When existing standards are subject to revision, the axis-order issue will be considered, and any necessary change will be made to bring it into conformity with the requirement that coordinate values shall be listed in the axis order of the CRS it references.
With Web Map Service (WMS) Version 1.3 (the current version, adopted in 2006), the OGC standard would also become an ISO standard. This meant that using EPSG 4326 with the order reversed was not an option. The creative fix: OGC introduced its own CRS, OGC 4326, which used the same parameters as the EPSG one, but the peculiar axis order.
In the meantime, Web Feature Service (WFS) in conjunction with OGC Web Service (OWS) Common fixed the problem, allowing all CRSs to express their own axis order.
While these developments were underway, the EPSG database was updated to allow local transformations that may involve re-ordering of axes to be specified in such a way as to be valid. As per ISO 19111, Spatial Referencing by Coordinates, these are termed "derived CRSs."
Finally, in early 2008, the OGC Architecture Board and the Membership revisited the axis order issue. The result of this latest effort is a new OGC policy statement titled, "Axis Order Policy and Recommendations." This document is available on OGC Network.
Because the geospatial community draws on the heritage and legacies of geography, geodesy, mathematics, computer science and other fields, only one solution to the axis-order issue is realistic: explicit specification of the axis-order in use. This is a kind of "truth in advertising" requirement. Developers who want users to select their software and applications will take care to ensure information about the axis order is readily available. And users who want to be sure their work is meaningful will take care to inform themselves about the axis order associated with all software and data in a project.
I personally have no preference for any particular axis-order scheme, but failure to deliver what one advertises is not acceptable. More and more users are totally reliant on geospatial data and services for their success and safety, and all chances for confusion must be eliminated.
|
Your Comments Post a comment All comments provided in this section are those of the individual who has created the post. These are not the opinions of Directions Media, its editors, staff or owners unless otherwise noted. Directions Media retains the right to edit or delete any comments posted herein.
|
|
||||||
| In the first Fig. (Lat, Lon), aren't the axis labels misplaced or its placing misleading regarding the point made in the text? |
||||||
|
||||||
| can you explain why google maps has the order reversed? (at least reversed from the way ESRI lists the coordinates.) |
||||||
|
||||||
| For an article on the history and importance of standards and axis-orders, that figure is definitely very confusing in the way it is labeled! Perhaps "Constant Longitude" and "Constant Latitude" would be better labels? Or use the mathematical norm and reverse them (the X axis is not the axis of Constant X). |
||||||
|
||||||
| I don't know how old Sam is, but he certainly has no understanding of the history of surveying, mapping and cartography. And what on earth is a 'Geodesist' - just a new made-up term for a 'geodetic surveyor' to further confuse? Geographic information systems have been around for a long time - they used to be called maps and plans, and were printed on paper. They were originally drawn by hand, mostly by plane table, using radial plotting. Surveying instruments enabled more accurate readings, which could be recorded and plotted back in the office. The advent of computers enabled the calculation and plotting to be automated, using the coordinate systems developed and used by surveyors and mapmakers over many years. With increased data storage came the possibility of maintaining the maps in a digital form, instead of print formats, and attaching attributes to the basic data. I have never heard of anyone using Sam's concepts of raster and DTED axes - standard surveying coordinates and map projections have been universally used since the early days of computing and certainly were not invented by IT people. Yes, some use x,y,z or E,N,elevation, and a few use y,x,z or N,E,height, but the differences are easy to adjust to, and it is easy to translate between systems. A multitude of map projections probably hasn't helped, but they all have a rigorous mathematical definition, determined by surveyors, cartographers and mathematicians. My point is that these systems have been tried and tested over many years and even many generations. Lots of people are familiar with them, lots of data is in these formats, lots of software uses these existing systems already. Various jurisdictions have already set their standards, some many years ago. Are you telling us that the OGC is adopting yet another set of standards based on those used by an obscure group of oil and gas producers? For local and even national systems, the standards you should be adopting are those of the territory in which you are operating!! One of the fundamental features of any GIS is the ability to integrate data from different sources and make it consistent with other data sets. Using any mapping standard other than that currently in use in the area of interest defeats the purpose, and introduces another layer of confusion. Because so much location-specific data is now collected using GPS enabled systems, it is probably wise that WGS coordinates should be the fundamental system used, with suitable parameters fixed for translation into local mapping and surveying coordinates. Here in Australia, we have a national mapping grid defined to coincide so closely with WSG, that the differences are only discernible over very long distances. In most places the map coordinates can also be used as ground coordinates for all but the most precise measurements. What could be simpler? The OGC would do better to educate GIS professionals without a surveying/cartographic/mathematical background on the importance of accurately integrating data using current standards and systems. |
||||||
|
||||||
| ....And what on earth is a 'Geodesist' It is true that while many GPS/GIS users do not come from a geography background, sub-meter accurate GPS equipment, imagery and other datasets are keeping users feet to the fire. Those 'little errors' are going to start adding up and multiplying ,so no matter what order x,y and z are in....like always, be sure to use metadata to document and view data about the data in cases where the 'known' standard is not the convention. |
||||||
|
||||||
| @Mike, if I give you a shape file (.shp) and tell you "the data is in geographics", and you are going to write a program to process that data, you'll get the ESRI shape file specification document, and see that the ordinates are stored as an array of double[]. So you'll fopen the file and read out the ordinates. And here's the question, is ordinate[0] the first latitude? or is it the first longitude? The specification document doesn't say, so you get to choose. How you answer that question will bake an implicit ordering into your software. If the answer to the question was obvious to one-and-all, there would be no issues, but it's not obvious to one-and-all, and there are issues. |
||||||
|
||||||
| Personally I think that the coordinate ordering should ALWAYS be the same no matter what CRS we are using. That would avoid many more confusions than trying to swap back and forth depending on CRS. It also over-complicates the implementation, since you are now required to always keep a full (ever growing and often out-of-date) CRS database handy so you can look up the coordinate ordering, just to be able to process the coordinates. As you state yourself, the point of the standard is to have IT to be interoperable. The thing to note here is that we are talking IT not geodesy. It's very important to distinguish storage with visual representation. The storage should always be the same, but it's up to the UI to present it in whatever format they desire. We have similar approaches to how we store and display numbers, dates etc. depending on the localized representation. Internal storage is always the same, and it's not until we display the value that we convert into a localized value. @Mike: I like how you dis Sam for not knowing what he's talking about, yet you don't know what a geodesist is? http://en.wikipedia.org/wiki/Geodesy (and no they are not surveyors either) "Geographic information systems have been around for a long time - they used to be called maps and plans, and were printed on paper." In that analogy a piece of paper with lines must be a word processing system then? |
||||||
|
||||||
| For a long time now I've used 'longitude, latitude' in that order, for precisely this reason (i.e. to be consistent with x,y and E,N). I live in hope that this will catch on, after a historical hangover of 250 years (thanks for the insight into why the convention of lat first, Sam; I never realised that). |
||||||
|
||||||
| First, I know Sam and have nothing against the man. But like many of the commenters, I think there's something wrong here. And while some of my concerns have already been voiced, one key problem has so far been missed. That key point is that (latitude, longitude) are angular (spherical) coordinates and (x, y) are rectilinear (Cartesian) coordinates. Going from one to the other is not simply a matter of getting the order right; a mapping between the two always requires an explicit transformation if it is to have any mathematical and practical validity. Unfortunately, software systems evolved with the map as their fundamental model for the surface of the earth, i.e., with the plane as their mathematical reference surface; rectilinear coordinates are often all they can handle. (In addition, this requires only high school-level geometry, whereas the mathematics required for proper treatment of an ellipsoidal reference surface is beyond most software developers.) Sure, nearly all GIS and mapping software can transform coordinates between unprojected (latitude, longitude) and projected (x, y) coordinate reference systems. But when it comes to actually managing (latitude, longitude) coordinates, locating the paths connecting individual points, and analyzing spatial relationships, all you can usually do is to pretend that longitude is like x and latitude is like y and hope for the best. This article is actually a great illustration of the confusion that ensues. For example, no, a datum is nothing like the "location of the axes on the earth." This habit of equating longitude with x and latitude with y is deeply ingrained. It leads to atrocious cartography and causes this kind of nonsensical discussion about the proper coordinate order. I’m sad to say that OGC has done nothing to clear up this confusion. Speaking of coordinate order, I would love to see a reference (Sam?) for the story that we say latitude, longitude because we were able to determine latitude accurately first. Personally I think it has more to do with what is easier to say in English; latitude-longitude and lat-long just roll off the tongue more easily than the other way around. For comparison: in Dutch (my native tongue) the order is usually reversed because it’s easier to say lengte (longitude)-breedte (latitude), in that order. As to the order in mathematical expressions, a quick check shows that, at least in one common reference (the famous Map Projections--A Working Manual by John P Snyder), the mathematical notation is indeed (phi, lambda), meaning (latitude, longitude). In my trusty old Mathematical Methods for Physicists, “Spherical Polar Coordinates” are given as (r, theta, phi), where r is the radius, theta the complement of latitude (the angle from the Z-axis rather than the equatorial plane), and phi the longitude--again, latitude before longitude. My guess is that traditions in mathematics had more to do with the preferred order than did the difficulty of determining longitude on the earth. By the way, in our field we really do have three coordinates as well, but the third one, radius, is implicitly determined by the ellipsoid parameters of the reference surface. So of course I agree that we must carry within each CRS definition the specified coordinate order; and Paul Ramsey's example of the shape file with unprojected coordinates is one of those painful things I hope our industry can leave behind soon. But if I had to choose an order for unprojected coordinates in a particular CRS, I'd pick (latitude, longitude), Mark Duffett's comment notwithstanding, precisely because it does NOT easily lend itself to the mindless application of (x, y) methods to these angular coordinates: that's just "flat-earth thinking". |
||||||
|
||||||
| Paul, if the file you give me is in 'geographic' coordinates, the data is 'lat, long and elev' surely. If it is in plane coords, the data is 'easting, northing, height' (or maybe northing, easting, height). Of course, you also need to specify the coord system used and the datum in each case. Why does it need to be more complicated? If the specification document doesn't define all these parameters, then it ought to. I would never accept data from any source without knowing such facts - the term 'professional irresponsibility' comes to mind. I hope you are not a teacher, Mark, and I feel for your students if you are - they won't know which way is up when they get out into the real world. Do yourself and others a favour and stick to the conventions that have worked well for 250 years. Of course I know what he meant by 'geodesist'! Surely you don't use Wikipedia as a reliable reference and dictionary? Their list of geodesists is mostly surveyors, cartographers and mathematicians anyway. Part of the problem with so many GPS and GIS users going out and doing their own thing is that they don't ask the experts first. And that is how the problems arise that the original article set out to address. Both require considerable knowledge and experience to use efficiently. These high tech systems have been made easy to use, but a detailed understanding of accuracies, data collection and storage, etc is required to achieve consistent and integratable data sets. Therefore make things easy for everyone and adopt standards which are simple, easy to grasp and do not deviate significantly from previous standards unless there is a very good reason. Ensure that any data which you collect or create is in a format which is totally consistent with other data sets in the area of interest. |
||||||
|
||||||
| Very enjoyable back and forth on this one. Thanks Sam for raising an issue that does not get enough press. I am sure you now (if you didn’t already) understand why you need a thick skin to raise such topics. But be that as it may, the main point for all of this is that in the end the consumer of the geospatial information (the decision maker as it were) whether it be one who drops bombs or one who calculates your property taxes is going to rely on the accuracy of the map he or she is using. One can only hope that the GIS software user that is not well versed in these issues is the one reading this and learning from it. Unfortunately they would probably be too scared to comment much. The challenge is when you automate very technical information with software that you enable it to be used properly. Proper documentation of the order of the coordinates is imperative as Robert Uleman said, it is not as simple as just Latitude and Longitude. |
||||||
|
||||||
| I don't know how old Mike is, but he seems to not understand that maps and plans are the results of a GIS, not the geographic information system itself (whether electronic computer based or pre-electronic). The GIS component is in the data collection, analysis and compilation prior to creating the resulting maps and plans. He also seems to have missed the point of the brief discussion of the DTED and display raster axes even though he uses them frequently if he is a computer user. In the electronic GIS environment, we need to account for geographic coordinate system differences and we also need to keep track of electronic coordinate systems and units in our software development and electronic data storage/usage. Failure to account for these creates problems. A targa file does not read in the same as a tiff or jpeg due to a different geographic origin and data travel path. The Mars Climate Orbiter crashed while landing due location/velocity software misunderstandings arrising from a missed unit conversion. As for the OGC "adopting yet another set of standards based on those used by an obscure group of oil and gas producers", I would think that, by their very purpose, the OGC would be expected to acknowledge and incorporate established coordinate reference systems (CRS). Oil and gas are not obscure products and I would not view the primary international commercial association of their producers (http://www.ogp.org.uk/) nor their Survey and Positioning Committee as an obscure group. Rather, I would see them as major commerical explorers in relatively undeveloped areas. As such, I would view them in the forefront of geospatial users researching and evaluating existing CRS and developing new ones where existing ones are lacking or absent. Obscurity is in the eye of the beholder; one could as easily dismiss someone's knowledge, experience and views simply because they live on some island in the (from my perspective) far-off South Pacific. |
||||||
|
||||||
| @Robert "That key point is that (latitude, longitude) are angular (spherical) coordinates and (x, y) are rectilinear (Cartesian) coordinates. Going from one to the other is not simply a matter of getting the order right;" I've heard this argument many times, but it doesn't fly. Actually it is a simple matter, and also matches very well how we conceptually think of it, which also is an important fact. For instance "WGS84 2d is EPSG code 4326" as Sam calls it is a good example. We all know how we display this on a map. We project it using the simplest projection formula there is, the Plate Carree: X=longitude. Y=latitude. This all aside the fact they I think its wrong that any WMS service support geographic coordinate systems, since they are all being projected and should have an equivalent projected coordinate system code specifying the Plate Carree projection. As Sam also mentions there are other flat projected coordinate systems that specify Northing before Easting. As I argued earlier, it shouldn't be about how you display your ordinates, but how you store them, and these should be consistent no matter what CRS you are using. To fully support correct ordinate ordering we are now required to carry around a full EPSG database, just so we can read in some coordinates. The complexity defeats the purpose, and a clear sign the academics overruled the practicalities. |
||||||
|
||||||
| Apparently, there's an axis of evil plotting to turn the world on its side. |
||||||
|
||||||
| For some reason, axis order discussions are always lively! At the end of the day, the interoperability issue comes down to what one OGC member called an "honesty" clause. Basically, this honesty clause states that either the documentation, the application, or the encoding tells the consumer what the axis order of the data is. Otherwise, the consumer has no idea of the axis order and all kinds of nasty things can happen. That said, I have the pleasure of working with numerous other standards organizations with their geospatial elements. One can continue to argue axis order, but the majority of these other standards organizations always state that geographics be expressed as Lat/Long and that the OGP (EPSG) is the normative authority for CRS codes and the parameters that define any given CRS. These standards organizations include the IETF, OMA, ISO, and OASIS. They follow this approach because they believe that expressing the axis order in the documentation and/or the encoding is critical to interoperability. I would encourage all to read the OGC recommended axis order guidance. There is nothing proscriptive in this guidance other than that we all document what axis order we are using in our data, applications, and so forth. To Robert: by following this guidance, an incredible amount of confusion can be avoided! |
||||||
|
||||||
| It's called metadata, and it should be attached to every geospatial element. With that there should never be any confusion about the coordinate system or map projection the spatial data is in, or how it was produced. While I appreciate geodesists' focus on the details, I think they sometimes forget where in the "world" we are. So learn to use GIS software, GPS equipment, and don't forget to note the geoid model you're using. Oh yeah, and take a geography course or two. |
||||||
|
||||||
| All the author has done is make an elementary point that xyz order varies in different types of commonly used mapping data and that the user should be wary of potential confusion. That this is so is well-evidenced by the ensuing discussion. There's no necessity for personal attacks. |
||||||
|
||||||
| The flu prevented me for responding earlier and although the discussion appears to have dried up I would like to make a few points. Firstly I’d like to thank Sam for bringing up this thankless subject, which has come up regularly in OGC over a period of years and ultimately led to the formulation of the OGC Axis Order Policy (see Carl’s comment). Not that the subject was overlooked in modeling. Axis order is explicitly modeled as part of the geodetic metadata that is required to associate coordinates unambiguously with a location in the physical world. See OGC Topic 2 (=ISO 19111). The ordering of geographic coordinates as latitude, longitude is old and well established, e.g. in the aerial and marine navigation domains. This order has therefore been captured in ISO 6709, which does nothing more than acknowledge common practice. The problem of axis order has only come up in this explicit manner because of interoperability requirements. Historically it is indeed as Sam described (he may even have got this story from me), but no quotes from historical documents are available, however, in all geodetic books I know of, both old and new, the order is (latitude, longitude). Many people are so used to the Anglo-Saxon mathematical convention of X = horizontal, thus East-West, Y= vertical, thus North-South, that they do not realize other conventions may exist around the world. Notably in Eastern Europe, the former Soviet Union and China the order is also X, Y (sic!), but X = North-South and Y = East-West. Grid coordinates are normally quoted in that order. The EPSG geodetic parameter dataset, which is the de-facto world standard dataset for geodetic reference parameters, describes the axis order explicitly, as required by OGC Topic 2. It does not PREscribe what people should use; it only records what is ISO standard, common practice or national convention. However, when a user geodetically references a spatial dataset using an EPSG definition, he or she should stick to everything in that definition, not change some details (e.g. axis order); that is bound to confuse the receiver of the data. However, acknowledging that some people may wish to deviate from that definition, OGC offers ways to do that. These ways are documented in the OGC Axis Order Policy. Leaving the military aside, the oil industry is probably the only industry that has a requirement for precise world-wide geodetic referencing, which is the reason why that industry has been able to put together such a comprehensive dataset of geodetic parameters. This dataset is available free of charge to everyone who want to use it. It also includes definitions of all the national geodetic systems the OGP Survey and Positioning Committee (of which I am a member) could reliable get hold of. Few people involved in this discussion have doubted the necessity of specifying the order of the coordinates (i.e. axis order). Instead the discussion has developed into a “religious” debate about what the “right” and “wrong” order is. In that dogmatic debate some have postulated that: 1. the Anglo-Saxon convention is the only right way to order coordinate axes; 2. latitude and longitude should also adhere to that order. I sympathise with Morten where he says that “coordinate ordering should ALWAYS be the same no matter what CRS…”. That will eventually happen, I have no doubt about that, but until that ideal state has been reached, organisations and developers that aim for software interoperability would do well to adjust to what actual practice is in the world, not what it ideally should be. Ironically, this is ultimately a non-subject. For a software developer it is trivial to swap the order of the coordinates if the metadata (i.e. the CRS definition) tells him the order in a received spatial dataset is different from what his software expects. Swapping the order back upon export is equally trivial. |
||||||
|
||||||
| Hi, Thank you very much for these notes. I was struggling since october last year, trying to understand why I should now call Y eastings and X northings. I am a foreigner where I am working now, and It took some time to assimilate this change, causing some problems in the way of course...I always was used to X (Eastings) Y(Northings) and Z (Elevation) which is very convenient if your work ends up in a cad program. |
||||||
