[OSRS-PROJ] Re: remotesensing.org PROJ reading datum gridshift files unnecessarily?

[Frank Warmerdam]

Paul Kelly wrote:
> Still, IMHO I don't think it should have been trying to load the datum
> shift file when the output co-ordinate system did not have a datum
> specified, i.e. whether or not the input point is inside the region
> covered by the shift file is relevant only if we are doing a datum shift,
> not if just doing the inverse projection from projected co-ordinates to
> lat/long. In this case I feel the PROJ pj_transform() function should just
> do the inverse projection (although the fact that it refused was a useful
> warning to you that something was wrong with your input values).
> 
> Maybe Frank can help (copied to PROJ list). I feel the call to
> pj_datum_transform() in pj_transform() should be conditional on
> ( srcdefn->datum_type != PJD_UNKNOWN
>   && dstdefn->datum_type != PJD_UNKNOWN )
> however it is far from clear what is the obvious solution and I don't
> pretend to fully understand the code there.

Paul,

I am boggled.  My belief had always been that pj_transform() would fail
if the two coordinate systems had different ellpsoids, but no explicit
datum information on one of them (or both).  However, trying this out,
and examining the code I can find no support for why I thought this was
the case.

If one coordinate system (source or destination) has datum shift information
but the other does not, pj_transform() is happily applying the datum shift
info where available, and just assuming that no datum adjustment is needed
on the other side.  I can even do conversions between coordinates systems
with different ellpisoids but no datum info for either coordinate system.

This isn't necessarily bad but it shakes my faith in my understanding of what
was going on.

That said, I don't want to avoid the pj_datum_transform() call if on of the
datums is PJD_UNKNOWN, because pj_datum_transform() also takes care of the
ellipse change.

Hmmm, on further review, this isn't always done right either.  The ellpsoid
conversion is only applied in the situation where I do a conversion through
geocentric coordinates ... which is only done if one of the two coordinate
systems is using a 3 or 7 parameter grid shift.   So currently we have the
odd situation that if we do a conversion between ellpsoids with both
coordinate system marked as PJD_UNKNOWN we get no change at all:

eg.

vc6 at gdal2200% cs2cs +proj=latlong +ellps=clrk66 +towgs84=0,0,0 +to +proj=latlong 
+ellps=WGS84 +towgs84=0,0,0
10 10
10dE    9d59'57.36"N 62.250

But if we do the very same thing, but provide a zero shift to WGS84 like
this, we at least get the ellipsoid conversion:

vc6 at gdal2200% cs2cs  +proj=latlong +ellps=clrk66 +to +proj=latlong +ellps=WGS84
10 10
10dE    10dN 0.000

Clearly I need to review this area of code.

However, Paul, your point I think was that you don't feel either "side" of
a datum shift should be done unless the datum information for both the
source and destionation are available, is that right?  I am not certain why
you feel this is necessarily the case.

I am creating a bugzilla entry to try and address some of the issues here.

   http://bugzilla.remotesensing.org/show_bug.cgi?id=368

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.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.