[pdal] "Unknown" values in WKT string
Alexandre Poirot
alexandre.poirot at pix4d.com
Tue Sep 15 08:16:23 PDT 2020
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200915/762240fe/attachment-0001.html>
More information about the pdal
mailing list