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

[Michael Barton]

Back to the original question.

I'd like users to be able to choose to overwrite an existing MASK from the
GUI in r.mask. 

AFAICT, this is only possible by making an overwrite flag of some kind in
the script. Currently it is -o (unless someone has changed it). The
system-wide flag --o also causes the script to be in overwrite mode. So what
is the best solution?

1) leave it as is (-o and --o will overwrite the existing MASK). Is this
really a problem?
2) make the flag another letter (Glynn nixed -f)?
3) a different solution that I haven't thought of?

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: Tue, 3 Oct 2006 14:32:07 +1300
> To: Michael Barton <michael.barton at asu.edu>
> Cc: <isaac.ullah at asu.edu>
> Subject: Re: raster MASKs; was [GRASS-dev] interferring ovewrite flags
> 
> Yes, you've got it. Glynn has answered on the list better than I could
> have, so I'll leave it there.
> 
> I'm not sure how well any of this is documented; should probably go in
> the r.mask help page. Perhaps the GRASS 5 programmers' manual has it
> written up nicely already?
> 
> 
> Hamish
> 
> 
> 
> Michael Barton wrote:
>> 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.
>> 
>>