I've observed some odd behaviour whilst rasterizing a file via the command line - not sure if it is simply a misinterpretation / typo on my part.
I have rasterized at 0.05 grid step in the cc GUI and as well as by the command line - it appears the command line only performed the 0.05 grid in the X direction while doing a step of 0.5 in the Y direction. Input was a 324MB .csv file with XYZ as well as RGB columns. Resulting cloud is essentially long lines of X-rasterized points spaced at 0.5 in the Y direction.
Command line input:
'"CloudCompare -SILENT -C_EXPORT_FMT ASC -SEP COMMA -EXT CSV -O "C:/Users/matt_/Downloads/Tree Count Trial/Trial 11 - Raster Input/Original Input Files/A5_Tile_+005_+002_2018-01-18_10h36_42_686.CSV" -RASTERIZE -GRID_STEP 0.05 -PROJ MAX"'
The normal 'grid size will be enormous' message pops up when not in SILENT mode but that doesn't make a difference. I'm pretty sure I have used exactly the same input as the GUI for a very different result.
I was going to attach the original input file + raster outputs from cc GUI & the command line but they're too large (even after 7zip!).
Suggestions?
Rasterize via command line - grid step
Re: Rasterize via command line - grid step
Hum that's weird ;). Especially the warning about the grid size warning...
Does the CSV file (cloud) has big coordinates maybe? If you set can you try with the '-GLOBAL_SHIFT AUTO' option?
Otherwise would it be possible for you to send me the cloud? (cloudcompare[at]danielgm.net)
Does the CSV file (cloud) has big coordinates maybe? If you set can you try with the '-GLOBAL_SHIFT AUTO' option?
Otherwise would it be possible for you to send me the cloud? (cloudcompare[at]danielgm.net)
Daniel, CloudCompare admin
Re: Rasterize via command line - grid step
Thanks for the prompt feedback.
The answer is yes: yes, the input file has large coordinates - i.e. sufficiently large such that the CC GUI warns & applies a shift every time one of these input files is opened. And yes, using the -GLOBAL_SHIFT AUTO option appears to have done the trick. Works as expected for the few files I have tried. Thanks for that!
As an aside, the warning message regarding grid size comes after clicking the 'Update grid' button in the CC GUI Rasterize function window - it doesn't prevent execution, just warms about an impending large cloud post-rasterize, i.e. a large cloud to begin with and a 'too small' step size - note the the post-rasterize cloud in this case is 3.7 million points at 0.05 grid step (and is one of the smaller ones in the set).
When running via command line this same message pops up in the console for an OK... no issues there, except when processing a largish batch of files and need to hit OK every for every file. Much better in -SILENT since CC just pushes on and does it anyway without telling me - a good time for a coffee break ;-)
The answer is yes: yes, the input file has large coordinates - i.e. sufficiently large such that the CC GUI warns & applies a shift every time one of these input files is opened. And yes, using the -GLOBAL_SHIFT AUTO option appears to have done the trick. Works as expected for the few files I have tried. Thanks for that!
As an aside, the warning message regarding grid size comes after clicking the 'Update grid' button in the CC GUI Rasterize function window - it doesn't prevent execution, just warms about an impending large cloud post-rasterize, i.e. a large cloud to begin with and a 'too small' step size - note the the post-rasterize cloud in this case is 3.7 million points at 0.05 grid step (and is one of the smaller ones in the set).
When running via command line this same message pops up in the console for an OK... no issues there, except when processing a largish batch of files and need to hit OK every for every file. Much better in -SILENT since CC just pushes on and does it anyway without telling me - a good time for a coffee break ;-)
Re: Rasterize via command line - grid step
Ah. In a classic case of unintended consequences & user wanting everything, there's been another snag.
I've tried to apply the -DROP_GLOBAL_SHIFT option at the end of the command line described earlier and tried exporting into various formats LAS / E57 / CSV etc - so that I can have my large coordinates back for comparison / reference to other things, but the CC console goes into a holding pattern and can't complete the operation. This is after having applied -GLOBAL_SHIFT AUTO before the rasterize.
Without DROP_GLOBAL_SHIFT it all works beautifully, just doesn't have the same coordinate system as the input file. Is there a special way to apply -DROP_GLOBAL_SHIFT or have I simply bumped into a limit on what coordinates CC can reasonably handle?
Clearly one option would be to do the same shift on the input file and have the input + rasterized versions both exported in the same coordinate system but, you know, I don't really want to go there if I don't have to :-).
I've tried to apply the -DROP_GLOBAL_SHIFT option at the end of the command line described earlier and tried exporting into various formats LAS / E57 / CSV etc - so that I can have my large coordinates back for comparison / reference to other things, but the CC console goes into a holding pattern and can't complete the operation. This is after having applied -GLOBAL_SHIFT AUTO before the rasterize.
Without DROP_GLOBAL_SHIFT it all works beautifully, just doesn't have the same coordinate system as the input file. Is there a special way to apply -DROP_GLOBAL_SHIFT or have I simply bumped into a limit on what coordinates CC can reasonably handle?
Clearly one option would be to do the same shift on the input file and have the input + rasterized versions both exported in the same coordinate system but, you know, I don't really want to go there if I don't have to :-).
Re: Rasterize via command line - grid step
I believe the DROP_GLOBAL_SHIFT would in fact remove the Global Shift information and as a result the large coordinates won't be restored at export time. The fact that the console hangs when adding this option is probably a separate issue (I'll look at this whenever I have some time).
Actually I wonder if the command line version of the rasterize tool is actually keeping the Global Shift information. This may explain why the original coordinates are not restored in your case... I'll also check that.
Actually I wonder if the command line version of the rasterize tool is actually keeping the Global Shift information. This may explain why the original coordinates are not restored in your case... I'll also check that.
Daniel, CloudCompare admin
Re: Rasterize via command line - grid step
For the records, I looked at the code, and the global shift information should be properly restored (if you don't use '-DROP_GLOBAL_SHIFT' of course).
For the hanging issue, I've not been able to reproduce it. Do you have a reproducible way to make it happen? If yes can you send me the data via email maybe? (or with a cloud sharing solution such as Dropbox or Google Drive). You can email me to 'admin [at] cloudcompare.org' now.
For the hanging issue, I've not been able to reproduce it. Do you have a reproducible way to make it happen? If yes can you send me the data via email maybe? (or with a cloud sharing solution such as Dropbox or Google Drive). You can email me to 'admin [at] cloudcompare.org' now.
Daniel, CloudCompare admin