So, I have 21 LiDAR files with incorrect information in their file headers. For example, when I import a single file into R using the following code, I get several warnings saying that there are no points found at each return in the file:
# Install lidR package
install.packages("lidR")
library(lidR)
# Import one LiDAR file
las <- dir(pattern = ".las")
i=1
temp <- readLAS(las[i])
Warning messages:
1: Invalid file: header states the file contains 0 points but 3408961 were found.
2: Invalid file: the header states the file contains 0 1st returns but 3322862 were found.
3: Invalid file: the header states the file contains 0 2nd returns but 81189 were found.
4: Invalid file: the header states the file contains 0 3rd returns but 4852 were found.
5: Invalid file: the header states the file contains 0 4th returns but 58 were found.
I've been told that I can use LAStools' lasinfo
to correct these headers, but I have very minimal experience using these tools, so I'm not really sure how to accomplish this. In my one attempt, I used the executable user interface of lasinfo
to "repair" the headers, but that resulted in an exported text file containing the header information – rather than a las file with a corrected header.
Could anyone tell me how I might be able to correct these headers?
Update:
Several folks have advised me to use the following code with lasinfo to repair my headers –
lasinfo -i *.las -repair
Doing so resulted in a report for each of my las files, however none of my las files were updated with correct header information. Additionally, they still result in the same warning messages mentioned above when imported into R. Below is one of the reports I received from using LASinfo to attempt a header repair:
(Note: These files had their CRS defined using las2las. This is why their generating software is listed as such. However, the raw files list "lasduplicate (181001) commercia" as their generating software. The reports are otherwise identical).
lasinfo (181219) report for 'F:\Grad School\Thesis\Spatial stuff\GSP Project\West Coast 2016\Use\Projected\job445643_41124_87_20.las'
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 17
project ID GUID data 1-4: B50B8F5F-1BD2-4C3C-39AC-01DF4D545CF3
version major.minor: 1.4
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 160606)'
file creation day/year: 301/2016
header size: 375
offset to point data: 1671
number var. length records: 2
point data format: 6
point data record length: 30
number of point records: 0
number of points by return: 0 0 0 0 0
scale factor x y z: 0.01 0.01 0.01
offset x y z: 300000 4600000 0
min x y z: 399586.17 4636046.09 4.24
max x y z: 400155.02 4637160.59 20.35
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: 3408961
extended number of points by return: 3322862 81189 4852 58 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 1136
description 'by LAStools of rapidlasso GmbH'
WKT OGC COORDINATE SYSTEM:
COMPD_CS["NAD83(NSRS2007) / California zone 1; NAVD88 height",PROJCS["NAD83(NSRS2007) / California zone 1",GEOGCS["NAD83(NSRS2007)",DATUM["NAD83_National_Spatial_Reference_System_2007",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6759"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4759"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",41.66666666666666],PARAMETER["standard_parallel_2",40],PARAMETER["latitude_of_origin",39.33333333333334],PARAMETER["central_meridian",-122],PARAMETER["false_easting",2000000],PARAMETER["false_northing",500000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","3489"]],VERT_CS["NAVD88 height",VERT_DATUM["North American Vertical Datum 1988",2005,EXTENSION["PROJ4_GRIDS","g2012a_conus.gtx,g2012a_alaska.gtx,g2012a_guam.gtx,g2012a_hawaii.gtx,g2012a_puertorico.gtx,g2012a_samoa.gtx"],AUTHORITY["EPSG","5103"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Up",UP],AUTHORITY["EPSG","5703"]]]
variable length header record 2 of 2:
reserved 43707
user ID 'LASF_Projection'
record ID 34735
length after header 48
description 'by LAStools of rapidlasso GmbH'
GeoKeyDirectoryTag version 1.1.0 number of keys 5
key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
key 3072 tiff_tag_location 0 count 1 value_offset 26910 - ProjectedCSTypeGeoKey: NAD83 / UTM 10N
key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
key 4096 tiff_tag_location 0 count 1 value_offset 5103 - VerticalCSTypeGeoKey: VertCS_North_American_Vertical_Datum_1988
the header is followed by 4 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
X 9958617 10015502
Y 3604609 3716059
Z 424 2035
intensity 14989 65535
return_number 1 4
number_of_returns 1 4
edge_of_flight_line 0 1
scan_direction_flag 0 1
classification 2 2
scan_angle_rank -7 25
user_data 0 0
point_source_ID 1027 1027
gps_time 145230027.108713 145230068.528501
extended_return_number 1 4
extended_number_of_returns 1 4
extended_classification 2 2
extended_scan_angle -1210 4203
extended_scanner_channel 0 0
number of first returns: 3322862
number of intermediate returns: 0
number of last returns: 3408961
number of single returns: 3322862
number of point records in header is correct.
extended number of point records in header is correct.
number of points by return in header is correct.
extended number of points by return in header is correct.
overview over extended number of returns of given pulse: 3322862 81189 4852 58 0 0 0 0 0 0 0 0 0 0 0
histogram of classification of points:
3408961 ground (2)
bounding box is correct.
Additionally, I was advised to use lasvalidate on my raw files. Here is an output from running the following:
C:\LAStools\bin\lasvalidate -i F:\Grad School\Thesis\Spatial stuff\GSP Project\West Coast 2016\Use\*.las -oxml
Output:
<?xml version="1.0" encoding="UTF-8"?>
-<LASvalidator>
-<report>
-<file>
<name>job445643_41124_87_20.las</name>
<path>F:\Grad School\Thesis\Spatial stuff\GSP Project\West Coast 2016\Use\job445643_41124_87_20.las</path>
<version>1.4</version>
<system_identifier>LAStools (c) by rapidlasso GmbH</system_identifier>
<generating_software>lasduplicate (181001) commercia</generating_software>
<point_data_format>6</point_data_format>
<CRS>not valid or not specified</CRS>
</file>
<summary>warning </summary>
-<details>
-<warning>
<variable>CRS</variable>
<note>there is a OGC WKT string but its check is not yet implemented</note>
</warning>
</details>
</report>
-<total>
warning
-<details>
<pass>0</pass>
<warning>1</warning>
<fail>0</fail>
</details>
</total>
<version>170323 built with LASread version 1.1 (180930) </version>
<command_line>C:\LAStools\bin\lasvalidate -i F:\Grad School\Thesis\Spatial stuff\GSP Project\West Coast 2016\Use\*.las -oxml </command_line>
</LASvalidator>
However, I'm not sure what to make of this. All of the outputs are the same, with only the file name changing between them. Should I be concerned about this 1 warning?
Best Answer
Have a look at the documentation here:
https://www.cs.unc.edu/~isenburg/lastools/download/lasinfo_README.txt
This suggests that simply using the
-repair
option will be enough and that the operation will be performed in place (i.e. you don't need to specify an output). For example:IMO the GUIs in LAStools are horrible and it's much easier to do everything via the command line.