clarification on the GPS time stored in LAS files and the gps_time range reported by lasinfo

[Martin Isenburg]

Hello,

I just got the following note:

"While testing lasinfo, I noticed two bugs in the gps_time range it reported. 

lasinfo reported:

gps_time 174893536.000000 174895488.000000

Which translates to these timestamps:

Jul 22, 1985 05:32:12 UTC

Jul 22, 1985 06:04:44 UTC

 

However, the correct GPS time range is:

gps_time 1174893536.000000 1174895488.000000

Which translates to these correct timestamps:

Mar 30, 2017 07:51:10 UTC

Mar 30, 2017 07:18:38 UTC

Notice that the leading “1” is missing in the lasinfo reported gps_time range."

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

What's going on? The LAS format stores in the "gps time" field the moment that the laser pulse was fired for all the returns it generates. The GPS time can be stored in one of two ways:

(1) GPS time of the week is a number between 0 and 3600*24*7 that expresses the number of seconds that have passed since the last Sunday night of the week in the moment that the pulse was shot.

(2) Adjusted Standard GPS time is a number that continuously increases that expresses the number of seconds that have passed since the beginning of GPS time (some date in 1971) in the moment that the pulse was shot *MINUS* one bilion seconds (i.e. the 'adjusted' part).

lasinfo simply reports the actual values stored. It does not map the range to the Standard GPS time. That would be trivial for the second representation (add one billion before printing the value but - a little warning - you will loose time stamp resolution if you simply add one billion to the 64 bit floating point Adjusted Standard GPS time stamps). But that would be impossible for the first representation as the GPS week is not stored with each point.

Regards.

Martin @rapidlasso

 

[Terje Mathisen]

Martin, you are of course (as usual :-) ) correct when you state that
all time stamps should use the Adjusted Standard GPS time instead of
time of week, but I still think lasinfo has a bug when it reports that
number as if the "Adjusted" part could be omitted!

I.e. lasinfo should definitely add 1e9 to the number of seconds before
converting to YMD HMS representation.

Re. your claim about losing resolution:

When a timestamp is stored as a FP number, the specification is
seriously messed up IMHO. :-(

I've been working in the NTP Hackers team for many years and that
protocol always uses fixed-point format for all timestamps specifically
to avoid steps in the resolution as the integer field gets larger. As
you note a double with 53-bit mantissa and an integer (seconds) part
between 1 and 2G would require 31 bits for the seconds leaving just 22
fractional bits. The latter would correspond to a resolution of ~250 ns
which would be marginal for pulse timestamps so the "Adjusted" bias is
required.

For Adj GPS timestamps the easiest way to decode it would be something
like this:

int64_t seconds = (int64_t) agpstime;
agpstime -= (double) seconds;
int32_t nanoseconds = (int32_t) (agpstime * 1.0e9);
seconds += ADJGPSBIAS; // 1E9
seconds += TAI_to_UTC_offset(seconds);

Terje

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


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

[Martin Isenburg]

Hello,

Tom, which of the two formats for specifying a GPS time stamp is used does in general not need to be "guessed" by a formula but is specified by a bit in the "global encoding" bit-field in the LAS header. However, a more robust software implementation may use a formula to "guess" that the time stamp is in “Adjusted Standard GPS time” by simply checking whether they fall outside of the GPS week range of [0, 604800) and that would be correct for all but that one week in September 2011 when then  “Adjusted Standard GPS time” had its zero crossing.

Terje, I would not say that lasinfo has a bug. It simply reports the min / max values stored in the different attribute fields of all point records without interpreting them. Note also that the extended scan angle is not scaled by 0.006. And also that the reported X, Y, and Z integer coordinates are not scaled and offset using the information from the header. It simply reports what values are stored. Also lasinfo does not report the GPS time range converted to a YMD HMS representation (maybe it should in a future version), so also there is no bug.

[...]

reporting minimum and maximum for all LAS point record entries ...

  X           -49999500   49999499

  Y           -49999500   49999500

  Z            -1534499    1534500

  intensity           0      65535

  return_number       1          1

  number_of_returns   1          1

  edge_of_flight_line 0          0

  scan_direction_flag 0          0

  classification      0          7

  scan_angle_rank    15         15

  user_data           0          0

  point_source_ID     0          0

  gps_time 174893536.000000 174895488.000000

  extended_return_number          1      1

  extended_number_of_returns      1      1

  extended_classification         1     81

  extended_scan_angle          2500   2500

  extended_scanner_channel        0      0

[...]

Regards,

Martin @rapidlasso

[Terje Mathisen]

Martin Isenburg wrote:
> Terje, I would not say that lasinfo has a bug. It simply reports the
> min / max values stored in the different attribute fields of all point
> records without interpreting them. Note also that the extended scan
> angle is not scaled by 0.006. And also that the reported X, Y, and Z
> integer coordinates are not scaled and offset using the information
> from the header. It simply reports what values are stored. Also
> lasinfo does not report the GPS time range converted to a YMD HMS
> representation (maybe it should in a future version), so also there is
> no bug.

Oops, me and my big mouth. Mea Culpa!

I should have remembered that, I just saw the message with translated
(typically using the localtime()/gmtime() call?) timestamp and forgot
that lasinfo doesn't do that. That does make your code correct of course.

OTOH I do think it would be a good idea to also translate any agpstime
to ascii since it would provide another often needed sanity check. I
know that I personally would love such a feature when I'm looking a new
lidar scans here in Norway where a single small area can get laz blocks
from up to 5 or 6 different projects.

Terje