Difference between revisions of "Axis Order Confusion"
m (Updated out of date link for OGC Axis Order policy) |
|||
(17 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
− | ''Be careful when talking about or calculating with or passing on coordinate tuples as they can be ordered either (x,y) or (y,x)!'' | + | ''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'' |
== Introduction == | == Introduction == | ||
− | 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. If you can add to the solution go hack the Wiki. | + | 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. |
+ | |||
+ | If you can add to the solution go hack the Wiki. Thank you. | ||
== Coordinate Systems == | == Coordinate Systems == | ||
Line 12: | Line 14: | ||
# Computer Graphics | # Computer Graphics | ||
#* Axis Order (X,Y) | #* Axis Order (X,Y) | ||
− | #* Unsigned values increase to the bottom and to the right. The | + | #* Unsigned values increase to the bottom and to the right. The resulting graphics (often the screen or window size) size is a limit |
# Geographical Coordinate Systems | # Geographical Coordinate Systems | ||
#* Axis Order varies, sometimes (Y,X), othertimes (X,Y) | #* Axis Order varies, sometimes (Y,X), othertimes (X,Y) | ||
− | #* Signed values increase up | + | #* Signed values increase right and up limited to -180, -90, 180, 90 (a spheroid) |
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. | 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. | ||
== History of Axis Orders == | == History of Axis Orders == | ||
− | This is just a very short introduction to the origin of this | + | 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.). |
=== Reading Direction === | === Reading Direction === | ||
− | 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 | + | 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! |
=== Mathematical Definition === | === Mathematical Definition === | ||
Line 36: | Line 38: | ||
=== Navigation === | === Navigation === | ||
− | 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 | + | 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. |
== Developing Software that uses Coordinates == | == Developing Software that uses Coordinates == | ||
− | + | 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. | |
+ | |||
+ | === Developing the Core === | ||
+ | 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?). | ||
+ | |||
+ | === Developing Human(e) Interfaces for the Rest of us=== | ||
+ | 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. | ||
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: | 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: | ||
Line 46: | Line 54: | ||
This should be our prime contribution to this issue. Help people work it out so that the result is correct. | This should be our prime contribution to this issue. Help people work it out so that the result is correct. | ||
+ | |||
+ | == Specifying Standards == | ||
+ | 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. | ||
+ | |||
+ | 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. | ||
== Why Bother? == | == Why Bother? == | ||
Line 54: | Line 67: | ||
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. | 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. | ||
− | 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 | + | 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. |
− | On the technical side people developing software naturally fall back to the X,Y axis order because 99.9% of all IT does it | + | 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. |
+ | |||
+ | == Finding Solutions == | ||
+ | * [https://portal.opengeospatial.org/files/76024 OGC Axis Order Policy Guidance] | ||
− | |||
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. | 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. | ||
Whatever you do be careful that you do it the "right" way and make your choice clearly visible. | Whatever you do be careful that you do it the "right" way and make your choice clearly visible. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | == Food for Thought == | ||
+ | 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | == Links and Further Reading == | ||
+ | * Chris Schmidt explains why GeoJSON does it "wrong": http://lists.geojson.org/pipermail/geojson-geojson.org/2009-November/000541.html | ||
+ | |||
+ | [[Category:Confusion]] |
Latest revision as of 08:25, 21 June 2018
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
Introduction
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 EOGEO wms-dev Mailing List for what others have thought about this and read the GeoTools, and GDAL/OGR efforts to shed light on the issue. Find another good summary of the problem here.
If you can add to the solution go hack the Wiki. Thank you.
Coordinate Systems
From the perspective of a geographic software design three coordinate systems can potentially be addressed. Each differ either in the order of the coordinate tuple or in the direction of increasing values.
- Mathematical
- Axis Order (X,Y)
- Signed values, increase to the right und upwards
- Computer Graphics
- Axis Order (X,Y)
- Unsigned values increase to the bottom and to the right. The resulting graphics (often the screen or window size) size is a limit
- Geographical Coordinate Systems
- Axis Order varies, sometimes (Y,X), othertimes (X,Y)
- Signed values increase right and up limited to -180, -90, 180, 90 (a spheroid)
All result in an ordered pair of numbers describing a position in space but there is some confusion as to the order.
History of Axis Orders
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.).
Reading Direction
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!
Mathematical Definition
From 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.
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.
Usage in Geodesy
From 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.
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.
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.
Developing Software that uses Coordinates
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.
Developing the Core
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?).
Developing Human(e) Interfaces for the Rest of us
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 Latitude and 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.
This confusion also applies to 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:
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.
This should be our prime contribution to this issue. Help people work it out so that the result is correct.
Specifying Standards
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.
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.
Why Bother?
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?
- A) Because it is a convention
- B) Because human life depends on it
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.
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 Latitude and Longitude printed on them.
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.
Finding Solutions
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.
Whatever you do be careful that you do it the "right" way and make your choice clearly visible.
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.
Food for Thought
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.
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.
Links and Further Reading
- Chris Schmidt explains why GeoJSON does it "wrong": http://lists.geojson.org/pipermail/geojson-geojson.org/2009-November/000541.html