LAS tools, lasinfo bug

[Alex Yeryomin]

Hi Martin.

We found that lasinfo.exe tool from Lastools prints some suspicious
values for gps_time on LAS files generated by our software like

gps_time -81983019.975991 -81982894.749952

However, we believe that our software has no bugs regarding that, since
it writes GPS times in Adjusted Standard GPS Time format (see "Table 4.4
- Global Encoding" of LAS 1.3 specification). It seems we observe such a
strange values because lastools (of 10 December 2011) does not pay
attention to "GPS Time Type" flag of "Global Encoding" value written in
the LAS file header. lastools just prints the time values as "GPS Week
Time".

Could you please check that?

Regards,

Alex

[Martin Isenburg]

Hello,

> We found that lasinfo.exe tool from Lastools prints some suspicious
> values for gps_time on LAS files generated by our software like
>
> gps_time -81983019.975991 -81982894.749952

This is to be expected as lasinfo reports the min/max value of every
field at that point. To get to the Adjusted Standard GPS Time you
would have to add "1,000,000,000". But then ... which data type do
you want to do this operation with? If you do it with a 64-bit float
arithmetic you will loose precision. The problem is that the LAS
format uses 64 bit double-precision floats to represent the GPS time
which was a seriously stupid idea and the reason that we suddenly need
the "Adjusted Standard GPS Time". We really should have fixed that in
LAS 1.4 ... )-:

I have just started a discussion on that in "the LAS room".

http://groups.google.com/group/lasroom/browse_thread/thread/b37f8e4782cfd481

I think that the correct thing to do would be to scale the negative
GPS_time with 1,000 (or 10,000), store the quantized result as a 64
bit integer which will preserve increments of 1000 picoseconds (or 100
picoseconds), then add the offset of 1,000,000,000 also scaled by
1,000 (or 10,000), and store the result as an unsigned 64-bit integer.
Here an example with different precisions for -81983019.975991 after
scaling, quantizing, and offsetting as described:

precision 1000 picoseconds:
918,016,980,024
precision 100 picoseconds:
9,180,169,800,240
precision 10 picoseconds:
91,801,698,002,401
precision 1 picoseconds:
918,016,980,024,009

an unsigned 64 bit allows to store numbers up to 2^64 =
18,446,744,073,709,551,616 which means - even at resolution of 1
picosecond - the counter would last for 18,446,744,073,709 seconds.
That means we could have gone 584,542 years before we would have
needed an "adjustment" bit.

Cheers,

Martin @lastools

[Alex Yeryomin]

Hi.

>This is to be expected as lasinfo reports the min/max value of every
> field at that point.

Ok, no problem with lasinfo as it just prints out raw field values, but
las2txt.exe does not pay attention to this gps time bit anyway. I don't
care how to calculate GPS time, I point only that clients converting LAS
files with such bit by las2txt.exe might have a problem.

> We really should have fixed that in LAS 1.4 ... )-:
>I have just started a discussion on that in "the LAS room".

Thanks.

Bye,

Alex

[Martin Isenburg]

Hello Alex (and all),

> Ok, no problem with lasinfo as it just prints out raw field values, but
> las2txt.exe does not pay attention to this gps time bit anyway. I don't
> care how to calculate GPS time, I point only that clients converting LAS
> files with such bit by las2txt.exe might have a problem.

But what number should 'las2txt.exe -i in.las -o out.txt -parse xyzt'
output as the GPS time when the bit is set? If it outputs the number
918016980.024009 into the string then how would you parse this back
into a variable? You could not use atof() or scanf("%lf") because if
you scan the number into a double you loose precision. So should
'las2txt.exe -i in.las -o out.txt -parse xyzt' maybe output a 64 bit
integer 918,016,980,024,009 that represents the GPS time as pico
seconds? That would make it possible to parse with scanf("%I64d")
without any precision loss.

Any other las2txt user having a comments on this? What behavior do you
like to see?

Cheers,

Martin

PS: As more people realize that they need to set the "adjusted bit"
this will cause more and more problems, either because they do not set
it or because they set it and then have trouble computing the actual
GPS-time without precision loss. I think we should really ask for this
to be amended in LAS 1.4 by allowing the GPS_time field to also be a
64 bit int that reports the time since 1980 in picoseconds ...