setting (correcting) the global_encoding bit from zero to one

[bruce.s...@gmail.com]

Hi folks,

 

I've built a merged LAS file (1.2), which spans multiple gps weeks.  However, the gpstime (returned by "t") is definitely the POSIX version of time (thankfully!).  I am surprised, though, that during the workflow, the value of global_encoding has been set to 0. 

 

Is there a way I flip this to 1 (one), in the header, without doing anything else to the file?

 

Here's part of the lasinfo output (which includes a warning about GPS week time, and inconsistent global encoding bit:

 

lasinfo for XX_minus_delta_as_z.las
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             0
  global_encoding:            0
  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000
  version major.minor:        1.2
  system identifier:          'LAStools (c) by rapidlasso GmbH'
  generating software:        'lasmerge (version 140615)'
  file creation day/year:     23/2015
...

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

  gps_time 52088466.524952 53710718.574792
WARNING: range violates GPS week time specified by global encoding bit 0
...

 

and here are some sample records, returned by las2txt -parse txyz xx_minus_delta_as_z.las -stdout:

 

...

52088476.085221 2487992.50 2389522.35 0.31
52088476.085230 2487990.66 2389520.28 0.08
52088476.085240 2487988.82 2389518.25 0.34
52088476.085259 2487985.08 2389514.18 0.54
52088476.085278 2487981.44 2389510.08 0.28
52088476.085307 2487975.86 2389503.95 0.38
52088476.085317 2487974.02 2389501.91 0.51
52088476.092991 2487972.51 2389502.40 0.54

...

 

Clearly, these aren't GPS seconds from a GPS week.  Is there a way I can tweak the global_encoding flag in this file, to 1, so I can move on with my workflow?

 

Got to say, great software.

 

-Bruce

[Martin Isenburg]

Hello,

Lucky you. GPS week time stamped points are a horrible curse for multi-week, -month, or -year LiDAR projects. I strongly advise folks to check whether their GPS time stamps fall outside the range from 0.0 seconds to 7×24×60×60 = 608,000.0 seconds. Otherwise you may not be able to recover flightline information, for example, which is quite crucial for QC & QA.

However, the time stamps you are seeing are most likely not POSIX time but Adjusted Standard GPS time. That simply means Standard GPS time minus one billion seconds. You can set the global encoding bit mask with lasinfo using the '-set_global_encoding 1' option or run lasinfo via the GUI to see the corresponding menu item.

Folks ... do not use GPS week time stamps!!!

Martin

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

[Heidemann, Hans]

As an addendum to Martin's note,

USGS specifications require Adjusted GPS Time and correct setting of the Global Encoding Bit for Time Type (Set, 1). Although most projects received use Adjusted GPS Time, a large number do not have the Global Encoding Bit for Time Time set correctly.

I concur with Martin that GPS Week Time is in general a poor time coding option and encourage all data producers to use Adjusted GPS Time for all projects, AND to ensure that the Time Type Bit is properly set.

Karl

H. Karl Heidemann, GISP

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57110

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

[Martin Isenburg]

Hello,

again and again I see "GPS week time stamp". I advise you to fix them now so you don't pull out your hair three or four years from now. How to fix this? Look up the GPS week in which the flight was done, like for example 1762. Use las2las with option '-week_to_adjusted 1762' to fix the time stamp. More detail in this thread here:

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

Martin

[Heidemann, Hans]

Thank you Martin, for again noting this widespread non-compliance with the LAS Specification.

Data producers should bring this matter to the attention of their software developers (internal and COTS) and their instrument manufacturers, to ensure that this flag is initially set correctly and remains so, from pre-processing through delivery.

Karl

H. Karl Heidemann, GISP

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57110

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour

[Heidemann, Hans]

Clarification:
1)  The LAS non-compliance we commonly see is LAS files that have Adjusted GPS Times recorded, but are coded for GPS Week Time in the header.

2)  A non-compliance with the USGS-NGP Lidar Base Spec that is occasionally still seen is LAS files with GPS Week Times.

Karl

H. Karl Heidemann, GISP

Physical Scientist, Lidar Science

U.S. Geological Survey

Mundt Federal Building

47914 252nd Street

Sioux Falls, SD  57110

605-594-2861

kheid...@usgs.gov

"Nothing matters very much, and very few things ... matter at all."

- Arthur James Balfour