<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 5:38 PM, Sören Gebbert <span dir="ltr"><<a href="mailto:soerengebbert@googlemail.com" target="_blank">soerengebbert@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">However, the correct use of GRASS_REGION is still unclear to me.</blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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).<br></div><div class="gmail_extra"><br>[1] <a href="https://grass.osgeo.org/grass70/manuals/libpython/script.html#script.core.region_env" target="_blank">https://grass.osgeo.org/<wbr>grass70/manuals/libpython/<wbr>script.html#script.core.<wbr>region_env</a><br></div></div>