[GRASS-dev] [bug #4742] (grass) i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use g.region

[Hamish]

> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4742
> > > -----------------------------------------------------------------
> > > 
> > > Subject: i.fusion.brovey, i.in.spotvgt, v.rast.stats: don't use
> > > g.region
> > > 
> > > Glynn wrote on the grass-dev:
> > > 
> > > > scripts shouldn't modify the WIND file unless persistently
> > > > changing the current region is the script's intended function.
> > > 
> > > > use either WIND_OVERRIDE or GRASS_REGION (the latter is cleaner,
> > > > but the former is probably easier).

in practice WIND_OVERRIDE is actually more work? see below.


Markus:
> i.in.spotvgt: it is an import script. The GRASS import commands are
>  expected to import a full map at original resolution. The internal
>  bit shuffling must therefore be done at the original map region
>  and resolution. The script saves the current user region and restores
>  it back.

(guessed) current region usage:

g.region save=region.save
g.region rast=$input
do_stuff()
g.region region.save
g.remove region=region.save

same thing, using WIND_OVERRIDE:

g.region save=region.save
g.region rast=$input
g.region save=region.tmp
g.region region.save
WIND_OVERRIDE=region.tmp
export WIND_OVERRIDE
do_stuff()
unset WIND_OVERRIDE   # unneeded if script exits, but good hygiene
g.remove region=region.save,region.tmp


the current way seems simpler to me - with the problem that if the
script exits prematurely you will be left in a different region than the
one you started in.

using g.region is much better than hacking a WIND file directly - parity
checking, etc. This is a danger with using GRASS_REGION=""

 
> i.fusion.brovey: Please look at the algorithm, it makes no sense to
>  to operate at user (random) resolution. But i.fusion.brovey saves the
>  region and restores it back as well.
>  Discussion: only fetch raster map resolution, but operate in user
>  region - feel free to implement this.

but,but,but ... "g.region -a" is needed in this case which can change
the bounds too?
 
> v.rast.stats: uses resolution of queried raster map (I don't think
>  that it makes too much sense to work at arbitray resolutions) but
>  respects the user defined coordinates. The script saves the current
>  region and restores it back.

again, is "g.region -a" needed here?



For C (and SWIG) modules, I think we need a lib fn like

char * G_window_string(cellhd); 

(any better G_() name?)

that will form a GRASS_REGION string from a cell-head structure.
maybe check that it is valid also (rows*nsres=ns_extent etc)??

with scripts I guess you could do

eval `g.region -g`
GRASS_REGION="north:$n;south:$s;..."
 or

ORIGINAL_REGION=`g.region -p | tr '\n' ';' | sed -e 's/ //g' -e 's/;$//'`
RES=50
GRASS_REGION=`echo "$ORIGINAL_REGION" | sed -e "s/nsres:[^;]/nsres:$RES/"`


in any case I think (with error checking) we should favour GRASS_REGION
over WIND_OVERRIDE as a cleaner solution. With a C lib fn it shouldn't
be any more work to create.


Hamish