r.mapcalculator script for QGIS processing

[neteler]

A wish received via personal email:

On Mon, Oct 23, 2017 at 10:06 AM, a QGIS developer wrote:

it would be great to have the GRASS raster calculator back in Processing. Since GRASS7 r.mapcalculator been "lost" in Processing (because it also has not been ported from GRASS64 to 7, correct?) and the attempt to make r.mapcalc work was not completely successful (see: ​https://issues.qgis.org/issues/6894) If you could help with that it would be *much* appreciated!

The old parameters were:

https://grass.osgeo.org/grass64/manuals/r.mapcalculator.html

Apparently the interest in the QGIS community is high to get a wrapper back as it used to exist in G6.

[neteler]

Ticket retargeted after milestone closed

[martinl]

All enhancement tickets should be assigned to 7.6 milestone.

[Neteler]

How hard would it be to implement a simple solution?

[wenzeslaus]

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, ​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.

[wenzeslaus]

See sandbox for source code (Subversion history preserved, but it is a complete rewrite anyway):

source:sandbox/wenzeslaus/r.mapcalculator​ (r73642)

Usage:
 r.mapcalculator [-sqc] expression=string [a=name] [b=name] [c=name]
   [d=name] [e=name] [f=name] output=value [seed=value] [--help]
   [--verbose] [--quiet] [--ui]

Flags:
  -s   Generate random seed (result is non-deterministic)
  -q   Quote the map names
  -c   Case sensitive variable names

Parameters:
  expression   Formula (e.g. A-B or A*C+B)
           a   A
           b   B
           c   C
           d   D
           e   E
           f   F
      output   Name for output raster map
        seed   Seed for rand() function

r.mapcalculator expression="0" output=zeros
r.mapcalculator expression="1" output=ones
r.mapcalculator expression="2" output=twos
r.mapcalculator expression="(A * B) / 2 + 3 * C" a=zeros b=ones c=twos output=result2

If you don't have sandbox repo, you can install also using:

g.extension r.mapcalculator url=https://trac.osgeo.org/grass/browser/sandbox/wenzeslaus/r.mapcalculator

I tried to cover in the documentation what are the differences to 5/6 version and r.mapcalc. Let me know what you think!

[neteler]

Great work! Successfully tested by Giovanni Manghi in QGIS (reported to me via personal email).

[neteler]

Replying to wenzeslaus:

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.

How about: r.mapcalc.simple ?

[wenzeslaus]

Replying to neteler:

Replying to wenzeslaus:

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.

How about: r.mapcalc.simple ?

This works for me. It is to certain extent applicable to other modules, it is similar to the names of pseudo-modules in QGIS, and we can call the raster algebra in this module a simple raster algebra or a simplified raster algebra.

5) We need test for moving this to the core.

6) Are we backporting it to 7.6?

[neteler]

Replying to wenzeslaus:

Replying to neteler:

How about: r.mapcalc.simple ?

This works for me. It is to certain extent applicable to other modules, it is similar to the names of pseudo-modules in QGIS, and we can call the raster algebra in this module a simple raster algebra or a simplified raster algebra.

Yes, fine.

5) We need test for moving this to the core.

Please do :)

6) Are we backporting it to 7.6?

Yes, please. It is requested frequently and will not break anything.

[PedroNGV]

Replying to neteler:

6) Are we backporting it to 7.6?

Yes, please. It is requested frequently and will not break anything.

Hi all,

Can it be backported to 7.4 also? It would be good to use with QGIS 2.18.

Thanks!

[hellik]

Replying to PedroNGV:

Replying to neteler:

6) Are we backporting it to 7.6?

Yes, please. It is requested frequently and will not break anything.

Hi all,

Can it be backported to 7.4 also? It would be good to use with QGIS 2.18.

Thanks!

what is the reason not to use QGIS 3.x? it's pretty stable now.

the focus of GRASS will be in the next step of releases, See

​https://lists.osgeo.org/pipermail/grass-dev/2018-November/090600.html

[PedroNGV]

Replying to hellik:

Replying to PedroNGV:

Replying to neteler:

6) Are we backporting it to 7.6?

Yes, please. It is requested frequently and will not break anything.

Hi all,

Can it be backported to 7.4 also? It would be good to use with QGIS 2.18.

Thanks!

what is the reason not to use QGIS 3.x? it's pretty stable now.

the focus of GRASS will be in the next step of releases, See

​https://lists.osgeo.org/pipermail/grass-dev/2018-November/090600.html

QGIS 2.18 will be the LTR version until 22-02-2019. Besides that, as much of QGIS plugins were not yet updated to Python 3 and so, to QGIS 3, it is expected that QGIS 2.18 keeps being used for quite some time.

But as GRASS roadmap is pointing 7.6 final release to the end of this year, that should be enough to introduce that version in QGIS 2.18!

Thanks for the info about the release roadmap!

[neteler]

Replying to wenzeslaus:

5) We need test for moving this to the core.

Test case added in r73751.

[neteler]

If there are no objections, I'll move the r.mapcalculator in the sandbox SVN to trunk, renaming it to r.mapcalc.simple

[martinl]

Replying to neteler:

If there are no objections, I'll move the r.mapcalculator in the sandbox SVN to trunk, renaming it to r.mapcalc.simple

+1

[neteler]

Replying to neteler:

If there are no objections, I'll move the r.mapcalculator in the sandbox SVN to trunk, renaming it to r.mapcalc.simple

Moved to trunk in r73791. Please test.

Keeping open for backport.

[martinl]

In 73794:

r.mapcalc.simple: more guisections, description cosmetics, see #3431

[martinl]

Any idea where to put to the menu? Raster -> Simplified raster map calculator?

[neteler]

Replying to neteler:

Keeping open for backport.

backported in r73803 (relbranch76) and r73804 (relbranch74)

Open: menu entry

[martinl]

Menu entry added in r73829, see screenshot below

[martinl]

Is it r73829 acceptable for backporting into g76 release branch?

[martinl]

Replying to neteler:

backported in r73803 (relbranch76) and r73804 (relbranch74)

I would include r.mapcalc.simple as a new module to GRASS 7.6.0. Why there is also backport to 7.4 release branch than? When 7.6.0 will be out than it will be integrated into QGIS.

[neteler]

Replying to martinl:

Replying to neteler:

backported in r73803 (relbranch76) and r73804 (relbranch74)

I would include r.mapcalc.simple as a new module to GRASS 7.6.0. Why there is also backport to 7.4 release branch than? When 7.6.0 will be out than it will be integrated into QGIS.

Right. An indeed the really important point is to have Python3 support, means: get trunk out as stable version.

[martinl]

Replying to martinl:

Is it r73829 acceptable for backporting into g76 release branch?

I took liberty to backport menu changes to g76 in r73880. Not so satisfied with Raster map calculator -> Raster map calculator menu entry? Any better idea?

[martinl]

Replying to martinl:

Replying to neteler:

backported in r73803 (relbranch76) and r73804 (relbranch74)

I would include r.mapcalc.simple as a new module to GRASS 7.6.0. Why there is also backport to 7.4 release branch than? When 7.6.0 will be out than it will be integrated into QGIS.

well, depends what we want. If r.mapcalc.simple is planned to be included in last QGIS 2.18 release, there is last chance:

PR/FF 	3.4.4 	2.18.28 	3.5 	2019-01-18 	3 	5

In this case backport to 7.4 branch make sense. Then we could release 7.4.4 before 2019-01-18. Please note that also processing toolbox would need to be modified to include new GRASS module.

[martinl]

Original issue solved.