Axis Order Confusion - Revision history

Wiki-Gbuehler: Updated out of date link for OGC Axis Order policy

2018-06-21T16:25:08Z

Updated out of date link for OGC Axis Order policy

Wiki-Leo: typos

2013-09-19T09:34:14Z

typos

Arnulf: /* Finding Solutions */

2010-10-26T15:06:41Z

Finding Solutions

Arnulf: /* Links and Further Reading */

2009-11-27T19:25:17Z

Links and Further Reading

Arnulf at 23:22, 25 November 2009

2009-11-25T23:22:05Z

Jidanni: added Category:Confusion

2009-05-31T22:38:21Z

added Category:Confusion

Hellik at 13:32, 30 May 2009

2009-05-30T13:32:08Z

Gfleming: corrected some spelling errors

2008-04-30T09:41:31Z

corrected some spelling errors

Arnulf: /* Introduction */ link to another problem definition

2008-03-26T22:14:17Z

Introduction: link to another problem definition

Warmerdam: /* Introduction */ add link to GDAL rfc on axis order.

2008-01-10T21:10:31Z

Introduction: add link to GDAL rfc on axis order.

@@ Line 72: / Line 72: @@
 == Finding Solutions ==
-* [http://www.ogcnetwork.net/node/491 OGC Axis Order Policy Guidance]
+* [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.

@@ Line 14: / Line 14: @@
 # Computer Graphics
 #* Axis Order (X,Y)
-#* Unsigned values increase to the bottom and to the right. The resutling graphics (often the screen or window size) size is a limit
+#* 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)
@@ Line 38: / Line 38: @@
 === 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 discussued 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.
+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 developent comprise implementing human machine interfaces on one side and developing software to be used by machines exclusively on the other.
+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 devlopers naturally fall back to. '''Beware:''' This is yet another assumption based on empirical observation that has not yet been confirmed (Poll this?).
+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 implemening 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.
+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:
@@ Line 58: / Line 58: @@
 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 resposnibility 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.
+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? ==
@@ Line 67: / 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.
-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 commiting 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.
+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 his way. People using other devices often naturally fall back to the (y, x) notation.
+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 ==
@@ Line 87: / Line 87: @@
 == 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]]

← Older revision		Revision as of 15:06, 26 October 2010
Line 72:		Line 72:

	== Finding Solutions ==		== Finding Solutions ==
		+	* [http://www.ogcnetwork.net/node/491 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.

@@ Line 85: / Line 85: @@
 == 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]]

← Older revision		Revision as of 23:22, 25 November 2009
Line 82:		Line 82:

	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.		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]]		[[Category:Confusion]]

← Older revision		Revision as of 22:38, 31 May 2009
Line 82:		Line 82:

	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.		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.
		+
		+	[[Category:Confusion]]

@@ Line 22: / Line 22: @@
 == History of Axis Orders ==
-This is just a very short introduction to the origin of this cnofusion and does not intended to prove anything (for example which is "right". Forget that.).
+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 ===

@@ Line 4: / Line 4: @@
 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. Tank you.
+If you can add to the solution go hack the Wiki. Thank you.
 == Coordinate Systems ==
@@ Line 17: / Line 17: @@
 # 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 shperoid)
+#* 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.
@@ Line 25: / Line 25: @@
 === 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 t left or from top to bottom in columns. There is no single correct definition!
+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 ===

@@ Line 2: / Line 2: @@
 == 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 [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 effort]to shed light on the issue.
+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.
 If you can add to the solution go hack the Wiki. Tank you.