negative gps time values
452 views
Skip to first unread message
Charles Cowart
Apr 3, 2012, 10:13:41 PM4/3/12
to last...@googlegroups.com
Hi everyone,
Has anyone ever created/encountered las files with large and negative gps time values? I've encountered several from different providers that display min/max values in lasinfo like the ones below:
gps_time -26644586.301395 -26631727.721383
In all cases, the GPS absolute time bit has been set to zero, and whether I manually flip the bit to 1 or not, the values are interpreted the same in both liblas and lastools. The range of the two values is 12,858 seconds, which seems reasonable for a tile possibly containing multiple passes.
I'm trying to discern whether or not these are double floating point values that are somehow misinterpreted, the products of some bad math applied to the dataset, a fault with the scanning hardware, etc. Lastools will display a warning, and after reviewing the section of code that produces it, it appears it does so because the values are truly less than zero. Any thoughts and/or suggestions are welcome; I've included lasinfo output at the bottom of this message.
I have a tangentially-related question - does anyone know of a way in lastools to manually set the gps absolute time flag to 1? I have a quick standalone binary that I can share with non-coders, but I am hoping there is a flag in las2las or lasinfo that might accomplish the same thing.
Cheers,
Charles
---
reporting all LAS header entries:
file signature: 'LASF'
file source ID: 0
global_encoding: 0
project ID GUID data 1-4: 2124359723 12262 20216 '????K|E'
version major.minor: 1.2
system identifier: ''
generating software: 'TerraScan'
file creation day/year: 43/2011
header size: 227
offset to point data: 880
number var. length records: 5
point data format: 1
point data record length: 28
number of point records: 10122144
number of points by return: 9925377 168362 24370 4035 0
scale factor x y z: 0.01 0.01 0.01
offset x y z: -0 -0 -0
min x y z: 595500.01 3714000.00 -105.07
max x y z: 597000.00 3715109.54 416.56
variable length header record 1 of 5:
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 48 - 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 26911 - ProjectedCSTypeGeoKey: PCS_NAD83_UTM_zone_11N
key 3073 tiff_tag_location 34737 count 22 value_offset 0 - PCSCitationGeoKey: NAD_1983_UTM_Zone_11N
key 3075 tiff_tag_location 0 count 1 value_offset 1 - ProjCoordTransGeoKey: CT_TransverseMercator
key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
key 3077 tiff_tag_location 34736 count 1 value_offset 5 - ProjLinearUnitSizeGeoKey: 1
key 3081 tiff_tag_location 34736 count 1 value_offset 4 - ProjNatOriginLatGeoKey: 0
key 3082 tiff_tag_location 34736 count 1 value_offset 0 - ProjFalseEastingGeoKey: 500000
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: -117
key 3092 tiff_tag_location 34736 count 1 value_offset 3 - ProjScaleAtNatOriginGeoKey: 0.9996
key 4097 tiff_tag_location 34737 count 26 value_offset 22 - VerticalCitationGeoKey: NAVD88 - Geoid09 (Meters)
key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
variable length header record 2 of 5:
reserved 43707
user ID 'LASF_Projection'
record ID 34736
length after header 80
description 'GeoTiff double parameters'
GeoDoubleParamsTag (number of doubles 10)
500000 0 -117 0.9996 0 1 6.37814e+06 298.257 0 0.0174533
variable length header record 3 of 5:
reserved 43707
user ID 'LASF_Projection'
record ID 34737
length after header 73
description 'GeoTiff ASCII parameters'
GeoAsciiParamsTag (number of characters 73)
NAD_1983_UTM_Zone_11N|NAVD88 - Geoid09 (Meters)|GCS_North_American_1983|
variable length header record 4 of 5:
reserved 43707
user ID 'NIIRS10'
record ID 4
length after header 10
description 'NIIRS10 Timestamp'
variable length header record 5 of 5:
reserved 43707
user ID 'NIIRS10'
record ID 1
length after header 26
description 'NIIRS10 Tile Index'
the header is followed by 2 user-defined bytes
reporting minimum and maximum for all LAS point record entries ...
x 59550001 59700000
y 371400000 371510954
z -10507 41656
intensity 1 4095
edge_of_flight_line 0 1
scan_direction_flag 0 1
number_of_returns_of_given_pulse 1 4
return_number 1 4
classification 1 7
scan_angle_rank -19 9
user_data 0 0
point_source_ID 5 41
gps_time -26644586.301395 -26631727.721383
WARNING: range violates GPS week time specified by global encoding bit 0
overview over number of returns of given pulse: 9757026 288008 60991 16119 0 0 0
histogram of classification of points:
4687402 Unclassified (1)
5434732 Ground (2)
10 Low Point (noise) (7)
Martin Isenburg
Apr 4, 2012, 7:58:27 AM4/4/12
to LAStools - efficient tools for LiDAR processing
Hello Charles,
> Has anyone ever created/encountered las files with large
> and negative gps time values? I've encountered several
> from different providers that display min/max values in
> lasinfo like the ones below:
>
> gps_time -26644586.301395 -26631727.721383
Yes. large negative GPS-times are a result of a poor design choice in
the GPS-time field of the LAS 1.X specification. See the discussion
here:
http://groups.google.com/group/lasroom/browse_thread/thread/a4ff19ea628fd80c
> In all cases, the GPS absolute time bit has been set to
> zero, and whether I manually flip the bit to 1 or not, the
> values are interpreted the same in both liblas and
> lastools. The range of the two values is 12,858 seconds,
> which seems reasonable for a tile possibly containing
> multiple passes.
In order to get the "real" time you need to add 1,000,000,000 to the
values. However, you cannot do this in double-precision floating-point
without making some decisions on how to "loose" precision (see
discussion thread above). Therefore both LASlib and libLAS defer this
choice to the user and leave the times negative. What you could do is
use las2las to turn the "adjusted standard GPS-time" (that you
currently have) into the "GPS week time" but then you loose
information about the week the data was collected and may have a wrap
around if folks were working weekends ... (-:
las2las -i lidar_adjusted.las -adjusted_to_week -o lidar_week.las
> I'm trying to discern whether or not these are double
> floating point values that are somehow misinterpreted,
> the products of some bad math applied to the dataset,
> a fault with the scanning hardware, etc. Lastools will
> display a warning, and after reviewing the section of code
> that produces it, it appears it does so because the values
> are truly less than zero. Any thoughts and/or suggestions
> are welcome; I've included lasinfo output at the bottom of
> this message.
lasinfo.exe merely warns you to make you aware of the fact that the
global encoding bit should be set as the GPS time range is outside the
range of GPS-week. you can get a bit more info out of lasinfo with the
'-gps_week' flag which will tell you in which GPS week your adjusted
standard GPS time falls. for more info see this thread here:
> WARNING: range violates GPS week time specified by global encoding bit 0
http://groups.google.com/group/lastools/browse_thread/thread/8a4fe49f0e678ea6
> I have a tangentially-related question - does anyone know of a way
> in lastools to manually set the gps absolute time flag to 1? I have
> a quick standalone binary that I can share with non-coders, but I
> am hoping there is a flag in las2las or lasinfo that might accomplish
> the same thing.
Yes. If you run lasinfo with the GUI you will find the option. If you
run from the command line then
lasinfo -i lidar_adjusted.las -set_global_encoding 1
does the trick. But careful with '-set_global_encoding xxx' as you may
corrupt your file for other LAS readers if you specify some wrong
values here.
Cheers,
Martin @lastools
> Has anyone ever created/encountered las files with large
> and negative gps time values? I've encountered several
> from different providers that display min/max values in
> lasinfo like the ones below:
>
> gps_time -26644586.301395 -26631727.721383
the GPS-time field of the LAS 1.X specification. See the discussion
here:
http://groups.google.com/group/lasroom/browse_thread/thread/a4ff19ea628fd80c
> In all cases, the GPS absolute time bit has been set to
> zero, and whether I manually flip the bit to 1 or not, the
> values are interpreted the same in both liblas and
> lastools. The range of the two values is 12,858 seconds,
> which seems reasonable for a tile possibly containing
> multiple passes.
values. However, you cannot do this in double-precision floating-point
without making some decisions on how to "loose" precision (see
discussion thread above). Therefore both LASlib and libLAS defer this
choice to the user and leave the times negative. What you could do is
use las2las to turn the "adjusted standard GPS-time" (that you
currently have) into the "GPS week time" but then you loose
information about the week the data was collected and may have a wrap
around if folks were working weekends ... (-:
las2las -i lidar_adjusted.las -adjusted_to_week -o lidar_week.las
> I'm trying to discern whether or not these are double
> floating point values that are somehow misinterpreted,
> the products of some bad math applied to the dataset,
> a fault with the scanning hardware, etc. Lastools will
> display a warning, and after reviewing the section of code
> that produces it, it appears it does so because the values
> are truly less than zero. Any thoughts and/or suggestions
> are welcome; I've included lasinfo output at the bottom of
> this message.
global encoding bit should be set as the GPS time range is outside the
range of GPS-week. you can get a bit more info out of lasinfo with the
'-gps_week' flag which will tell you in which GPS week your adjusted
standard GPS time falls. for more info see this thread here:
> WARNING: range violates GPS week time specified by global encoding bit 0
> I have a tangentially-related question - does anyone know of a way
> in lastools to manually set the gps absolute time flag to 1? I have
> a quick standalone binary that I can share with non-coders, but I
> am hoping there is a flag in las2las or lasinfo that might accomplish
> the same thing.
run from the command line then
lasinfo -i lidar_adjusted.las -set_global_encoding 1
does the trick. But careful with '-set_global_encoding xxx' as you may
corrupt your file for other LAS readers if you specify some wrong
values here.
Cheers,
Martin @lastools
Reply all
Reply to author
Forward
0 new messages