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 <[email protected]>: > > On Fri, Jul 25, 2014 at 5:05 AM, Pietro <[email protected]> wrote: >> >> On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden >> <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
