[pdal] Change vertical datum

[Jim Klassen]

On 6/13/22 17:59, Howard Butler wrote:
>
>> On Jun 7, 2022, at 9:07 AM, Ulises Ibarra <ulisesmartinibarra at gmail.com> wrote:
>>
>> Hello everyone:
>>
>> I'm not sure that the topics that I expose correspond to the topics that are covered in this list, if not, I wish you could tell me where to go.  Maybe on the PROJ list?
>>
>> When I do a vertical datum shift of a point cloud, using the following pipeline:
>>
>> [
>> "input.las",
>> {
>> "type":"filters.reprojection",
>> "in_srs":"EPSG:32614",
>> "out_srs":"+init=epsg:32614 +geoidgrids=C:/nubes/geoides/GGM10_GEO.gtx"
>> },
>> {
>> "type":"writers.las",
>> "filename":"output_with_Vertical_Datum_GGM2010.las"
>> }
>> ]
>>
>> Questions:
>>
>> 1.- After running the command I get an alert:
>>
>> " Warning 1: +init=epsg:XXXX syntax is deprecated. It might return a CRS with a non-EPSG compliant axis order."
>>
>> Could you tell me what I'm doing wrong at this point?
>>
>> 2.- What argument would I have to use to see in the metadata something like "Vertical Datum": "GGM10" or "Mexican Gravimetric Geoid 2010"? Of course, in case the datum change has been made.
> Ulises,
>
> PDAL supports whatever version of PROJ you have linked.
>
> See https://pdal.io/tutorial/grid-shift.html for some inspiration on how facts might apply to your specific geodetic configuration.
>
> Additionally, you might find https://pdal.io/stages/filters.projpipeline.html useful for specific application of PROJ transformation steps to data.
>
> Howard

To add to Howard's answer:

1) The warning is just a warning.  It is warning that if you have a CRS 
like EPSG:4326 that the proj4 string version won't know that it is 
really supposed to have coordinates in (lat, lon) order and will 
"incorrectly" treat it as (lon, lat) as proj4 does.  This generally 
isn't an issue for UTM projections which are, as far as I know, all in 
the (Easting, Northing) order which is the same as what proj4 assumes.

2) If you are using proj4 strings for the output projection (with 
vdatum) you will need to set the "a_srs" option in the writers.las stage 
to get the vertical datum written to the LAS file.

3) For both 1 and 2, it is "better" to specify the CRS as EPSG codes or 
as a fallback as WKT2.  For example, I use EPSG:6344+5703 for 
NAD83(2011)/UTM 15N/NAVD88 (North American Vertical Datum 1988 meters).  
Hopefully, there is an EPSG code for GGM10 as the WKT2 method is very 
verbose.

4) I've noticed that using the proj4 strings can be significantly faster 
than using the proper EPSG codes for transforming points.  I looked into 
trying to figure out why this is the case a little, but ran out of time 
on to complete that investigation.  I suspect it has to do with proj 
looking up the best transformation for each point (which in the case of 
5703 includes searching multiple grid files, where specifying it as a 
proj4 string forces one grid file).

5) projinfo and gdalsrsinfo are your friends when searching for 
alternate representations (proj4, WKT, ...) of CRSs.

6) I'm not sure if this applies in your area, but make sure your 
vertical datum is defined for the horizontal datum you are using. For 
example, NAVD88 is not technically defined on WGS84, only on NAD83.  
Also, the grid file used to do the vertical transformation has to match 
with the corresponding horizontal datum realization or errors will 
typically be introduced.  (NAVD88 2012 and 2018 grids go with 
NAD83(2011), the NAVD88 2009 grid goes with NAD83(NSRS2007), etc.)

> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal