[pdal] Regarding Reprojection Between Vertical Datums

[Greg Troxel]

Nicholas Stanley <nicholas.stanley at luminartech.com> writes:

> I am trying to get the /NAD83(2011) / Conus Albers + NAVD88 height/
> data *out* of its native elevation model, converted *into* a wgs84
> EPSG 32610 ellipsoidal projection.
>
> When I run the conversion command /  //pdal translate filename.laz
> filename_utm.laz reprojection
> --filters.reprojection.out_srs="EPSG:32610"//
>
> /The resulting file lines up in Easting/Northing precisely, but seems
> to have retained the old elevation data (which is ~30M+ above our
> UTM10 WGS84 "Ground Truth")

I would suggest using ITRF2008 or ITRF2014 as a destination, because
WGS84 is an ensemble, and those match the last two membres (and are very
close to each other).  In the proj world, NAD83/WGS84 transforms end up
using a null transform, which is arguably pedantically reasonable, but
IMHO in almost all cases the wrong approach.

Strictly, you should be talking about epoch in WGS84(Gnnnn)/ITRFyyyy.
But that's 20-30cm very issh, if you're not in CA.

30M is suspiciously close to a geoid height.  So:

  You say you have "WGS84" ground truth.  Are you clear on whether the
  vertical component is "WGS84 Ellipsoidal Height", which is implied by
  what you just said, or "WGS84 Orthometric Height"?  The two are
  related by the EGM2008 gravity model, also published by NGA.

  To convert from NAVD88 to WGS84 ellipsoidal height, you have to first
  convert to NAD83(2011) ellipsoidal height, using an NGS-published
  geoid model such as GEOID18, and then to WGS84/ITRF using a datum
  transformation.  If you want to go to WGS84 Orthometric Height you
  have to do the previous and then apply EGM2008.


FWIW, I have measured NAD83(2011) epoch 2010.0 HAE on a benchmark via
RTK and transformed to NAVD88 and gotten agreement at the 10 cm level.
However this was via looking up GEOID18 on NGS's website and doing it
manually.

I would suggest manually transforming a point to verify your
understanding of what you are dealing with.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20220712/85ee1f0e/attachment.sig>