[pdal] "Unknown" values in WKT string
Andrew Bell
andrew.bell.ia at gmail.com
Tue Sep 15 08:51:41 PDT 2020
If your data is point format 7, then it is necessarily version 1.4. The
last line of the code that you referenced checks for this case, and PDAL
should be using the WKT specification that is in the file. Geotiff can't be
used with point format 7 and if it exists, you should get an error.
That said, you make have uncovered a bug in that we expect WKT for any file
with version 1.4, even if it's point format 0-5. I'll have to look back at
the code history to verify that there's not some reason that this is done.
On Tue, Sep 15, 2020 at 11:16 AM Alexandre Poirot <
alexandre.poirot at pix4d.com> wrote:
> Hello Howard,
>
> Thanks for your reply and sorry to be so late to answer.
>
> In terms of libraries, I use :
> - libgeotiff 1.6.0
> - proj 7.0.1
> - gdal 3.1.0
> - LASzip 3.4.3
> - laz-perf 1.4.0
> - PDAL 2.1.0
>
> I use a specific build environment that builds all these libraries for
> each OS I'm using (MacOS, Linux, Windows).
>
> The software that produced this file is "LP360 from GeoCue Group Inc.", so
> probably issued by this: https://geocue.com/products/lp-360/
>
> After investigation, I realized that the file I was trying to read have 2
> VLRs:
> - An "OGC Well Known Text" which is the WKT string I expected PDAL to read
> - A "GeoTiff Projection Keys" which is what is actually read (in
> https://github.com/PDAL/PDAL/blob/2.1.0/io/GeotiffSupport.cpp#L148)
>
> So I guess the "Unknown" in the WKT string I get from PDAL comes from the
> process of reading the GeoTiff Projection Keys.
>
> In this file the point data format is 7, and the global encoding field
> value is 17 (0b00010001).
>
> Now I went a bit in the PDAL code to understand why the GeoTiff Projection
> Keys were chosen over the OGC Well Known Text and I found this block
> https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212.
>
> Then I investigated a bit more by reading the LAS 1.4 format specification
> (http://www.asprs.org/wp-content/uploads/2019/03/LAS_1_4_r14.pdf).
> About the global encoding field value, in means that:
> - The GPS Time Type is "Adjusted Standard GPS Time"/
> - The WKT bit is set, meaning the CRS is WKT and not GeoTIFF.
>
> In the specification, it is also said that:
> -----
> The CRS is represented by either GeoTIFF or Well Known Text (WKT) as
> indicated by the WKT Global Encoding bit. Point Record Formats 0-5 can use
> either GeoTIFF or WKT, but not both simultaneously. Point Data Record
> Formats 6-10 must use WKT.
> -----
>
> Since my LAS 1.4 file has a point format of 7 and its WKT bit set, this
> means we should use the WKT record here and not the GeoTIFF one. The
> GeoTiff record is actually superfluous as it would never be used, but it
> doesn't make the whole file invalid.
>
> I guess the logic in
> https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212 needs
> to be updated to be specification compliant.
>
> What is the best option here to adjust this behavior of PDAL?
>
> Best regards,
> Alexandre Poirot | Software Engineer
> Route de Renens 24 | 1008 Prilly, Switzerland
> alexandre.poirot at pix4d.com
> https://www.pix4d.com/
>
>
> PS: I don't know yet if I can share the file with you, but here is a dump
> of lasinfo of this file:
> reporting all LAS header entries:
> file signature: 'LASF'
> file source ID: 0
> global_encoding: 17
> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
> version major.minor: 1.4
> system identifier: 'OTHER'
> generating software: 'LP360 from GeoCue Group Inc. '
> file creation day/year: 133/2020
> header size: 375
> offset to point data: 4608
> number var. length records: 2
> point data format: 7
> point data record length: 54
> number of point records: 0
> number of points by return: 0 0 0 0 0
> scale factor x y z: 0.001 0.001 0.001
> offset x y z: 1000000 1000000 0
> min x y z: 663911.055 524463.042 179.282
> max x y z: 664455.787 524605.649 251.952
> start of waveform data packet record: 0
> start of first extended variable length record: 0
> number of extended_variable length records: 0
> extended number of point records: 8286875
> extended number of points by return: 8279964 6911 0 0 0 0 0 0 0 0 0 0 0
> 0 0
> variable length header record 1 of 2:
> reserved 0
> user ID 'LASF_Projection'
> record ID 2112
> length after header 816
> description 'OGC Well Known Text'
> WKT OGC COORDINATE SYSTEM:
> COMPD_CS["NAD83(2011) / Alabama West + Ellipsoid
> (Meters)",PROJCS["NAD83(2011) / Alabama
> West",GEOGCS["NAD83(2011)",DATUM["NAD83_National_Spatial_Reference_System_2011",SPHEROID["GRS
> 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1116"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6318"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",30],PARAMETER["central_meridian",-87.5],PARAMETER["scale_factor",0.999933333],PARAMETER["false_easting",600000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","6356"]],VERT_CS["Ellipsoid
> (Meters)",VERT_DATUM["Ellipsoid",2002],UNIT["metre",1.0,AUTHORITY["EPSG","9001"]],AXIS["Up",UP]]]
> variable length header record 2 of 2:
> reserved 0
> user ID 'LASF_Projection'
> record ID 34735
> length after header 64
> description 'GeoTiff Projection Keys'
> GeoKeyDirectoryTag version 1.1.0 number of keys 7
> key 1024 tiff_tag_location 0 count 1 value_offset 1 -
> GTModelTypeGeoKey: ModelTypeProjected
> key 1025 tiff_tag_location 0 count 1 value_offset 1 -
> GTRasterTypeGeoKey: RasterPixelIsArea
> key 3072 tiff_tag_location 0 count 1 value_offset 6356 -
> ProjectedCSTypeGeoKey: NAD83(2011) / Alabama West
> key 3076 tiff_tag_location 0 count 1 value_offset 0 -
> ProjLinearUnitsGeoKey: look-up for 0 not implemented
> key 4096 tiff_tag_location 0 count 1 value_offset 32767 - EPSG code
> 32767 not found in 'vertcs.csv' file
> set_VerticalCSTypeGeoKey: look-up for 32767 not implemented
> VerticalCSTypeGeoKey: look-up for 32767 not implemented
> key 4098 tiff_tag_location 0 count 1 value_offset 0 -
> VerticalDatumGeoKey: Vertical Datum Codes 0
> key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
> VerticalUnitsGeoKey: Linear_Meter
> the header is followed by 3245 user-defined bytes
> reporting minimum and maximum for all LAS point record entries ...
> X -336088945 -335544213
> Y -475536958 -475394351
> Z 179282 251952
> intensity 512 14080
> return_number 1 2
> number_of_returns 1 2
> edge_of_flight_line 0 1
> scan_direction_flag 1 1
> classification 0 2
> scan_angle_rank -45 40
> user_data 0 7
> point_source_ID 2 2
> gps_time 271441788.061201 271441882.931595
> Color R 0 65280
> G 0 65280
> B 0 65280
> extended_return_number 1 2
> extended_number_of_returns 1 2
> extended_classification 0 2
> extended_scan_angle -7474 6636
> extended_scanner_channel 0 0
> number of first returns: 8279964
> number of intermediate returns: 0
> number of last returns: 8279964
> number of single returns: 8273053
> overview over extended number of returns of given pulse: 8273053 13822 0 0
> 0 0 0 0 0 0 0 0 0 0 0
> histogram of classification of points:
> 1530388 never classified (0)
> 110209 unclassified (1)
> 6646278 ground (2)
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
--
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200915/2380b4e4/attachment-0001.html>
More information about the pdal
mailing list