Changes between Version 3 and Version 4 of rfc20_srs_axes
- Timestamp:
- Jan 4, 2008, 12:36:42 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
rfc20_srs_axes
v3 v4 38 38 39 39 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. 40 41 == The Hack == 42 43 The main mechanism by I propose to work around the dilemma is to differentiate between geographic coordinate systems with the AXIS values set and those without. In particular, a WKT coordinate system with the EPSG authority code (ie. 4326) set, but no axis declarations will be assumed to be long, lat even though that is contrary to the definition from EPSG of 4326. Only in cases where we really *know* we want to honour EPSG's axis order will we actually populate the axis declarations indicating lat, long. 44 45 The hope is that this will let us continue to (mis)use EPSG:4326 definitions without necessary honouring the EPSG axis ordering except in specific circumstances. 40 46 41 47 == OGRSpatialReference ==