Changes between Initial Version and Version 1 of rfc20_srs_axes

Timestamp:

Jan 4, 2008, 12:17:53 PM (16 years ago)

Author:

warmerdam

Comment:

--

rfc20_srs_axes

@@ +1 @@
+= RFC 20: OGRSpatialReference Axis Support = 
+
+Author: Frank Warmerdam[[BR]]
+Contact: warmerdam@pobox.com[[BR]]
+Status: Development
+
+== Summary ==
+
+The OGRSpatialReference and OGRCoordinateTransformation classes assume that all coordinate systems use x=easting, y=northing (or in geographic terms x=longitude, y=longitude).  In practice some coordinate systems use alternate axis orientations (such as the Krovak projection), a some standards (GML, WMS 1.3, WCS 1.1) require honouring the EPSG declaration that all it's geographic coordinates refer to x as latitude and y as longitude. 
+
+This RFC attempts to extend the OGRSpatialReference, and OGRCoordinateTransformation classes to support alternate axis orientations, and to update selected drivers (GML, WMS, WCS, GMLJP2) to properly support axis ordering.  
+
+== WKT Axis Representation ==
+
+The OGC WKT SRS format (per OGC 01-???) already indicates a way of defining coordinate system axes as shown in this example:
+
+{{{
+GEOGCS["WGS 84",
+    DATUM["WGS_1984",
+        SPHEROID["WGS 84",6378137,298.257223563,
+            AUTHORITY["EPSG","7030"]],
+        TOWGS84[0,0,0,0,0,0,0],
+        AUTHORITY["EPSG","6326"]],
+    PRIMEM["Greenwich",0,
+        AUTHORITY["EPSG","8901"]],
+    UNIT["degree",0.0174532925199433,
+        AUTHORITY["EPSG","9108"]],
+    AXIS["Lat",NORTH],
+    AXIS["Long",EAST],
+    AUTHORITY["EPSG","4326"]]
+}}}
+
+There is one AXIS definition per axis with order relating to position within a tuple.  The first argument is the user name for the axis and exact values are not specified.  The second argument is a direction and may be one of NORTH, SOUTH, EAST or WEST.
+
+== Dilemma == 
+
+The core challenge of this RFC is adding support for axes orders, including honouring EPSG desired axis order for geographic coordinate systems where appropriate without breaking existing files and code that make extensive use of EPSG coordinate systems but override axis orientations and assume they should be treated as long, lat regardless of what EPSG says. 
+
+In particular, we come up with appropriate policies and mechanisms to decide when a file in a geographic coordinate system like EPSG:4326 is to be treated as lat/long and when it should be long/lat.  Because of the extensive existing practice it behooves us to err on the side of past practice, and require "opting in" to honouring EPSG axis ordering.
+
+== OGRSpatialReference ==
+
+New methods:
+