how to handle LAS files that have different timestamps types (GPS week time VS Posix)
Farwell, Steve - NRCS, Fort Worth, TX
Hello, I was wondering what is the best approach if I have a large LiDAR project area that has LAS files that have different timestamp types (GPS week time VS Posix) in the project area. Would LAStools be able to convert a batch of LAS files from one timestamp type into another type? I am needing a way to thin out the LAS files by a certain thinning factor then merge all the thinned LAS file into one LAS file which will be used as an Project Overlay in a WMS.
Regards,
Steven Farwell
Paradigm Systems GIS Inc.
Steve....@ftw.usda.gov
USDA/NRCS/NGMC/RTB, Bldg. #23
Fort Worth, Texas,
Work:(817) 509-3424
Cell:(214) 663-6094
Martin Isenburg
as far as I understand a global encoding of 1 - just like a global
encoding of 0 - both mean that GPS Standard Time was used - at least
according to the format specification. The difference is that when the
global encoding bit is set there is an offset of 1,000,000,000
subtracted from the GPS Standard Time resulting in what the spec calls
Adjusted GPS Standard Time. See also the discussion here:
https://lidarbb.cr.usgs.gov/index.php?showtopic=7160
In order to avoid GPS time precision issues you should convert all
your files from GPS Standard Time (global encoding = 0) to Adjusted
GPS Standard Time (global encoding = 1) . There is not a single
command for doing so in LAStools so you need to do the following two
commands:
las2las -i test_tile.las -i test_tile_1.las -translate_gps_time
-1000000000
lasinfo -i test_tile_1.las -set_global_encoding 1
but only do this for files that currently have global_encoding equal 1
or you will corrupt your time stamps. maybe you can send me a
lasinfo.exe report for both LAS files that you show in the image? the
lasinfo.exe report contains the range of GPS-times in the file.
cheers,
martin
ps: i was worried that this "adjustment" that the design choice
"double" for the GPS-time now requires will cause plenty of headaches
now and in the future. i really wish we would change to an integer
representation for GPS-time in nanoseconds for LAS 1.4. see the
discussion here:
http://groups.google.com/group/lasroom/browse_thread/thread/b37f8e4782cfd481
Farwell, Steve - NRCS, Fort Worth, TX
Regards,
Steven Farwell
Paradigm Systems GIS Inc.
Steve....@ftw.usda.gov
USDA/NRCS/NGMC/RTB, Bldg. #23
Fort Worth, Texas,
Work:(817) 509-3424
Cell:(214) 663-6094
Hello,
https://lidarbb.cr.usgs.gov/index.php?showtopic=7160
cheers,
martin
http://groups.google.com/group/lasroom/browse_thread/thread/b37f8e4782cfd481
--
Download LAStools at
http://lastools.org/
Visit the LAStools group at
http://groups.google.com/group/lastools/
Be social with LAStools at
http://www.facebook.com/LAStools
http://www.twitter.com/LAStools
Mike Watry
Type means
the timestamps are GPS *Week* time, as in the number of seconds since
the start of
the GPS week. This is a further difference from the 1 value, where
time is referenced
to Jan 1, 1980 (with the 1,000,000,000 offset) instead of to the start
of the week.
This 0 meaning caused problems as collections crossed the week
boundary, as the
timestamp would get reset. (Reference the 3rd paragraph, or 1st bullet
of the preamble
to the LAS 1.2 specification.) Furthermore, to know the actual time
of collection of a point
(human readable), you need to know the GPS week, which is not explicit
in the header
but implicit from the year and date in the header.
I appreciate your discussion on future changes, including the
discussion of floating point
numbers in the video of your paper presentation on LAZ. Interesting
side note is the old
"0" setting, which has serious problems, at least did not have the
precision problem... ;-)
- Mike W.
Martin Isenburg
turns out I got it wrong. Mike is correct when he says that if the
lowest global encoding bit is 0 then you should only have GPS *week*
time. In this case all your GPS times are in the range from 0 to 604
800. Simply checking that range will usually tell you what GPS time
you have in your file. Here are some typical examples for GPS week
time:
lasinfo IowaDNR-CloudPeakSoft-1.0-UTM15N.las -stdout | grep "gps_time"
gps_time 597987.305116 600731.680834
lasinfo autzen-colorized-1.2-3.las -stdout | grep "gps_time"
gps_time 245369.896569 249783.702971
lasinfo SerpentMoundModelLASData.las -stdout | grep "gps_time"
gps_time 499450.805994 500410.856459
lasinfo USACE_Merrick_lots_of_VLRs.las -stdout | grep "gps_time"
gps_time 221766.301617 578835.151884
to convert this to Adjusted Standard GPS time you would first have to
add w * 604 800 before you subtract 1,000,000,000 where w is the week
in which that LIDAR was flown. right now we are in week 1671 (see
http://leapsecond.com/java/gpsclock.htm). I will add transform filters
to the next version of las2las that will allow you to convert from GPS
week time to the Adjusted Standard GPS time and vice versa.
Cheers,
Martin @lastools
Martin Isenburg
at http://lastools.org/download/las2las.exe you can download an
updated version of las2las.exe that does conversions between GPS week
time and Adjusted Standard GPS time as follows:
lasinfo week.las -stdout | grep "gps_time"
gps_time 130778.000009 130786.894848
las2las -i week.las -o adjusted.laz -week_to_adjusted_gps 1650
lasinfo adjusted.laz -stdout | grep "gps_time"
gps_time -1949221.999991 -1949213.105152
las2las -i adjusted.laz -o week1.laz -adjusted_gps_to_week
lasinfo week1.laz -stdout | grep "gps_time"
gps_time 130778.000009 130786.894848
Cheers,
Martin @lastools
Gottfried Mandlburger
Just a short note on the timestamps issue. Unfortunately the
interpretation of timestamps within LAS files has changed with the LAS
versions:
Global Encoding Bit 0:
LAS 1.0:
LAS 1.1:
no encoding information available
LAS 1.2:
0: GPS Time is GPS Week Time
1: GPS Time is POSIX Time or (!!) Standard GPS Time minus 1 x 10**9
LAS 1.3:
LAS 1.4:
0: GPS Time is GPS Week Time
1: GPS Time is Standard GPS Time minus 1 x 10**9
Unfortunately, the LAS 1.2 specification was not consistent concerning
the time system nomenclature using "POSIX" and "Standard GPS Time"
synonymously. However, both time scales have different origins:
POSIX: January 1, 1970
GPS Time: January 6, 1980
However, POSIX is no longer mentioned in the LAS 1.3/1.4 specification
and it seems that "Standard GS Time" was always intended by the authors
of the LAS 1.2 specification. But still some confusion related to POSIX
timestamps may occur in LAS 1.2 files.
Kind regards,
Gottfried
------------------------------------------------------------------------
Dr. Gottfried Mandlburger Inst. of Photogrammetry and Remote Sensing
Vienna University of Technology
Gusshausstrasse 27-29
A-1040 Wien
email: g...@ipf.tuwien.ac.at Tel (++43 1) 58801 12235
www: http://www.ipf.tuwien.ac.at Fax (++43 1) 58801 12299
OPALS: http://www.ipf.tuwien.ac.at/opals
------------------------------------------------------------------------
--
Farwell, Steve - NRCS, Fort Worth, TX
Regards,
Steven
-----Original Message-----
From: last...@googlegroups.com [mailto:last...@googlegroups.com] On Behalf Of Martin Isenburg
Hello Steve,
Cheers,
Martin @lastools
--
Martin Isenburg
a final follow-up. las2las does the full conversion now via '-
week_to_adjusted 1650' and '-adjusted_to_week' and lasinfo has a new
option to compute the '-gps_week'. here an example use of this
functionality. of course this will also run in batch mode ('-i *.las')
and in multi-core batch mode ('-cores 3').
lasinfo week.laz -gps_week -stdout | grep gps_
gps_time 413162.560400 414095.322000
las2las -i week.laz -o error.laz -adjusted_to_week
WARNING: global encoding flag indicates file already in GPS week time
use '-force' to force conversion.
las2las -i week.laz -o adjusted.laz -week_to_adjusted 1650
lasinfo -i adjusted.laz -gps_week -stdout | grep gps_
gps_time -1666837.439600 -1665904.678000
gps_week 1650 1650
gps_secs_of_week 413162.560400 414095.322000
las2las -i adjusted.laz -o error.laz -week_to_adjusted 1660
WARNING: global encoding flag indicates file is already Adjusted
Standard GPS time
use '-force' to force conversion.
las2las -i adjusted.laz -o week1.laz -adjusted_to_week
lasinfo -i week1.laz -gps_week -stdout | grep gps_
gps_time 413162.560400 414095.322000
cheers,
martin