On Tue, Sep 27, 2016 at 5:38 PM, Sören Gebbert <soerengebb...@googlemail.com > wrote:
> However, the correct use of GRASS_REGION is still unclear to me. There is a function in grass.script [1] which can generate the right string. It calls g.region with -u, so you can modify the region with g.region, but without actually changing it. Then you just set the environmental variable for the process. If you anyway control the environment for the subprocess, I think, there is not much difference between GRASS_REGION and WIND_OVERRIDE expect for a file and length of command line. If the g.region code is moved to library (there might be some modules which would benefit from it) and parser accepts standard options with values, then parser could just set this variable in the same way it sets GRASS_OVERWRITE (to keep parser and rest of lib/gis separate - although this might not be an option anyway if it needs to use the g.region functions). [1] https://grass.osgeo.org/grass70/manuals/libpython/ script.html#script.core.region_env
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
