Hi Daniel,
I have some problems with GPS Time inside LAS files:
When merging point clouds via command line with those that have a significant time shift difference, the resulting merged clouds do not reflect the correct GPS Time.
When attempting to open an LAS file from the GUI, it is not possible to enter a large time shift value (e.g., 402950000) into the designated input box, as it exceeds the allowable number limit.
Please let me know if you need additional information!
Thanks,
Mario
GPS Time problem
GPS Time problem
- Attachments
-
- GPS_Time.zip
- (5.67 KiB) Downloaded 241 times
Re: GPS Time problem
Sorry, I still didn't have the time to look at this... It's true that the support for GPS time is quite limited, especially when merging clouds.
I'll try to look at what can be done in the next version (it may take some time!)
I'll try to look at what can be done in the next version (it may take some time!)
Daniel, CloudCompare admin
Re: GPS Time problem
Sorry for the very long time it took to look at this.
I've increased the resolution of the time shift that can be input in the LAS file opening dialog (up to 10^9). You can test the latest 2.14.alpha version online.
However, I've tested on my side, and normally a time shift is automatically applied when loading a LAS file via the command line tool. Which means that by default the accuracy should be preserved. Unless, the spanning of GPS time is so long that the first GPS time encountered in the file is very small, and the last one is very large. In this case, I imagine that the default shift based on the first GPS time might be too small to compensate for the large values that appear later in the file.
I've increased the resolution of the time shift that can be input in the LAS file opening dialog (up to 10^9). You can test the latest 2.14.alpha version online.
However, I've tested on my side, and normally a time shift is automatically applied when loading a LAS file via the command line tool. Which means that by default the accuracy should be preserved. Unless, the spanning of GPS time is so long that the first GPS time encountered in the file is very small, and the last one is very large. In this case, I imagine that the default shift based on the first GPS time might be too small to compensate for the large values that appear later in the file.
Daniel, CloudCompare admin