<div dir="ltr"><div><div>&gt; have you verified that the 54 cm is not within the limits of the difference between HT2_0 and CGVD28?? if that is so then there is no error<br><br>Well, it turns out I made a math error: the difference is ~5cm, not 54cm. That&#39;s a small error, but what we really want is for the outputs to match.<br>


<br>&gt; another source of errors might be the path you go to that elevation..<br><br></div>The HT2_0 file is the grid shift file, so that&#39;s the mechanism proj is using to get from the original orthometric heights to the ellipsoidal heights. The HT2_0 file uses geographic coordinates, so proj must be doing the horizontal transformation first, then the vertical shift -- so if the horizontal coordinates are off, the elevation will be off. <br>


<br></div>So 5cm is obviously a small error, but it disagrees with GPS-H...<br><div><div><br>&gt; make sure that &quot;las2las&quot; and GPS-H do the same assumptions<br><br></div><div>My working hypothesis was that, since GPS-H is using HT2_0 with the NAD83(CSRS) reference frame, and our original data uses NAD83(Original), there should be a +towgs84 argument in my original -&gt; WGS84 transformation, because WGS84 has changed between those two reference frames. However:<br>


<br>&gt; how large was the horizontal difference?<br><br></div><div>My transformation from the original horizontal coordinates to WGS84 and GPS-H&#39;s transformation are almost identical. Even if there is a reference frame difference, the difference in shift values should be negligible.<br>

<br></div><div>So... we have just discovered that the grid shift files may be misaligned by 8&#39; to the East. Shifting them by that much provides almost perfect results, at least for our study area.<br><br></div><div>Thanks for your time!<br>
</div><div>Rob<br></div><div><br><br>

 </div></div></div>