Issues with translating overly precise data
633 views
Skip to first unread message
UCMatt Walker
Jun 5, 2018, 8:38:32 AM6/5/18
to LAStools - efficient tools for LiDAR processing
I'm trying to translate data from MGA zone 54 to a local coordinate grid.
I've found that the following command
las2las.exe -i "20180301 A3.las" -translate_xyz -278750 -6135050 0 -reoffset 0 0 0 -o out.las
gives the following warnings
WARNING: reoffsetting from 281072 to 0 causes LAS integer overflow for min_xWARNING: reoffsetting from 281072 to 0 causes LAS integer overflow for max_xWARNING: reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for min_yWARNING: reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for max_yWARNING: reoffsetting from 94.3158 to 0 causes LAS integer overflow for min_zWARNING: reoffsetting from 94.3158 to 0 causes LAS integer overflow for max_z
I found in another post these warnings can be due to excessive precision so I ran a revised command
las2las.exe -i "20180301 A3.las" -rescale 0.01 0.01 0.01 -translate_xyz -278750 -6135050 0 -reoffset 0 0 0 -out2.las
and this yeilded correctly positioned data.although now with only cm accuracy.
How do I achieve a translation but maintain mm accuracy?
cheers, Matt
below is lasinfo inspection of the original file over the offending datset..
lasinfo.exe "20180301 A3.las" -stdout
lasinfo (180520) report for '20180301 A3.las'
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.3
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'blanked'
file creation day/year: 279/2017
header size: 235
offset to point data: 305
number var. length records: 1
point data format: 2
point data record length: 26
number of point records: 12550278
number of points by return: 12550278 0 0 0 0
scale factor x y z: 0.000000189330318 0.00000012247382 0.000000039642274
offset x y z: 281072.38044459274 6133297.1896777395 94.315790675596872
min x y z: 280665.79668332945 6133034.17915117 9.18465583974205
max x y z: 281478.96420585603 6133560.2002043091 179.4469255114517
WARNING: stored resolution of min_x not compatible with x_offset and x_scale_factor: 280665.79668332945
WARNING: stored resolution of min_y not compatible with y_offset and y_scale_factor: 6133034.17915117
WARNING: stored resolution of min_z not compatible with z_offset and z_scale_factor: 9.18465583974205
WARNING: stored resolution of max_x not compatible with x_offset and x_scale_factor: 281478.96420585603
WARNING: stored resolution of max_y not compatible with y_offset and y_scale_factor: 6133560.2002043091
WARNING: stored resolution of max_z not compatible with z_offset and z_scale_factor: 179.4469255114517
start of waveform data packet record: 0
variable length header record 1 of 1:
reserved 0
user ID 'LASF_Projection'
record ID 34735
length after header 8
description ''
GeoKeyDirectoryTag version 1.1.0 number of keys 1
key 17 tiff_tag_location 0 count 81 value_offset 0 - key ID 17 not implemented
the header is followed by 8 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
intensity 0 0
return_number 1 1
number_of_returns 1 1
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 0 0
scan_angle_rank 0 0
user_data 0 0
point_source_ID 0 0
Color R 0 65280
G 0 65280
B 0 65280
number of first returns: 12550278
number of intermediate returns: 0
number of last returns: 12550278
number of single returns: 12550278
overview over number of returns of given pulse: 12550278 0 0 0 0 0 0
histogram of classification of points:
12550278 never classified (0)
Martin Isenburg
Jun 5, 2018, 9:21:45 AM6/5/18
to LAStools - efficient command line tools for LIDAR processing
Hello,
the lasinfo report (thanks for sending it (-:) shows that you are currently having data stored with "insane" resolution:
scale factor x y z: 0.000000189330318 0.00000012247382 0.000000039642274
of around 0.2 micrometer (um) for x, almost 0.1 um for
y, and 0.04 um or 40 nanometer (nm) for z. The human hair has a diameter of 40 to 120 um. So you are far from millimeter. The scale factors are chosen this way to spread the bounding box across the entire extend of a 32 bit integer - the data type the LAS format uses internally for storage of fixed-point numbers. You can see that in the min max values reported for all point attribute entries:
This is *not* what the design of the LAS format wanted people to do. Spreading the range of each bounding box axis across the entire range of a 32 bit integer is not the intended use of the LAS fixed-point format. The intended use was to know the approximate error in your coordinates and then choose an appropriate scaling factor, such as, for example, 0.01 (or centimeters) for airborne LiDAR. 0.001 (or millimeters)
for mobile LiDAR, and 0.00025 or 0.0001 (submillimeters) for extremely high-precision distance measurements. The scale factors in your file are not only silly but cause a number of issues:
* the tiniest translation / shift will cause an integer overflow in the LAS format
* the merge of two data sets will cause an integer overflow in the LAS format
* pretty much any other operation on the coordinates will also cause
an integer overflow in the LAS format
* LASzip compression rates are lousy
* ....
* ....
I strongly advise against producing LAS/LAZ files where the bounding box is spread across the entire extend of the internally used 32 bit integer and I encourage you to contact whoever produced the exporter that generated those files to fix their software.
I'm trying to translate data from MGA zone 54 to a local coordinate grid.I've found that the following commandlas2las.exe -i "20180301 A3.las" -translate_xyz -278750 -6135050 0 -reoffset 0 0 0 -o out.lasgives the following warningsWARNING: reoffsetting from 281072 to 0 causes LAS integer overflow for min_xWARNING: reoffsetting from 281072 to 0 causes LAS integer overflow for max_xWARNING: reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for min_yWARNING: reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for max_yWARNING: reoffsetting from 94.3158 to 0 causes LAS integer overflow for min_zWARNING: reoffsetting from 94.3158 to 0 causes LAS integer overflow for max_z
These WARNINGs are there for a reason and in this case are serious. Without adjusting the scale factors the resulting LAS file will be garbage for the reasons mentioned above.
I found in another post these warnings can be due to excessive precision so I ran a revised commandlas2las.exe -i "20180301 A3.las" -rescale 0.01 0.01 0.01 -translate_xyz -278750 -6135050 0 -reoffset 0 0 0 -out2.las
Well done.
and this yeilded correctly positioned data.although now with only cm accuracy.How do I achieve a translation but maintain mm accuracy?
Use a scale factor that captures millimeter accuracy instead:
las2las.exe -i 20180301 A3.las ^
-rescale 0.001 0.001 0.001 ^
-reoffset 0 0 0 ^
-translate_xyz -278750 -6135050 0 ^
-o out3.las
Regards,
Martin @rapidlasso
================================================
UCMatt Walker
Jun 5, 2018, 9:47:50 AM6/5/18
to LAStools - efficient tools for LiDAR processing
Thanks Martin,
I suspected the resolution was excessive but didn't understand how it all fit together. Your explanation has made it very clear. I'll pass on your feedback to the author/supplier
I adjusted the scale factor to millimeter but it resulted in some warnings
las2las.exe -i "20180301 A3.las" -rescale 0.001 0.001 0.001 -translate_xyz -278750 -6135050 0 -reoffset 0 0 0 -o out.las
WARNING: rescaling from 1.22474e-007 to 0.001 and reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for min_y
WARNING: rescaling from 1.22474e-007 to 0.001 and reoffsetting from 6.1333e+006 to 0 causes LAS integer overflow for max_y
The data appears to be positioned correctly so is the Warning message of concern in this instance?
The lasinfo output is below
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.3
system identifier: 'LAStools (c) by rapidlasso GmbH'
generating software: 'las2las (version 180520)'
file creation day/year: 279/2017
header size: 235
offset to point data: 305
number var. length records: 1
point data format: 2
point data record length: 26
number of point records: 12550278
number of points by return: 12550278 0 0 0 0
scale factor x y z: 0.001 0.001 0.001
offset x y z: 0 0 0
min x y z: 1915.797 -2015.821 9.185
max x y z: 2728.964 -1489.800 179.447
start of waveform data packet record: 0
variable length header record 1 of 1:
reserved 0
user ID 'LASF_Projection'
record ID 34735
length after header 8
description ''
GeoKeyDirectoryTag version 1.1.0 number of keys 1
key 17 tiff_tag_location 0 count 113 value_offset 0 - key ID 17 not implemented
the header is followed by 8 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
X 1915797 2728964
Y -2015821 -1489800
Z 9185 179447
intensity 0 0
return_number 1 1
number_of_returns 1 1
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 0 0
scan_angle_rank 0 0
user_data 0 0
point_source_ID 0 0
Color R 0 65280
G 0 65280
B 0 65280
number of first returns: 12550278
number of intermediate returns: 0
number of last returns: 12550278
number of single returns: 12550278
overview over number of returns of given pulse: 12550278 0 0 0 0 0 0
histogram of classification of points:
12550278 never classified (0)
Martin Isenburg
Jun 5, 2018, 11:45:36 AM6/5/18
to LAStools - efficient command line tools for LIDAR processing
Hello Matt,
looks good. Those WARNINGs are emitted at the core of the LASlib library where reoffsetting and rescaling happens and it is not at that point that you are also LAStransforming your data with a translation of all coordinates that matches the reoffsetting, hence the WARNINGs. But if you look at your offsets, your scales, and the ranges of the raw X Y Z signed 32 bit integers then you can convince yourself that all is good:
scale factor x y z: 0.001 0.001 0.001
offset x y z: 0 0 0
min x y z: 1915.797 -2015.821 9.185
max x y z: 2728.964 -1489.800 179.447
[...]
reporting minimum and maximum for all LAS point record entries ...
X 1915797 2728964
Y -2015821 -1489800
Z 9185 179447
After scaling these integers with their corresponding scales and adding their corresponding offsets (here all zeros) you get exactly the bounding box values, and not some modulo 2^31 version of them,.
Regards,
Martin @rapidlasso
--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
Reply all
Reply to author
Forward
0 new messages