[Gdal-dev] gdal warp code silently skipping datum shift

Brent Fraser bfraser at geoanalytic.com
Fri Mar 17 14:31:26 EST 2006


Frank,

  I'd love to see a message (from proj? gdal?) to indicate which method (and
which grid file if applicable) the tool was using to resolve the difference
in datums.  It would take away a lot of the worry when using proj/gdal to do
datum conversions based on NTv2, etc.

Brent Fraser

----- Original Message ----- 
From: "Frank Warmerdam" <warmerdam at pobox.com>
To: "John Johnson" <jdjohnso at google.com>
Cc: <gdal-dev at lists.maptools.org>
Sent: Friday, March 17, 2006 11:46 AM
Subject: Re: [Gdal-dev] gdal warp code silently skipping datum shift


> John Johnson wrote:
> > So here's my question. Is there any way that GDAL can detect that it
> > "should" be doing a datum shift, but is missing the necessary
> > parameters? If so it could fail to warp wather than silently producing a
> > bad warp. Looking at the data structres in data/gcs.csv I'm not sure
> > there is currently enough information to distinguish between a datum
> > that doesn't need to be shifted and one that needs to but is missing the
> > necessary parameters.
>
> John,
>
> Any datum completely missing a TOWGS84 clause, and not the specially
> handled NAD27 datums using grid shift files would be considered lacking
> datum shift information and could be flagged accordingly.   However,
> I would be very hesitant to have gdalwarp just fail for these cases.
> It might be better to have it issue a warning in these cases.
>
> Internally what I imagine I would do is:
>   1) Are the input and output the same datum?  (based on datum EPSG code,
>      or lacking that the datum name).  If so, assume ok.
>
>   2) Translate both coordinate systems to PROJ.4  Do both have datum
>      information (ie. +towgs84 or +nadgrids= clauses)  If so, assume
>      ok.
>
>   3) A change of datum seems to be happening, but there is no apparent
>      datum shift info, issue a warning.
>
> Potentially I could accomplish this in the
OGRCreateCoordinateTransformation()
> function.  Possibly adding a flag indicating if missing datum shifts
should
> be:
>   - handled as currently (quietly convert just based on ellipsoid)
>   - issue a warning.
>   - terminate with a failure.
>
> Ideally I would also like to come up with a way of identifying
> transformations where multiple datum shift strategies are avalable
> and selecting one.  But that would require more substantial efforts.
>
> If you would like to file a bug report on this issue, I can try and queue
> up a work item.
>
> 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    | President OSGF, http://osgeo.org
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev




More information about the Gdal-dev mailing list