Raster modules should creat a group in case of multiple outputs

[landam]

Reported by huhabla on 12 Apr 2010 15:30 UTC While implementing WPS support for grass7 i stuck in handling multiple outputs of raster modules. This is also an issue for the graphical work-flow-modeler which should be able to connect grass modules to each other in case of compatible inputs and outputs (like dx does).

There is currently (please correct me if i am wrong) no convenient generic way to automatically recognize multiple raster outputs (r.texture, i.pca ... ), except r.in.gdal which creates a group for imported maps with multiple bands.

I would like to suggest that every module which creates multiple raster outputs should create a group in the way which r.in.gdal does. Multiple output parameter should be marked by setting opt->multiple=YES. It would be meaningful to implement this as default option.

I would like to start this kind of enhancement if there are no objections against it.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1033

[landam]

Comment by wenzeslaus on 27 Mar 2014 04:56 UTC This is idea is now extended by outputting temporal datasets when appropriate since not all multiple outputs are groups. And this probably should be discussed together.

I would say that the basename/prefix can serve also as a name for group or temporal dataset. But these general (textual) basenames/prefixes are not friendly to automated tools since they don't tell what they are unless we add some special types to parser (I think we should). More discussion and concrete examples needed.

Similar think also applies to inputs of course. This might be even more controversial.

[landam]

Comment by wenzeslaus on 15 Feb 2015 02:47 UTC From http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html grass-dev QGIS Processing & GRASS:

I've modified https://grass.osgeo.org/grass77/manuals/r.ros and G7:r.rgb in https://trac.osgeo.org/grass/changeset/63777 and https://trac.osgeo.org/grass/changeset/63796 but there are other which needs the same, I named at least some of them in comment:182:ticket:2409. .htmlI cannot work on this more but similar change as I did for https://grass.osgeo.org/grass77/manuals/r.rgb could be done for G7:r.blend too. It also has an output option which is a "basename for red, green and blue output raster maps". .htmlThere are some other modules I'm not completely sure about such as https://grass.osgeo.org/grass77/manuals/i.pansharpen and G7:i.topo.corr. .htmlSome other seems that they don't need this change (e.g., https://grass.osgeo.org/grass77/manuals/i.pca, G7:i.landsat.toar, G7:i.landsat.acca, and G7:i.tasscap) because the number of outputs is variable. However, I'm not sure how the suffixes are generated, sometimes it seems that they are even expected on the input. Standard basename separator (underscore, https://trac.osgeo.org/grass/ticket/2136) should be used in all cases otherwise it is not really standard, now many of them are probably using dot. .htmlLast issue I know about is https://grass.osgeo.org/grass77/manuals/r.texture where the number of outputs depends on number of requested textures. G7:r.neighbors actually solves this issue by using output not as a basename but as multiple and requesting as many outputs as requested methods. .htmlSee also:

• comment:12:ticket:2409
• comment:13:ticket:2409
• comment:14:ticket:2409
• comment:17:ticket:2409
• comment:179:ticket:2409

[landam]

Modified by @landam on 12 May 2016 06:42 UTC

[landam]

Modified by @landam on 25 Aug 2016 15:51 UTC

[landam]

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

[landam]

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

[landam]

Modified by neteler on 12 Jun 2018 20:48 UTC

[landam]

Comment by @landam on 25 Sep 2018 16:51 UTC All enhancement tickets should be assigned to 7.6 milestone.

[landam]

Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed