using txt2las to add extra bytes to a LAS/LAZ file

[Martin Isenburg]

Hello,

recently I had a customer wanting to really put the new ExtraBytes
capability that was added in the LAS 1.4 specification. Note that both
rapidlasso GmbH as well as RIEGL Laser Measurement Systems GmbH have
decided to allow including Extra Bytes also with LAS 1.2 or LAS 1.3
files because ... it makes sense and causes no harm to those who
cannot exploit it. (-:

How do you add "Extra Bytes" to a LAS/LAZ file when you have a text
file that has some more interesting attributes, such as a "relevant
angle phi" in radians ranging from -3.1415 to 3.1415 or a "range from
target" in millimeters that is between 0 and 300,000 (=> 300 meters).
Here is a little exercise with the attached 6 line ASCII file in.txt.
You need the latest (!!!) LASools version for this to work.

First we skip the first line with the header information, then we
parse x y z and two extra byte attributes located at position 4 and 6.
We skip position 5. That is all encoded as 'xyz0s1'. We set the scale
for x ,y , z to millimeters (0.001) because this was a mobile LiDAR
collect from a truck.

We store the radian angle "phi" using data type 4 (short) with a scale
of 0.01. Why use a short? It is sufficient, for example, because when
we know the resolution of or angle measurements was 0.01. Anything
more precise will just add zeros or white noise to the end of each
number. And that would not only mislead the recepient of the data but
also hamper compression when using LAZ. Hence the angle will be stored
using a scaled short that will range from round(-3.1415 / 0.01) = -315
to round(3.1415 / 0.01) = 315. Do *not* use data types 9 (float) or 10
(double) to encode such values. Floating points are *only* needed when
the range of your numbers is exponential (or logharithmic).

We store the millimeter "range" using data type 5 (unsigned long) with
the default scale of 1. We choose this because we know that given all
the errors in IMU, GPS, and the scanner comined the range measurements
are only accurate to around 3 mm. So there in no need to store
sub-millimeter system errors which will just bloat up the file and
miss-lead the reipient about the accuracy of the data.

Below the entire exercise including how to reverse parse it with
las2txt and the lasinfo output documenting the "ExtraBytes" VLRs.

txt2las -i in.txt ^
-skip 1 ^
-parse xyz0s1 ^
-set_scale 0.001 0.001 0.001 ^
-add_extra 4 "phi" "relevant angle [rad]" 0.001 ^
-add_extra 5 "range" "range from target [mm]" ^
-o out.laz
WARNING: written 5 points but expected 0 points

las2txt -i out.laz -parse xyz01 -stdout
368205.137 6674407.906 29.004 0.80 23905
368205.051 6674407.918 29.069 1.12 23907
368205.092 6674407.938 29.058 1.00 23912
368205.179 6674407.937 29.025 1.28 23903
368205.114 6674407.952 29.068 1.52 23904

lasinfo -i out.laz
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 00000000-0000-0000-0000-000000000000
version major.minor: 1.2
system identifier: 'LAStools (c) by Martin Isenburg'
generating software: 'txt2las (version 131003)'
file creation day/year: 277/2013
header size: 227
offset to point data: 665
number var. length records: 1
point data format: 0
point data record length: 26
number of point records: 5
number of points by return: 5 0 0 0 0
scale factor x y z: 0.001 0.001 0.001
offset x y z: 360000 6670000 0
min x y z: 368205.051 6674407.906 29.004
max x y z: 368205.179 6674407.952 29.069
variable length header record 1 of 1:
reserved 43707
user ID 'LASF_Spec'
record ID 4
length after header 384
description 'by LAStools of Martin Isenburg'
Extra Byte Descriptions
data type: 4 (short), name "phi", description: "relevant angle
[rad]", scale: 0.01, offset: 0 (not set)
data type: 5 (unsigned long), name "range", description: "range
from target [mm]", scale: 1 (not set), offset: 0 (not set)
LASzip compression (version 2.2r0 c2 50000): POINT10 2 BYTE 2
reporting minimum and maximum for all LAS point record entries ...
X 8205051 8205179
Y 4407906 4407952
Z 29004 29069
intensity 0 0
edge_of_flight_line 0 0
scan_direction_flag 0 0
number_of_returns_of_given_pulse 1 1
return_number 1 1
classification 0 0
scan_angle_rank 0 0
user_data 0 0
point_source_ID 0 0
overview over number of returns of given pulse: 5 0 0 0 0 0 0
histogram of classification of points:
5 Created, never classified (0)

Regards,

Martin