Storing multiple laser data in LAS point source ID

107 views
Skip to first unread message

Harrison Knoll

unread,
Mar 17, 2021, 12:19:07 PM3/17/21
to LAStools - efficient tools for LiDAR processing
Where should one store the laser of origin for LiDAR sensors that have multiple lasers inside?  The velodyne, quanergy, livox, etc etc systems will have multiple lasers firing and accepting returns.  It is important to denote which laser did a point originate.  

The LAS file format is very limiting, and I have seen manufacturers in the past stuff this data in the point_source_id column.  Does anyone have any recommendations?

Then the next question pertains to expanding this notion and what should be done with more advanced analysis - for example it is important for machine learning to store both the predicted class but also the inference confidence level, and ideally it would be great to store multiple classes on each point with confidence interval --- but now I am dreaming.

There are many things we wish our LAS vessel to do but first thing first. What is recommended for the laser number origin.  point_source_id?

Martin Isenburg

unread,
Mar 17, 2021, 12:29:19 PM3/17/21
to LAStools - efficient command line tools for LIDAR processing
Hello Harrison, 

very well timed question. Just this Monday during the ASPRS LWG meeting I proposed a "Laser Beam ID" or so as a new addition to be added to the "Standardization of Common Extra Bytes" that we are considering to add to the LAS specification.


Your input could be valuable in this process. We were converging on an unsigned integer called "Beam ID" or similar that would be a number between 0 and 31 for a Velodyne HDL 32 and could be stored as either an unsigned 8 bit, an unsigned 16 bit or an unsigned 32 bit integer with the highest number where all bits are on 0xFF, 0xFFFF or 0xFFFFFFFF are always reserved as a "no data" value for any points that are not part of the survey (artificial infill points, for example, from other sources).

Would that work for you? I already have this technology more or less ready in LAStools as I was flying a LidarUSA Snoopy HD here in Samara and saw this value stored in the user data field and wanted to move it somewhere more suitable.

Regards,

Martin



--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lastools/029f62af-6297-4eef-8622-9779fe9bba6cn%40googlegroups.com.

Martin Isenburg

unread,
Mar 17, 2021, 5:19:00 PM3/17/21
to LAStools - efficient command line tools for LIDAR processing
Hello Harrison,

your question today combined with the LAS Working Group meeting discussion from Monday inspired me to write up a little blog post on the Velodyne HDL-32E system that visited me here in Costa Rica and how I stored it's "beam ID" to a custom attribute via the "extra bytes" concept of the LAS 1.4 specification with two command lines

https://rapidlasso.com/2021/03/17/preparing-drone-lidar-from-snoopy-by-lidarusa-carrying-a-velodyne-hdl-32e/

namely

las2las ^
-i Samara\Drone\00_raw_aligned\*.laz ^
-add_attribute 1 "laser beam ID" "which beam ranged this return" ^
-odir Samara\Drone\00_raw_temp -olaz

las2las ^
-i Samara\Drone\00_raw_temp\*.laz ^
-copy_user_data_into_attribute 0 ^
-set_user_data 0 ^
-set_point_source 0 ^
-odir Samara\Drone\00_raw_ready -olaz

Regards,

Martin

Martin Isenburg

unread,
Mar 18, 2021, 1:52:41 PM3/18/21
to LAStools - efficient command line tools for LIDAR processing
Hello,

that there is a general need to store the value is also evident from a recent LAStools user forum post that included data from another Velodyne system, I assume from one of their "Puck" systems, as they also have an extra byte storing this value.


The lasinfo report is below and the data can be obtained in the discussion thread above:

E:\software\LAStools\bin>lasinfo -i GCP.laz -histo attribute0 1 
WARNING: no payload for LASF_Projection VLR with record_id 2112.
lasinfo (210128) report for 'GCP.laz'
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             0
  global_encoding:            1
  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000
  version major.minor:        1.4
  system identifier:          'LAStools (c) by rapidlasso GmbH'
  generating software:        'QT Modeler 8.2.1573'
  file creation day/year:     76/2021
  header size:                375
  offset to point data:       1347
  number var. length records: 3
  point data format:          1
  point data record length:   41
  number of point records:    16882
  number of points by return: 1889 0 0 0 0
  scale factor x y z:         0.001 0.001 0.001
  offset x y z:               420000 7070000 0
  min x y z:                  428158.055 7073961.979 -0.040
  max x y z:                  428158.984 7073962.943 1.256
  start of waveform data packet record: 0
  start of first extended variable length record: 693509
  number of extended_variable length records: 0
  extended number of point records: 16882
  extended number of points by return: 1889 0 0 0 0 0 0 0 0 0 0 0 0 0 0
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Spec'
  record ID            4
  length after header  768
  description          'by LAStools of rapidlasso GmbH'
    Extra Byte Descriptions
      data type: 2 (char), name "Ring", description: "Lidar Ring in Velodyne", scale: 1, offset: 0
      data type: 9 (float), name "Range", description: "Range from Lidar to Point", scale: 1, offset: 0
      data type: 6 (long), name "elev", description: "copied elevation", scale: 0.01, offset: 0 (not set)
      data type: 6 (long), name "agl", description: "copied above ground level", scale: 0.01, offset: 0 (not set)
variable length header record 2 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            2112
  length after header  0
  description          'OGC WKT'
variable length header record 3 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  40
  description          'by LAStools of rapidlasso GmbH'
    GeoKeyDirectoryTag version 1.1.0 number of keys 4
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 3072 tiff_tag_location 0 count 1 value_offset 28356 - ProjectedCSTypeGeoKey: GDA94 / MGA 56S
      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
the header is followed by 2 user-defined bytes
LASzip compression (version 3.4r3 c2 50000): POINT10 2 GPSTIME11 2 BYTE 2
reporting minimum and maximum for all LAS point record entries ...
  X             8158055    8158984
  Y             3961979    3962943
  Z                 -40       1256
  intensity           0        255
  return_number       0          1
  number_of_returns   0          0
  edge_of_flight_line 0          0
  scan_direction_flag 0          0
  classification      2          4
  scan_angle_rank     0          0
  user_data           0         13
  point_source_ID     0          0
  gps_time 1607514048.607132 1607514465.053890
  attribute0          0         15  ('Ring')
  attribute1    1.50853    26.5418  ('Range')
  attribute2          0          0  ('elev')
  attribute3          0       1.26  ('agl')
number of first returns:        16882
number of intermediate returns: 0
number of last returns:         16882
number of single returns:       16882
WARNING: there are 14993 points with return number 0
WARNING: there are 16882 points with a number of returns of given pulse of 0
histogram of classification of points:
            2556  ground (2)
           11790  low vegetation (3)
            2536  medium vegetation (4) 
attribute 0 histogram with bin size 1.000000
  bin 0 has 1122
  bin 1 has 1100
  bin 2 has 1108
  bin 3 has 1054
  bin 4 has 1068
  bin 5 has 1078
  bin 6 has 1029
  bin 7 has 1048
  bin 8 has 925
  bin 9 has 992
  bin 10 has 1064
  bin 11 has 1067
  bin 12 has 962
  bin 13 has 1012
  bin 14 has 1063
  bin 15 has 1190
  average attribute 0 7.450953678474114 for 16882 element(s)

Reply all
Reply to author
Forward
0 new messages