Rounding issue scalar field GPS time from las files
Posted: Sun Oct 04, 2015 9:38 pm
Hi,
I use a lot the GPS_time information for individual points in airborne lidar stored in las1.3. Gps_time is generally the GPS time of the week in seconds. It needs to be precise at least at 1e-6 to account for typical acquisition frequencies of current systems (> 100 khz), and is coded over 32 bits in the las 1.3 format. It typically looks like 124675.123456
In Cloudcompare I pick a point with a specific geometry and go back to the raw records of Full Waveform to find the corresponding waveform with gps_time. I choose, 6 digits resolution in the display settings.
Somehow I've had the impression that the digits I read in the pick point box were not correct as :
. in some cases, points nearby have exactly the same value, when they should be different (acquisition was at 200 khz, so the time difference should be 5e-6).
. the waveforms do not correspond to what I should find (i.e. complex waveform for vegetation, simple echo for bare ground).
To check that there was a rounding issue, I created 2 fake las 1.3 files in which the gps_time was set to the z coordinate and another one with the x coordinate (in lambert, so very big coordinate with rounding issue if you use single precision):
. With the gps_time equals to elevation, there was no rounding and no error: both are perfectly equals
. With gps_time set to z: there was rounding issues at cm resolution : [23:22:55] [Picked] - Time = 625125.6250000, [23:22:55] [Picked] - [original] (625125.6100006;5386048.3199997;64.2500000)
Because, if I remember well scalars can only be stored as single precision (or you need to recompile with double precision), would it be possible to use a similar trick as the coordinate to "shift" the gps-time and keep a time resolution of 1e-6 s ? This is the only scalar in las files needing this, but this is actually quite important.
I use a lot the GPS_time information for individual points in airborne lidar stored in las1.3. Gps_time is generally the GPS time of the week in seconds. It needs to be precise at least at 1e-6 to account for typical acquisition frequencies of current systems (> 100 khz), and is coded over 32 bits in the las 1.3 format. It typically looks like 124675.123456
In Cloudcompare I pick a point with a specific geometry and go back to the raw records of Full Waveform to find the corresponding waveform with gps_time. I choose, 6 digits resolution in the display settings.
Somehow I've had the impression that the digits I read in the pick point box were not correct as :
. in some cases, points nearby have exactly the same value, when they should be different (acquisition was at 200 khz, so the time difference should be 5e-6).
. the waveforms do not correspond to what I should find (i.e. complex waveform for vegetation, simple echo for bare ground).
To check that there was a rounding issue, I created 2 fake las 1.3 files in which the gps_time was set to the z coordinate and another one with the x coordinate (in lambert, so very big coordinate with rounding issue if you use single precision):
. With the gps_time equals to elevation, there was no rounding and no error: both are perfectly equals
. With gps_time set to z: there was rounding issues at cm resolution : [23:22:55] [Picked] - Time = 625125.6250000, [23:22:55] [Picked] - [original] (625125.6100006;5386048.3199997;64.2500000)
Because, if I remember well scalars can only be stored as single precision (or you need to recompile with double precision), would it be possible to use a similar trick as the coordinate to "shift" the gps-time and keep a time resolution of 1e-6 s ? This is the only scalar in las files needing this, but this is actually quite important.