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

Hamish hamish_nospam at yahoo.com
Mon Oct 2 03:37:36 EDT 2006

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

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:
* raster/r.null/null.c


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.



More information about the grass-user mailing list