Bug report #17127

Control order by which bands are stacked

Added by andre mano over 6 years ago. Updated over 6 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Processing/GDAL
Affected QGIS version:2.18.12 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:duplicate
Crashes QGIS or corrupts data:No Copied to github as #:25026

Description

When using gdal-merge from the Processing toolbox, it is not possible to control the order by which the bands are to be stacked (screenshot attached). Example below:

For merging 7 Landsat bands into a single image this command is generated:

gdal_merge.bat -a_nodata -9999 -ot Float32 -separate -o "[temporary file]" -of GTiff
/L5197024_02420100627_B10.TIF
/L5197024_02420100627_B40.TIF (will become Band 2 when it should be band 4)
/L5197024_02420100627_B50.TIF (and so on...)
/L5197024_02420100627_B60.TIF
/L5197024_02420100627_B30.TIF
/L5197024_02420100627_B20.TIF
~/L5197024_02420100627_B70.TIF

User should have the possibility to control order so that the command would look like this:

gdal_merge.bat -a_nodata -9999 -ot Float32 -separate -o "[temporary file]" -of GTiff
/L5197024_02420100627_B10.TIF
/L5197024_02420100627_B20.TIF
/L5197024_02420100627_B30.TIF
/L5197024_02420100627_B40.TIF
/L5197024_02420100627_B50.TIF
/L5197024_02420100627_B60.TIF
~/L5197024_02420100627_B70.TIF

image.png (113 KB) andre mano, 2017-09-12 01:24 PM


Related issues

Related to QGIS Application - Bug report #17327: Sorting of input layer Layers in Processing "multiple inp... Closed 2017-10-25

History

#1 Updated by Giovanni Manghi over 6 years ago

  • Category changed from GDAL Tools to Processing/GDAL

#2 Updated by Giovanni Manghi over 6 years ago

see also #17327

#3 Updated by Jürgen Fischer over 6 years ago

  • Related to Bug report #17327: Sorting of input layer Layers in Processing "multiple inputs" widgets added

#4 Updated by Giovanni Manghi over 6 years ago

  • Resolution set to duplicate
  • Status changed from Open to Closed

Closing in favor of #17327 because this is more general.

Also available in: Atom PDF