On Thu, Nov 10, 2016 at 5:27 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
[was: Adding an expert mode to the parser]
On Sun, Sep 25, 2016 at 10:16 PM, Vaclav Petras <wenzeslaus@gmail.com>
wrote:
On Sun, Sep 25, 2016 at 5:40 PM, Sören Gebbert
<soerengebbert@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@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@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@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@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