las2txt, decimals

381 views
Skip to first unread message

Veldman, Edgar

unread,
Apr 18, 2012, 10:55:03 PM4/18/12
to last...@googlegroups.com

Martin,

 

Is there any way to specify the number of decimals in an output txt file using las2txt? I have LAS files in LatLon coordinates, and would like to convert this to a txt file, maintaining the decimal degree accuracy. By default, I seem to get 7 decimals from las2txt, but I would like to get a couple more. Is this hard coded or can this be changed? I send you a sample LAS file yesterday to you normal email address.

 

las2txt -i 540000-8240000_LL.las –parse xyz

 

results in:

129.4167330 -15.8289120 190.000

129.4167332 -15.8290024 188.240

129.4167334 -15.8290928 187.500

 

Thanks,

Edgar

 

Martin Isenburg

unread,
Apr 19, 2012, 3:05:31 AM4/19/12
to LAStools - efficient tools for LiDAR processing
Hello Edgar,

> Is there any way to specify the number of decimals in an output txt file
> using las2txt?

las2txt uses the full number of decimals that are in the LAS/LAZ
files.

> I have LAS files in LatLon coordinates, and would like to
> convert this to a txt file, maintaining the decimal degree accuracy. By
> default, I seem to get 7 decimals from las2txt, but I would like to get
> a couple more.

there are none. if you run lasinfo.exe -i 540000-8240000_LL.las (i
have copied the resulting output below) you notice that the scaling
factor is 1e-7 1e-7 0.001 which exactly corresponds to the output of
las2txt in terms of number of decimals.

> las2txt -i 540000-8240000_LL.las -parse xyz
>
> results in:
>
> 129.4167330 -15.8289120 190.000
> 129.4167332 -15.8290024 188.240
> 129.4167334 -15.8290928 187.500

it also seems that this (Terrasolid-generated?) LAS file has an
incorrect scale factor for the elevation. It is reported as 0.001 but
the data has only 0.01 precision as a quick run with lasprecision -i
540000-8240000_LL.las will confirm:

lasprecision -i 540000-8240000_LL.las
[...]
Z differences
0 : 22129 0
10 : 7548 0.01
20 : 345 0.02
30 : 68 0.03
40 : 12 0.04
50 : 6 0.05
60 : 6 0.06

this is not inherently bad (apart from wrongly "advertising" more
precision than there actually is) but it will negatively affect LASzip
compression for no good reason other than to store a bunch of extra
zeros in your file. you can "fix" this with

lasprecision -i 540000-8240000_LL.las -o 540000-8240000_LL_cm.laz -
rescale 1e-7 1e-7 0.01

Cheers,

Martin @lastools

-----------------------------------------------------------------

C:\lastools\bin>lasinfo 540000-8240000_clipped_LL.las
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.2
system identifier: ''
generating software: 'TerraScan'
file creation day/year: 18/2012
header size: 227
offset to point data: 423
number var. length records: 2
point data format: 0
point data record length: 20
number of point records: 30132
number of points by return: 30132 0 0 0 0
scale factor x y z: 1e-007 1e-007 0.001
offset x y z: 129.41673208719459 -15.833613035278834 0
min x y z: 129.4167321 -15.8335143 166.150
max x y z: 129.4668907 -15.8283579 253.860
variable length header record 1 of 2:
reserved 43707
user ID 'LASF_Projection'
record ID 34735
length after header 64
description 'Georeferencing Information'
GeoKeyDirectoryTag version 1.1.0 number of keys 7
key 1024 tiff_tag_location 0 count 1 value_offset 2 -
GTModelTypeGeoKey: ModelTypeGeographic
key 2048 tiff_tag_location 0 count 1 value_offset 4326 -
GeographicTypeGeoKey: GCS_WGS_84
key 2054 tiff_tag_location 0 count 1 value_offset 9102 -
GeogAngularUnitsGeoKey: Angular_Degree
key 2057 tiff_tag_location 34736 count 1 value_offset 0 -
GeogSemiMajorAxisGeoKey: 6378137
key 2058 tiff_tag_location 34736 count 1 value_offset 1 -
GeogSemiMinorAxisGeoKey: 6356752.314
key 2059 tiff_tag_location 34736 count 1 value_offset 2 -
GeogInvFlatteningGeoKey: 298.2572236
key 4099 tiff_tag_location 0 count 1 value_offset 9001 -
VerticalUnitsGeoKey: Linear_Meter
variable length header record 2 of 2:
reserved 43707
user ID 'LASF_Projection'
record ID 34736
length after header 24
description 'Double Param Array'
GeoDoubleParamsTag (number of doubles 3)
6.37814e+006 6.35675e+006 298.257
reporting minimum and maximum for all LAS point record entries ...
x 0 501586
y 987 52551
z 166150 253860
intensity 0 1
edge_of_flight_line 0 0
scan_direction_flag 0 0
number_of_returns_of_given_pulse 0 0
return_number 1 1
classification 1 1
scan_angle_rank 0 0
user_data 0 0
point_source_ID 111 111
WARNING: there are 30132 points with a number of returns of given
pulse of 0
histogram of classification of points:
30132 Unclassified (1)

Veldman, Edgar

unread,
Apr 19, 2012, 3:28:47 AM4/19/12
to last...@googlegroups.com
Hi Martin,

Thank you for the info.

The reason that I expected that my data had more decimals, was that I loaded the file in Globalmapper and this is what the feature information for a point shows, 10 decimals for lat/Lon:

Point location: 129.4167329872 -15.8289120353 (Lat/Lon: 15° 49' 44.0833" S, 129° 25' 0.2388" E)

This compared to the las2txt output made me wonder where the rest of the decimals had gone.
129.4167330 -15.8289120 190.000

Maybe Globalmapper doesn't show the actual point information?
This data was generated using Globalmapper, but the header of the LAS file still shows Terrascan.

Edgar

Hello Edgar,

Cheers,

Martin @lastools

-----------------------------------------------------------------

--
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

Martin Isenburg

unread,
Apr 19, 2012, 9:47:53 AM4/19/12
to last...@googlegroups.com
Hello Edgar,

> The reason that I expected that my data had more decimals, was
> that I loaded the file in Globalmapper and this is what the feature
> information for a point shows, 10 decimals for lat/Lon:
>
> Point location: 129.4167329872 -15.8289120353 (Lat/Lon: 15° 49' 44.0833" S, 129° 25' 0.2388" E)

[...]

> Maybe Globalmapper doesn't show the actual point information?
> This data was generated using Globalmapper, but the header of the LAS file still shows Terrascan.

I had noticed before that the LAS output of Globalmapper is not
optimal because is can result in miss-understandings in terms of the
precision of the file. I had even offered my services to rectify that
but that was not followed up at the time. So let me explain here the
reason why you are seeing 10 decimal digital of which the last three
are sense-less).

The LAS header of the Globalmapper generated LAS files contains these
scale and offset values (as can be seen in the lasinfo output that are
again at the end of the email)

scale factor x y z: 1e-007 1e-007 0.001
offset x y z: 129.41673208719459 -15.833613035278834 0

each double-precision LAS point's coordinate is computed based on the
following formula from the integers stored in the LAS file:

x = scale_factor_x * X + offset_x
y = scale_factor_y * Y + offset_y
z = scale_factor_z * Z + offset_z

so you will find that the particular formula for this file is

x = 0.0000001 * X + 129.41673208719459
y = 0.0000001 * Y + -15.833613035278834
z = 0.001 * Z + 0

because Globalmapper stores such "weird" offsets your points are
reported to all have many more precision digits than they actually
have because those "extra digits" are all the same digits. If you look
more careful you shall find that all of your 10 digit x coordinates
end in xxx.xxxxxxx872 and that all your 10 digit y coordinates end in
xxx.xxxxxxx353.

hence, globalmapper has essentially shifted your data set that really
only has 7 digits of precision stored in the LAS file by
0.00000008719459 in x direction and in 0.000000035278834 in y
direction.

cheers,

martin @lastools

Veldman, Edgar

unread,
Apr 19, 2012, 7:49:55 PM4/19/12
to last...@googlegroups.com
Hi Martin,

You are right, all the decimals end with the same pattern, so 7 decimals seems to be all I'm actually getting.
Thanks for the explanation.

Edgar

-----Original Message-----
From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Martin Isenburg

Hello Edgar,

[...]

cheers,

martin @lastools

--

Terje Mathisen

unread,
Apr 20, 2012, 3:01:33 AM4/20/12
to last...@googlegroups.com
Veldman, Edgar wrote:
> Hi Martin,
>
> You are right, all the decimals end with the same pattern, so 7 decimals seems to be all I'm actually getting.

Not only is 7 decimals what you have, it is almost certainly a (little)
bit more than required:

In the north-south direction degrees with 7 decimals correspond to 1.11
cm, while the east-west granularity is a bit less (depending upon how
far you are from equator).

Anyway, unless you manage to get some magical means to locate each LIDAR
hit with mm precision, a cm-level location is sufficient. :-)

(Sub-cm precision would be far more likely (and useful) for a land-based
static survey of a small area or structure. Getting useful information
in 10 decimals would correspond to 10um precision.:-) )

Terje


--
- <Terje.M...@tmsw.no>
"almost all programming can be viewed as an exercise in caching"

chuck

unread,
Apr 20, 2012, 3:54:44 AM4/20/12
to LAStools - efficient tools for LiDAR processing
Hi Folks,

Is it typical to also see the same repeating 3 digits at the end of
the
GPS time stamp per each data pulse? I have been looking closely
at some data sets recently and have noted this, but am not sure if
it is specific to certain hardware and strip calibration software
sets.

Regards - Chuck
> - <Terje.Mathi...@tmsw.no>
Reply all
Reply to author
Forward
0 new messages