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

Michael Barton michael.barton at asu.edu
Mon Oct 9 23:55:23 EDT 2006 

The issue is that you can't get a check box for the --o flag out of the
parser. You need to specify a flag with a single letter AFAIK. You have to
specify it as "o" in the script header that creates the GUI, which makes it
come out as -o if you run the script from the command line. I want users to
have a check box to overwrite or not overwrite the MASK.

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

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



> From: "Patton, Eric" <epatton at nrcan.gc.ca>
> Date: Mon, 9 Oct 2006 22:45:16 -0300
> To: 'Michael Barton ' <michael.barton at asu.edu>, 'Hamish '
> <hamish_nospam at yahoo.com>, 'Glynn Clements ' <glynn at gclements.plus.com>,
> ''GRASS devel ' ' <grass-dev at grass.itc.it>
> Subject: RE: raster MASKs; was [GRASS-dev] interferring ovewrite flags
> 
> If the parser overwrite (--o) is sufficient to overwrite a mask in r.mask,
> is it possible to nix the -o flag? Probably don't need the redunant
> fuctionality.
> 
> ~ Eric.
> 
> -----Original Message-----
> From: grass-dev-bounces at grass.itc.it
> To: Hamish; Glynn Clements; 'GRASS devel '
> Sent: 10/9/2006 12:44 PM
> Subject: Re: raster MASKs; was [GRASS-dev] interferring ovewrite flags
> 
> 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.
>>> 
>>> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

More information about the grass-dev mailing list