[Proj] +axis switch to control axis orientation

support.mn at elisanet.fi support.mn at elisanet.fi
Tue Mar 9 03:08:18 EST 2010


I am only worried that the new development in proj4 is lost due
to some formal detail?

At least if someone could make a document about the new features
and how to use them? That would be nice. There are many newcomers
that need last time information about the proj4 development.

New features could be separated using new names with improved functions
so that old compilations would continue to be as they were?

Regards: Janne.


Frank Warmerdam [warmerdam at pobox.com] kirjoitti: 
> support.mn at elisanet.fi wrote:
> > Frank Warmerdam [warmerdam at pobox.com] kirjoitti: 
> >> 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.
> > 
> > I would like to have the support there also since if the user enters the switch
> > then he also expects to have the effect.
> > 
> > Why would that need to be checked for every point? Just write two different
> > loops and check it before entering the loop .. or something similar?
> Janne,
> The pj_inv() and pj_fwd() functions only operate on a single point -
> not an array of points like pj_transform(), so there is no loop.
> Are you suggesting that we also ought to add prime meridian (+pm),
> "latlong as a projection" support (+proj=latlong), and alternative
> longitude wrapping (+lon_wrap) support in pj_fwd() and pj_inv() to
> provide for fully comparible functionality?  Datum shifting is the
> one thing we would not need in these functions that is in pj_transform()
> since pj_fwd() and pj_inv() are always operating within the datum same
> datum.
> If anything, I'd rather just drop the "proj" program, making it an
> alias for cs2cs rather than do this sort of change to pj_fwd() and
> pj_inv().  Are you concerned about end users of "proj" or developers
> who might be using pj_fwd()/pj_inv()?  I'm already trying to discourage
> new developers from using pj_fwd() / pj_inv() directly unless they
> really know what they are doing.
> 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
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj

More information about the Proj mailing list