tile-based mutli-core batch processing with LAStools - a small example

[Martin Isenburg]

Hello,

this will be a small example on how to first quality check a newly received set of flight strips and how to then create a tile-based mutli-core batch processing pipeline with LAStools. To get started first download the latest version of LAStools (130126 or newer):

http://lastools.org/download/lastools.zip

then download these 7 example flight strips

http://liblas.org/samples/LDR030828_211804_0.laz
http://liblas.org/samples/LDR030828_212242_0.laz
http://liblas.org/samples/LDR030828_212622_0.laz
http://liblas.org/samples/LDR030828_213023_0.laz
http://liblas.org/samples/LDR030828_213450_0.laz
http://liblas.org/samples/LDR030828_213842_0.laz
http://liblas.org/samples/LDR030828_214222_0.laz

and put the 7 LAZ strips into a folder called .\lastools\bin\strips_raw - we will work here inside the .\lastools\bin directory for simplicity of explanation so please open a DOS window and change your command line into the .\lastools\bin directory (e.g. "cd c:\lastools\bin").

First let us do some QUALITY CHECKING. I usually run lasindex + lasview + lasinfo across the strips to see if the data makes sense. Only add the '-cores 3' option when you have a computer with at least 4 cores. If you have an 8 core machine you may even add '-cores 7' and so on ...

C:\lastools\bin>lasindex -i strips_raw\LDR*.laz -cores 3

start the lasview GUI either with double-click and browsing for the seven flight strips or by typing

C:\lastools\bin>lasview -i strips_raw\LDR*.laz -gui

now you can maneuver up and down and highlight the different strips. You may look at all the data by pressing the VIEW button or you could inspect a smaller area by picking a rectangular region as shown in the attached screenshot. You can use the <c> key to toggle through the different visualizations. One is a bit crazy and that is the one for the point_source_ID which seems rather random. It was probably used for some unrelated purpose and not cleaned up before distributing the data. Not nice, but we will fix that later.

In the GUI you can also see that the files have apparently no projection information and scaling factors of 0.001 that could capture details down to millimeter precision. Since this is airborne LiDAR we will fix the scaling factor to a more appropriate centimeter resolution. Finally, the creation day and year is not set, which - if we know when the data was flown - could easily be added.

Before attempting to improve these LAS/LAZ files we should make sure that our work will be worthwhile by running a quick visualization based of how well the flight strips fit together. We do this with

lasoverlap -i strips_raw\LDR*.laz -files_are_flightlines -utm 19N ^
                 -step 1.0 -max_diff 1.0 ^
                 -o strip_overlap.png

Because I know that the missing projection in the LAS file is UTM zone 19N I can simply add this to the command line. Why? Because then lasoverlap will produce in addition to the PNG output also a KML file that allows me to drag and drop them into Google Earth to visualize the resulting overlap and difference rasters  with context. Troubles in the data would be an empty spot in the overlap raster and/or saturated blue or red spots in an open (=> non-forested) area. If either was the case I could send the data back to the vendor to have him fix it ...

Finally we run lasinfo on one one of the files and compute the density

C:\lastools\bin>lasinfo -i strips_raw\LDR030828_211804_0.laz -cd
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             0
  global_encoding:            0
  project ID GUID data 1-4:   0 0 0 ''
  version major.minor:        1.0
  system identifier:          'ALSXX'
  generating software:        'ALSXX_PP V2.56c'
  file creation day/year:     0/0
  header size:                227
  offset to point data:       5587
  number var. length records: 3
  point data format:          0
  point data record length:   20
  number of point records:    2404613
  number of points by return: 2210130 0 194483 0 0
  scale factor x y z:         0.001 0.001 0.001
  offset x y z:               0 4000000 0
  min x y z:                  272254.830 4714389.375 65.050
  max x y z:                  275391.197 4714711.445 169.208
variable length header record 1 of 3:
  reserved             43707
  user ID              'LeicaGeo'
  record ID            1001
  length after header  5120
  description          ''
variable length header record 2 of 3:
  reserved             43707
  user ID              'LeicaGeo'
  record ID            1002
  length after header  22
  description          'MissionInfo'
variable length header record 3 of 3:
  reserved             43707
  user ID              'LeicaGeo'
  record ID            1003
  length after header  54
  description          'UserInputs'
the header is followed by 2 user-defined bytes
LASzip compression (version 2.0r2 c2 50000): POINT10 2
reporting minimum and maximum for all LAS point record entries ...
  X  272254812  275391197
  Y  714389375  714711445
  Z      65050     169208
  intensity 0 255
  edge_of_flight_line 0 1
  scan_direction_flag 0 1
  number_of_returns_of_given_pulse 1 2
  return_number                    1 3
  classification      1     1
  scan_angle_rank   -13    13
  user_data           0     0
  point_source_ID     0   255
WARNING: 2 points outside of header bounding box
number of last returns: 2209098
covered area in square units/kilounits: 728996/0.73
point density: all returns 3.30 last only 3.03 (per square units)
      spacing: all returns 0.55 last only 0.57 (in units)
overview over number of returns of given pulse: 2014615 389998 0 0 0 0 0
histogram of classification of points:
         2404613  Unclassified (1)
real max x larger than header max x by 0.000422
real min x smaller than header min x by 0.017715

In addition to the things already mentioned (e.g. poor scaling factor, no creation date, missing projection VLR, random point_source_IDs) I also do not like the slightly inaccurate bounding box and the three VLRs that mean nothing to me. Another fishy thing is that there are many returns with number 3 while all pulses are reported to have maximally 2 returns yet there is no return with number 2. The return number is either 1 or 3 but ... was this an older scanner with maximally two return per pulse? Was this behavior spec conform in LAS 1.0?

In any case, in the next email we will see how to turn these "imperfect" strips into more "beautiful" strips.

Cheers,

Martin @rapidlasso

http://rapidlasso.com - fast tools to beautify your LiDARs

[James Dunnam]

Hi all,

Just out of curiosity, and to make sure I'm understanding this right, with lasoverlap the -step 1.0 and max_diff  2.0; the flight lines are converted to a raster with 1 meter pixels, and the difference is colored from -2 meters to 2 meters. Does this sound right?

--
--
Download LAStools at
http://lastools.org/
Visit the LAStools group at
http://groups.google.com/group/lastools/
Be social with LAStools at
http://www.facebook.com/LAStools
http://www.twitter.com/LAStools
 
 
 

--
-A polar bear is a rectangular bear after a coordinate transformation.