On Fri, Jul 25, 2014 at 5:05 AM, Pietro <peter.z...@gmail.com> wrote:
> On Fri, Jul 25, 2014 at 10:39 AM, Martin Zbinden > <martin.zbin...@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
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
