CloudCompare forum

Hi Daniel,

those contours are from TIN surfaces in AutoCAD that use the 5 m and 10 m average raster grid clouds generated in Cloud Compare. I did not generate the contours in Cloud Compare.

The shift I applied is to subtract half the grid spacing from both the X and Y values. So 10 m grid = subtract 5 m from both x and Y.

Andrew

I thought this raster 'origin' thing was fixed a while ago :|. This half-pixel shift should normally be set thanks to the "AREA_OR_POINT" flag in the geotiff file (which is set to "AREA"). See http://www.gdal.org/gdal_datamodel.html.

This means that pixels represent a region around the center and not the "center" itself. And I believe it does change the resulting raster position of half a pixel. But as we discussed a lot about this on the forum, I believe we need to stick to this convention. So maybe your patch of manually translating the resulting polylines makes sense.

Perhaps it was fixed when loading in a tif file however when generating the rasterised clouds.

Here is a more obvious example of it. I've got the original 1 m grid selected (red points) and the 5 m grid generated by exporting the rasterised surface as a cloud (white points)
When I turn both point grids (1 m raw, 5 m ave raster from cloud compare) into ACAD the 1 m contours look like this: Shifting the surface -2.5 m in the X and Y axis makes it line up.

I understand the convetion may be for raster, but if we're exporting it as an X,Y,Z cloud then surely it needs to be adjusted so the points are in the center of the raster pixel?

However as a side note i would have though that if we're going from a 1 m grid to a 5 m grid, we would be losing area coverage by at least 2.5 m on the edges?

Hum, the fact is that the raster grid is placed by default on the bottom-left corner (point). But it can actually span over the right and bottom corners because we use regular steps (and a grid will be filled even if only one point falls inside, even in a corner...).

At least it explains why you see the output grid cell 'centers' fall at half the step size compared to the initial points (because, especially on an initially gridded cloud, the points on the left will always be on the raster cells borders, and the center of these cells will be at exactly half the cell size on the right... The user can change the origin of the grid to avoid this problem.

I'm a little bit more surprised by the (grid) points on the right or on the top, that seems a little bit too far from the right border. I'll investigate on that.

Daniel,

I did a quick check on a small area of some raw photogrammetry generated survey. The resulting contour offset appears when creating a raster from that as well. Once again shifting it (in this case -0.5 m in the x and y axis as its a 1 m raster grid) solves it. When doing a volume comparison between the raw and the 1 m ave raster without the shift the variation ranges from -0.252 to 0.411 m.

If i do the same comparison after shifting it the variation ranges from -0.215 to 0.293 m.

I would expect it to be worse for larger grid spacing.

Daniel and Andrew Perth

Great result. I made the test according to your observation (I moved in the southwest orientation) with 1m mesh (x = -0.5 y = -0.5) and made the comparison in 2 softwares - Global mapper and Autocad Civil 3D. See Below. The result was quite satisfactory considering the difference in the algaritm of software. Congratulations Andrew Perth for the help.

Okay I think I finally understood the issue. See https://github.com/CloudCompare/CloudCompare/issues/767.

You can download the latest 2.10.alpha version online.

I'll let you test ;)

That's great to hear. I'll give it a test when I get some time. Probably not for a week or so. Thanks Daniel :D