https://wiki.osgeo.org/api.php?action=feedcontributions&user=Gbuehler&feedformat=atomOSGeo - User contributions [en]2020-01-27T16:02:02ZUser contributionsMediaWiki 1.25.3https://wiki.osgeo.org/index.php?title=Axis_Order_Confusion&diff=115402Axis Order Confusion2018-06-21T16:25:08Z<p>Gbuehler: Updated out of date link for OGC Axis Order policy</p>
<hr />
<div>''Be careful when talking about or calculating with or passing on coordinate tuples as they can be ordered either (x,y) or (y,x) or (x,y) but meant as (y,x)! Use a notation that makes it obvious what you are talking about by adding direction as N, E, S, W''<br />
<br />
== Introduction ==<br />
A lot of trouble has been caused by a deep misunderstanding between software developers and GIS users with respect to the order of the X and Y values in a coordinate tuple. Before you start to rant away that they (the respective others) are completely mad at not sticking to either convention A (x,y) or convention B (y,x) please consider this to be a fact. Then read on and find out how we deal with the problem. Check out the [http://lists.eogeo.org/pipermail/wms-dev/2005-January/000707.html EOGEO wms-dev Mailing List] for what others have thought about this and read the [http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue GeoTools], and [http://trac.osgeo.org/gdal/wiki/rfc20_srs_axes GDAL/OGR] efforts to shed light on the issue. Find another [http://terraetl.blogspot.com/2007/11/axis-order-confusion-software-geodesy.html good summary] of the problem here. <br />
<br />
If you can add to the solution go hack the Wiki. Thank you.<br />
<br />
== Coordinate Systems ==<br />
From the perspective of a geographic software design three [http://en.wikipedia.org/wiki/Coordinate_system coordinate systems] can potentially be addressed. Each differ either in the order of the coordinate [http://en.wikipedia.org/wiki/Tuple tuple] or in the direction of increasing values.<br />
<br />
# Mathematical<br />
#* Axis Order (X,Y)<br />
#* Signed values, increase to the right und upwards<br />
# Computer Graphics<br />
#* Axis Order (X,Y)<br />
#* Unsigned values increase to the bottom and to the right. The resulting graphics (often the screen or window size) size is a limit<br />
# Geographical Coordinate Systems<br />
#* Axis Order varies, sometimes (Y,X), othertimes (X,Y)<br />
#* Signed values increase right and up limited to -180, -90, 180, 90 (a spheroid)<br />
<br />
All result in an [http://en.wikipedia.org/wiki/Ordered_pair ordered pair] of numbers describing a position in space but there is some confusion as to the order.<br />
<br />
== History of Axis Orders ==<br />
This is just a very short introduction to the origin of this confusion and does not intended to prove anything (for example which is "right". Forget that.).<br />
<br />
=== Reading Direction ===<br />
The common reading direction (beware - this is only yet another convention) is from the left to the right and from the top to the bottom. Take a non-western approach to reading and you might end up from right to left or from top to bottom in columns. There is no single correct definition!<br />
<br />
=== Mathematical Definition ===<br />
From [http://en.wikipedia.org//wiki/Cartesian_coordinate_system Wikipedia: Cartesian coordinate system]: ''In mathematics, the Cartesian coordinate system is used to uniquely determine each point in the plane through two numbers, usually called the x-coordinate and the y-coordinate of the point. To define the coordinates, two perpendicular directed lines (the x-axis or abscissa and the y-axis or ordinate), are specified, as well as the unit length, which is marked off on the two axes''.<br />
<br />
This definition extends the vague terms of the x- and y-axis with the definitions ''abscissa'' and ''ordinate''. This helps to make sure that people what they are talking about. <br />
<br />
=== Usage in Geodesy ===<br />
From [http://en.wikipedia.org/wiki/Geodesy#Coordinate_systems_in_the_plane Wikipedia: Geodesy]: ''It is geodetic practice — contrary to the mathematical convention — to let the x axis point to the North and the y axis to the East.''<br />
<br />
This definition extends the vague terms of the x- and y-axis with the definitions of ''North'' and ''East''. This helps to make sure that people know what they are talking about. <br />
<br />
=== Navigation ===<br />
Nowadays we are used to have positions come out of GPS and other machines and have x and y displayed as if there was no difference. Especially in maritime navigation there has always been a very big difference between finding the position along the rotational axis of the earth and the latitude (distance from the equator). Although both depended on each other a complete different set of tools (hardware) had to be used to find the exact position. This has led to a special terminology and the use of the terms latitude and longitude. Probably due to the same error which is being discussed now Geodesy uses the x-axis as a measure to the north and the y-axis as a measure to the east (or west) of a prime meridian. <br />
<br />
== Developing Software that uses Coordinates ==<br />
The two edges to software development comprise implementing human machine interfaces on one side and developing software to be used by machines exclusively on the other. <br />
<br />
=== Developing the Core ===<br />
When developing the core which interacts at a specified technical level it will be normal to use the notation (x,y,z) because it is what all developers naturally fall back to. '''Beware:''' This is yet another assumption based on empirical observation that has not yet been confirmed (Poll this?).<br />
<br />
=== Developing Human(e) Interfaces for the Rest of us===<br />
When implementing interfaces for users we have to take into account that to many the standard way of putting X in front and Y in the back in a coordinate tuple is unfamiliar altogether. This is in part caused by using different terms to describe the same thing, namely [http://en.wikipedia.org/wiki/Latitude Latitude] and [http://en.wikipedia.org/wiki/Longitude Longitude]. For some irrelevant historical reason they additionally learned to change the order and say Latitude, Longitude (that is: y, x). To make things easier (what irony) in Geodesy the definitions for x (north) and y (east) are also different so that we end up by saying (x,y) meaning (Latitude, Longitude) but meaning (y,x) in a mathematical sense. Are they crazy? No they are not, they are simply sticking to other conventions. <br />
<br />
This confusion also applies to [http://www.math.montana.edu/frankw/ccp/multiworld/multipleIVP/spherical/body.htm Spherical Coordinates] in mathematics which does not make things any easier but shows that we are not alone with our problems. Citing from that page:<br />
<br />
'''''Warning:''' The notation for spherical coordinates is not standard. Sometimes they are written in a different order and sometimes the letters phi and theta are interchanged. In short, be careful when using spherical coordinates. You cannot assume that when someone else uses notation that looks like the notation here it is being used the same way.''<br />
<br />
This should be our prime contribution to this issue. Help people work it out so that the result is correct.<br />
<br />
== Specifying Standards ==<br />
When it comes to creating standards it will be important to take all of these issues into account. In most cases where the corresponding software standards concern the inner workings of a system the axis order should stick to the mathematical notation of (x,y,z). There is no reason not to. <br />
<br />
But at the same time it lies in the responsibility of the standards body to make sure that all interfaces that extend into other usage areas are well marked and there is abundant information to those implementing front ends and using software about the intricacies involved.<br />
<br />
== Why Bother? ==<br />
There are several reasons why it is necessary to bother. Most have been mentioned on a very long mailing list thread at the OGC regarding the use of latlon in standards specifications (I am ignorant of whether these lists are public). If you had to pick from two reasons why to use either (x,y) or (y,x) which would you choose?<br />
: A) Because it is a convention<br />
: B) Because human life depends on it<br />
<br />
So lets forget about whether it hurts anybody to read lonlat instead of latlon in a specification (option A). They will have to put up with this. <br />
<br />
But yes, there are large user groups who are accustomed to using the wrong (both from mathematical and computer technological view point) axis order of Y, X. Every user in a nautical, aerial and ground navigation environment is used to a different notation. Basically anybody working with machine interfaces to spatially enabled technology is in danger of committing an axis order confusion. If you look at the hardware tools they usually very clearly depict the axis order through labels. If you take a GPS or a radar it always says <tt>Latitude</tt> and <tt>Longitude</tt> printed on them. <br />
<br />
On the technical side people developing software naturally fall back to the X,Y axis order because 99.9% of all IT does it this way. People using other devices often naturally fall back to the (y, x) notation. <br />
<br />
== Finding Solutions ==<br />
* [https://portal.opengeospatial.org/files/76024 OGC Axis Order Policy Guidance]<br />
<br />
It will not help to define new standards or deprecate old ones or fix a new definition as the involved standard are already given. The only possible cure for this disease is to make people know about it. No matter how far the tuple is pushed in either the software or the user direction at one point it will collide with reality, either in computer graphics (which additionally have their origin in the upper left) or on a ship which does navigate first by latitude and then by longitude.<br />
<br />
Whatever you do be careful that you do it the "right" way and make your choice clearly visible.<br />
<br />
Develop a new concise directory with coordinate system parameters that follow the same axis order. This will finally and definitely remove the risk of mixing up x and y axis. At one point or another in history this will have to happen, so why not now.<br />
<br />
== Food for Thought ==<br />
Another complication (that will be more of a concern in the future) is the third or "Z" axis, does it really mean "up". I've run into this problem recently as well.<br />
<br />
One thought about a possible solution. Why not just come up with a Labeling mechanism of some sort. Something related to a getCapabilities type of request. Maybe define a data header-line request. Something like this might be useful for other types of requests too. Solves everything I can think of related to Axis Orientation.<br />
<br />
== Links and Further Reading ==<br />
* Chris Schmidt explains why GeoJSON does it "wrong": http://lists.geojson.org/pipermail/geojson-geojson.org/2009-November/000541.html<br />
<br />
[[Category:Confusion]]</div>Gbuehler