[GRASS-dev] [GRASS GIS] #2032: r.mapcalc does not always respect MASK

#2032: r.mapcalc does not always respect MASK
-------------------------+--------------------------------------------------
Reporter: pvanbosgeo | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.mapcalc | Platform: Linux
      Cpu: Unspecified |
-------------------------+--------------------------------------------------
If I run:

{{{
r.mask raster=mymask
r.mapcalc "test1 = 1"
r.mapcalc "test2 = test1"
r.mask -r
}}}

The layer ''test1'' has value 1 for all raster cells within the current
region. In layer ''test2'' only cells within the masked area have the
value 1, cells outside the mask have nodata, as I would expect.

Running GRASS 7.0 rv 57144 on Ubuntu 13.04

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2032&gt;
GRASS GIS <http://grass.osgeo.org>

#2032: r.mapcalc does not always respect MASK
-------------------------+--------------------------------------------------
  Reporter: pvanbosgeo | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Resolution: invalid | Keywords: r.mapcalc
  Platform: Linux | Cpu: Unspecified
-------------------------+--------------------------------------------------
Changes (by mmetz):

  * status: new => closed
  * resolution: => invalid

Comment:

Replying to [ticket:2032 pvanbosgeo]:
> If I run:
>
{{{
r.mask raster=mymask
r.mapcalc "test1 = 1"
r.mapcalc "test2 = test1"
r.mask -r
}}}
>
> The layer ''test1'' has value 1 for all raster cells within the current
region. In layer ''test2'' only cells within the masked area have the
value 1, cells outside the mask have nodata, as I would expect.

From the raster intro [0]:
"Raster input maps are automatically masked if a raster map named MASK
exists. The MASK is only applied when ''reading'' maps from the disk."

A MASK is not applied when writing out files. If you set the output cell
value to constant 1, all output cells will have the value 1, even if a
MASK was set while writing the output raster.

[0] http://grass.osgeo.org/grass70/manuals/rasterintro.html

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2032#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#2032: r.mapcalc does not always respect MASK
-------------------------+--------------------------------------------------
  Reporter: pvanbosgeo | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Resolution: invalid | Keywords: r.mapcalc
  Platform: Linux | Cpu: Unspecified
-------------------------+--------------------------------------------------

Comment(by pvanbosgeo):

OK, thanks, I didn't know that / hadn't read that part of the manual
carefully enough. Perhaps not something that the user will encounter
often, but nonetheless, it is something I can see others might overlook as
well when using r.mapcalc. Perhaps a short note of this can be added to
the r.mapcalc help file (which is where I looked to see where my
expectations of the behavior of r.mapcalc were wrong)?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2032#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#2032: r.mapcalc does not always respect MASK
-------------------------+--------------------------------------------------
  Reporter: pvanbosgeo | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Resolution: invalid | Keywords: r.mapcalc
  Platform: Linux | Cpu: Unspecified
-------------------------+--------------------------------------------------

Comment(by glynn):

Replying to [comment:2 pvanbosgeo]:
> OK, thanks, I didn't know that / hadn't read that part of the manual
carefully enough. Perhaps not something that the user will encounter
often, but nonetheless, it is something I can see others might overlook as
well when using r.mapcalc. Perhaps a short note of this can be added to
the r.mapcalc help file (which is where I looked to see where my
expectations of the behavior of r.mapcalc were wrong)?

The behaviour isn't specific to r.mapcalc. Except for a few special cases,
the MASK behaviour isn't implemented by the individual modules, but by the
raster I/O library. You can observe the same behaviour with e.g.
r.neighbors.

The correct place to document this behaviour is wherever the MASK
behaviour is described, e.g. the rasterintro manual page and the r.mask
manual page. FWIW, the first sentence of the DESCRIPTION section of the
r.mask manual page (after the summary) is:
{{{
The MASK is only applied when reading an existing GRASS raster map,
for example when used in a module as an input map.
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2032#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

On Tue, Jul 16, 2013 at 8:26 PM, GRASS GIS <trac@osgeo.org> wrote:

#2032: r.mapcalc does not always respect MASK

-------------------------+--------------------------------------------------
  Reporter: pvanbosgeo | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Resolution: invalid | Keywords: r.mapcalc
  Platform: Linux | Cpu: Unspecified

-------------------------+--------------------------------------------------

Comment(by glynn):

Replying to [comment:2 pvanbosgeo]:
> OK, thanks, I didn't know that / hadn't read that part of the manual
carefully enough. Perhaps not something that the user will encounter
often, but nonetheless, it is something I can see others might overlook as
well when using r.mapcalc. Perhaps a short note of this can be added to
the r.mapcalc help file (which is where I looked to see where my
expectations of the behavior of r.mapcalc were wrong)?

The behaviour isn't specific to r.mapcalc. Except for a few special cases,
the MASK behaviour isn't implemented by the individual modules, but by the
raster I/O library. You can observe the same behaviour with e.g.
r.neighbors.

  The correct place to document this behaviour is wherever the MASK

behaviour is described, e.g. the rasterintro manual page and the r.mask
manual page. FWIW, the first sentence of the DESCRIPTION section of the
r.mask manual page (after the summary) is:
{{{
The MASK is only applied when reading an existing GRASS raster map,
for example when used in a module as an input map.
}}}

Just to clarify, of course the behaviour should be mentioned in the
mentioned manual pages. I merely suggested to add a reminder for this part
of the behaviour of MASK in the help file of r.mapcalc.

The reason I think such a reminder might be helpful is that modules like
r.neighbors always require an existing map as input and therefore the MASK
will normally be respected. For most other modules there is no reading of
an input map and thus the MASK has normally not influence (e.g.,
r.surf.fractal). For r.mapcalc, both are possible.

BTW, is the mentioning in e.g., the help file of r.neighbor that it
respects existing MASK not just that; a (useful imho) reminder of the
default behaviour mentioned in the raster intro page, viz.
"Raster input maps are automatically masked if a raster map named MASK
exists."?

Anyway, just to clarify my initial suggestion. I probably will not forget
this behaviour anyway :-).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2032#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

Paulo van Breugel wrote:

The reason I think such a reminder might be helpful is that modules like
r.neighbors always require an existing map as input and therefore the MASK
will normally be respected.

"Respected" in the sense that the input will be masked. But
r.neighbors computes the aggregate over the non-null neighbours, so it
will typically write non-null values to some of the cells which are
masked (more specifically, the masked regions will tend to shrink by
the neighbourhood radius).

--
Glynn Clements <glynn@gclements.plus.com>