<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 2:37 AM, Ben Caradoc-Davies <span dir="ltr">&lt;<a href="mailto:Ben.Caradoc-Davies@csiro.au" target="_blank">Ben.Caradoc-Davies@csiro.au</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Are height adjustments expected when converting between ellipses?<br>

<br>
I am trying to understand some unexpected behaviour I found in OGR (via<br>
the Python bindings) while validating the correctness of 3D conversions<br>
between ellipses. In the original form I was using OGC WKT definitions,<br>
but I have boiled the behaviour down to a simple Proj.4 example. I am<br>
using proj 4.7.0 (proj-bin 4.7.0-2 amd64 debian/sid).<br>
<br>
The example:<br>
<br>
WGS84 has an ellipsoid with semimajor axis of 6378137 m.<br>
WGS66 has an ellipsoid with semimajor axis of 6378145 m.<br>
<br>
So, let&#39;s take a point on the WGS84 ellipsoid at the intersection of the<br>
meridian and the equator, (6378137, 0, 0) in geocentric X, Y, Z metres.<br>
This point should be 8 m *below* the WGS66 ellipsoid, so I expect that<br>
if I convert it to WGS66 longlat, the height should be -8.0 metres<br>
exactly, by definition.<br>
<br>
$ echo &quot;6378137 0 0&quot; | cs2cs +proj=geocent +ellps=WGS84 +no_defs +to<br>
+proj=longlat +ellps=WGS66 +no_defs<br>
0dE     0dN 0.000<br>
<br>
What? That can&#39;t be right. This height should be -8.000 in WGS66.</blockquote><div><br></div><div style>Ben,</div><div style><br></div><div style>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. </div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>Of course it is still a bit invisible to the user whether datum shifting is being applied or not which is unfortunate. </div><div style><br></div><div style>Contrast what you see with:</div>
<div style><br></div><div style>echo &quot;6378137 0 0&quot; | cs2cs +proj=geocent +datum=WGS84 +no_defs +to +proj=longlat +ellps=WGS66 +towgs84=0,0,0 +no_defs<br></div><div style><div>0dE<span class="" style="white-space:pre">        </span>0dN -8.000</div>
<div><br></div><div style>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 &quot;equivelent to WGS84&quot;). </div>
<div style><br></div></div><div style>Best regards,</div></div><div><br></div>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div></div>