txt2las: Wrong number of returns and return index in case of 8 returns?

[Alex Yeryomin]

Hello.

I have processed a line collected by Optech Galaxy, which can record up to 8 discrete returns per pulse. Optech LMS reports after decoding that the line contains a lot of shots with 8 returns. lasinfo shows 8 returns for LAS 1.4 file as well. However, when I convert the LAS 1.4 file into text, there are no 8-returns at all. These shots have wrong number of returns and return index, for example:

407647.688912 7 1 669611.21 4867850.91 127.41

407647.688912 7 2 669610.97 4867850.92 126.08

407647.688912 7 3 669610.72 4867850.92 124.68

407647.688912 7 4 669610.50 4867850.93 123.47

407647.688912 7 5 669610.11 4867850.93 121.27

407647.688912 7 6 669609.09 4867850.95 115.61

407647.688912 7 6 669608.31 4867850.96 111.23 

407647.688912 7 6 669607.70 4867850.97 107.84

The same if I convert from a text file with a shot, which contains 8 returns. For example, LMS outputs a shot with 8 returns into txt file:

# GPS Time, Number of returns, Return index, X, Y, Z

 407647.688912 8 1   669611.207  4867850.914  127.413

 407647.688912 8 2   669610.967  4867850.918  126.080

 407647.688912 8 3   669610.717  4867850.922  124.681

 407647.688912 8 4   669610.501  4867850.926  123.472

 407647.688912 8 5   669610.106  4867850.932  121.265

 407647.688912 8 6   669609.093  4867850.949  115.613

 407647.688912 8 7   669608.308  4867850.962  111.227

 407647.688912 8 8   669607.703  4867850.972  107.842

Save these lines into "8returns.txt" and run the next command:

> txt2las -parse tnrxyz 8returns.txt -o 8returns.las -set_version 1.4

WARNING: return number 8 is out of range of three bits

WARNING: return number 8 is out of range of three bits

WARNING: written 8 points but expected 0 points

> las2txt -parse tnrxyz 8returns.las -o 8returns_2.txt

407647.688912 7 1 669611.21 4867850.91 127.41

407647.688912 7 2 669610.97 4867850.92 126.08

407647.688912 7 3 669610.72 4867850.92 124.68

407647.688912 7 4 669610.50 4867850.93 123.47

407647.688912 7 5 669610.11 4867850.93 121.27

407647.688912 7 6 669609.09 4867850.95 115.61

407647.688912 7 7 669608.31 4867850.96 111.23

407647.688912 0 0 669607.70 4867850.97 107.84

Why does txt2las complain about 3 bits limit as LAS 1.4 is specified?

Regards,

Alex

[Martin Isenburg]

Hello,

Simple answer: These two "ASCII text conversion" tools have not yet been upgraded to work with the new LAS 1.4 point types. As the tools are open source you could go and fix that yourself. Even better: post a link to a small sample of your Optech Galaxy LAS 1.4 output somewhere and I use the opportunity to upgrade these tools as soon as possible.

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

[Martin Isenburg]

Hello Alex,

why is your example using GPS week time? Is this the LMS default? I hope not. Noone should use GPS week time. Seems to a remnant from the days when folks could only afford a single LiDAR scan a year. But especially for larger multi-week, multi-month, or even multi-year project the use of GPS week time (numbers between 0 and 604800) is a horrible idea. Please - everbody - use Adjusted Standard GPS time. Please - Leica, Optech, RIEGL, Trimble, .. -please make Adjusted Standard GPS time the default export option. Here some threads on the topic.

http://groups.google.com/d/topic/lastools/H7AGxYaoJ7g/discussion

http://groups.google.com/d/topic/lastools/Er8mrD2ma7g/discussion

http://groups.google.com/d/topic/lastools/dU8CWeVrhNE/discussion

http://groups.google.com/d/topic/lastools/zYlXNRbwXIk/discussion

The latest version of las2txt (version should be able to handle LAS 1.4 files correctly (with higher return counts and numbers, higher scan angle precision, and more classifications). Unfortunately RIEGL seems to be also defaulting to GPS week time if the provided sample data is any indication. People!!!

las2txt -version

LAStools (by mar...@rapidlasso.com) version 150330

las2txt -i Q680i_las14.las -parse tnrca -stdout | more

387312.840148 2 2 4 24

387312.840151 1 1 4 24

387312.840153 1 1 4 24

387312.840156 1 1 4 24

387312.840158 1 1 4 24

387312.840161 1 1 4 24

387312.840163 1 1 4 24

387312.840166 1 1 4 25.002

387312.846229 1 1 4 24

387312.846232 1 1 4 24

387312.846235 1 1 4 24

387312.846237 1 1 4 24

387312.846240 1 1 4 24

387312.846243 1 1 4 24

387312.846245 1 1 4 24

387312.846248 1 1 4 25.002

387312.846250 1 1 4 25.002

[...]

Martin @rapidlasso

[Alex Yeryomin]

Hi, Martin.

I just ran txt2las -parse tnrxyz 8.txt -o 8.las -set_version 1.4 for the text file with 8 returns (see above), but unfortunately it still complains:

LAStools (by mar...@rapidlasso.com) version 150330

WARNING: return number 8 is out of range of three bits

...

As for GPS time, yes, GPS week time is by default in LMS. I agree with your opinion, Martin, but it seems most of users do not like to have the absolute time in LAS files, and we were requested to switch to GPS week by default (initially, the absolute time was by default). However, the user can always overwrite default settings for new projects. It can be done once, and then all new projects will inherit the new defaults. When I need to analyze LAS files using las2txt or txt2las, I can easily specify 2 options to deal with the absolute time (-adjusted_to_week and -week_to_adjusted), but maybe it causes some issues for other users in their workflow. 

Regards,

Alex