Exporting raster - georeferencing ?

[betadk@gmail.com]

When exporting a raster or image, it seems that the global shift / scale is not restored and the raster is therefore not geo-referenced correctly (point cloud was in UTM). Is one supposed to transform to originals outside of CloudCompare ?
Thanks.

[daniel]

Global shift should be restored when exporting the raster to geotiff (via the 'Rasterize' tool). But indeed, not when exporting to an image.

[libak]

Hi Daniel

How do I export a rasta to geotiff while maintaining global shift (scale)?

When I import the geotiff into ACAD, the geotiff is 1mm in length which is not correct - the bounding box in CC is ~39000

Rgds

[daniel]

Which version are you using?

And can you explain how you generated the geotiff exactly? From which cloud?

Ideally, if you could share the original cloud and the parameters you used that would help a lot.

[libak]

Hi Daniel

I’m using 2.13.1

This is how I generated the geotiff
> select point cloud
> Hit rasterize button
> set parameters
> update grid
> Rasterize viewport shows my point cloud, ok.
> Export > Raster
> Export RGB colors > OK
> Save as type: geotiff (*.tif)
> Save
> In AutoCAD I enter IMAGEATTACH, and set scale to 1
Now the length of the image in ACAD is 1mm

I can’t share the point cloud, but the size of it is not 1mm :-)

Thanks

[daniel]

Ah, you duplicated the message... Not sure which thread to follow now...

[benb]

Dear Forum Participants and CC Development Wizards,
I want to preserve the geospatial reference info that is in my original LAS files when I export a Raster.
I have experienced this question with CCv2.13.2 and 2.14a. They give the same result for this case.

For LAS files with geospatial metadata that places them correctly in the Yucatan Peninsula, Mexico.
1. Import LAS file into CC (tried 2.13.2 and 2.14a (Dec 26 2024), both have same issue).
2. In Open LAS file window/Loading tab, select all, apply to all
3. In Global shift/scale window, CHECK Preserve global shift on save, Click Yes to All

4. In DB tree select LAS file, Tools/Projection/Rasterize
5. In rasterize window, update grid, In Export tab/Export statistics, height is checked.
6. Click Raster button, Export raster options appears, Export height is checked, Click OK
7. Save as geotiff, new name, try out the new file in ArcGIS Pro, should sit on top of LAS file,
but it goes instead to the Sahara Desert (Niger). in CC, click OK on Rasterize window and, ...
8. File/Close all, remove all entities, try again...
9. File open original LAS file, in Open LAS file window, click Apply All
10. In Global shift/scale window, UNCHECK Preserve global shift on save, click Yes to all.

11. Select LAS file in DB tree, Tools/Projection Rasterize, Update Grid
12. In Export, click Raster button, in Export Raster Options, click OK, new name, save, try it
Now the file is in the Atlantic Ocean west of Ghana, ...
go back to CC, file close all, remove entities, try again
13. File open, load LAS file, Select all, Apply to All
14 In Global shift/scale, UNCHECK Preserve global shift on save, Click No button

15. Tools/Projection/Rasterize, Update Grid, Click Raster button
16. Export raster options, click OK, new name, save, try it in ArcGIS Pro, back to Sahara
one more combination to try, so last attempt before posting query to forum, ...
17. back to CC, in Rasterize window, click OK to close it, File/close all/remove all entities
18. Load LAS file, Apply all
19. Last option, ... in Global shift/scale, CHECK Preserve global shift on save, click NO button

20. rasterize, Update grid, click Raster button, Export raster options OK, save, try, SAHARA again.
The exported file is losing its georeference info to make it land correctly in the Yucatan...
instead it is landing in Africa or in the Atlantic ocean, ...

How can I preserve the geospatial information for the placement of the data when I rasterize it?
This problem has beset me with both 2.13.2 and 2.14alpha, maybe user malfunction or a bug,..
For clarity, I skipped over that I set Scalar Fields to Classification and set Min/Max to 1.1-2.1.
I also like to adjust the step size and observe the results to find an effective signal/noise ratio.
I am resampling LiDAR data to an optimum spatial resolution to create DEM files to visualize.
I love its results it when I set Rasterize to Cell height values, Z, median, Project SF(s) median,
resample, and Fill with Kriging. Takes long time to process, but worth the wait, except that -
for the moment it loses the geospatial data on its correct location, so it is unusable!
Please help.

Hoping for guidance on how to use CC to rasterize LAS files without losing geospatial info.
thanks,

-benb

[daniel]

Well, it's more a general limitation of CloudCompare that doesn't "explicitly" handle geospatial references. The only thing CC can do is preserve it if you load a LAS file for instance, process the cloud, and then later save the cloud back to a LAS file. Because in this case CC remembered the blob of data specific to a LAS files that represents your geospatial reference. But CC doesn't know what it means. And if you were to save to another format, even if this format can handle a geospatial reference, CC wouldn't know how to convert the LAS blob to the new format's own blob/convention.

The only thing CC properly manages and preserves are the (large) coordinates. And you should keep them untouched by keeping the "Preserve global shift on save" option checked all the time.

What happens in your case is that when you generate the raster, the coordinates are properly preserved, but the geospatial reference is not transferred from the LAS file. There's probably no geospatial reference defined in the geotiff file. Therefore, I guess that Arcgis defaults it to something and it falls somewhere... Can't you override the geospatial reference of the raster in Arcgis maybe? And restore the original one?

[DA523]

You can assign any crs by gdaltransform.exe outside of cc

[benb]

Well, it's more a general limitation of CloudCompare that doesn't "explicitly" handle geospatial references. The only thing CC can do is preserve it if you load a LAS file for instance, process the cloud, and then later save the cloud back to a LAS file. Because in this case CC remembered the blob of data specific to a LAS files that represents your geospatial reference. But CC doesn't know what it means. And if you were to save to another format, even if this format can handle a geospatial reference, CC wouldn't know how to convert the LAS blob to the new format's own blob/convention.

The only thing CC properly manages and preserves are the (large) coordinates. And you should keep them untouched by keeping the "Preserve global shift on save" option checked all the time.

What happens in your case is that when you generate the raster, the coordinates are properly preserved, but the geospatial reference is not transferred from the LAS file. There's probably no geospatial reference defined in the geotiff file. Therefore, I guess that Arcgis defaults it to something and it falls somewhere... Can't you override the geospatial reference of the raster in Arcgis maybe? And restore the original one?

CloudCompare retained the Extents from the original LAS file in the Exported Raster. I used the Define Projection tool in ArcGIS Pro to assign the correct CRS to the file. Then I selected the raster layer in the Contents pane, selected Data/Export Raster, and saved the raster as a new file. Upon reloading the new raster image file into ArcGIS as a layer, I found that it contained the corrected CRS and retained the Extents information. It displayed in the proper location correctly in the Map window. I will apply this solution to all the raster images in my dataset that I have generated with CC from LAS files. The process added a black border to the four sides of the image, but that may just be a display properties issue (Band 1 = Value 0).

I think that solved problem of how to use CC to Rasterize LAS files for visualizing georeferenced LiDAR data in ArcGIS Pro. Thanks for your explanation and the tip about "Preserve global shift on Save", also thanks to DAS23 for the alternative solution of assigning the CRS in gdaltransform. Maybe a next version of CC could extract the CRS from the original LAS file and rewrite that CRS into the Exported Raster in the Rasterize tool. Meanwhile, using Define Projection is a simple solution for ArcGIS users. Thank you for such an amazing tool, I am glad to have found it. With this method, I expect to convert hundreds of transects previously processed as 1m/px DTM files in to .5m/px or better. My experiments with CC showed that original LAS files had enough ground returns to justify a tighter step value to increase spatial resolution on the derived visualization rasters, and I just needed to solve the problem of the CRS to effectively apply the solution to all the files. Now I am off to the races with this solution. So far, so good, Thank you!