Rasterise Outputs arent maintaining the original CRS

[ewan_SA]

Hi all,

I’m having a lot of trouble getting my workflow to produce georeferenced rasters that QGIS can use properly, and I’d really appreciate any help.

Here’s what I’m doing:

I export a point cloud from RealityCapture as a .las file — usually in EPSG:27700 (British National Grid) or EPSG:7405 (OSGB + ODN height).

After some edits, I use the Rasterize tool in CloudCompare to export a GeoTIFF raster (height grid).

When I open that GeoTIFF in QGIS, even after setting the correct CRS (EPSG:27700 or 7405), it always loads at off the coast of Africa at coordinates (0,0).

I’ve tried both clicking “Yes” and "No" to apply the global shift when initially loading into clouc compare, but I get the same result both ways.

I am cewrtain that the CRS is correct on the cloud I import, I confirmed this with the RCINFO file.

Is there any way to get CloudCompare to preserve real-world position when exporting rasters or is manually georeferencing in QGIS the only reliable fix?

I am very new to GIS so apologies if i am missing something obvious. If anyone has experience with RealityCapture → CloudCompare → QGIS workflows and can share how they handle this, I’d really appreciate it!

[daniel]

Normally, you should (always) click 'YES' when asked to apply a Global Shift. That's mandatory to restore the original coordinates.

Then which version are you using? Normally, exported geotiff rasters should preserve the coordinates.

[ewan_SA]

Hi, thanks for your response,

Im currently running CC version 2.13.2.

I have exported rasters from Cloud Compare into QGIS before and it has been successful at preserving the coordinates so im really unsure why this is now happening consistently.



As I said, the CRS is mainteined in the output from reality capture, and it is recognised upon uploading to CC when asking to apply Global shift.

After doing this, I am also getting what appears to be an error message in the Console that suggests the coordinates have been reset to 0,0.



Im assuming this is the root of the issue but so far I have not been able to solve it.

Thanks again for the help.

[daniel]

No the warning is normal, it just to tell the user that all coordinates have been (temporarily) translated to local coordinates.

But this should normally be restored when exporting entities to most of the file formats supported by CC, and also to geotiff files.

[greeton]

I am having the same problem when exporting rasters, the exported raster has lost its original coordinates, has anyone found a solution because I don't see one on this post?

[daniel]

Did you apply (and keep) the suggested Global Shift? And which output format have you chosen?

[DA523]

use gdalwarp.exe to set CRS to tiff

[markermurt]

This is a really common CloudCompare gotcha, so you’re not missing something obvious. CloudCompare does not reliably write georeferencing (origin + CRS) into GeoTIFFs when rasterizing. Even if the point cloud has the correct CRS, the raster export often drops the world origin, so QGIS falls back to 0,0 off Africa.

The key thing to check is whether your cloud has been “shifted” in CloudCompare. If a global shift is applied, CC works in local coordinates and the raster will export in that local space. You can see this under Edit → Edit Global Shift & Scale. If there’s a shift, QGIS won’t know about it.

In practice, the most reliable workflows are either:
– Export the raster without shift and then manually georeference it in QGIS using the known origin, or
– Skip CloudCompare for rasterization and generate the DEM directly in RealityCapture or another GIS-aware tool.

Unfortunately, manual georeferencing in QGIS is still the safest fix when using CloudCompare today.