[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
GRASS GIS
trac at osgeo.org
Fri Feb 20 05:32:43 PST 2015
#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options | Platform: Unspecified
Cpu: Unspecified |
----------------------------------+-----------------------------------------
Comment(by wenzeslaus):
Replying to [comment:194 neteler]:
> r.mapcalculator was proposed to be removed if not needed by QGIS
Processing. I wonder how harmful it is to just keep it.
`r.mapcalculator` documentation should say that it is only for QGIS and it
should not be used by others because it is not guaranteed.
I have very limited QGIS Processing knowledge but I guess QGIS Processing
still needs `r.mapcalculator` because there is not way how QGIS Processing
can know which maps to import and which maps to export. From my
understanding, the only way to know would be if standard `r.mapcalc` would
offer a flag (e.g. `-l`) which lists the inputs and output(s?):
{{{
> r.mapcalc -l "test1 = test2 + test3 + 5"
input=test2,test3
output=test1
}}}
and does only the parsing, not the actual computation. In GRASS GIS, this
could be used for example, by GUI to validate the expression. Instead of
flag, a separate module can be used (as mentioned in comment:190).
I'm not sure how serious it is but as mentioned in comment:187,
`r.mapcalculator` is a Shell script and Shell script are no longer
supported by standalone GRASS GIS. But perhaps it is not an issue because
QGIS installs its own GRASS GIS on MS Windows, OSGeo4W probably contains
some shell and all systems except for MS Windows just have some shell.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2409#comment:195>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list