Re: [GRASS-dev] GRASS 7.0beta3 planning
Hi, +1 to beta3. Maybe the announcement of it is a chance to update the instructions on http://grass.osgeo.org/download/software/linux/ : Linux Mint: ppa:grassgis/grassgis-testing doesn't exist. But probably ppa from Ubuntu should work, too. (see remarks below) Ubuntu: ppa:grass/grass-stable is ok. Generally Ubuntu GRASS 7 is not working well together with parallel grass_6.4.3-3 installation. Errors: 1) on installation: E: /var/cache/apt/archives/grass-doc_6.4.3-4~trusty1_all.deb: Versuch, /usr/share/man/man1/r3.out.vtk.1grass.gz zu überschreiben, welches auch in Paket grass70-doc 7.0-3-30661~ubuntu14.04.1 ist. 2) when starting GRASS 70: Unable to get GRASS version bash: /usr/lib/grass70/etc/prompt.py: No such file or directory I have to note that I'm working on Linux Mint with Ubuntugis unstable repository. Self-compiled from beta2 source runs fine. Thanks, Martin -- Martin Zbinden Student BFH HAFL @home: Riedacker 523, CH-3154 Rüschegg Heubach +41 31 738 84 23 2014-08-04 14:14 GMT+02:00 Markus Neteler nete...@osgeo.org: Hi, it seems that the backporting efforts are settled for beta 3 and the rest to be done later. If there are no objections, I can prepare the beta3 release tomorrow. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pygrass: Region.set_current() doesn't work
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.in.wcs, r.soillossbare: Added my first addons, issues with g.extension
Hi everybody, I just wanted to tell you that uploaded my first two addons for G7: - r.in.wcs : Import data for region from WCS-server - r.soillossbare: Calculate soilloss for bare soil according to Neteler Mitasova, 2008 [1] Well, I'm open to read your feedback and learn from it. I know that it is not yet real GRASS 7 code as I wanted to maintain some G6-compatibility. Maybe I should rewrite everything using pygrass. Generally it seems to install and work. Surely there are still some issues to solve. The first comes already during install: Fetching r.in.wcs from GRASS-Addons SVN (be patient)... Compiling... /bin/sh: 1: cannot create /usr/local/grass-7.0.0svn/locale/s criptstrings/r.in.wcs_to_translate.c: Directory nonexistent sed: couldn't flush stdout: Datenübergabe unterbrochen (broken pipe) make: [/usr/local/grass-7.0.0svn/locale/scriptstrings/r.in.w cs_to_translate.c] Fehler 2 (ignoriert) Installing... Updating metadata file... WARNING: No metadata available Installation of r.in.wcs successfully finished Why does g.extension try to write to /usr/local , although I just want to install for current user? Also, the minimal html doc has some encoding problem. I have created it just with --html-description flag. Thank you in advance for any hint. Martin sources: [1] Markus Neteler and Helena Mitasova, 2008, Open Source GIS: A GRASS GIS Approach. Third Edition. -- Martin Zbinden Riedacker 523 3154 Rüschegg Heubach +41 78 628 28 82 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] pygrass: Region.set_current() doesn't work
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 wenzesl...@gmail.com:
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
