Feature request #11323

Allow editing gdal commands in processing

Added by Paolo Cavallini about 5 years ago. Updated 8 months ago.

Status:Feedback
Priority:Normal
Assignee:-
Category:Processing/GDAL
Pull Request or Patch supplied:No Resolution:
Easy fix?:No Copied to github as #:19619

Description

See the implementation in GDALTools itself. Thi, together with the next feature req, would allow to get rid of the duplication between GDALTools and Processing


Related issues

Related to QGIS Application - Bug report #14600: Processing > gdalwarp: wrong error message, no command di... Closed 2016-04-01
Duplicated by QGIS Application - Feature request #15090: Make the GDAL/OGR console call editable Rejected 2016-06-21
Duplicated by QGIS Application - Bug report #20631: Add back ability to modify gdal commands before running them Closed 2018-11-26

History

#1 Updated by Giovanni Manghi about 5 years ago

  • Project changed from 78 to QGIS Application
  • Category deleted (58)

#2 Updated by Giovanni Manghi about 5 years ago

  • Category set to Processing/GDAL

#3 Updated by Giovanni Manghi about 5 years ago

  • Assignee set to Victor Olaya

#4 Updated by Alexander Bruy almost 4 years ago

  • Status changed from Open to In Progress

We already have field with generated GDAL command, but if I'm not wrpng, it is not editable yet.

#5 Updated by Giovanni Manghi over 2 years ago

  • Easy fix? set to No

#6 Updated by Paolo Cavallini almost 2 years ago

  • Assignee deleted (Victor Olaya)

Still true in QGIS 3. Unsure whether this is still an issue, as commands should be editable in the Processing history, for all algs.

#7 Updated by Nyall Dawson over 1 year ago

  • Subject changed from Add an echo of the command line to GDALTools algs to Allow editing gdal commands in processing

#8 Updated by Nyall Dawson over 1 year ago

I'd be inclined to close this as a "won't-fix". The command line is shown only as a shortcut for people developing batch files and for execution outside of QGIS. There's no real way to fit an editable command into the processing world.

Alternative options would be:

1. A separate plugin allowing execution of gdal command line tools via a toolbar button. Users could then copy commands from processing windows and paste and edit using that plugin.

Or

2. A new gdal algorithm with a single "command" parameter, allowing for pasting of a gdal command to execute.

#9 Updated by Nyall Dawson over 1 year ago

  • Status changed from In Progress to Feedback

#10 Updated by Paolo Cavallini over 1 year ago

I understand well your point. Same thing applies to other backends (grass, saga).
However, good old GDALTools made this straightforward, and power users took advantage of this function extensively. I think that missing it is a regression, not a very good thing.
Perhaps a more general solution should be designed, i.e. the capability of re-running analyses editing the command string by hand.

#11 Updated by Nicolas Cadieux over 1 year ago

Nyall Dawson wrote:

I'd be inclined to close this as a "won't-fix". The command line is shown only as a shortcut for people developing batch files and for execution outside of QGIS. There's no real way to fit an editable command into the processing world.

Alternative options would be:

1. A separate plugin allowing execution of gdal command line tools via a toolbar button. Users could then copy commands from processing windows and paste and edit using that plugin.

Or

2. A new gdal algorithm with a single "command" parameter, allowing for pasting of a gdal command to execute.

Hi,

I can't figure out how to add a comment without modifying the comment. Perhaps the "cite" button is the only way... anyways, I agree with Paolo that this is a major setback as the old tool really permitted users to learn the gdal command lines. It also gave flexibility. I agree that a "other command" parameter would be one way to go. Still, it would be important to see the list of files being used (in the case of gdalbuiltvrt). Currently all we see is that the file list will be created in (buildvrtInputFiles.txt). This is important as the order of the files is important in this module. Sorry if I messed up your comment. I will only see if I did this correctly after I press the "send" button!

Nicolas

#12 Updated by Jürgen Fischer about 1 year ago

  • Duplicated by Bug report #20631: Add back ability to modify gdal commands before running them added

#13 Updated by Sfkeller - 8 months ago

I'd like to support this feature request turning the output command text field of the dialog into an editable text field (referring to #21978).

My test case and goal is to call e.g. "gdal_grid" as follows:

gdal_grid -a nearest:radius1=1:radius2=1:nodata=-99 \
-txe 50 350 -tye 650 450 -outsize 3 2 -zfield z \
"grid in.gpkg" "grid out.tif" 

The parameters "-txe 50 350 -tye 650 450 -outsize 3 2" are currently unreachable through the processing dialog (i.e. they are not layer output creation options). Think also about the -sql option.

Also available in: Atom PDF