[Proj] Height and ellipse conversions

[Ben Caradoc-Davies]

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/

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/

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

Kind regards,

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