Help interpreting GPS Tim

[d weasson]

OK, I'm an amateur here, and my searching for an answer has been unsuccessful.  I'm hoping someone can help me interpret the lasinfo's GPS time.

A sample record is at the bottom of this post, and here is how I interpreted it so far:

version major minor 1.2 means LAS specification version 1.2.

according to those standards 

global_encoding 0 means GPS Week Time

file creation day/year 174/2010 means June 23, 2010, which was a Wednesday.

gps_time 334368.065945 336746.871043 means...hmmmm....

I found this conversion for GPS Week time to time:

GPS Time of Week to Day of Week with Time of Day

The value given for GPS Time of Week represents the number of seconds into the week. Therefore, to determine the day and time from that value, calculations are performed to break down the number of seconds into day, hour, minute, and second values.

( https://www.novatel.com/support/knowledge-and-learning/published-papers-and-documents/unit-conversions/ )

Example:  511200                               511200           334368.065945       336746.871043

Day 511200 / 86400 seconds per day              5.916667 days    3.870000763 days    3.89753323 days

Hour 0.916667 x 86400 / 3600 seconds per hour  22.000000 hours  20.880018320 hours  21.54079751 hours

Minute 0.000 x 3600 / 60 seconds per minute     0.000000 mins   52.801099080 mins   32.44785072 mins

Second 0.000 x 60 seconds per minute            0.000000 secs   48.065945000 secs   26.87104300 secs

                                               Th 10:00:00pm    Tu 8:52:48pm        Tu 9:32:27pm

So, right off the bat there is a Tuesday (Day 3) vs Wednesday (Day 174/2010) issue.

So... maybe the GPS time is the actual seconds within a day? 

                                                                334368.065945       336746.871043

GPS time / 86400 seconds per day                                 3.870000763 hours   3.89753323 hours

Minutes remainder * 24 hours                                    20.880018320 mins   21.54079751 mins

Seconds remainder * 60 seconds                                  52.801099080 secs   32.44785072 secs

                                             Wed June 23, 2010     3:20:53am          3:21:32am

So, are either of those computations correct?  And if not, what is the correct computation?

At a more basic level, is the time stamp the time of the FLIGHT, or the time of the PROCESSING of the file.  Basically, I need the former, not the latter!

Any help would be appreciated.  Thanks, Darlene

Here is the output from the lasinfo:

lasinfo (170828) report for D:\...\a1.las

reporting all LAS header entries:

  file signature:             'LASF'

  file source ID:             0

  global_encoding:            0

  project ID GUID data 1-4:   2364A7A9-A882-4FFD-4193-A44E48D7280E

  version major.minor:        1.2

  system identifier:          'NIIRS10'

  generating software:        'GeoCue GeoCoder'

  file creation day/year:     174/2010

  header size:                227

  offset to point data:       830

  number var. length records: 4

  point data format:          1

  point data record length:   28

  number of point records:    7238701

  number of points by return: 5681927 1378521 173893 4360 0

  scale factor x y z:         0.01 0.01 0.01

  offset x y z:               0 0 0

  min x y z:                  2420000.00 1737500.00 213.04

  max x y z:                  2424999.99 1742499.99 1704.09

variable length header record 1 of 4:

  reserved             43707

  user ID              'LASF_Projection'

  record ID            34735

  length after header  192

  description          'GeoTiff Projection Keys'

    GeoKeyDirectoryTag version 1.1.0 number of keys 23

      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected

      key 2048 tiff_tag_location 0 count 1 value_offset 4269 - GeographicTypeGeoKey: GCS_NAD83

      key 2049 tiff_tag_location 34737 count 24 value_offset 76 - GeogCitationGeoKey: GCS_North_American_1983

      key 2050 tiff_tag_location 0 count 1 value_offset 6269 - GeogGeodeticDatumGeoKey: Datum_North_American_Datum_1983

      key 2051 tiff_tag_location 0 count 1 value_offset 8901 - GeogPrimeMeridianGeoKey: PM_Greenwich

      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree

      key 2055 tiff_tag_location 34736 count 1 value_offset 9 - GeogAngularUnitSizeGeoKey: 0.01745329252

      key 2056 tiff_tag_location 0 count 1 value_offset 7019 - GeogEllipsoidGeoKey: Ellipse_GRS_1980

      key 2057 tiff_tag_location 34736 count 1 value_offset 6 - GeogSemiMajorAxisGeoKey: 6378137

      key 2059 tiff_tag_location 34736 count 1 value_offset 7 - GeogInvFlatteningGeoKey: 298.2572221

      key 2061 tiff_tag_location 34736 count 1 value_offset 8 - GeogPrimeMeridianLongGeoKey: 0

      key 3072 tiff_tag_location 0 count 1 value_offset 26995 - ProjectedCSTypeGeoKey: NAD83 / Mississippi West

      key 3073 tiff_tag_location 34737 count 52 value_offset 0 - PCSCitationGeoKey: NAD_1983_StatePlane_Mississippi_West_FIPS_2302_Feet

      key 3075 tiff_tag_location 0 count 1 value_offset 1 - ProjCoordTransGeoKey: CT_TransverseMercator

      key 3076 tiff_tag_location 0 count 1 value_offset 9003 - ProjLinearUnitsGeoKey: Linear_Foot_US_Survey

      key 3077 tiff_tag_location 34736 count 1 value_offset 5 - ProjLinearUnitSizeGeoKey: 0.3048006096

      key 3081 tiff_tag_location 34736 count 1 value_offset 4 - ProjNatOriginLatGeoKey: 29.5

      key 3082 tiff_tag_location 34736 count 1 value_offset 0 - ProjFalseEastingGeoKey: 2296583.333

      key 3083 tiff_tag_location 34736 count 1 value_offset 1 - ProjFalseNorthingGeoKey: 0

      key 3088 tiff_tag_location 34736 count 1 value_offset 2 - ProjCenterLongGeoKey: -90.33333333

      key 3092 tiff_tag_location 34736 count 1 value_offset 3 - ProjScaleAtNatOriginGeoKey: 0.99995

      key 4097 tiff_tag_location 34737 count 24 value_offset 52 - VerticalCitationGeoKey: NAVD88 - Geoid03 (Feet)

      key 4099 tiff_tag_location 0 count 1 value_offset 9003 - VerticalUnitsGeoKey: Linear_Foot_US_Survey

variable length header record 2 of 4:

  reserved             43707

  user ID              'LASF_Projection'

  record ID            34736

  length after header  80

  description          'GeoTiff double parameters'

    GeoDoubleParamsTag (number of doubles 10)

      2.29658e+006 0 -90.3333 0.99995 29.5 0.304801 6.37814e+006 298.257 0 0.0174533

variable length header record 3 of 4:

  reserved             43707

  user ID              'LASF_Projection'

  record ID            34737

  length after header  101

  description          'GeoTiff ASCII parameters'

    GeoAsciiParamsTag (number of characters 101)

      NAD_1983_StatePlane_Mississippi_West_FIPS_2302_Feet|NAVD88 - Geoid03 (Feet)|GCS_North_American_1983|

variable length header record 4 of 4:

  reserved             43707

  user ID              'NIIRS10'

  record ID            4

  length after header  10

  description          'NIIRS10 Timestamp'

the header is followed by 4 user-defined bytes

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

  X           242000000  242499999

  Y           173750000  174249999

  Z               21304     170409

  intensity           0        255

  return_number       1          4

  number_of_returns   1          4

  edge_of_flight_line 0          1

  scan_direction_flag 0          1

  classification      1         12

  scan_angle_rank   -28         28

  user_data         170        205

  point_source_ID 13013      13015

  gps_time 334368.065945 336746.871043

number of first returns:        5681927

number of intermediate returns: 182131

number of last returns:         5674804

number of single returns:       4300161

overview over number of returns of given pulse: 4300161 2405698 513380 19462 0 0 0

histogram of classification of points:

          167863  unclassified (1)

         1747599  ground (2)

          194347  medium vegetation (4)

          826544  high vegetation (5)

             236  noise (7)

            2382  water (9)

         4299730  overlap (12)

[Kirk Waters - NOAA Federal]

There are few things going on with the time and date that aren't necessarily what you think they are. First the creation date. The LAS format spec defines that as the date the file was created, which may not (usually not?) the day the data was collected. Data are often cut up into tiles and could have multiple dates of data in them, so a single date wouldn't work anyway.

Second, the GPS time. There is a global encoding bit that tells how to interpret (you got that right). It isn't always set right, but a 0 means time is seconds of the week and a 1 means adjusted GPS time. The adjusted part is important. It's not the time you would plug into the converter you found. It would be, if you added 1 billion to it (the adjustment).

Your file says global encoding bit of 0 (seconds of the week) and that's consistent with the range of times you have, since they all fit in a week. The problem is that you don't know what week. The creation date may be useless for this. At a minimum, you can't trust it. This is why we don't like seconds of the week. You're likely going to have to find out more about your data. If you're lucky there is metadata. If you're really lucky, someone has flight logs to match up dates with flight ids.

Kirk Waters, PhD                     | NOAA Office for Coastal Management

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

coast.noaa.gov/digitalcoast

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

[Evon Silvia]

Kirk's correct on all points. The File Creation date isn't a reliable source of information with respect to the actual flight date. That information will be found in the metadata somewhere. You might need a codex to figure out which lines were flown on which dates. 

Here's a primer on GPS time as encoded in LAS files.

For GPS Week Time (global encoding bit 0 = 0), it is the number of seconds since GPS midnight (roughly* UTC-0, or GMT, or Zulu time) of the previous Sunday morning. Thus you'd need to know the GPS week for your flight based on your approximate acquisition date(s). If you can figure out the GPS week number, you can multiply that by 604,800 and subtract 1,000,000,000 to convert to Adjusted Standard GPS Time. Most LAS processing software (including lastools) can do this conversion for you if you can provide a date and/or week number.

las2las -i *.las -odir adj_time -week_to_adjusted ####

...where #### = the GPS Week Number

For Adjusted Standard GPS Time (global encoding bit 0 = 1), your timestamp is the number of seconds that have passed since midnight of the morning of January 6, 1980, minus 1 billion. Thus if you take that timestamp, add 1,000,000,000, and use some function to add that to the timestamp of 0:00:00 1/6/1980, you'll get the human-comprehensible UTC-0 (almost*) time of that particular pulse. 

In Excel, that looks something like this:

=DATE(1980,1,6)+(1000000000+####)/(24*60*60)

...where #### is your Adjusted Standard GPS Time (e.g., 126631245.000012 becomes 5:07:25PM on 9/18/2015)

In Qt-style C++ code, that looks like this:

QDateTime(QDate(1980, 1, 6), QTime(0, 0, 0, 0), Qt::UTC).addMSecs(qRound64(1000.0 * (#### + 1000000000.0)));

...where #### is your Adjusted Standard GPS Timestamp as a double

You should have enough info to do this in your language of choice.

Hope that helps.

Evon

--

Evon Silvia PLS

QSI Solutions Developer

ASPRS LAS Working Group Chair

Quantum Spatial

517 SW 2nd Street, Suite 400, Corvallis, OR 97333

P: (541) 452-8502

E: esi...@quantumspatial.com

[Evon Silvia]

Forgot the asterisk. 

* I keep saying almost UTC-0/GMT/Zulu time because the timestamps are actually in GPS Time, which doesn't include leap seconds, while UTC time does include leap seconds. The difference between them depends on the date itself. The offset between the two is currently 18 leap seconds (based on # of leap seconds since 1/6/1980), but goes down by 1 roughly every 1-3 years. The Wikipedia article on this topic is actually quite good and reliable: https://en.wikipedia.org/wiki/Leap_second

So, using my example, here are seven equivalent timestamps:

• GPS Week Time:          228045.000012 (GPS Week 1862)
• Adjusted Std GPS Time:  126631245.000012
• GPS Time:               5:07:25.000012PM Sept. 18, 2015
• GPS Time:              17:07:25.000012   Sept. 18, 2015
• UTC Time (+17 LS):     17:07:42.000012   Sept. 18, 2015
• PDT Time (UTC-7:00):   10:07:42.000012   Sept. 18, 2015
• PST Time (UTC-8:00):    9:07:42.000012   Sept. 18, 2015

As this example shows, don't forget to account for time zones if you're comparing to local timestamps. Note that most software packages/languages do NOT account for these leap seconds automatically, so you might have to do this conversion yourself. They cannot be predicted.

Evon

[d weasson]

So just to clarify both your and Evon's replies -- it is pretty certain that 

1) the file creation day/year is the PROCESSING date for the data, and doesn't have anything to do with when the LiDAR was flown, other than it obviously has to post date the collection, and

2) the gps_time(s) are the earliest and latest COLLECTION times of the data points in the file, represented as seconds into the GPS Week, but there is no way, without knowing the flight information, which week the data was collected.

I hope that is correct.  I'm dealing with some pretty ugly data (long story, which I'm guessing will be explained in a subsequent post when I next can't figure something out!), and even knowing what date the files were processed is a help -- I can gather them together into groups of similar processing, at least.  

I appreciate your help!  Regards, Darlene