[Proj] +axis switch to control axis orientation

[Frank Warmerdam]

support.mn at elisanet.fi wrote:
> Hello,
> 
> my opinion is that it is an improvement and since it is downwards compatible
> it is also very welcome. My only concern is that it only works partially? An user
> might expect it to do the hole work but it just did half of it? How could it be
> implemented so that all routines used that switch?

Janne,

I presume your concern is that it has no effect on the pj_inv() and pj_fwd()
functions.  It is possible to implement support for it within them rather than,
or in addition to in pj_transform() but it would be more complicated for a
few reasons and likely slower since the axis switching decision would need
to be checked for every point rather than once for a whole array of points to
be transformed.

There are already a bunch of services that only apply for applications
going through pj_transform().  These include prime meridian handling
(+pm), datum shifting and alternate longitude wrapping (ie. 0 to 360
instead of -180 to 180).  So I think there is at least a precident for
the operation of the two API entry points being fairly distinct.

In part, I'm trying to keep the functioning of pj_fwd() and pj_inv() as
focused on the projection function as possible, while treating
pj_transform() as a higher level "coordinate system transformations"
function.  One benefit of this is that in theory at some point I could
replace everything from pj_fwd()/pj_inv() down with use of Gerald's new
library while treating pj_transform() and all it's services as a higher
level function that would remain distinct from the low level projections
library.

What do you think?  Is my reasoning at all convincing?

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