[GRASS-user] Re: raster MASKs; was [GRASS-dev] interferring ovewrite flags

[Hamish]

Michael Barton wrote:
> 
> Right. I understand, even if I didn't phrase it that way. Does this
> happen for any r.mapcalc processing using the same procedures or just
> ones in which MASK is the result? Also, is it always an "and" or can
> you also get the effects of an "or"? Definitely a 'gotcha' to watch
> out for. I'm concerned especially because we are doing a lot of
> iterative r.mapcalc processing in scripts and this could be a problem.


The MASK is generally applied when a row of input data is read from the
disk.

A module scan specifically ask to ignore the MASK, but the vast vast
majority of raster modules process data by row (to save memory), and use
G_get_raster_row() to do that.

G_get_raster_row_nomask() is the non-masking version. Things that use it:
  display/d.rast.edit/mk_tmp_file.c
  imagery/i.rectify/perform.c
  imagery/i.ortho.photo/photo.rectify/perform.c
  raster/r.compress/main.c
  raster/r.le/r.le.patch/driver.c
  raster/r.le/r.le.patch/trace.c
  raster/r.le/r.le.pixel/cellclip.c
  raster/r.le/r.le.pixel/driver.c
* raster/r.null/null.c



So:

r.mapcalc MASK='if(isnull(roads))'
r.mapcalc MASK=fields
d.rast elevation.dem   # displays with holes
r.mapcalc one=1        # full coverage once MASK is removed
r.mapcalc two=elevation.dem  # holes once MASK is removed
g.remove MASK
d.rast one
d.rast two


the numeric mapcalc cmd hasn't read a map from the disk, so in fact it
is a solid block. The "two" map has read, so in fact contains holes.
If the "one" map is displayed with a MASK in place, it appears to have
holes in it, but these are introduced when d.rast loads the map to
display it.


clear?


Hamish