#2986: r.mapcalc with same variable on LHS and RHS
--------------------------+-------------------------
Reporter: mankoff | Owner: grass-dev@…
Type: defect | Status: closed
Priority: major | Milestone: 7.0.4
Component: Docs | Version: 7.0.3
Resolution: fixed | Keywords: r.mapcalc
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by glynn):
Replying to [comment:8 mankoff]:
> I'm still confused. The specific case of {{{r.mapcalc 'map=map'}}}
mentioned 2 comments above does seem to work for me in v7.0.3 (see code
example below).
If the map had categories or quantisation rules, they will be discarded. A
colour table should also be discarded but isn't because
Rast_remove_colors(mapname,"") doesn't work (it compares the mapset
literally with the current mapset without checking for the empty string).
> Also, the last comment appears to say that everything on the LHS, even
if a new unique LHSname, will be a variable and not a map (I'm not even
sure what "variables" are in GRASS).
The result of any expression can be assigned to a variable; that's what
"=" does. If the assignment is a top-level expression (i.e. not a sub-
expression), the value is written to an output map with the same name as
the variable. Assignments other than at the top level (e.g. within eval(),
which exists for this specific purpose) don't generate an output map. E.g.
the i.pansharpen script uses the following r.mapcalc expression:
{{{
eval(k = "$ms1" + "$ms2" + "$ms3")
"$outr" = 1.0 * "$ms3" * "$panmatch3" / k
"$outg" = 1.0 * "$ms2" * "$panmatch2" / k
"$outb" = 1.0 * "$ms1" * "$panmatch1" / k
}}}
Here, k is just a variable; because it occurs as a sub-expression of the
eval() call rather than as a top-level expression, it doesn't result in an
output map named "k". Its value is used in the subsequent expressions,
avoiding the need to repeat the calculation for each one.
Regardless of whether a variable is written to an output map, it's still a
variable (i.e. something which is calculated for each row), not an input
map (thus you cannot use any modifiers on it). If you use a name for both
a variable and an input map, the variable hides the input map for all
expressions following the assignment which creates the variable.
> Finally, would it be possible to change this behavior, so that
{{{r.mapcalc 'map = map * 2'}}} is valid syntax?
No. It's already syntactically valid, the issue is that modifying a map
while it is being read is undefined behaviour which only "sort-of" works
(e.g. it may not work at all if r.external and r.external.out are in use
such that the input and output maps refer to the same data file). That's
an issue with the core GRASS libraries, and not something which r.mapcalc
can realistically work around.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2986#comment:9>
GRASS GIS <https://grass.osgeo.org>