[Proj] +axis switch to control axis orientation

[Daniel Morissette]

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.

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). 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)

Daniel


Frank Warmerdam wrote:
> Folks,
> 
> As part of an effort to support the transverse mercator south orientated
> based coordinate systems as well as a few other coordinate systems with
> unusual axis orientations I have tentatively introduced support for a new
> +axis parameter for coordinate systems in PROJ.4 (the OSGeo version).
> 
> The +axis switch takes three character arguments defining the axis
> orientation of the coordinate system.  The possible values are:
> 
> 'e' - easting
> 'w' - westing - an x/longitude with the opposite sign to normal.
> 'n' - northing
> 's' - southing - a y/latitude with the opposite sign to the normal.
> 'u' - up - normal z
> 'd' - down - a z/elevation with the opposite sign to the normal.
> 
> So, a normal coordinate system is defined as "+axis=enu".  This is the
> default and it may be omitted in the normal case.  Some variations:
> 
> "end" - Normal in x/y but the Z is a depth rather elevation.
> "neu" - reversed x/y axes, for instance +proj=latlong +axis=neu would truely
>          be a latitude/longitude coordinate system.
> "wsu" - A coordinate system with the sign of x and y negated as is used
>          for transverse mercator south orientated.
> 
> I have committed preliminary support for this switch in PROJ.4 trunk.  I
> should note that the axis switching is done on entrance to pj_transform()
> and (in reverse) on exit.  So applications, like proj, that call pj_fwd()
> and pj_inv() directly will ignore the axis orientation just as they ignore
> the prime meridians, and datum shifts.   However, programs that do use
> pj_transform() - like cs2cs - will utilize the axis orientation switches.
> 
> eg.
> cs2cs +proj=latlong +datum=WGS84 \
>    +to \
>         +proj=tmerc +ellps=WGS84 +datum=WGS84 +k_0=1 +lon_0=31 +lat_0=0 \
>                     +x_0=0 +y_0=0 +axis=wsu
> 30.5 -29.5
> 48483.46        3264793.45 0.00
> 
> Though this is already in trunk, I am seeking feedback from the community
> on the approach.  Whether it seems sufficiently general for other possible
> uses, and whether the naming seems reasonable.
> 
> I should note that anyone who feels that non-projection coordinate system
> services (like datum shifts, etc) do not belong in PROJ.4 need not feel
> obligated to make that point again in reference to +axis.  It can be assumed
> to apply.
> 
> If there is no widespread outcry against this functionality, I will
> document it properly and make modifications to the mechanisms for
> generating the epsg init file to take advantage of it.
> 
> Best regards,


-- 
Daniel Morissette
http://www.mapgears.com/