[Proj] +axis switch to control axis orientation

[Frank Warmerdam]

Daniel Morissette wrote:
> Hi Frank,
> 
> I think that's a good idea. +1
> 
> BTW, how do you plan to reflect this in future revisions of the "epsg" 
> file? Will every definition contain an explicit +axis parameter or will 
> it be specified only for those that do not use the default (+axis=enu)? 
> I think it would be best if the epsg file contained an explicit +axis 
> value for every definition.

Daniel,

It was my intention to *not* emit a +axis definition for coordinate
systems with the default axis orientation; however, I do not feel
strongly on this topic.

> This question crossed my mind as I was trying to figure the logic that 
> would have to be implemented in an application that wants to rely on the 
> axis order info from the epsg file (for OGC WMS 1.3.0 support for 
> instance). 

Currently the epsg init file is still being generated with the
rule not to honour EPSG axis order for geographic coordinate systems.
That is, the default importFromEPSG() rule is used on the OGRSpatialReference
rather than the importFromEPSGA() which will preserve the geographic
coordinate systems axis orientation as defined by EPSG.

If this approach remains unchanged, the epsg init file is still not very
helpful for determining the epsg expected axis ordering.  I'm wondering
if I ought to generate an "epsga" version of the file that explicitly
always follows the epsg axis order conventions.

On a related point, I've been quite quite surprised how often EPSG
defines axis orientations other than easting, northing for projected
coordinate systems.  Translating the pcs.csv file I have found
1072 coordinate systems with non-default axis orientation out of
7051 total projected coordinate systems.  I'm now quite worried that,
like with geographic coordinate systems, we are going to find that
EPSG follows "paper conventions" in it's definition of axis orientation
for many projected coordinate systems even though that does *not*
reflect usage patterns in GIS.

If I just carry through the EPSG axis orientation, I'm worried that
lots of coordinate systems that were in reasonably wide use will
suddenly be broken.  I am not sure how to address this.  I could take
the EPSG/EPSGA approach where I only used the EPSG axis orientation
in exceptional circumstances (like TM south oriented projections) in
the epsg init file, but do use them all the time in the "epsga" file.

 > I guess applications will need to be aware that they are
> running against a version of PROJ.4 with +axis support, and in this case 
> know that it can rely on the presence of the +axis parameter to decide 
> on coordinate order. However, to make sure things don't break if for 
> whatever reason the app is still using an old epsg file without +axis 
> info, it would be better to know that if +axis is absent then we should 
> not assume the default of "enu" but instead behave as if the information 
> is not available and either produce a fatal error or fallback on other 
> mechanisms if any is available. Hence my conclusion that you should 
> provide +axis explicitly in *all* definitions in the epsg file, 
> including those that use +axis=enu. (That was hard to explain, hopefully 
> my comment makes sense to you after a few reads)

I see your point though I'm not sure I'm completely convinced this is
the best way for applications to check.  Normally applications don't
actually get to "see" the definition loaded from the epsg init file
and used within PROJ.4.  It might be better if apps just checked the
proj.4 version to decide whether it is likely handling the axis order
issues automatically

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent