[GRASS-dev] Passing computational region to individual commands

[Markus Neteler]

On Thu, Nov 10, 2016 at 5:27 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> [was: Adding an expert mode to the parser]
>
> On Sun, Sep 25, 2016 at 10:16 PM, Vaclav Petras <wenzeslaus at gmail.com>
> wrote:
>>
>> On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert
>> <soerengebbert at googlemail.com> wrote:
>>>>
>>>> >r.mapclac --raster-region= --north= --south= --west= --east= --res=
>>>> >--ewres= --nsres= --vect-region --raster-align= ...
>>
>>
>> I like this in the sense that if the region setting for the module is
>> something which should be managed by these extra options, then they
should
>> be managed in parser, rather than introduced one by one for individual
>> modules.
>>
>> But how is this different from using GRASS_REGION? Convenience of
>> --raster-region=? Better syntax than environmental variable?
>
>
> It would work better when using GRASS GIS by grass command with --exec:
>
> grass72 /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation
> --region-raster=elevation
>
> which needs to be now done using two commands:
>
> grass72 /path/to/grassdata/test1/PERMANENT/ --exec g.region
raster=elevation
> grass72 /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation

Here another trick, using the GRASS_REGION variable:

# running "as usual":
[neteler at oboe ~]$ grass72 ~/grassdata/nc_spm_08_grass7/user1/ --exec
g.region -p
Cleaning up temporary files...
Starting GRASS GIS...
Executing <g.region -p> ...
projection: 99 (Lambert Conformal Conic)
zone:       0
datum:      nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:      220750
south:      220000
west:       638300
east:       639000
nsres:      1
ewres:      1
rows:       750
cols:       700
cells:      525000
Execution of <g.region -p> finished.
Cleaning up temporary files...

[neteler at oboe ~]$ grass72 ~/grassdata/nc_spm_08_grass7/user1/ --exec
r.univar elevation -g
Cleaning up temporary files...
Starting GRASS GIS...
Executing <r.univar elevation -g> ...
n=525000
null_cells=0
cells=525000
min=103.973014831543
max=131.708312988281
range=27.7352981567383
mean=120.934871230352
mean_of_abs=120.934871230352
stddev=6.60021004461348
variance=43.5627726330167
coeff_var=5.45765665226668
sum=63490807.3959351
Execution of <r.univar elevation -g> finished.
Cleaning up temporary files...

# change of region on the fly (region shifted towards south, lower
resolution):
[neteler at oboe ~]$ export GRASS_REGION="proj: 99;zone: 0;north:
220000;south: 219250;east: 639000;west: 638300;cols: 70;rows: 75;e-w resol:
10;n-s resol: 10;top: 1.000000000000000;bottom: 0.000000000000000;cols3:
700;rows3: 750;depths: 1;e-w resol3: 1;n-s resol3: 1;t-b resol: 1" ;
grass72 ~/grassdata/nc_spm_08_grass7/user1/ --exec r.univar elevation -g
Cleaning up temporary files...
Starting GRASS GIS...
Executing <r.univar elevation -g> ...
n=5250
null_cells=0
cells=5250
min=98.3359756469727
max=125.935424804688
range=27.5994491577148
mean=115.330883091518
mean_of_abs=115.330883091518
stddev=5.63072216279044
variance=31.7050320745394
coeff_var=4.88223276528831
sum=605487.136230469
Execution of <r.univar elevation -g> finished.
Cleaning up temporary files...


BTW: The GRASS_REGION syntax I generated like this:

[neteler at oboe ~]$ cat ~/grassdata/nc_spm_08_grass7/user1/WIND | tr -s ' ' '
' | tr '\n' ';'
proj: 99;zone: 0;north: 220750;south: 220000;east: 639000;west:
638300;cols: 700;rows: 750;e-w resol: 1;n-s resol: 1;top:
1.000000000000000;bottom: 0.000000000000000;cols3: 700;rows3: 750;depths:
1;e-w resol3: 1;n-s resol3: 1;t-b resol: 1;

... and then modified it accordingly to my needs.

GRASS_REGION does not affect the stored computational region (i.e. the WIND
file) but appears to be only used by the following module call.

Markus

-- 
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161123/83aad546/attachment.html>