Hi,
I've come across some trouble defining the computational region from pygrass:
If I understand correctly, Region.set_current() can be used
to effectively change the region currently used by GRASS. But changing
extent of Raster()-object and executing set_current() does not have
any effect.
Below is a minimal example.
Can somebody tell me if this is a bug or simply a misunderstanding from my site?
I am using GRASS GIS 7 (SVN rev 61281) on Linux Mint 17.
Thanks for any help.
Martin
minimal working example:
#!/usr/bin/env python
#-*- coding: utf-8 -*-
from grass.pygrass.gis.region import Region
from grass.pygrass.modules.shortcuts import raster as r, vector as v,
general as g, display as d
region = Region()
g.region(flags='p')
# here region information are still identical, Region() seems to be
initialized with current region
region.north += 100
region.east += 100
region.south -= 100
region.west -= 100
region.set_current()
region
g.region(flags='p')
# g.region(flags='p') still shows the old region settings, not the
enlarged region
r.mapcalc("test = 1")
# load in QGIS, is really size of old region
--
Martin Zbinden
Riedacker 523
3154 Rüschegg Heubach
+41 78 628 28 82
Hi Martin,
On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden
<martin.zbinden@gmail.com> wrote:
If I understand correctly, Region.set_current() can be used
to effectively change the region currently used by GRASS. But changing
extent of Raster()-object and executing set_current() does not have
any effect.
I found the same thing some months ago:
https://lists.osgeo.org/pipermail/grass-dev/2014-February/067543.html
as explained by Vaclav:
"If you change region in C or using ctypes in Python, it is affecting
only the current process."
best regards
Pietro
On Fri, Jul 25, 2014 at 5:05 AM, Pietro <peter.zamb@gmail.com> wrote:
On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden
<martin.zbinden@gmail.com> wrote:
> If I understand correctly, Region.set_current() can be used
> to effectively change the region currently used by GRASS. But changing
> extent of Raster()-object and executing set_current() does not have
> any effect.
I found the same thing some months ago:
https://lists.osgeo.org/pipermail/grass-dev/2014-February/067543.html
as explained by Vaclav:
"If you change region in C or using ctypes in Python, it is affecting
only the current process."
And on the hand, if you change region using g.region, only region for
subprocesses is changed but library functions are not affected. So,
g.region will affect pygrass.modules.Module but not pygrass.raster,
pygrass.vector and others.
I was actually the one saying that pygrass Region should use library
functions, not g.region, to be part of C library wrapper together with
other pygrass functions. However, pygrass.modules needs their own
mechanism, perhaps simple Module('g.region', ...) is the most appropriate.
One could suggest to have Region calling both g.region and library
functions but this could significantly decrease speed due to invocation of
subprocesses especially when Region API is in style region.set_north(),
region.set_south(). Maybe as a opt-in feature (set in constructor) but I'm
not 100% sure about that.
Vaclav
So, what is the pythonic way to manipulate region then? I ended up with:
reg.vect(parcels.name)
regbuffer = 100
reg.north += regbuffer
...
reg.set_current()
# set_current() not working right now
# so using r.raster for being sure:
g.region(n=str(reg.north), s=str(reg.south), w=str(reg.west),
e=str(reg.east), res='2', flags='a')
Is there a more elegant solution?
Module g.region needs string input.
Thanks for your information. I can live with it now.
Martin
--
Martin Zbinden
Student BFH HAFL
@home:
Riedacker 523,
CH-3154 Rüschegg Heubach
+41 31 738 84 23
2014-07-25 15:21 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:
On Fri, Jul 25, 2014 at 5:05 AM, Pietro <peter.zamb@gmail.com> wrote:
On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden
<martin.zbinden@gmail.com> wrote:
> If I understand correctly, Region.set_current() can be used
> to effectively change the region currently used by GRASS. But changing
> extent of Raster()-object and executing set_current() does not have
> any effect.
I found the same thing some months ago:
https://lists.osgeo.org/pipermail/grass-dev/2014-February/067543.html
as explained by Vaclav:
"If you change region in C or using ctypes in Python, it is affecting
only the current process."
And on the hand, if you change region using g.region, only region for
subprocesses is changed but library functions are not affected. So, g.region
will affect pygrass.modules.Module but not pygrass.raster, pygrass.vector
and others.
I was actually the one saying that pygrass Region should use library
functions, not g.region, to be part of C library wrapper together with other
pygrass functions. However, pygrass.modules needs their own mechanism,
perhaps simple Module('g.region', ...) is the most appropriate.
One could suggest to have Region calling both g.region and library functions
but this could significantly decrease speed due to invocation of
subprocesses especially when Region API is in style region.set_north(),
region.set_south(). Maybe as a opt-in feature (set in constructor) but I'm
not 100% sure about that.
Vaclav