Capture d’écran 2024-09-03 115946.png (9 KiB) Viewed 2221 times
I'd like to delete this offset or set it to 0 so that when I export the cloud other software I don't have coordinates overflow problem that really mess up my data. I don't understand how to do it since I have no global shifts applied.
Capture d’écran 2024-09-03 120044.png (2.76 KiB) Viewed 2221 times
Is it possible to remove this offset in CloudCompare? If not, do you have a simple workflow from other tools that I could use?
Hum, that's weird, there must be something wrong with this file... Hopefully it's a unique instance.
And normally, if you use the latest version of CC (2.14.alpha), if you load the file with a (0, 0, 0) Global Shift, then it should be saved with this 'offset' instead of the original one. If it doesn't work, then I'm interested to have access to your file (you can send it to 'admin@cloudcompare.org').
It seems that regardless on the options on the import global shift settings or later in the "edit global shift settings", even if I specify new shift settings and tick or untick "keep original position fixed", the "LAS.offset" fields are never overwritten.
I am using Kharkiv version 2.13.1, but I just tried with 2.14a and got the same behaviour I will provide you via email a small 4M pts extract of a ptcloud that exhibits the same behavior but should be faster to load/experiment with than the other full cloud I'm working on, which is confidential and cannot be shared it unfortunately.
Keep in mind I may simply be misunderstanding what the global shift options actually do especially given it seems this behavior concerns several files, if you have in-depth resources other than the wiki on this subject that can help, maybe I'll be able to find what is wrong with my method myself.
The only workaround I found to keep the cloud as is but just set the .las offset to zero, is to save it in .ply and then resave the .ply back in .las. CloudCompare then says this in the console:
[11:24:52] [LAS] Will use the minimum bounding-box corner (X, Y) as LAS offset
Which is not 0 but is way more reasonable in especially when dealing with huge offsets.