Casey wrote:
How easy would it be to implement an
option in the ps.map instructions for colortables so that
the user could decide if he/she wanted to use a discrete
colortable vs. a continuous color table (see attached).
done in SVN. the new colortable 'discrete y|n' command will force a
Dylan:
I also agree on this matter. I think that one thing that is making
this decision particularly difficult is that we are lacking a robust
interchange format for complex vector data.
I guess we need to create v.pack, v.unpack modules. should be much easier
than the r.pack, r.unpack.
#587: WinGRASS: can't open a map for wxDigitizing
---+
Reporter: hamish| Owner: martinl
Type: defect| Status: closed
Priority: major | Milestone: 6.4.0
#587: svn versions should better reflect svn rev
--+-
Reporter: hamish | Owner: martinl
Type: enhancement | Status: reopened
Priority: major| Milestone: 6.4.0
Component:
Hamish wrote:
Dylan:
I also agree on this matter. I think that one thing that is making
this decision particularly difficult is that we are lacking a robust
interchange format for complex vector data.
I guess we need to create v.pack, v.unpack modules. should be much easier
than the r.pack,
Thomas wrote:
I am aware that after installing GRASS I have to run
Init.sh in /etc of the sources, but it stops with:
./Init.sh: line 412: /etc/clean_temp: No such file or
directory
Starting GRASS ...
Error in startup script: couldn't read file
/etc/gis_set.tcl: no such file or directory
Glynn:
Can anyone tell me where to find a Windows version of wxPython
which works for compiling GRASS?
Martin wrote:
do you mean for compiling extensions like vdigit or nviz? If so, I
don't know ... It's possible to compile the extensions with wxPython
from osgeo4w, but loading fails
#85: v.what.vect additional upload options
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone:
#89: d.legend: option to get info from stdin instead of raster
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor
#394: v.mkgrid: lines not areas
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: 6.5.0
#500: GUI menu item to swtich GUIs
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: closed
Priority: major| Milestone: 6.4.0
#568: xganim: minor improvements
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: 6.5.0
#90: v.parallel: problems with inside corners
--+-
Reporter: hamish | Owner: rmatev
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component:
#554: wxGUI location wizard: Search in description with 0 hits
---+
Reporter: hamish| Owner: martinl
Type: defect| Status: closed
Priority: major |
#559: wingrass stand-alone installer: MSys console doesn't work
---+
Reporter: hamish| Owner: cnielsen
Type: defect| Status: closed
Priority: minor | Milestone: 6.4.0
Just a quick update on my own thoughts (awful):
There is a note in the OGR SQlite driver page which states that
the SpatiaLite extenstion to SQLite databases will be fully
supported by the time GDAL 1.7.0 gets released:
http://www.gdal.org/ogr/drv_sqlite.html
So I guess here we have a good
Sorry for this question almost coming out from nowhere, but is this
SpatiaLite extension treating geometric data topologically ? or is it
conform to OGC simple feature definitions ?
If so, it's quite a negative point for a universal data exchange model
and for information preservation, isn't it ?
Hi Vincent,
actually, SpatiaLite seems to use its own (apparently strictly 2D)
geometry representations in the SQLite DB. I could not find any hint in
the documentation that topology is imposed on the data:
http://www.gaia-gis.it/spatialite/spatialite-manual-2.3.0.html
#586: WinGRASS: 3D view wxNVIZ does not work
---+
Reporter: hamish| Owner: martinl
Type: defect| Status: assigned
Priority: major | Milestone: 6.4.0
Hi,
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
database
User could import only desired modules from 'grass' package, e.g.
from grass import raster
?
Martin
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
Ben,
What's wrong with OGC simple feature definitions? Too simple for
your purposes?
Well, briefly analysing this point, I would say storing data in a non
topological way may not be a problem, as far as Grass handles the format
and finally, per se, can deal with spatial relationships between
Dear all,
I am experimenting a bit with SQLite spatial data storage and have found
the following problem in v.out.ogr (main.c, starting at ca. line 263):
Ogr_ds = OGR_Dr_CreateDataSource(Ogr_driver, dsn_opt-answer,
papszDSCO);
CSLDestroy(papszDSCO);
if (Ogr_ds == NULL)
Hi Paolo,
thanks for the stats, but I believe that the comparison is quite
inappropriate.
My 2 cents...
The graph grass vs. qgis
(http://www.google.com/insights/search/overviewReport?cat=q=qgisgeo=date=gprop=clp=cmpt=q#q=qgis%2Cgrasscmpt=q)
shows that grass is much more searched then qgis,
Massimiliano Cannata ha scritto:
thanks for the stats, but I believe that the comparison is quite
inappropriate.
I'm aware of this, and I pointed it out. Nevertheless, the *trends* are
interesting, and I think they are well explained by my hypotheses.
All the best.
--
Paolo Cavallini:
#85: grass needs wxWidgets to compile some GUI tools
+---
Reporter: hamish |Owner: osgeo4w-...@lists.osgeo.org
Type: enhancement | Status: new
Priority: major|
I have started a new Wiki page on GRASS and spatial DBMS, since I
believe this is a really hot topic which will see a big surge in
user attention in the near future:
http://grass.osgeo.org/wiki/Spatial_SQL
I have added some very preliminary text on SQLite for a start.
The results of my first
Hi all,
would make sense to you to introduce new global flag for shell style
module output?
'--g'
Then all '-g' flags and similar flags with different key could be
replaced by '--g'. In the case of g.region
`g.region -g` would be changed to `g.region -p --g`
Also grass python interface could
#111: r.los fails in WinGRASS with high values for max_dis parameter
---+
Reporter: gsancho | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority:
On Fri, May 8, 2009 at 1:57 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
database
User could import only desired modules from 'grass' package, e.g.
from grass import raster
Sounds good to me (and
On Thu, May 7, 2009 at 1:45 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2009/5/7 Hamish hamis...@yahoo.com:
I think that with the move in 6.4 to SQLite as default db
backend,
Probably we could move to SQLite in GRASS 6.5. Note there are still
remaining bugs, e.g. v.dissolve doesn't
On Fri, May 8, 2009 at 3:39 PM, Massimiliano Cannata
massimiliano.cann...@supsi.ch wrote:
...
Maybe web site hits statistics are more relevant? or number of download?
Find them here (That's *real* data):
http://grass.osgeo.org/logs-bin/awstats.pl?config=grass.osgeo.org
Not sure if it exists for
Martin Landa wrote:
I mean configure --with-python --with-wxwidgets=
ie where to find the wx-config program? I've filed a ticket with osgeo4w,
hopefully it's not noise.
http://trac.osgeo.org/osgeo4w/ticket/85
wx-config is not part of the OSGeo4w wxPython package. Probably you
Hi,
2009/5/8 Glynn Clements gl...@gclements.plus.com:
wx-config is not part of the OSGeo4w wxPython package. Probably you
need to compile your own wxPython using mingw. Also python-config is
Ultimately, one of the biggest problems facing the Windows version is
that it's *still* a major
Martin Landa wrote:
I would suggest splitting grass.py into several modules, e.g.
general
raster
vector
database
User could import only desired modules from 'grass' package, e.g.
from grass import raster
This would be a good point to consider how it relates to the SWIG
interface.
Martin Landa wrote:
missing. Question: do we need python-config? wxGUI extensions are
build using setup.py. So --with-python could check only if 'python'
binaries are available (?)
to the question: any objection to make python-config checking
optional? So --with-python will check if
Markus Neteler wrote:
On Thu, May 7, 2009 at 1:45 PM, Martin Landa wrote:
Hi,
2009/5/7 Hamish:
I think that with the move in 6.4 to SQLite as default db
backend,
Probably we could move to SQLite in GRASS 6.5. Note there
are still remaining bugs, e.g. v.dissolve doesn't work on
36 matches
Mail list logo
