[Proj] Height and ellipse conversions

[Frank Warmerdam]

On Tue, Jun 11, 2013 at 8:40 PM, Ben Caradoc-Davies <
Ben.Caradoc-Davies at csiro.au> wrote:

> On 12/06/13 07:33, Frank Warmerdam wrote:
>
>> In a somewhat recent version of PROJ.4 the behavior was changed so that
>> if no proper datum information is given, no attempt is made to convert
>> between datums based on bare ellipsoid information.  So in the cases
>> given, there is no attempt made to translate between the ellipses.
>> The behavior used to be different but it seemed to lead to many
>> unexpected results when people did not provide datum shift info and it
>> was decided those results were doing more harm than good.
>> Of course it is still a bit invisible to the user whether datum shifting
>> is being applied or not which is unfortunate.
>> Contrast what you see with:
>> echo "6378137 0 0" | cs2cs +proj=geocent +datum=WGS84 +no_defs +to
>> +proj=longlat +ellps=WGS66 +towgs84=0,0,0 +no_defs
>> 0dE0dN -8.000
>>
>> In this case the eight meter change in height is entirely done based on
>> the ellipsoid difference but it is only applied because we have provided
>> information declaring datum relationship of the two datums (the first as
>> WGS84, and the second as "equivelent to WGS84").
>>
>
> Thanks, Frank. That is a huge help and explains the behaviour I see.
>
> One unfortunate side-effect of this new behaviour is that published Proj.4
> settings lacking +towgs84=0,0,0 such as this are incomplete:
> http://spatialreference.org/**ref/epsg/4891/proj4/<http://spatialreference.org/ref/epsg/4891/proj4/>


Ben,

Yes, that is true, though I'd claim there is no clear right transformation
to use in this case.


>
> Furthermore, it appears that OGR does not set enough datum information
> when importing OGC WKT, so conversions between WGS84 and WGS66 do not
> change height. Or do you consider this OGC WKT incomplete because it lacks
> TOWGS84?
> http://spatialreference.org/**ref/epsg/4891/prettywkt/<http://spatialreference.org/ref/epsg/4891/prettywkt/>


It might be nice if GDAL/OGR would lookup a preferred datum shift when
there is an explicit reference to an OGC datum like this.  It certainly
does not provide explicit information on how to transform to other datums
in the WKT itself.



>
> The OGR workaround is to import Proj.4 with +towgs84=0,0,0 rather than OGC
> WKT.


Assuming towgs84=0,0,0 is an acceptable approximation.  I would claim it
often is not a very good choice.

Best regards,
Frank


>
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <Ben.Caradoc-Davies at csiro.au>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>



-- 
---------------------------------------+--------------------------------------
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 Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20130611/57794974/attachment-0001.htm