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.
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
From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 3 Oct 2006 14:32:07 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <isaac.ullah@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
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 2 Oct 2006 20:37:36 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grassuser@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.
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
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.
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
From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 3 Oct 2006 14:32:07 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <isaac.ullah@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
From: Hamish <hamish_nospam@yahoo.com>
Date: Mon, 2 Oct 2006 20:37:36 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grassuser@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.
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.
That's a problem with the GUI, not the parser.
As every module supports --o, the GUI should unconditionally add a
checkbox for overwrite. It shouldn't expect the parser to tell it to
do so.
The parser can't report --o etc as normal flags, because they aren't
normal flags; e.g. you can't combine them ("-x -y -z" can be
abbreviated to "-xyz", but that doesn't work with the "--" flags).
I've never really touched g.module and so don't really know how it works. I
can try to look into to this for 6.3.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Adding the --o etc flags would need an extension to the syntax (we
can't use add_flag, because they aren't like other flags). I'll look
into it.
I've committed changes to parser.c and gui.tcl to pass the --overwrite
flag to the GUI code. I don't know whether d.m/gis.m will need any
changes; please test.
Thanks again Glynn. I'll try to test as soon as I can.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
From: Glynn Clements <glynn@gclements.plus.com>
Date: Wed, 11 Oct 2006 09:30:54 +0100
To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>,
<grass-dev@grass.itc.it>
Subject: Re: raster MASKs; was [GRASS-dev] interferring ovewrite flags
Glynn Clements wrote:
Adding the --o etc flags would need an extension to the syntax (we
can't use add_flag, because they aren't like other flags). I'll look
into it.
I've committed changes to parser.c and gui.tcl to pass the --overwrite
flag to the GUI code. I don't know whether d.m/gis.m will need any
changes; please test.