Opened 15 years ago
Last modified 6 years ago
#1033 new enhancement
Raster modules should creat a group in case of multiple outputs
Reported by: | huhabla | Owned by: | huhabla |
---|---|---|---|
Priority: | normal | Milestone: | 7.6.2 |
Component: | Raster | Version: | svn-trunk |
Keywords: | raster, multiple, output, group, temporal, basename, imagery | Cc: | huhabla |
CPU: | All | Platform: | All |
Description
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.
Change History (10)
comment:1 by , 11 years ago
Keywords: | temporal added |
---|---|
Platform: | Unspecified → All |
comment:2 by , 10 years ago
Keywords: | basename imagery added |
---|
From grass-dev QGIS Processing & GRASS:
I've modified G7:r.ros and G7:r.rgb in r63777 and r63796 but there are other which needs the same, I named at least some of them in comment:182:ticket:2409.
I cannot work on this more but similar change as I did for G7: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".
There are some other modules I'm not completely sure about such as G7:i.pansharpen and G7:i.topo.corr.
Some other seems that they don't need this change (e.g., G7: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, #2136) should be used in all cases otherwise it is not really standard, now many of them are probably using dot.
Last issue I know about is G7: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.
See also:
comment:3 by , 9 years ago
Milestone: | 7.0.0 → 7.0.5 |
---|
comment:4 by , 8 years ago
Milestone: | 7.0.5 → 7.3.0 |
---|
comment:7 by , 6 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:8 by , 6 years ago
Milestone: | 7.4.2 → 7.6.0 |
---|
All enhancement tickets should be assigned to 7.6 milestone.
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.