Global shift problem

[Anne Stewardson]

I geo-referenced a number of .las files against .txt control files last week. On opening them today, to merge with neighbouring files, they appear not to have saved their 'global shift' values, and are all at the equivalent of "0,0" (but the z/height value is correct, I expect there was no global shift imposed on the z value). I was using the newer version of Cloud Compare (2.12 alpha). I installed the earlier stable version (2.11.3), and have successfully re-georeferenced one file as a test, but I need to export this as an e57 file to open in Point Cab (it doesn't like las format and shows this format as a decemated grid). When I opened the e57 in Point Cab it says the e57 file is corrupt and crashes the software (I remembered this is why I was using the 2.12 version).
Up until last week the workflow of ge-referencing in 2-12 alpha, and exporting as an e57, was working fine, so I know it was working correctly. The only thing that has changed on my PC (in the last week) is the latest Win10 Pro update. Could that have effected it?
Any ideas would be greatly recieved,

Anne

[daniel]

Hum, it shouldn't...

Can you explain your exact process? Or share data with me so that I can reproduce the issue on my side?

[Anne Stewardson]

Hi Daniel,

I re-installed after posting, and all was good, until a few hours agao, when it's happened again.
So in 2.12 I am geo-referencing files from the Horizon, using control points (in a txt file format) and scanned spheres within the data. As the area covered comprises multiple scans I need to get the RMS quite low, to allow more accurate merging of the files later on. After the initial scan Georeferencing, I then clean the data using the Noise filter and the SOR filter and then sub-sampling the data to "Space" 0.01. These are then saved as seperate .las files, as they mey need to be used for more than one area (I know it's confusing!)
The next part is to gather all the newly created .las together, for a specific area and finely reference them to as close as possible to each other for the merge to one file.
It appears, to be occuring randomly at any stage through the above workflow. I have noticed it is mainly on saving individual elements of the .bin, but then also sometimes it effects the entirety of the .bin file (when the whole .bin is saved). It appears that on saving the Global Shift translation is forgotten in the newly saved file.

Again, at the beginning of the week it was working perfectly fine after the re-install of 2.12. I was wanting to export the .e57 files, which 2.11.3 doesn't seem to want to create (although it goes through the motions, and creates a file), which is why I re-installed 2.12. So the Global Shift has been remembered on all files created up-until around 3pm (GMT). Short of another uninstall/reinstall, I'm not sure what to do.
Best Wishes,

Anne

[daniel]

What can I say, that's very strange, because it should 'work' or 'not work', but not one and then the other for no reason :D

Something bad must be happening at some point in time, or a tool that you use and that would wipe the global shift information?

Can you try to reproduce the steps and pay attention to the 'Global shift' field in the cloud properties? Like each time you do something? And try to spot when it disappears?

Or is it only when you export to BIN?

[Anne Stewardson]

It seems to be only when I'm saving the bin or the elements created as new .las files that it loses the Global shift elements. It means I don't know if it's worked or not until I open the new file (which also means closing the old bin, that still appears to retain the global shift, needs to be saved and closed! My machine struggles to run 2 sessions of CC at once with the data I'm working on being quite large files, and that's an I-9 with 128GB RAM).

[daniel]

And can you try the same process on a small cloud? (maybe by segmenting a small portion with the scissors tool?)

[Anne Stewardson]

Hi Daniel,
I already have, as the data I was working on, when I first noticed this, involved cropping the overlapping data from multiple scan sessions to 100m grid squares within an external landscape (there are many derilict buildings from a deserted village and farmland lying underneath a tree canopy, and the area covers about 2.5 square km with hundreds of individual scan-runs). I only have the full scans required required for each 100m square (all geo-referenced, and opening with the suggested Global shift as usual), and after fine referencing these get cropped to the 100m square boundary (dxf box imported from CAD), with the extranious data deleted from the .bin project. There are usually only elements from 3 or 4 scans by this point, non covering the whole area of the 100m square. Then I have to manually crop out the trees, and merge the remaining "good" data (that of the ground and buildings and field boundaries). As it is quite a long drawn-out process I am saving the .bin fairly regularly. It is usually from the first "save" that the Global shift data ends up being replaced with the "on Screen" co-ordinate data in then .bin. (or the .las or the .e57)

When I have opened one of the individual scan-run .bin files (one full scan and it's sphere co-ordinate txt file) they are correctly placed relative to each other and look correct, but both the "shifted box centre" and the "Global box centre" contain exactly the same values as each other, instead of the "Global Box centre" indicating the real world co-ordinates. I also have to provide contours from the data (which is actually how I first noticed this problem), and instead of them reflecting the real world, they are now showing the "Shifted box" co-ordinates.

I know it's a complete head-scratcher, as, like I said, up until about 4 weeks ago now it was working correctly, as it always had done! The conveluted way round that I'm currently practicing is installing 2.11.3, completing my georeferencing and creating the 100m square, and then uninstalling to reinstall 2.12 to export the e57 for Point Cab! Not ideal, but I can't think of another work around.

Let me know if you have any other thoughts,
BW
Anne

[daniel]

Wow! At least you should use the 'archive' version of CloudCompare (7zip) that you can unzip anywhere and launch it from there (so that you don't need to uninstall the other version each time).

I'll to play on my side to reproduce the issue, but that's definitely weird...

[VXGrid]

I geo-referenced a number of .las files against .txt control files last week. On opening them today, to merge with neighbouring files, they appear not to have saved their 'global shift' values, and are all at the equivalent of "0,0" (but the z/height value is correct, I expect there was no global shift imposed on the z value). I was using the newer version of Cloud Compare (2.12 alpha). I installed the earlier stable version (2.11.3), and have successfully re-georeferenced one file as a test, but I need to export this as an e57 file to open in Point Cab (it doesn't like las format and shows this format as a decemated grid). When I opened the e57 in Point Cab it says the e57 file is corrupt and crashes the software (I remembered this is why I was using the 2.12 version).
Up until last week the workflow of ge-referencing in 2-12 alpha, and exporting as an e57, was working fine, so I know it was working correctly. The only thing that has changed on my PC (in the last week) is the latest Win10 Pro update. Could that have effected it?
Any ideas would be greatly recieved,

Anne

Hi Anne,

Sorry for my intrusion:
Thanks for providing Daniel with all necessary information, so he is able to reproduce the issue, so it can be solved.

I like to add something regarding PointCab / GeoSLAM Draw:
Our LAS Import is much more robust than our E57 import, so in theory the conversion to E57 should not be necessary:
When importing a LAS/LAZ file in PointCab/Draw coming from a GeoSLAM device, please make sure that you change the project type back to terrestrial or GeoSLAM project (see image1) after choosing the point cloud.

If the issue with the decimated grid persists please contact us at support@pointcab-software.com, so we can fix this for all customers.

Martin