[GRASS-dev] [GRASS-user] pygrass: Region.set_current() doesn't work
martin.zbinden at gmail.com
Fri Jul 25 07:48:10 PDT 2014
So, what is the pythonic way to manipulate region then? I ended up with:
regbuffer = 100
reg.north += regbuffer
# 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.
Student BFH HAFL
CH-3154 Rüschegg Heubach
+41 31 738 84 23
2014-07-25 15:21 GMT+02:00 Vaclav Petras <wenzeslaus at gmail.com>:
> On Fri, Jul 25, 2014 at 5:05 AM, Pietro <peter.zamb at gmail.com> wrote:
>> On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden
>> <martin.zbinden at 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:
>> 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.
More information about the grass-dev