People often want to know when data were collected. There are lots of reasons they want to know. They might be trying to find other data taken at or near the same time, or perhaps want to know what the tide stage was during the collection. The lidar industry has historically not done a very good job of making this information available, at least not easily. The LAS format does have a mechanism to store the time for each point very precisely, except time was originally stored in seconds of the GPS week (the GPS signal broadcasts the time as the number of weeks since January 6, 1980 and the number of seconds so far in that week – only the seconds were stored in LAS). You can back that out if you know what GPS week it was collected in, but pretty useless if you don’t. Since LAS version 1.2, there has been a way to store an adjusted GPS time that can be converted to normal time and most recent collections store it that way. We’re going to look at how you extract those times.
In any case, the Python datetime library just characterizes a conceptual baseclass for tzinfo, and leaves it over to others to really actualize tzinfo creation. This is the place the tz module of dateutil comes in—it gives all that it is required to turn upward timezones from your OS timezone information. Regarding the question on using gpsd versus nmea. The gpsd client is a full featured gps interface that enables high level programming interface for gps data for lots of conceiveable applications but the price for that is the application programmer does not have visibility into the actual performance of the gps interface and the data.
Getting Adjusted GPS Time
Python Current Utc Time
To start with, you’re going to need something that can read a LAS file and give you some information. If you’re a programmer, you can simply work with the format specification and read the GPS time entry for every point. That’s a bit of work and most of you probably aren’t programmers, so we’ll skip that approach. There are likely a number of packages that can help you out, but I’m going to just look at one of Martin Isenburg’s tools from the LAStools collection. The lasinfo program will give you some basic information about a LAS file including the minimum and maximum GPS time stamps. If my LAS file is testlidar.las, I’d run the command: lasinfo testlidar.las. This works on LAZ files too, which provides a nice way to save space by compressing the data. There is a gui with LAStools if you don’t want to use the command line (note that many LAStools require a license, but lasinfo does not).
Your output will include a line that looks like:
gps_time -28329269.780373 -28329247.236305
That’s the file’s minimum and maximum GPS time record. This one is in adjusted GPS time (that’s the seconds since GPS started in 1980 minus 1 billion). Just looking at it, it’s a bit hard to even tell what year that might be, let alone calendar day or time of day. However, Tiffany Summerscales did put a nice converter on the web that lets you put in GPS time and get regular time. Eve online pandemic horde.
This tool wants GPS time and we’ve got a time that was adjusted by subtracting a billion (1e9). Adding that back to the minimum to get 971670730.219627, entering that as the GPS time and clicking the convert button, we get something that looks like the image below (make sure you select the GPS radio button).
This particular collection is in California, so earliest data in this particular tile was collected just before 9:32 PM local time on October 20, 2010. You might guess this is a small file since only 22 seconds separates the minimum and maximum time. Indeed, it only has 256K points.
GPS Time for Individual Points
There are definitely programs out there that will let you visualize the point cloud and retrieve the GPS time when you query the information for a point. If your GIS or remote sensing software is smart enough to read LAS or LAZ points, it is likely it can give you the time for a point. Most people probably don’t need that level of detail and the time ranges for a file will do. You might need that detail if the data file has multiple flights covering many days.
Gps To Utc
Dealing With GPS Seconds of the Week
An important caveat is that a lot of data is still in the GPS seconds of the week format. If the times are between zero and 604800, it is almost certainly seconds of the week (but it could be between September 14 and 20, 2011). If you happen to know the day or week the data were collected, you can still get a better estimate of the real time (sometimes the metadata will help, sometimes not). Use the GPS time converter again, but this time enter midnight of the Sunday for that week and convert that to GPS time. Then add your seconds of the week and plug it back in as the GPS time. For example, if I knew the collection was between November 12 and 15, 2012, I would use the converter to get the UTC seconds (since the start of GPS) for November 11 (Sunday) at midnight (00:00:00). Giving me a UTC time of 103667216 to add to my seconds of the week.
I hope you found this useful. I was certainly happy to find the GPS converter and I’m thankful to Tiffany Summerscales for making it available. She’s even got that full PHP code for those who want all the details.
If you’re interested in mapping the points using their time stamps as an attribute, there is another GeoZone post to talk about that.