Well, this email is older but was never answered. I guess in most cases the situation is still the same.
···
On Thu, Aug 7, 2014 at 3:45 PM, Markus Neteler <neteler@osgeo.org> wrote:
Forwarded message from Giovanni Manghi:
Hi all,
as you may know GRASS modules are available in QGIS through the
QGIS/GRASS plugin but also through Processing (ex Sextante), that makes it particularly easy to use them because users don’t
need to know about locations/mapsets.
A few GRASS modules are not available in the Processing toolbox,
but with a little help this would be probably possible. We are looking
for help (a not too advanced python knowledge should be enough) in adding them.
As it stands now Processing always expects a GRASS module to create
one (or more outputs) from one (or more) inputs. There are obvious
exceptions to this, examples:
- r.ros (maybe others): the output in this GRASS module is just a
prefix for 3/4 output maps with an hardcoded name. Processing does not
actually support such case.
I’ve modified r.ros and r.rgb in r63777 and r63796 but there are other which needs the same, I named at least some of them in #2409, comment 182:
I cannot work on this more but similar change as I did for r.rgb could be done for 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 i.pansharpen and i.topo.corr.
Some other seems that they don’t need this change (e.g., i.pca, i.landsat.toar, i.landsat.acca, and 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 r.texture where the number of outputs depends on number of requested textures. r.neighbors actually solves this issue by using output not as a basename but as multiple and requesting as many outputs as requested methods
Please read the following to understand more about the issues and possible possible solutions:
http://trac.osgeo.org/grass/ticket/2409#comment:12
http://trac.osgeo.org/grass/ticket/2409#comment:13
http://trac.osgeo.org/grass/ticket/2409#comment:14
http://trac.osgeo.org/grass/ticket/2409#comment:17
http://trac.osgeo.org/grass/ticket/2409#comment:179
http://trac.osgeo.org/grass/ticket/2409#comment:182
http://trac.osgeo.org/grass/ticket/2136
*r.null/v.distance: this modules modify the input layer instead of
creating a new output
In case of r.null it seems like a purpose of the module but maybe it’s just point of view. In case of vector modules, they modify very often, especially attribute table.
- r.mapcalc: in Processing there is already r.mapcalculator, but it is
limited to 6 inputs. R.mapcalc is missing because it uses real map
name instead of parameters like “A”, because it is not limited to 6
inputs and because Processing uses random names for temporary input
GRASS layers
See the following for discussion:
http://trac.osgeo.org/grass/ticket/2409#comment:187
http://trac.osgeo.org/grass/ticket/2409#comment:190
- a few modules would benefit from a coordinate picker from the QGIS
map canvas. There is already something similar that allows to choose
(from canvas) the region size, so it should be relatively simple
In case of coordinates, this should be able to guess from:
gisprompt: old,coords,coords
The rest is up to the wrapper.
However, there are some other places where GRASS GIS could do a better job. Namely, there are standard options but they are “write only”, i.e. you create an option in standard way but then the information is lost. This is issue in GRASS itself, for example --script will not give you standard options, you have to go to the source code which in this case throws away convenience of --script.
- support GRASS layers as input: at the moment Processing imports
vector/raster data (non GRASS) and place them on the fly in a
temporary mapset, then runs the GRASS module against them. As QGIS can
use GRASS data it would be nice to support them also in Processing, it
would obviously necessary to skip the import (and eventually export)
phase.
…and the other layers could be linked rather than imported (± projection). This is not something which GRASS can help with unless we decide to build some addition interface which would call GRASS modules from command line and would import/export/link the maps/layers on the fly. Something like:
grass70 r.lake elevation=file:///some/file.tiff water_level=10 lake=file:///some/new/file.tiff coordinates=100,520
This idea could be modified to some git/svn/sqlite3/geogig approach with grass init EPSG:...
, grass r.external ...
, grass r.lake elevation=map...
but that’s another story. Perhaps a GSoC idea?
Vaclav
for who may be interested this is good starting point
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass/GrassAlgorithm.py
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev