<div dir="ltr">Well, this email is older but was never answered. I guess in most cases the situation is still the same.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 3:45 PM, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p>Forwarded message from Giovanni Manghi:</p>
<p>Hi all,</p>
<p>as you may know GRASS modules are available in QGIS through the<br>
QGIS/GRASS plugin but also through Processing (ex Sextante), that makes it particularly easy to use them because users don't<br>
need to know about locations/mapsets.</p>
<p>A few GRASS modules are not available in the Processing toolbox,<br>
but with a little help this would be probably possible. We are looking<br>
for help (a not too advanced python knowledge should be enough) in adding them.</p>
<p>As it stands now Processing always expects a GRASS module to create<br>
one (or more outputs) from one (or more) inputs. There are obvious<br>
exceptions to this, examples:</p>
<p>* r.ros (maybe others): the output in this GRASS module is just a<br>
prefix for 3/4 output maps with an hardcoded name. Processing does not<br>
actually support such case.</p></blockquote><div>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:<br><br>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".<br><br>There are some other modules I'm not completely sure about such as i.pansharpen and i.topo.corr.<br><br>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.<br><br>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<br><br></div><div>Please read the following to understand more about the issues and possible possible solutions:<br></div><div><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:12">http://trac.osgeo.org/grass/ticket/2409#comment:12</a><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:13">http://trac.osgeo.org/grass/ticket/2409#comment:13</a><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:14">http://trac.osgeo.org/grass/ticket/2409#comment:14</a><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:17">http://trac.osgeo.org/grass/ticket/2409#comment:17</a><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:179">http://trac.osgeo.org/grass/ticket/2409#comment:179</a><br><a href="http://trac.osgeo.org/grass/ticket/2409#comment:182">http://trac.osgeo.org/grass/ticket/2409#comment:182</a><br><a href="http://trac.osgeo.org/grass/ticket/2136">http://trac.osgeo.org/grass/ticket/2136</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>*r.null/v.distance: this modules modify the input layer instead of<br>
creating a new output</p></blockquote><div>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. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>* r.mapcalc: in Processing there is already r.mapcalculator, but it is<br>
limited to 6 inputs. R.mapcalc is missing because it uses real map<br>
name instead of parameters like "A", because it is not limited to 6<br>
inputs and because Processing uses random names for temporary input<br>
GRASS layers</p></blockquote><div>See the following for discussion:<br></div><div> </div><div><a href="http://trac.osgeo.org/grass/ticket/2409#comment:187">http://trac.osgeo.org/grass/ticket/2409#comment:187</a> <br></div><div><a href="http://trac.osgeo.org/grass/ticket/2409#comment:190">http://trac.osgeo.org/grass/ticket/2409#comment:190</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>* a few modules would benefit from a coordinate picker from the QGIS<br>
map canvas. There is already something similar that allows to choose<br>
(from canvas) the region size, so it should be relatively simple</p></blockquote><div>In case of coordinates, this should be able to guess from:<br><br>gisprompt: old,coords,coords<br><br></div><div>The rest is up to the wrapper.<br><br>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>* support GRASS layers as input: at the moment Processing imports<br>
vector/raster data (non GRASS) and place them on the fly in a<br>
temporary mapset, then runs the GRASS module against them. As QGIS can<br>
use GRASS data it would be nice to support them also in Processing, it<br>
would obviously necessary to skip the import (and eventually export)<br>
phase.</p></blockquote><div>...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:<br><br></div><div>grass70 r.lake elevation=file:///some/file.tiff water_level=10 lake=file:///some/new/file.tiff coordinates=100,520<br><br></div><div>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?<br><br></div><div>Vaclav<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p>for who may be interested this is good starting point</p>
<p><a href="https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass/GrassAlgorithm.py" target="_blank">https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/grass/GrassAlgorithm.py</a></p>
<br>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br></blockquote></div><br></div></div></div>