[GRASS-dev] Fwd: QGIS Processing & GRASS

[Vaclav Petras]

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 at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150111/79660ab0/attachment.html>