Issue with PTS->LAS
112 views
Skip to first unread message
caspar.forsberg
Apr 11, 2014, 7:00:45 AM4/11/14
to last...@googlegroups.com
Dear forum,
I've had an issue a couple of times with LAS files converted from PTS from various leica scanners.
The LAS looks just fine in the LAStools viewer and in CloudCompare, but in VRUI Lidar viewer it's completely "striped" (see attached images)
Anyone have an idea of what's going on/ what I'm doing wrong?
Best regards/ Caspar Forsberg
I've had an issue a couple of times with LAS files converted from PTS from various leica scanners.
The LAS looks just fine in the LAStools viewer and in CloudCompare, but in VRUI Lidar viewer it's completely "striped" (see attached images)
Anyone have an idea of what's going on/ what I'm doing wrong?
Best regards/ Caspar Forsberg
Martin Isenburg
Apr 11, 2014, 7:04:43 AM4/11/14
to LAStools - efficient command line tools for LIDAR processing
Can you send a lasinfo.exe TXT as well as a lasvalidate.exe XML report ...?
lasinfo -i your_file.las -o report.txt
lasvalidate -i your_file.las -o report.xml
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
Martin Isenburg
Apr 11, 2014, 1:33:06 PM4/11/14
to LAStools - efficient command line tools for LIDAR processing
Hello Caspar,
wow ... this is one ugly LAS file. Which software did you use for the conversion? May I suggest to use txt2las in the future to avoid this uglyness. Alternatively you can use pointzip.exe (from http://pointzip.org).
See these entries are ugly and are likely the culprit for troubles in some software. The fixed point integer coordinates were scales such that their integer representations X Y Z have a (near) fixed range of zero to 1 billion ... a horrible idea. Just search for the word "fluff" or "crappy" in the LAStools forum for more info on this topic as we had issues like that a few times already.
scale factor x y z: 0.000000022602001 0.000000090231003 0.000000043607998
offset x y z: 1492847.3219998933 6742081.9270000104 324.673000010252
min x y z: 1492847.3219998933 6742081.9270000104 324.673000010252
max x y z: 1492869.9240001298 6742172.1580032352 368.28099960327148
reporting minimum and maximum for all LAS point record entries ...
X 0 999999958
Y 0 1000000005
Z 0 1000000039
offset x y z: 1492847.3219998933 6742081.9270000104 324.673000010252
min x y z: 1492847.3219998933 6742081.9270000104 324.673000010252
max x y z: 1492869.9240001298 6742172.1580032352 368.28099960327148
reporting minimum and maximum for all LAS point record entries ...
X 0 999999958
Y 0 1000000005
Z 0 1000000039
I suggest the following LAStools treatment for immediate relieve:
las2las -i crappy.las ^
-repair_zero_returns ^
-rescale 0.001 0.001 0.001 ^
-auto_reoffset ^
-o beautiful.laz
Martin
PS: Michael Olson from Oregon State wrote: "What coordinate system are you using? If you are using real world coordinates, the problem is likely that VRUI is truncating the coordinates by reading them in as floats ornot providing an offset for when importing to OpenGL. So sometimes you have to manually shift the data so that it is closer to 0,0,0." I combined this here with my answer to have one less email for everybody as VRUI is a bit off-topic in this forum ...
Martin Isenburg
Apr 12, 2014, 6:29:30 AM4/12/14
to LAStools - efficient command line tools for LIDAR processing
Hello,
turns out that popular "Cloud Compare" software created the "crappy" scaling. It's a great software but I would *strongly* advise to use it for importing your LAS / LAZ files and then exporting them again in LAS / LAZ format as part of your workflow. Cloud Compare will rescale your LAS / LAZ files and drop the information stored as Variable Length Records (VLRs) such as projection information and slightly modify other attributes as well. Below an example with fusa.laz. I include the lasinfo report of the original first and then of the one exported from Cloud Compare. All I did was load it into Cloud Compare (version 2.5.3 [Windows 64 bits]) and then save it again. See for yourself:
D:\lastools\bin>lasdiff -i fusa.laz -i fusa_cc_export.laz
checking 'fusa.laz' against 'fusa_cc_export.laz'
headers are different
different version: 1.1 1.2
different system_identifier: 'LAStools (c) by Martin Isenburg' 'libLAS'
different generating_software: 'lasclassify (110920) unlicensed' 'libLAS 1.7.0'
different file_creation day.year: 40.2010 101.2014
different offset_to_point_data: 321 227
different number_of_variable_length_records: 1 0
different point_data_format: 1 3
different point_data_record_length: 28 34
different number_of_points_by_return: (263413,13879,281,0,0) (0,0,0,0,0)
WARNING: different x_scale_factor: 0.01 0.00000025
WARNING: different y_scale_factor: 0.01 0.00000025
WARNING: different z_scale_factor: 0.01 0.000000022
WARNING: different x_offset: 0 277749.999998779
WARNING: different y_offset: 0 6122250.000003052
WARNING: different z_offset: 0 42.21000061
different max_x: 277999.99 277999.99
different min_x: 277750 277749.999998779
different max_y: 6122499.99 6122499.989993286
different min_y: 6122250 6122250.000003052
different min_z: 42.21 42.21000061
skipping check of variable length records due to different number (1 != 0)
headers have 20 differences.
x: 27799997 999919980 scaled offset x 278000 278000
y: 612234220 368814755 scaled offset y 6.12234e+006 6.12234e+006
scan_angle_rank: 89 0
point 1 of 277573 is different
gps time of point 1 of 277573 is different: 5880.963028 != 5880.962891
x: 27799997 999919980 scaled offset x 278000 278000
y: 612234253 370134808 scaled offset y 6.12234e+006 6.12234e+006
z: 6430 997741644 scaled offset z 64.3 64.3
scan_angle_rank: 89 0
point 2 of 277573 is different
gps time of point 2 of 277573 is different: 5880.963032 != 5880.962891
x: 27799952 998119908 scaled offset x 278000 278000
y: 612233974 358974361 scaled offset y 6.12234e+006 6.12234e+006
z: 6309 943089430 scaled offset z 63.09 63.09
scan_angle_rank: 89 0
point 3 of 277573 is different
gps time of point 3 of 277573 is different: 5880.978038 != 5880.978027
x: 27799955 998239913 scaled offset x 278000 278000
scan_angle_rank: 89 0
point 4 of 277573 is different
gps time of point 4 of 277573 is different: 5880.978043 != 5880.978027
scan_angle_rank: 89 0
point 5 of 277573 is different
gps time of point 5 of 277573 is different: 5880.978047 != 5880.978027
more than 5 points are different ... shutting up.
scaled offset points are different (max diff: 7.44913e-006 7.44779e-006 9.26045e-007).
both have 277573 points. took 0.795 secs.
D:\lastools\bin>lasinfo ..\data\fusa_cc_export.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: 'libLAS'
generating software: 'libLAS 1.7.0'
file creation day/year: 101/2014
header size: 227
offset to point data: 227
number var. length records: 0
point data format: 3
point data record length: 34
number of point records: 277573
number of points by return: 0 0 0 0 0
scale factor x y z: 0.000000249990005 0.00000024998999 0.000000022139999
offset x y z: 277749.99999877927 6122250.0000030519 42.210000610351557
min x y z: 277749.99999877927 6122250.0000030519 42.210000610351557
max x y z: 277999.98999999953 6122499.9899932863 64.349999999999994
LASzip compression (version 2.2r0 c2 50000): POINT10 2 GPSTIME11 2 RGB12 2
reporting minimum and maximum for all LAS point record entries ...
X 0 999999983
Y 0 1000000000
Z 0 1000000000
intensity 10 62293
return_number 1 3
number_of_returns 1 3
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 1 6
scan_angle_rank 0 0
user_data 0 197
point_source_ID 1 1
gps_time 5880.962891 5886.739746
Color R 0 0
G 0 0
B 0 0
number of points by return was not set in header: 263413 13879 281 0 0
overview over number of returns of given pulse: 249493 27232 848 0 0 0 0
histogram of classification of points:
17553 unclassified (1)
180868 ground (2)
37030 high vegetation (5)
42122 building (6)
D:\lastools\bin>lasinfo ..\data\fusa.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.1
system identifier: 'LAStools (c) by Martin Isenburg'
generating software: 'lasclassify (110920) unlicensed'
file creation day/year: 40/2010
header size: 227
offset to point data: 321
number var. length records: 1
point data format: 1
point data record length: 28
number of point records: 277573
number of points by return: 263413 13879 281 0 0
scale factor x y z: 0.01 0.01 0.01
offset x y z: 0 0 0
min x y z: 277750.00 6122250.00 42.21
max x y z: 277999.99 6122499.99 64.35
variable length header record 1 of 1:
reserved 43707
user ID 'LASF_Projection'
record ID 34735
length after header 40
description 'by LAStools of Martin Isenburg'
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 32754 - ProjectedCSTypeGeoKey: UTM 54 southern hemisphere
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
LASzip compression (version 2.0r1 c2 50000): POINT10 2 GPSTIME11 2
reporting minimum and maximum for all LAS point record entries ...
X 27775000 27799999
Y 612225000 612249999
Z 4221 6435
intensity 10 62293
return_number 1 3
number_of_returns 1 3
edge_of_flight_line 0 0
scan_direction_flag 0 0
classification 1 6
scan_angle_rank 79 103
user_data 0 197
point_source_ID 1 1
gps_time 5880.963028 5886.739738
overview over number of returns of given pulse: 249493 27232 848 0 0 0 0
histogram of classification of points:
17553 unclassified (1)
180868 ground (2)
37030 high vegetation (5)
42122 building (6)
Olsen, Richard (RC) (CIV)
Apr 12, 2014, 12:17:36 PM4/12/14
to last...@googlegroups.com
I think you probably meant to say:
I would *strongly* advise you not to use it for importing your LAS / LAZ
rc olsen
From: last...@googlegroups.com [last...@googlegroups.com] on behalf of Martin Isenburg [martin....@gmail.com]
Sent: Saturday, April 12, 2014 3:29 AM
To: LAStools - efficient command line tools for LIDAR processing
Subject: Re: [LAStools] Issue with PTS->LAS
Sent: Saturday, April 12, 2014 3:29 AM
To: LAStools - efficient command line tools for LIDAR processing
Subject: Re: [LAStools] Issue with PTS->LAS
Reply all
Reply to author
Forward
0 new messages