CloudCompare forum

Hi Daniel

I'm using Cloudcompare a few days and by the way very good software. I did some testing by drawing contours and exporting in dxf format compared to some other software like GlobalMapper, Photoscan AgiSoftware. There is a significant difference in the design of the Contour Lines in the design of the contours in the CloudCompare. See the attached drawing. Line in green color are from CloudCompare software. Version 2.10 Alpha.

Well, the most evident answer is that we probably don't use the same algorithm to generate the contour lines? (in the latest version we use GDAL's).

And are you using the exact same raster to test this by the way? Otherwise the raster generation parameters may differ?

Daniel, yes I'm using the same source, not raster, but point cloud (.las) exported from CloudCompare. The distance difference in this case was approximately 70cm from a contour line to the one generated in the CloudCompare.

Well, the rasterize process has a big influence on the resulting contour lines. You have to consider the projection options (lowest, average or highest altitude, etc.). And also the raster step. And that's probably the same for the other tools?

Daniel,

what is the correct procedure for generating contour lines in CloudCompare ??? I already exported the mesh to other software and the result was the same obtained from the contour lines in the CloudCompare. I'm following this video on youtube (https://www.youtube.com/watch?v=OgIk15vMTG4) to make contour lines. But the result is not satisfactory.

Well, I don't know how the other softwares generates the contour line from a point cloud, but I bet they apply some kind of 'rasterization' behind the scenes, or maybe some meshing of the cloud? And to do this they probably use some parameters.

Anyway, for CloudCompare, the two most important parameters are the grid step (you'd better set it as small as possible: of course it can't be too small otherwise you'll end up with a gigantic number of cells, and you don't want to get too many empty cells). So you basically need to lower the grid step until holes appear in between the cells. This way you'll get the best resolution possible.

Then, depending on the actual grid step you were able to use (it will depend on the cloud resolution), then you'll need to take care of the 'cell projection' parameter. If you take the lowest point, it might be more robust to potential noise or small vegetation, but if the local slope is steep, it will also be inaccurate... Maybe in a first attempt I would keep the 'average' height. And I would never use the 'maximum' height apart for very specific applications.

Hello guys,

I just came across this issue as well and I think I have figured it out. When cloud compare creates a raster grid it doesn't put the new point in the right X,Y co-ordinate. As such if you make a 10 m average grid then you will see a shift in your contours by 7.0711 m to the north-east.

The easiest fix for this is to simply shift the points to the south-west by a value found using this formulae: shift distance = (Grid spacing * Sqrt(2))/2 or just subtract half of the grid spacing from your x and y values.

Daniel would it be possible to have this shift added into Cloud Compare?

Here are a couple pictures of the surface i'm working with. Grey is as provided by a surveyor, orange is a 5 m average raster and the blue is a 10 m average raster. Red square is 5 x 5 square, green is 10 by 10 square.

Unadjusted: Shifted: kind regards,

Andrew

Which version are you using?

Hi Daniel,

I've currently got v2.9.1 (64 bit) installed.

Andrew

Hum, the 2.9 version was already relying on GDAL to produce contour lines so I'm a bit surprised.

But I guess I'll apply the shift of half a cell then? (to be on the safe side, can you express it in terms of X,Y coordinates?)