<div dir="ltr">
Hello Howard,<br><br>Thanks for your reply and sorry to be so late to answer.<br><br>In terms of libraries, I use :<br>- libgeotiff 1.6.0<br>- proj 7.0.1<br>- gdal 3.1.0<br>- LASzip 3.4.3<br>- laz-perf 1.4.0<br>- PDAL 2.1.0<br><br>I use a specific build environment that builds all these libraries for each OS I'm using (MacOS, Linux, Windows).<br><br>The software that produced this file is "LP360 from GeoCue Group Inc.", so probably issued by this: <a href="https://geocue.com/products/lp-360/">https://geocue.com/products/lp-360/</a><br><br>After investigation, I realized that the file I was trying to read have 2 VLRs:<br>- An "OGC Well Known Text" which is the WKT string I expected PDAL to read<br>- A "GeoTiff Projection Keys" which is what is actually read (in <a href="https://github.com/PDAL/PDAL/blob/2.1.0/io/GeotiffSupport.cpp#L148">https://github.com/PDAL/PDAL/blob/2.1.0/io/GeotiffSupport.cpp#L148</a>)<br><br>So I guess the "Unknown" in the WKT string I get from PDAL comes from the process of reading the GeoTiff Projection Keys.<br><br>In this file the point data format is 7, and the global encoding field value is 17 (0b00010001).<br><br>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 <a href="https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212">https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212</a>.<br><br>Then I investigated a bit more by reading the LAS 1.4 format specification (<a href="http://www.asprs.org/wp-content/uploads/2019/03/LAS_1_4_r14.pdf">http://www.asprs.org/wp-content/uploads/2019/03/LAS_1_4_r14.pdf</a>).<br>About the global encoding field value, in means that:<br>- The GPS Time Type is "Adjusted Standard GPS Time"/<br>- The WKT bit is set, meaning the CRS is WKT and not GeoTIFF.<br><br>In the specification, it is also said that:<br>-----<br>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.<br>-----<br><br>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.<br><br>I guess the logic in <a href="https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212">https://github.com/PDAL/PDAL/blob/2.1.0/io/LasHeader.cpp#L198-L212</a> needs to be updated to be specification compliant.<br><br>What is the best option here to adjust this behavior of PDAL?<br><br>Best regards,<br>Alexandre Poirot | Software Engineer<br>Route de Renens 24 | 1008 Prilly, Switzerland<br><a href="mailto:alexandre.poirot@pix4d.com">alexandre.poirot@pix4d.com</a><br><div><a href="https://www.pix4d.com/">https://www.pix4d.com/</a></div><div><br></div><div><br></div><div>PS: I don't know yet if I can share the file with you, but here is a dump of lasinfo of this file:<font face="monospace"><br>reporting all LAS header entries:<br> file signature: 'LASF'<br> file source ID: 0<br> global_encoding: 17<br> project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000<br> version major.minor: 1.4<br> system identifier: 'OTHER'<br> generating software: 'LP360 from GeoCue Group Inc. '<br> file creation day/year: 133/2020<br> header size: 375<br> offset to point data: 4608<br> number var. length records: 2<br> point data format: 7<br> point data record length: 54<br> number of point records: 0<br> number of points by return: 0 0 0 0 0<br> scale factor x y z: 0.001 0.001 0.001<br> offset x y z: 1000000 1000000 0<br> min x y z: 663911.055 524463.042 179.282<br> max x y z: 664455.787 524605.649 251.952<br> start of waveform data packet record: 0<br> start of first extended variable length record: 0<br> number of extended_variable length records: 0<br> extended number of point records: 8286875<br> extended number of points by return: 8279964 6911 0 0 0 0 0 0 0 0 0 0 0 0 0<br>variable length header record 1 of 2:<br> reserved 0<br> user ID 'LASF_Projection'<br> record ID 2112<br> length after header 816<br> description 'OGC Well Known Text'<br> WKT OGC COORDINATE SYSTEM:<span class="gmail-im"><br> 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]]]<br></span>variable length header record 2 of 2:<br> reserved 0<br> user ID 'LASF_Projection'<br> record ID 34735<br> length after header 64<br> description 'GeoTiff Projection Keys'<br> GeoKeyDirectoryTag version 1.1.0 number of keys 7<br> key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected<br> key 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsArea<br> key 3072 tiff_tag_location 0 count 1 value_offset 6356 - ProjectedCSTypeGeoKey: NAD83(2011) / Alabama West<br> key 3076 tiff_tag_location 0 count 1 value_offset 0 - ProjLinearUnitsGeoKey: look-up for 0 not implemented<br> key 4096 tiff_tag_location 0 count 1 value_offset 32767 - EPSG code 32767 not found in 'vertcs.csv' file<br>set_VerticalCSTypeGeoKey: look-up for 32767 not implemented<br>VerticalCSTypeGeoKey: look-up for 32767 not implemented<br> key 4098 tiff_tag_location 0 count 1 value_offset 0 - VerticalDatumGeoKey: Vertical Datum Codes 0<br> key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter<br>the header is followed by 3245 user-defined bytes<br>reporting minimum and maximum for all LAS point record entries ...<br> X -336088945 -335544213<br> Y -475536958 -475394351<br> Z 179282 251952<br> intensity 512 14080<br> return_number 1 2<br> number_of_returns 1 2<br> edge_of_flight_line 0 1<br> scan_direction_flag 1 1<br> classification 0 2<br> scan_angle_rank -45 40<br> user_data 0 7<br> point_source_ID 2 2<br> gps_time 271441788.061201 271441882.931595<br> Color R 0 65280<br> G 0 65280<br> B 0 65280<br> extended_return_number 1 2<br> extended_number_of_returns 1 2<br> extended_classification 0 2<br> extended_scan_angle -7474 6636<br> extended_scanner_channel 0 0<br>number of first returns: 8279964<br>number of intermediate returns: 0<br>number of last returns: 8279964<br>number of single returns: 8273053<br>overview over extended number of returns of given pulse: 8273053 13822 0 0 0 0 0 0 0 0 0 0 0 0 0<br>histogram of classification of points:<br> 1530388 never classified (0)<br> 110209 unclassified (1)<br> 6646278 ground (2)</font>
</div><div><span class="sewpexogzl8611w"></span><span class="sewpexogzl8611w"></span></div>
</div>