LAS 1.4 is slowly loosing GPS time resolution ...
Martin Isenburg
we are now in GPS week 1672, second of week 305118 and counting [1].
The total number of seconds that have passed is 1,011,530,718. In LAS
1.4 we are to subtract 1 billion from this number - which leaves
11,530,718 - and store it as a double-precision float. How much GPS
time precision will be stored?
Because the number 11,530,718 falls into the range between 2^23
(8,388,608) and 2^24 (16,777,216) the 51 mantissa bits cover the range
of 8,388,608 in increments of 3.72529 nanoseconds. This is until the
1st of May 2012. Then the GPS time passes16,777,216 and we loose one
bit of resolution. Then the minimal increment will be 7.450580597
nanoseconds. And on the 11th in November 2012 we will loose another
bit. And on the 12th of May in November 2013 again. And on the 20th
January of 2016 again, etc. Here the complete list of resolution loss
dates and corresponding nanosecond increments:
3.73 nsec - current resolution of LAS 1.2/1.3/1.4 in Adjusted Standard GPS time
down to 7.45 nsec - starting 5/1/2012
down to 14.90 nsec - starting 11/11/2012
down to 29.80 nsec - starting 12/5/2013
down to 59.60 nsec - starting 1/20/2016
down to 119.21 nsec - starting 4/22/2020
down to 238.42 nsec - starting 10/24/2028
down to 476.84 nsec - starting 10/28/2045
while the sensors shown at each ILMF/ELMF seem to increase in
resolution, the LAS 1.4 format we just decided on will systematically
loose resolution in the coming month and years. will this be a
problem? i am not sure but i would say "yes". can someone comment on
this? i would really like especially the hardware and system vendors
(leica/riegl/optech/ahab/toposys/MDL/Fugro/...) to express their
opinion here.
cheers,
martin @lastools
ps: there is an easy fix if we are quick (there is no LAS 1.4 content
yet). by allowing the Adjusted GPS time to be expressed scaled to
nanoseconds and by storing the number of nanoseconds using a 64 bit
integer we are good for several hundred years with a fixed resolution
of exactly 1 nanosecond ...
Martin Isenburg
On Thu, Jan 26, 2012 at 5:30 AM, JeeWee <jwi...@jchance.com> wrote:
> hi Martin, I'm impressed with how detailed and quickly you calculated
> all that. And I think you are right 64-bit integers are more precise,
> so it is better to implement those. (Maybe some calculations could be
> somewhat "cheaper", also). It doesn't however sound really alarming to
> loose 447 nanoseconds of precision, exchanging by LAS 30 years ahead
> from now, as our system nowadays has a millisecond of precision. (I
> know that the hardware will increase precision, and that also for
> example in the days of MS-DOS they thought "way, way enough, support
> for 1 MB RAM"). regards, Jan Willem de Pater
thanks for this information. maybe someone else can weigh in on that?
i think what you are referring to is the time resolution of the GPS
sensors themselves. while may have only millisecond precision it does
get interpolated with the scanner's pulse shot frequency and that is
now at up to 400,000 / second and likely (?!?) to be rising with
multiple-pulses-in-air technology. At 400,000 / second (where we are
today) you need a gps-time resolution of 0.0000025 secs or 0.0025
milliseconds or 2.5 microseconds or 2500 nanoseconds to uniquely
identify each pulse in the delivered product (aka the LAS file).
Below are the sample GPS-times and the differences to the previous
GPS-time (aka spacings) for single returns from the "fusa.laz" file
that is part of the lastools.zip distribution. You can see it uses
spacings as close as 4 microseconds or 4000 nanoseconds. We have
already lost the resolution that would have allowed us specify the
location of single returns "on the pulse" (which we we would have with
the 1 ns resolution that a 64 bit nanosecond counter would give us).
Not sure how much technology will advance in terms of temporal pulse
spacing but - in my opinion - our "resolution cushion" with
double-precision floats is not as "comfy" as one may think ...
Anyone know hat pulse shot rates we may be looking at in 2 - 5 years?
regards,
martin @lastools
las2txt -i ..\data\fusa.laz -parse t# -single_only -stdout | more
5880.9630319999997 5880.9630319999997
5880.9780469999996 0.015014999999948
5880.9780520000004 0.000005000000783
5880.9780920000003 0.000039999999899
5880.9780970000002 0.000004999999874
5880.9781030000004 0.000006000000212
5880.9781080000002 0.000004999999874
5880.9781130000001 0.000004999999874
5880.9781169999997 0.000003999999535
5880.9781220000004 0.000005000000783
5880.9781270000003 0.000004999999874
5880.9781320000002 0.000004999999874