#2272: Improve consistency in random generator usage
-+--
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal |
Martin Landa wrote:
probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX
systems.
Note that the Python standard library typically goes into
/usr/lib/pythonX.Y (where X.Y is the version) on Unix.
OTOH, the standard library includes DSOs as well as .py/.pyc files,
#2031: G_legal_filename() cleanup patch for GRASS 6
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone:
Huidae Cho wrote:
I'm not talking about the current structure. Yes, the modules are the CLI
right now and the GUI calls the CLI modules internally. What I'm saying is
that it would great if we could separate the logic and CLI and put the
logic in plugins
We already do that, except that the
Hi,
2014-05-03 15:49 GMT+02:00 svn_gr...@osgeo.org:
Author: hcho
Date: 2014-05-03 06:49:33 -0700 (Sat, 03 May 2014)
New Revision: 60054
I would say that such invasive changes should be discussed in advance.
Now the vector library goes in different direction that raster library
which promote
#2017: ogsf compilation error
---+
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: new
Priority:
Hi,
2014-05-03 6:12 GMT+02:00 Anna Petrášová kratocha...@gmail.com:
Do you plan to discuss somewhere the design of the catalog? Perhaps
summarize the main points about the integration with layer manager and map
display, gui design, planned features etc on Trac?
good idea, I created trac wiki
hi,
in osgeo4w, gdal was recently updated to gdal 1.11.0
in [1] it refers to gdal 1.9.0
[...]
8 CONFIG_VERSION=1.9.0
[...]
should this be updated to 1.11.0?
[1]
http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w/gdal-config
-
best regards
Helmut
--
View this
#2279: wingrass71: rendering problems with raster layers automatically added by
finished
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
#2279: wingrass71: rendering problems with raster layers automatically added by
finished
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status:
Helmut Kudrnovsky wrote
Hi,
tested with winGRASS71 by osgeo4w from today.
Rendering is activated in map display.
start e.g. r.slope.aspect in the wxgui, define more than one outputs.
Automatically adding the results to map display is activated.
run r.slope.aspect, after the output
Martin,
I agree that it's not fun to call fatal error whenever opening something,
so I thought about adding fatal error in Vect routines. But some modules
actually check its return value and do cleaning before exit. Another option
would be to have Vect*2 routines that call fatal error and let the
On Sun, May 4, 2014 at 11:04 AM, Helmut Kudrnovsky hel...@web.de wrote:
hi,
in osgeo4w, gdal was recently updated to gdal 1.11.0
in [1] it refers to gdal 1.9.0
[...]
8 CONFIG_VERSION=1.9.0
[...]
should this be updated to 1.11.0?
Likely yes, since it appears to be updated:
Hi,
2014-05-04 18:52 GMT+02:00 Markus Neteler nete...@osgeo.org:
should this be updated to 1.11.0?
Likely yes, since it appears to be updated:
http://download.osgeo.org/osgeo4w/x86/versions.html
http://download.osgeo.org/osgeo4w/x86_64/versions.html
I'm no expert of OSGeo4W though...
we
Hi,
2014-05-04 16:16 GMT+02:00 Huidae Cho gras...@gmail.com:
I agree that it's not fun to call fatal error whenever opening something, so
I thought about adding fatal error in Vect routines. But some modules
actually check its return value and do cleaning before exit. Another option
please
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status:
#2279: wingrass71: rendering problems with raster layers automatically added by
finished modules
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status:
Martin,
Even after defining error handlers, we still need to call G_fatal_error to
trigger them. The Vect_set_error_handler_io manual recommends to use this
routine after Vect_open_old* because it needs the point to In and Out, but
if Vect_open_old* fails and doesn't call G_fatal_error, at what
19 matches
Mail list logo
