please use Adjusted Standard GPS time stamps

[Martin Isenburg]

Folks!

When you produce ‪LiDAR‬, please make sure to export it to LAS/LAZ with Adjusted Standard GPS time stamps. Do *not* use GPS seconds of the week because this clock resets to zero each Sunday morning. I do not know any reason to use a number which is always between 0 and 604800 and does not tell you when the LiDAR return was collected. Below a nice blog entry by NOAA Digital Coast on what you can do if your #LiDAR has Adjusted Standard GPS time stamps.

http://csc.noaa.gov/digitalcoast/geozone/mapping-lidar

Also ... did you know that you can go from second of week to adjusted standard GPS time stamps when you know the actual week (and back) with las2las? Below an example. How are the weeks counted? We are right now in week 1778. Look up any week on this calendar: http://leapsecond.com/java/gpscal.htm So if you remember which day which survey was flown you can "fix" all your less useful GPS second of week times into more useful adjusted standard GPS time 

D:\lastools\bin>lasinfo -i fusa.laz
[...]
  gps_time 5880.963028 5886.739738

---------------------------
D:\lastools\bin>las2las -i fusa.laz -week_to_adjusted 1671 -o fusa_adjusted.laz
D:\lastools\bin>lasinfo -i fusa_adjusted.laz
[...]
  gps_time 10626680.963028 10626686.739738
---------------------------
D:\lastools\bin>las2las -i fusa_adjusted.laz -adjusted_to_week -o fusa_week.laz
D:\lastools\bin>lasinfo -i fusa.laz
[...]
  gps_time 5880.963028 5886.739738

Cheers,

Martin @rapidlasso

[Yan Wang]

Hi Martin,

This method works well (http://csc.noaa.gov/digitalcoast/geozone/mapping-lidar). But there is a problem that different images turns out the same date.
I used different study areas for testing ( which means different flight date for lidar). However, those different study areas got the same flight date, which is 2011-09-13.
I can't figure it out where goes wrong. Could you give me some suggestions?
Thanks!

Yan

[Kirk Waters - NOAA Federal]

Yan,

Could you send me samples of the two study areas so I can take a closer look? Any idea what the flight dates were? It looks like the right code was posted, so that wasn't it.

Regards,

Kirk

On Thu, Feb 6, 2014 at 11:30 AM, Kirk Waters - NOAA Federal <kirk....@noaa.gov> wrote:

Yan,

Let me check something out. That date looks familiar. I remember I had a typo in the python script at one point such that it grabbed the x value instead of the time (index 0 instead of index 2). Always possible the wrong thing got posted.

Kirk

--

Kirk Waters, PhD                     | NOAA Coastal Services Center

Applied Sciences Program       | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    

www.csc.noaa.gov/digitalcoast

On Thu, Feb 6, 2014 at 11:20 AM, Yan Wang <wang...@umn.edu> wrote:

Hi Martin,

This method works well (http://csc.noaa.gov/digitalcoast/geozone/mapping-lidar). But there is a problem that different images turns out the same date.
I used different study areas for testing ( which means different flight date for lidar). However, those different study areas got the same flight date, which is 2011-09-13.
I can't figure it out where goes wrong. Could you give me some suggestions?
Thanks!

Yan

On Wednesday, February 5, 2014 8:57:31 AM UTC-6, Martin Isenburg wrote:

Folks!

When you produce LiDAR, please make sure to export it to LAS/LAZ with Adjusted Standard GPS time stamps. Do *not* use GPS seconds of the week because this clock resets to zero each Sunday morning. I do not know any reason to use a number which is always between 0 and 604800 and does not tell you when the LiDAR return was collected. Below a nice blog entry by NOAA Digital Coast on what you can do if your #LiDAR has Adjusted Standard GPS time stamps.

http://csc.noaa.gov/digitalcoast/geozone/mapping-lidar

Also ... did you know that you can go from second of week to adjusted standard GPS time stamps when you know the actual week (and back) with las2las? Below an example. How are the weeks counted? We are right now in week 1778. Look up any week on this calendar: http://leapsecond.com/java/gpscal.htm So if you remember which day which survey was flown you can "fix" all your less useful GPS second of week times into more useful adjusted standard GPS time 

D:\lastools\bin>lasinfo -i fusa.laz
[...]
  gps_time 5880.963028 5886.739738

---------------------------
D:\lastools\bin>las2las -i fusa.laz -week_to_adjusted 1671 -o fusa_adjusted.laz
D:\lastools\bin>lasinfo -i fusa_adjusted.laz
[...]
  gps_time 10626680.963028 10626686.739738
---------------------------
D:\lastools\bin>las2las -i fusa_adjusted.laz -adjusted_to_week -o fusa_week.laz
D:\lastools\bin>lasinfo -i fusa.laz
[...]
  gps_time 5880.963028 5886.739738

Cheers,

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,

between GPS weeks 1653 and 1654 the Adjusted GPS Standard time (which
is simply GPS Standard time - one billion seconds) made its zero
crossing going from a negative to a positive number. The GPS time
stamps happened to be stored particularly precise during this time.
(-; Insider joke about why it is a bad idea to store time stamps with
a floating-point representation
(https://groups.google.com/d/topic/lasroom/pP8Z6mKP2Aw/discussion).
Would be a timely co-incidence if it had nothing to do with the zero
crossing.

Regards,

Martin @rapidlasso

lasinfo -i ..\data\fusa.laz -stdout | grep gps_time
gps_time 5880.963028 5886.739738

==============

las2las -i ..\data\fusa.laz -o fusa_adjusted.laz -week_to_adjusted 1652
lasinfo -i fusa_adjusted.laz -stdout | grep gps_time
gps_time -864519.036972 -864513.260262

las2las -i ..\data\fusa.laz -o fusa_adjusted.laz -week_to_adjusted 1653
lasinfo -i fusa_adjusted.laz -stdout | grep gps_time
gps_time -259719.036972 -259713.260262

las2las -i ..\data\fusa.laz -o fusa_adjusted.laz -week_to_adjusted 1654
lasinfo -i fusa_adjusted.laz -stdout | grep gps_time
gps_time 345080.963028 345086.739738

las2las -i ..\data\fusa.laz -o fusa_adjusted.laz -week_to_adjusted 1655
lasinfo -i fusa_adjusted.laz -stdout | grep gps_time
gps_time 949880.963028 949886.739738

On Thu, Feb 6, 2014 at 5:34 PM, Kirk Waters - NOAA Federal

[Kirk Waters - NOAA Federal]

That's a good point that there is a week of time where the adjusted GPS time has values that could look like seconds of the week. I think this is actually the problem Yan ran into. His data is likely in seconds of the week and when you assume those values are adjusted GPS seconds, you get a date in the middle of September, 2011. If you can figure out the real week for the data, you can fix your data as Martin suggests.

Kirk Waters, PhD                     | NOAA Coastal Services Center

Applied Sciences Program       | 2234 South Hobson Ave
843-740-1227                          | Charleston, SC 29405    

www.csc.noaa.gov/digitalcoast

[Yan Wang]

Hi Kirk,

I've just shared with you the two study area samples by Google Drive.
About the flight date, I can only know that one is spring ,2010, the other is fall 2012.
If in this way, I can't run this python script to get specific flight date of this LiDAR data, right?
Thanks

Yan

[Kirk Waters]

I checked the files Yan sent me. The 2012 one gave the 2012 dates as it should have. The 2010 one was in GPS seconds of the week, so it gave a September 2011 date when it was run through the conversion. Both were correctly encoded (the 2012 one had global encoding=1, thus was adjusted GPS seconds, the 2010 one had global encoding=0, thus was GPS seconds of the week). I suspect people trying to fix data that is in GPS seconds of the week would like something that would convert a date to the GPS week so they could apply Martin's adjustment in las2las. Looks like there is a calendar online at http://adn.agi.com/GNSSWeb/ that would do that.

Kirk