[pdal] Fwd: Re: z-units conversion

[Paul White]

Subject: 	Re: [pdal] z-units conversion
Date: 	Thu, 19 Mar 2020 11:09:42 -0600
From: 	Paul White <paul at dgi.com>
To: 	Andrew Bell <andrew.bell.ia at gmail.com>


Hi Andrew,

Thanks for your reply.

On 3/19/2020 10:31 AM, Andrew Bell wrote:
> Without seeing your pipeline it's hard to answer.
Here's my .json file:

[
     "Job520660_36076_92_01.laz",
     {
     "type":"filters.colorization",
     "raster":"google_wms_satellite_1478.tif"
     },
     "pdal_colorization_Job520660_36076_92_01.laz"
]

and I execute it like this in a Anaconda3 Prompt window:

pdal pipeline colorize.json


> You can assign any SRS you like at output with the a_srs option,
Yes, I'm aware of that, using 'spatialreference', 
'filters.reprojection', 'in_srs', 'out_srs', etc.
In this use case, the SRS of the input .laz is "EPSG: 32618". In the 
case of EPSG:32618,
it is a UTM projection and by definition, the x/y units are in meters. 
All well and good...

However, SRS definitions do not assign a unit value to Z.

My input .laz file (shown above) has the z-units in feet (actually, they 
are identified
in the .laz as "Linear_Foot_US_Survey"). Here is the result of running 
lasinfo on the
original .laz:

    Keyed_Information:
       GTModelTypeGeoKey (Short,1): ModelTypeProjected
       ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_18N
       ProjLinearUnitsGeoKey (Short,1): Linear_Meter
       VerticalCSTypeGeoKey (Short,1): Unknown-3855
*VerticalUnitsGeoKey (Short,1): Linear_Foot_US_Survey*
       End_Of_Keys.

After the 'filters.colorization' step, the z-units are changed/renamed 
to "Linear_Meter":

    Keyed_Information:
       GTModelTypeGeoKey (Short,1): ModelTypeProjected
       GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
       GTCitationGeoKey (Ascii,8): "unknown"
       GeogCitationGeoKey (Ascii,7): "WGS 84"
       GeogAngularUnitsGeoKey (Short,1): Angular_Degree
       ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_18N
       ProjLinearUnitsGeoKey (Short,1): Linear_Meter
       VerticalCSTypeGeoKey (Short,1): Unknown-3855
       VerticalCitationGeoKey (Ascii,15): "EGM2008 height"
       VerticalDatumGeoKey (Short,1): Unknown-1027
*VerticalUnitsGeoKey (Short,1): Linear_Meter*
       End_Of_Keys.


As you can see, the 'VerticalUnitsGeoKey' has been changed to meters.

This renders the 'colorized' .laz incompatible with all of my other data 
sources
(DEM's, DSM's, shapefiles and other 3D data types, etc.) in a 3D/4D 
co-visualized
application environment.

I'm looking for a PDAL filter to either leave the 'VerticalUnitsGeoKey' 
alone (output
.laz same as input .laz) or set/name it to 'Linear_Foot_US_Survey' or 
even just plain 'Feet'.

Any suggestions would be most helpful.

Thanks for your time,
Paul



> but I'm not sure what else might be going on.
>
> On Wed, Mar 18, 2020 at 6:08 PM Paul White <paul at dgi.com 
> <mailto:paul at dgi.com>> wrote:
>
>     I have an input .las which is UTM 18 N-- x/y units are in meters and
>     z-units are in 'Linear_Foot_US_Survey'.
>     When process the input .las through any PDAL filters, the output
>     z-units
>     are renamed to 'Linear_Meter'.
>     How can I designate the z-units to remain in feet?
>
>     _______________________________________________
>     pdal mailing list
>     pdal at lists.osgeo.org <mailto:pdal at lists.osgeo.org>
>     https://lists.osgeo.org/mailman/listinfo/pdal
>
>
>
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com <mailto:andrew.bell.ia at gmail.com>
> ------------------------------------------------------------------------
> NOTE: This message was trained as non-spam. If this is wrong, please 
> correct the training as soon as possible.
> Spam <https://rio.dgi.com:8443/b.php?c=s&i=012ggw7io&m=d965d3c93268>
> Not spam <https://rio.dgi.com:8443/b.php?c=n&i=012ggw7io&m=d965d3c93268>
> Forget previous vote 
> <https://rio.dgi.com:8443/b.php?c=f&i=012ggw7io&m=d965d3c93268>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200319/57b08754/attachment.html>