Re: [GRASS-dev] [GRASS GIS] #2046: radius limitation option on v.voroni
#2046: radius limitation option on v.voroni
-+--
Reporter: dnewcomb | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.4.4
Component: Default | Version: unspecified
Keywords: |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by mmetz):
This can be done with v.voronoi + v.buffer + v.overlay.
For example with hospitals in the NC dataset:
{{{
g.region -p vect=boundary_county
g.region -pa res=100
v.voronoi in=hospitals out=hospitals_v
v.buffer in=hospitals out=hospitals_b distance=2 type=point
v.overlay ain=hospitals_v atype=area bin=hospitals_b op=and
out=hospitals_vb olayer=0,1,0
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2046#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.segment: invalid region id 0
On Friday 26 of July 2013 15:41:25 Moritz Lennert wrote: On 26/07/13 15:17, Nikos Alexandris wrote: On Wednesday 17 of July 2013 12:56:58 Nikos Alexandris wrote: In any case, if wanted, I will try during the weekend to replicate a Huge region, as the one Moritz tested with a rational threshold (close to zero). I couldn't make it -- my machine was under some sort of heavy reconstruction during the last weekend. Is this still of interest? Let a machine to chew-up a big region with i.segment? Markus and I have been busy testing in the last weeks and thanks to Markus' rapid reaction in correcting some bugs, we've been able to segment an image with 555,727,911 non-null cells in a region with 2,617,375,744 total cells. Markus' machine did this in just 15 hours ! On mine it took much longer, but this is probably in large parts due to a software raid 5 that makes disk io really slow. WoW! Great news! Lot of work behind the scenes I guess. Thanks a million... Let me know if and what I can test (besides my on-going work in which I do use i.segment). Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2045: r.to.vect: use less memory
#2045: r.to.vect: use less memory --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Keywords: r.to.vect memory |Platform: Unspecified Cpu: Unspecified | --+- Comment(by mlennert): Replying to [comment:4 mmetz]: Replying to [comment:3 mlennert]: Replying to [comment:2 mlennert]: Replying to [comment:1 mmetz]: Replying to [ticket:2045 mlennert]: Trying to convert a raster file to vector areas on a machine with 10GB, the process was killed after having used up all memory and swap. There was a memory leak in r.to.vect, fixed in trunk r57281. (and r57281) Thanks ! I now get through the Extracting areas... part without the process being killed. I still see continuous increase in memory usage, though, up to 88,5% at the end of the extraction stage. Is this normal ? Now it's busy writing areas... And memory usage continued to increase. The process was killed during the Registering primitives... step. You can try to set the environment variable GRASS_VECTOR_LOWMEM before running r.to.vect. GRASS_VECTOR_LOWMEM reduces the amount of memory used by vector topology structures (the spatial index is built on disk). IOW, r.to.vect might use quite a bit of memory which is difficult to change, and the vector topology structures also need memory (in g7 much less than in g6). So you think the continuous increase up to 88.5% during the area extraction is normal ? I'll try the GRASS_VECTOR_LOWMEM option on Monday. Just brainstorming: I'm not sure I completely understand the module's workings, but IIUC, it systematically goes through rows an columns and checks whether pixel values change. But does that mean it reads all areas into memory before writing them ? Would it be feasible / of interest to write each area immediately after its boundaries have been identified and then free the memory again ? I could even imagine a solution where the module works with segments of the map, writes out the areas identified in a segment, then goes on to the next segment and then at the end use a v.dissolve equivalent to fusion all neighboring areas with identical values. Unless the v.dissolve process takes a lot of memory, I could imagine that at least the first part could work with a low memory consumption, or ? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2045#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] A big Thank You to the Admins
Thanks to our admins taking care all of the stuff we enjoy (The web-page, the Wiki, Trac, mailing lists and else). Yesterday was https://en.wikipedia.org/wiki/System_Administrator_Apprec iation_Day. If you didn't have a Happy Day yesterday, then Have a Great Day today :D Best, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2015: Missing file association dialog pops up all the time
#2015: Missing file association dialog pops up all the time +--- Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Python | Version: svn-trunk Keywords: wingrass|Platform: MSWindows 7 Cpu: All | +--- Comment(by hellik): see thread ''[GRASS-dev] Python handling in winGRASS7'' in dev-ML: http://lists.osgeo.org/pipermail/grass-dev/2013-July/065137.html http://lists.osgeo.org/pipermail/grass-dev/2013-July/065140.html and http://docs.python.org/3/using/windows.html#launcher for some hints. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2015#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2015: Missing file association dialog pops up all the time
#2015: Missing file association dialog pops up all the time +--- Reporter: wenzeslaus | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Python | Version: svn-trunk Keywords: wingrass|Platform: MSWindows 7 Cpu: All | +--- Comment(by hellik): Replying to [comment:4 hellik]: see thread ''[GRASS-dev] Python handling in winGRASS7'' in dev-ML: http://lists.osgeo.org/pipermail/grass-dev/2013-July/065137.html http://lists.osgeo.org/pipermail/grass-dev/2013-July/065140.html and http://docs.python.org/3/using/windows.html#launcher for some hints. and here for the structure of the py.ini-file: https://bitbucket.org/vinay.sajip/pylauncher/src/tip/Doc/launcher.rst#rst- header-customization-via-ini-files https://bitbucket.org/pypa/pylauncher/src/7520661dbf4cd643486f4e1ff56212e168ad7167/py.ini.template?at=default -- Ticket URL: http://trac.osgeo.org/grass/ticket/2015#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2015: Missing file association dialog pops up all the time
#2015: Missing file association dialog pops up all the time
+---
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Python | Version: svn-trunk
Keywords: wingrass|Platform: MSWindows 7
Cpu: All |
+---
Comment(by hellik):
Replying to [comment:4 hellik]:
see thread ''[GRASS-dev] Python handling in winGRASS7'' in dev-ML:
http://lists.osgeo.org/pipermail/grass-dev/2013-July/065137.html
http://lists.osgeo.org/pipermail/grass-dev/2013-July/065140.html
and
http://docs.python.org/3/using/windows.html#launcher
for some hints.
some quick tests:
(1) Download Python 3.3.2 Windows x86 MSI Installer
(2) extract Python 3.3.2 without installing it
(e.g. msiexec /a C:\dl\testunzip\python-3.3.2.msi /qb
TARGETDIR=C:\dl\testunzip\uz)
(3) open a windows console in C:\dl\testunzip\uz and type py --version
{{{
C:\dl\testunzip\uzpy --version
Python 2.7.2
}}}
= it's the system wide python 2.7.2 installed by ArcGIS10.1.
or
{{{
C:\dl\testunzip\uzpy --help
Python Launcher for Windows Version 3.3.2150.1013
usage: py [ launcher-arguments ] script [ script-arguments ]
Launcher arguments:
-2 : Launch the latest Python 2.x version
-3 : Launch the latest Python 3.x version
-X.Y : Launch the specified Python version
-X.Y-32: Launch the specified 32bit Python version
The following help text is from Python:
usage: C:\Python27\ArcGIS10.1\python.exe [option] ... [-c cmd | -m mod |
file |
-] [arg] ...
Options and arguments (and corresponding environment variables):
-B : don't write .py[co] files on import; also
PYTHONDONTWRITEBYTECODE=x
[...]
}}}
(4) script example
http://docs.python.org/3/using/windows.html#from-a-script
{{{
hello.py
#! python
import sys
sys.stdout.write(hello from Python %s\n % (sys.version,))
}}}
{{{
C:\dl\testunzip\uzpy hello.py
hello from Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32
bit (Int
el)]
}}}
(5) put py.ini in the same folder as the windows python launcher py.exe.
content of py.ini which points to the osgeo4w-bundled python 2.7.4
{{{
py.ini
[commands]
myprog=C:\OSGeo4W\bin\python.exe
}}}
and change hello.py to
{{{
#! myprog
import sys
sys.stdout.write(hello from Python %s\n % (sys.version,))
}}}
{{{
C:\dl\testunzip\uzpy hello.py
hello from Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32
bit (Int
el)]
}}}
(6) change py.ini to point to the extracted (not installed) python 3.3.2
{{{
py.ini
[commands]
myprog=C:\dl\testunzip\uz\python.exe
}}}
{{{
C:\dl\testunzip\uzpy hello.py
hello from Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC
v.1600
32 bit (Intel)]
}}}
it seems to be possible to switch the used python interpreter by using the
Python Launcher for Windows concept and point to a specfic python
interpreter (installed or bundled).
could this help?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2015#comment:6
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Note that Python 3 includes a launcher utility for Windows: http://docs.python.org/3/using/windows.html#launcher The idea is that the .py extension can be associated with the launcher, which can be configured to use a specific version of Python in a specific context. I don't know whether it's possible to make use of this without installing the rest of Python 3, though. some more test see here: http://trac.osgeo.org/grass/ticket/2015#comment:6 Python Launcher for Windows is a interesting concept for switching between python versions or for pointing to a specific python interpreter. shebang + py.ini seems to work (see tests in the ticket). IIUC, by this concept a WinGrass-python script would have to be invoked by py.exe (Python Launcher for Windows)? - could this be integrated in WinGrass? - would this help to call a python-script within a python-script? - would this help to type only r. in the WinGrass7-windows-console without the .py-extension to start a grass-python-script? - would this help for http://trac.osgeo.org/grass/ticket/2015? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5069091.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Custom GRASS command line prompt
I want to alter the default GRASS command line prompt. For my needs, I find it better to have the current Mapset shown along with the Location. As a first experiment, I edited the corresponding file in place: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp, line 1039: - f.write(PS1='GRASS %s (%s):\w '\n % (grass_version, location_name)) + f.write(PS1='G %s (%s/%s):\w '\n % (grass_version, location_name, mapset)) Now it appears like: G 7.0.svn (utm_37s/post):~ . My understanding is that I probably need to edit the file: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp Do you have customised prompts? Any ideas for a more productive command line? Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]
Helmut Kudrnovsky wrote: Python Launcher for Windows is a interesting concept for switching between python versions or for pointing to a specific python interpreter. shebang + py.ini seems to work (see tests in the ticket). IIUC, by this concept a WinGrass-python script would have to be invoked by py.exe (Python Launcher for Windows)? The idea is that you associate the .py extension with py.exe, and it figures out which python.exe to use for a given script. - could this be integrated in WinGrass? Maybe, but it has many of the same issues as any other approach which affects system-wide configuration. - would this help to type only r. in the WinGrass7-windows-console without the .py-extension to start a grass-python-script? Invoking scripts without an extension requires that the extension is present in PATHEXT. - would this help to call a python-script within a python-script? - would this help for http://trac.osgeo.org/grass/ticket/2015? The bottom line is that the .py extension has to be associated with a Python interpreter, or something which invokes one (e.g. py.exe). There are multiple valid solutions, and GRASS cannot impose a particular one. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1866: broken db driver communication in winGRASS 7
#1866: broken db driver communication in winGRASS 7 --+- Reporter: martinl | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Database | Version: unspecified Keywords: sqlite, wingrass |Platform: MSWindows 2K Cpu: Unspecified | --+- Comment(by neteler): Replying to [comment:48 neteler]: Now backported to devel_branch6 in r57274. Relbranch TODO Done for 6.4.4 in r57305. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1866#comment:49 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
On Wed, Jul 17, 2013 at 3:21 PM, Markus Neteler nete...@osgeo.org wrote: ... I agree that r.latlong would be more appropriate. If there are no objections, I would rename it in both G6 Addons and G7. Done for G7 in r57306. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
On Sat, Jul 27, 2013 at 10:38 PM, Markus Neteler nete...@osgeo.org wrote: On Wed, Jul 17, 2013 at 3:21 PM, Markus Neteler nete...@osgeo.org wrote: ... I agree that r.latlong would be more appropriate. If there are no objections, I would rename it in both G6 Addons and G7. Done for G7 in r57306. Done also for G6 Addons in r57308. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
I'm trying to understand the function of i.latlong: when would it be useful? r.sun optionally takes lat,long raster maps as input, and you could use r.mapcalc x(), y() to create those then use r.proj to bring them into your projected location. (or some v.mkgrid + m.proj + r.in.xyz magic) but it turns out that the overhead in opening and reading those maps is more work than just using the pj_() functions to calculate the cell-center coordinate values either per-row,column or even for each cell on-the-fly within the module. So it's a net loss and for grass7's r.sun I'd planned to remove those two r.sun input options. (it was otherwise added to r.sun in years past to allow r.sun to work in an XY location, but I don't think that justifies the extra module complexity) ? thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
Nikos: I want to alter the default GRASS command line prompt. For my needs, I find it better to have the current Mapset shown along with the Location. As a first experiment, I edited the corresponding file in place: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp, line 1039: - f.write(PS1='GRASS %s (%s):\w '\n % (grass_version, location_name)) + f.write(PS1='G %s (%s/%s):\w '\n % (grass_version, location_name, mapset)) Now it appears like: G 7.0.svn (utm_37s/post):~ . My understanding is that I probably need to edit the file: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp Do you have customised prompts? Any ideas for a more productive command line? I'd suggest to put the change in ~/.grass.bashrc instead. fwiw here's what I have there wrt the prompt: SHORT_VER=`echo $GRASS_VERSION | cut -f1,2 -d. | sed -e 's/\.//'` export PS1='G$SHORT_VER:\W ' export HISTSIZE=3000 .or. export PS1='G$SHORT_VER:\w ' export PROMPT_DIRTRIM=2 as full dir path gets much too long, especially on WinGrass where the terminal width is a pain to resize. For simplicity one of my favourites is still just: export PS1='GRASS$SHORT_VER ' If you do most of your work with a small set of locations, it might also be an idea to figure something out with Xresources to color the terminal background based on which one you're running in. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1866: broken db driver communication in winGRASS 7
#1866: broken db driver communication in winGRASS 7 --+- Reporter: martinl | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Database | Version: unspecified Keywords: sqlite, wingrass |Platform: MSWindows 2K Cpu: Unspecified | --+- Comment(by hamish): Replying to [comment:49 neteler]: Replying to [comment:48 neteler]: Now backported to devel_branch6 in r57274. Relbranch TODO Done for 6.4.4 in r57305. Hi, fwiw speaking generally, I would suggest to hold back on non-essential backporting to relbr64 for a couple of weeks in case an emergency 6.4.3.1 needs to be created from the release branch. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1866#comment:50 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r57291: configure.in: disable pwd -W (WinGRASS)
Hi, re r57291, it's not safe to modify core files after the last RC :-( http://trac.osgeo.org/grass/changeset/57291/grass/branches/releasebranch_6_4/configure.in There's a missing quote at the end of line 110. One thousand times lucky this was in a commented out part!! Hamish ps- curly brackets do not work for quoting strings or paths, only variable names. if used when not actually needed it fools students of the code into thinking that they will be safe to use instead of real quotes, and so the misconception breakage gets propagated on and on. This is especially important for things touching MS Windows where spaces in the path names are common and the future reader may not be a veteran Bourne coder. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
