[pdal] Regarding Reprojection Between Vertical Datums

[Nicholas Stanley]

Our "ground truth" is using WGS84 Ellipsoidal Height. The survey was 
created in ~2017, but unfortunately I don't have much additional info 
about the Epoch.

Technically, yes, I am in California - is it fair to say this 
complicates things somewhat? The data for conversion is a USGS survey of 
the San Francisco Bay Area.

Following the logic of your process:

*Step 1: Convert the **/NAD83(2011) / Conus Albers + NAVD88 height /**to 
NAD83 Ellipsoidal using GEOID18 *


E.G.: pdal translate USGS_LPC_CA_NoCAL_Wildfires_B5b_2018_w2274n1959.laz 
Step1_NAD83.laz reprojection 
--filters.reprojection.out_srs="+init=EPSG:xxxx 
+geoidgrids=~/Downloads/vdatum/core/geoid18/v2018prvi.gtx" 
--writers.las.a_srs=EPSG:xxxx

(Not sure which EPSG codes to use here - any guess?)

*Step 2. Convert resulting Step 1. file into destination projection 
(WGS84 UTM 10 Ellipsoidal https://epsg.io/32610, or alternatively, 
https://epsg.io/7789 ITRF 2014)

*

On 7/12/22 14:45, Greg Troxel wrote:

E.G.: pdal translate USGS_LPC_CA_NoCAL_Wildfires_B5b_2018_w2274n1959.laz 
Step1_NAD83.laz reprojection 
--filters.reprojection.out_srs="+init=EPSG:xxxx 
+geoidgrids=~/Downloads/vdatum/core/geoid18/v2018prvi.gtx" 
--writers.las.a_srs=EPSG:xxxx




> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20220712/81be5024/attachment.htm>