Rounding issue scalar field GPS time from las files

[Dimitri]

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.

[daniel]

Indeed, I think there has been already a thread (on this forum or on github) about this issue.

In fact the GPS time is coded on 64 bits (double precision) while the scalar values in CC are coded on 32 bits (single precision).

I agree we should indeed add a kind of 'global shift' to scalar fields. And to limit the impact on the existing code we would only use it when saving the scalar field, or when displaying the value in labels (and the shift will probably be set automatically).

[daniel]

OK that's fixed!

[Dimitri]

Thanks Daniel, it works perfectly !