[GRASS-dev] [GRASS GIS] #3431: r.mapcalculator script for QGIS processing

[GRASS GIS]

#3431: r.mapcalculator script for QGIS processing
-------------------------+-------------------------------------------------
  Reporter:  neteler     |      Owner:  wenzeslaus
      Type:              |     Status:  new
  enhancement            |
  Priority:  normal      |  Milestone:  7.6.0
 Component:  Python      |    Version:  7.2.2
Resolution:              |   Keywords:  r.mapcalculator, r.mapcalc,
       CPU:              |  r3.mapcalculator, r3.mapcalc, QGIS
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------
Changes (by wenzeslaus):

 * keywords:  r.mapcalculator, r.mapcalc => r.mapcalculator, r.mapcalc,
     r3.mapcalculator, r3.mapcalc, QGIS
 * owner:  grass-dev@… => wenzeslaus


Comment:

 1) Here things I plan to use to get started implementing a simple
 solution, i.e. what was in 6.4. Please, let me know if you know about
 more.

 *
 source:grass/branches/releasebranch_6_4/scripts/r.mapcalculator/r.mapcalculator
 *
 source:grass/branches/releasebranch_6_4/scripts/r3.mapcalculator/r3.mapcalculator
 * r67000 list maps flag (#2592)

 2) Also, [https://issues.qgis.org/issues/6894#note-25 QGIS issue 6894,
 note 25] says:

 > Victor had created a new raster calculator using native QGIS
 classes...But in QGIS 2.x, r.mapcalc is still a must needed algorithm

 So will this be even used? This being useful for other programs would be a
 good reason to have this.

 3) Related to the generalization. What about other algebra modules, e.g.
 t.rast.mapcalc? Do we need a wrapper for each of those?

 4) Since the simple solution is keeping the functionality in a separate
 module, I suggest to rethink the name of the module. r.mapcalc versus
 r.mapcalculator​ might be little confusing.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3431#comment:6>
GRASS GIS <https://grass.osgeo.org>