[GRASS-dev] Re: [GRASS GIS] #509: wxgui: startup menu crunched on small display

2009-02-27 Thread GRASS GIS
#509: wxgui: startup menu crunched on small display ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: minor | Milestone: 6.4.0 Component:

[GRASS-dev] Re: [GRASS GIS] #509: wxgui: startup menu crunched on small display

2009-02-27 Thread GRASS GIS
#509: wxgui: startup menu crunched on small display ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: minor | M

[GRASS-dev] Re: [GRASS GIS] #501: wxgui: g.message getting squashed

2009-02-27 Thread GRASS GIS
#501: wxgui: g.message getting squashed ---+ Reporter: hamish| Owner: martinl Type: defect| Status: closed Priority: major | Milestone: 6.4.0 Component: wxGUI

[GRASS-dev] Fwd: question about gui switching menu item

2009-02-27 Thread Michael Barton
Martin suggested I forward this to the list. Michael Begin forwarded message: From: Martin Landa Date: February 27, 2009 5:59:09 AM GMT-07:00 To: Michael Barton Subject: Re: question about gui switching menu item Michael, this is question for ML especially for Hamish who added this item to

Re: [GRASS-dev] question about raster cats and labels

2009-02-27 Thread Michael Barton
On Feb 27, 2009, at 2:04 AM, Moritz Lennert wrote: On 27/02/09 05:45, Michael Barton wrote: Is it possible in a raster to have multiple cells with the same cat value but different label values? Not as far as I know. Labels are linked to cat values, not to cells. This is the entire logic

Re: [GRASS-dev] large vector and indices, speed up db

2009-02-27 Thread Moritz Lennert
On 27/02/09 14:19, Markus Metz wrote: Moritz Lennert wrote: Yes, querying the geometries is very slow currently because of the fact that the spatial and topological index is kept in memory and not on file, so every time you launch an interactive query, it has to rebuild it which is very slow

Re: [GRASS-dev] large vector and indices, speed up db

2009-02-27 Thread Markus Metz
Moritz Lennert wrote: Yes, querying the geometries is very slow currently because of the fact that the spatial and topological index is kept in memory and not on file, so every time you launch an interactive query, it has to rebuild it which is very slow on large vectors. See http://josef.fs

Re: [GRASS-dev] r.los on windows question

2009-02-27 Thread Benjamin Ducke
Michael, this is a problem with dirty memory allocation that never got fixed. On some systems, like Linux, the memory manager is a bit more "relaxed" and lets this pass. On Windows, it's more strict and kills the application. The crashes appear a bit random which is typical for memory allocation

Re: [GRASS-dev] question about raster cats and labels

2009-02-27 Thread Moritz Lennert
On 27/02/09 05:45, Michael Barton wrote: Is it possible in a raster to have multiple cells with the same cat value but different label values? Not as far as I know. Labels are linked to cat values, not to cells. This is the entire logic of the system, i.e. that cat values represent the conten

Re: [GRASS-dev] r.los on windows question

2009-02-27 Thread Moritz Lennert
On 26/02/09 22:20, Michael Barton wrote: Just ran into an issue in the OSGeo4W version of GRASS that I had originally hit in 6.3 and subsequently forgotten about. I wonder if anyone else has experienced this. r.los with crash with a restart message in Windows XP if the max_dist is too large.

Re: [GRASS-dev] large vector and indices, speed up db

2009-02-27 Thread Moritz Lennert
On 26/02/09 18:37, Wouter Boasson wrote: In response to: Hello, reading this thread, and being sometimes concerned with large vector files (associated with big related tables), I wonder if it's worth manually creating indexes (on cat field) : can it be a effective way to speed up queries, or is

Re: [GRASS-dev] large vector and indices, speed up db

2009-02-27 Thread Vincent Bain
Thank you Moritz and Wouter, personnaly used to operating directly on tables through a psql terminal, I am not aware of the actual performances of db.* modules. In the present case, programming special interfaces for end-users who massively implement vector attributes, maybe it would be a good id