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

[Michael Barton]

OK. Thanks. It took a bit of re-reading this to get it all--and to connect
the dots with your initial post. I think the r.mask script does not have
these issues because it uses r.reclass (like the original GRASS 5 r.mask
did), but it is a good reason for caution when using r.mapcalc to create a
MASK. Just to make sure I've got it, could you check my comments below?

Thanks
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Hamish <hamish_nospam at yahoo.com>
> Date: Mon, 2 Oct 2006 20:37:36 +1300
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <grassuser at grass.itc.it>
> Subject: Re: raster MASKs; was [GRASS-dev] interferring ovewrite flags
> 
> 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

These commands do NOT respect a MASK ???

> 
> 
> 
> 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

r.mapcalc will respect a MASK ONLY if the formula to create a new map
includes an existing map (i.e., read from disk).

A new map created from a formula that does NOT include an existing map will
NOT respect a MASK, even though it may APPEAR to do so when you display it
using d.rast with a MASK in place--because d.rast DOES respect a MASK.

> 
> 
> 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?

I think so.

> 
> 

...From earlier message

> "additive" in a processing sense, not mathematical. (still 0|NULL,1)
> 
> 
> for example:  (spearfish)
> 
> r.mapcalc MASK='if(isnull(roads))'

MASK created with holes for roads

> r.mapcalc MASK=fields

r.mapcalc reads map "fields", respecting MASK that leaves holes for roads,
and writes new MASK with fields but without roads.

> d.rast elevation.dem

d.rast respects new MASK that is limited to fields without roads.

> 
> shows elevation where there is fields but no roads, as fields is read
> in with a mask in place.