#1467: include/gis.h hard-coding version a the SVN revision level
-+--
Reporter: strk | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor
#413: doxygen comments in get_row.c are wrong?
-+--
Reporter: karme | Owner: grass-dev@…
Type: defect | Status: closed
Priority: major | Milestone: 6.4.4
On 06/05/14 16:28, Rémi Cura wrote:
Hello everybody,
I'm trying to track why converting from grass 7 vector to postgis
topology vector is so slow.
(http://trac.osgeo.org/postgis/ticket/2695), few sec to import it into
grass , few sec to build topology in grass,*several minutes to push it*
into
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
--+-
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: closed
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
--+-
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: closed
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
--+-
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: closed
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
--+-
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: reopened
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
--+-
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: closed
2014-05-07 10:23 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
On 06/05/14 16:28, Rémi Cura wrote:
Hello everybody,
I'm trying to track why converting from grass 7 vector to postgis
topology vector is so slow.
(http://trac.osgeo.org/postgis/ticket/2695), few sec to import it into
On Fri, May 2, 2014 at 11:19 PM, Huidae Cho gras...@gmail.com wrote:
OK, I did a quick search and there are 104 calls to Vect_open_new. 63 calls
don't check its return value and 41 calls check. 27 of the 41 that do the
check do some cleaning work before finally throwing a fatal error. Most
Glynn Clements wrote:
Huidae Cho wrote:
But again, when they call fatal error internally, they don't have pointers
to maps. It would be great if we could keep track of opened raster/vector
maps and properly close existing maps and delete unfinished new maps inside
G_fatal_error. And use
On Wed, Apr 30, 2014 at 9:51 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make such things mandatory is
going to get reverted. Again.
really nice attitude
On Wed, May 7, 2014 at 9:21 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
Glynn Clements wrote:
...
If so, I suggest changing that, however invasive it may be.
Very invasive.
I'd
certainly suggest holding off on any 7.0 release until that's
resolved.
Hmm. This sounds like
#2159: v.external gui exceeds the border of the screen
-+--
Reporter: madi | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal |
Markus Metz wrote:
People installing GRASS want to use GRASS. They want GRASS to work out
of the box. They can use any Python version they want, as long as
WinGRASS uses its embedded Python version. Users will not notice it.
You're assuming that users have a free choice as to what they
Markus Metz wrote:
If so, I suggest changing that, however invasive it may be.
Very invasive.
Probably not. Admittedly, it would affect a lot of code, but only in
fairly trivial ways. Specifically, all of the Map variables would
become pointers rather than structures, calls to vector
16 matches
Mail list logo
