Re: [GRASS-dev] ps.map colortable
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 categorical map to use a gradient legend, or a floating point map to use a discrete category legend. needed: a nice writeup on how to (or given number of breakpoints a nice script to automatically) set up range-band labels for FP raster maps that can be fed to r.category. (anything in d.vect.thematic already? qgis's graduated symbol equal interval setup?) Hamish ps [offtopic]- just if anyone knows, in qgis's graduated symbol or continuous color setup how to set more than a 2-color transition for vector maps? It's a pain to data-enter but I can calculate varying symbol size per class pretty much in my head. A 4-color transition over 8 classes is much much harder to do manually. for raster maps they have greyscale, freakout, and bcyr at least but more would be nice there too. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] single vs. multiple sqlite db files [was v.db.calc]
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. Dumping from GRASS vectors -- shapefiles -- GRASS can sometimes lead to data loss. (make that often) to move forward on this I guess we need to start coding the easy way to switch between per-map and per-mapset sqlite modes. there seems to be enough support for both ways to warrant it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #587: WinGRASS: can't open a map for wxDigitizing
#587: WinGRASS: can't open a map for wxDigitizing
---+
Reporter: hamish| Owner: martinl
Type: defect| Status: closed
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: duplicate |Keywords: wingrass digitize
Platform: MSWindows XP | Cpu: x86-32
---+
Comment (by hamish):
Replying to [comment:11 martinl]:
{{{
#define GIS_H_DATE $Date$
}}}
done in r37043.
any objections to backporting this?
The patch for g.version attached (comments?)
* keep it easily parsable (on one line), and as backwards compatible as
possible for existing script parsing.
* (for grass 7 only) s/GRASS/GRASS GIS/
* flags for diff't info? (only if needed)
* modify doc/howto_release.txt to say that GRASS_VERSION_DATE should be
manually set to the release day for official releases, and for SVN builds
take it from GIS_H_DATE?
* append the numeric value portion of GIS_H_VERSION (ie rev #) to
GRASS_VERSION_NUMBER in the g.version output if 'svn' is found in
GRASS_VERSION_NUMBER. so it automatically looks like 6.4.0svn32001
This way it could be backwards compatible for g6 script parsing.
* is GRASS_VERSION_UPDATE_PKG relevant anymore for grass = 5?
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/587#comment:12
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] Re: [GRASS GIS] #587: svn versions should better reflect svn rev
#587: svn versions should better reflect svn rev --+- Reporter: hamish | Owner: martinl Type: enhancement | Status: reopened Priority: major| Milestone: 6.4.0 Component: default | Version: 6.4.0 RCs Resolution: |Keywords: g.version Platform: All | Cpu: All --+- Changes (by hamish): * status: closed = reopened * type: defect = enhancement * component: wxGUI = default * summary: WinGRASS: can't open a map for wxDigitizing = svn versions should better reflect svn rev * platform: MSWindows XP = All * keywords: wingrass digitize = g.version * resolution: duplicate = * cpu: x86-32 = All Comment: hijacked ticket, but the orig was a dud anyway -- Ticket URL: https://trac.osgeo.org/grass/ticket/587#comment:13 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] single vs. multiple sqlite db files [was v.db.calc]
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, r.unpack. Unless we take interchange to include other GIS. I find it frustrating that there is no established vector data format that adequately preserves information between different systems. SQLite + WKT/WKB should be a good and simple way to provide that. It is easy to turn an SQLite DB into a spatial database, following these guidelines: http://trac.osgeo.org/fdo/wiki/FDORfc16 Of course, OGR/GDAL already has support for this standard: http://www.gdal.org/ogr/drv_sqlite.html but I imagine it would be more convenient if GRASS supported it natively? Data exchange with other GIS apps could also be managed by pumping (WKT/WKB) SQL statements through stdin/stdout, without the need to go through a file, at all (of course both ends would need to support this). In the interim, why not create a nice wrapper module that uses the OGR SQlite driver to store/extract attributes and geometries? SpatiaLite is just one (albeit very nice!) implementation of that general idea, which should be fairly easy to implement in GRASS. The biggest problem with the current SpatiaLite API re. GRASS seems to be that it caters for 2D coordinates only. I am not sure how hard it would be to work around that limitation. Ben Dumping from GRASS vectors -- shapefiles -- GRASS can sometimes lead to data loss. (make that often) to move forward on this I guess we need to start coding the easy way to switch between per-map and per-mapset sqlite modes. there seems to be enough support for both ways to warrant it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Geospatial Consultant Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] python issues
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 start grass with the grass64 script, not with Init.sh. all the grass64 script does is set the $GISBASE variable then call Init.sh, but that is the critical grass variable. /etc/gis_set.tcl: no such file or directory with $GISBASE expands to /usr/local/grass64/etc/gis_set.tcl etc. see also the batch scripting wiki page which tells you how to run grass without init.sh Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #570: startup problem with standalone GRASS install
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 due to the swig-related errors. Glynn: 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 Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #85: v.what.vect additional upload options
#85: v.what.vect additional upload options --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.5.0 Component: Vector | Version: unspecified Resolution: |Keywords: v.what.vect Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * keywords: = v.what.vect * platform: = Unspecified * component: default = Vector * cpu: = Unspecified * milestone: 6.4.0 = 6.5.0 -- Ticket URL: https://trac.osgeo.org/grass/ticket/85#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
[GRASS-dev] Re: [GRASS GIS] #89: d.legend: option to get info from stdin instead of raster
#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| Milestone: 6.5.0 Component: Display | Version: unspecified Resolution: |Keywords: d.legend Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * keywords: = d.legend * platform: = Unspecified * component: default = Display * cpu: = Unspecified * milestone: 6.4.0 = 6.5.0 -- Ticket URL: https://trac.osgeo.org/grass/ticket/89#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
[GRASS-dev] Re: [GRASS GIS] #394: v.mkgrid: lines not areas
#394: v.mkgrid: lines not areas --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.5.0 Component: Vector | Version: unspecified Resolution: |Keywords: v.mkgrid Platform: All | Cpu: All --+- Changes (by hamish): * platform: Unspecified = All * cpu: Unspecified = All * milestone: 6.4.0 = 6.5.0 -- Ticket URL: https://trac.osgeo.org/grass/ticket/394#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
[GRASS-dev] Re: [GRASS GIS] #500: GUI menu item to swtich GUIs
#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 Component: default | Version: 6.4.0 RCs Resolution: fixed|Keywords: gui Platform: All | Cpu: All --+- Changes (by hamish): * status: new = closed * resolution: = fixed Comment: it's not working on wingrass, but it's a generic Makefile problem. closing this ticket as it's done. H -- Ticket URL: https://trac.osgeo.org/grass/ticket/500#comment:9 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] Re: [GRASS GIS] #568: xganim: minor improvements
#568: xganim: minor improvements --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.5.0 Component: default | Version: svn-develbranch6 Resolution: |Keywords: xganim Platform: Linux| Cpu: x86-32 --+- Changes (by hamish): * milestone: 6.4.0 = 6.5.0 -- Ticket URL: https://trac.osgeo.org/grass/ticket/568#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
[GRASS-dev] Re: [GRASS GIS] #90: v.parallel: problems with inside corners
#90: v.parallel: problems with inside corners --+- Reporter: hamish | Owner: rmatev Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: v.parallel Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * keywords: = v.parallel -- Ticket URL: https://trac.osgeo.org/grass/ticket/90#comment:11 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] Re: [GRASS GIS] #554: wxGUI location wizard: Search in description with 0 hits
#554: wxGUI location wizard: Search in description with 0 hits ---+ Reporter: hamish| Owner: martinl Type: defect| Status: closed Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Resolution: fixed |Keywords: location wizard Platform: MSWindows XP | Cpu: x86-32 ---+ Changes (by hamish): * status: assigned = closed * resolution: = fixed -- Ticket URL: https://trac.osgeo.org/grass/ticket/554#comment:11 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] Re: [GRASS GIS] #559: wingrass stand-alone installer: MSys console doesn't work
#559: wingrass stand-alone installer: MSys console doesn't work ---+ Reporter: hamish| Owner: cnielsen Type: defect| Status: closed Priority: minor | Milestone: 6.4.0 Component: Installation | Version: 6.4.0 RCs Resolution: fixed |Keywords: wingrass Platform: MSWindows XP | Cpu: x86-32 ---+ Changes (by hamish): * status: assigned = closed * resolution: = fixed -- Ticket URL: https://trac.osgeo.org/grass/ticket/559#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] single vs. multiple sqlite db files [was v.db.calc]
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 candidate for a universal data exchange format that works out-of-the box with every application that supports the GDAL/OGR interface. Plus SpatiaLite comes with a very nice set of userland GUI tools to manage (spatial) data in an SQLite DB, so what more could one ask for? Ben Benjamin Ducke wrote: 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, r.unpack. Unless we take interchange to include other GIS. I find it frustrating that there is no established vector data format that adequately preserves information between different systems. SQLite + WKT/WKB should be a good and simple way to provide that. It is easy to turn an SQLite DB into a spatial database, following these guidelines: http://trac.osgeo.org/fdo/wiki/FDORfc16 Of course, OGR/GDAL already has support for this standard: http://www.gdal.org/ogr/drv_sqlite.html but I imagine it would be more convenient if GRASS supported it natively? Data exchange with other GIS apps could also be managed by pumping (WKT/WKB) SQL statements through stdin/stdout, without the need to go through a file, at all (of course both ends would need to support this). In the interim, why not create a nice wrapper module that uses the OGR SQlite driver to store/extract attributes and geometries? SpatiaLite is just one (albeit very nice!) implementation of that general idea, which should be fairly easy to implement in GRASS. The biggest problem with the current SpatiaLite API re. GRASS seems to be that it caters for 2D coordinates only. I am not sure how hard it would be to work around that limitation. Ben Dumping from GRASS vectors -- shapefiles -- GRASS can sometimes lead to data loss. (make that often) to move forward on this I guess we need to start coding the easy way to switch between per-map and per-mapset sqlite modes. there seems to be enough support for both ways to warrant it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Geospatial Consultant Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] single vs. multiple sqlite db files [was v.db.calc]
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 ? Bye, Vincent Le vendredi 08 mai 2009 à 12:08 +0100, Benjamin Ducke a écrit : 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 candidate for a universal data exchange format that works out-of-the box with every application that supports the GDAL/OGR interface. Plus SpatiaLite comes with a very nice set of userland GUI tools to manage (spatial) data in an SQLite DB, so what more could one ask for? Ben Benjamin Ducke wrote: 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, r.unpack. Unless we take interchange to include other GIS. I find it frustrating that there is no established vector data format that adequately preserves information between different systems. SQLite + WKT/WKB should be a good and simple way to provide that. It is easy to turn an SQLite DB into a spatial database, following these guidelines: http://trac.osgeo.org/fdo/wiki/FDORfc16 Of course, OGR/GDAL already has support for this standard: http://www.gdal.org/ogr/drv_sqlite.html but I imagine it would be more convenient if GRASS supported it natively? Data exchange with other GIS apps could also be managed by pumping (WKT/WKB) SQL statements through stdin/stdout, without the need to go through a file, at all (of course both ends would need to support this). In the interim, why not create a nice wrapper module that uses the OGR SQlite driver to store/extract attributes and geometries? SpatiaLite is just one (albeit very nice!) implementation of that general idea, which should be fairly easy to implement in GRASS. The biggest problem with the current SpatiaLite API re. GRASS seems to be that it caters for 2D coordinates only. I am not sure how hard it would be to work around that limitation. Ben Dumping from GRASS vectors -- shapefiles -- GRASS can sometimes lead to data loss. (make that often) to move forward on this I guess we need to start coding the easy way to switch between per-map and per-mapset sqlite modes. there seems to be enough support for both ways to warrant it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] single vs. multiple sqlite db files [was v.db.calc]
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 http://www.gaia-gis.it/spatialite/spatialite-sql-2.3.0.html But anyway, the OGR driver does not exclusively use SpatiaLite's storage model. You can use simple WKB/WKT tables if you want. It seems that even support for AutoDesk's way of SQLite spatial data storage will be supported in the future. As long as all applications access the database via the OGR driver, it doesn't matter which representation you prefer, they'll all work for data exchange. What's wrong with OGC simple feature definitions? Too simple for your purposes? Ben Vincent Bain wrote: 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 ? Bye, Vincent Le vendredi 08 mai 2009 à 12:08 +0100, Benjamin Ducke a écrit : 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 candidate for a universal data exchange format that works out-of-the box with every application that supports the GDAL/OGR interface. Plus SpatiaLite comes with a very nice set of userland GUI tools to manage (spatial) data in an SQLite DB, so what more could one ask for? Ben Benjamin Ducke wrote: 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, r.unpack. Unless we take interchange to include other GIS. I find it frustrating that there is no established vector data format that adequately preserves information between different systems. SQLite + WKT/WKB should be a good and simple way to provide that. It is easy to turn an SQLite DB into a spatial database, following these guidelines: http://trac.osgeo.org/fdo/wiki/FDORfc16 Of course, OGR/GDAL already has support for this standard: http://www.gdal.org/ogr/drv_sqlite.html but I imagine it would be more convenient if GRASS supported it natively? Data exchange with other GIS apps could also be managed by pumping (WKT/WKB) SQL statements through stdin/stdout, without the need to go through a file, at all (of course both ends would need to support this). In the interim, why not create a nice wrapper module that uses the OGR SQlite driver to store/extract attributes and geometries? SpatiaLite is just one (albeit very nice!) implementation of that general idea, which should be fairly easy to implement in GRASS. The biggest problem with the current SpatiaLite API re. GRASS seems to be that it caters for 2D coordinates only. I am not sure how hard it would be to work around that limitation. Ben Dumping from GRASS vectors -- shapefiles -- GRASS can sometimes lead to data loss. (make that often) to move forward on this I guess we need to start coding the easy way to switch between per-map and per-mapset sqlite modes. there seems to be enough support for both ways to warrant it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Benjamin Ducke Senior Geospatial Consultant Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #586: WinGRASS: 3D view wxNVIZ does not work
#586: WinGRASS: 3D view wxNVIZ does not work ---+ Reporter: hamish| Owner: martinl Type: defect| Status: assigned Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Resolution:|Keywords: wingrass nviz Platform: MSWindows XP | Cpu: Unspecified ---+ Comment (by martinl): Replying to [comment:3 martinl]: is it possible to grey them (vdigit wxnivz) out in the list instead of removing them? if not, having them pop up an explaination box? that way people don't pull their hair out trying to find them somewhere else because they remember they had seem them somewhere before.. yes, it would be better, anyway wxPython doesn't allow disabling items in wx.Combobox (toolbar). It would be possible via customized widgets - extra work... Another approach: * don't remove items from toolbar's combobox * after choosing e.g. 'vdigit', show dialog which explains to the user that the extension is not available. * switch back to '2D view' Would this be better from user point of view? M. -- Ticket URL: http://trac.osgeo.org/grass/ticket/586#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
[GRASS-dev] grass python module
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] single vs. multiple sqlite db files [was v.db.calc]
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 features of a vector map (adjacency, containment, overlapping, and so on). My point of view on vector model (perhaps we are sliding towards a new topic right now) is that topological structure is helpful mainly for : * detecting digitizing errors, * easily performing spatial analysis, * significantly reducing map storage volumes. But for my personal needs (particularly dealing with both space and time variability data mapping) I admit that non-topological models can be a good way to handle data... Vincent ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.out.ogr and data source that do not support creation or overwrite
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)
G_fatal_error(_(Unable to open OGR data source '%s'),
dsn_opt-answer);
Now, the last bit aborts operation whenever a new OGR data source could
not be created or an existing one overwritten. Unfortunately, there
are many database storage drivers in OGR, that do not support creation
of new data sources (i.e. databases), but only layers (i.e. tables
inside existing databases). With the current code, that capability
can never be used!
Either I am doing something really stupid here, or nobody has noticed
that problem before.
Anyway, a quick fix that works for me (but is not exactly pretty) is to
blindly attempt connecting to an existing source in case one of the
drivers with that problem is used:
Ogr_ds = OGR_Dr_CreateDataSource(Ogr_driver, dsn_opt-answer,
papszDSCO);
/* some OGR drivers do not support overwriting existing sources
or creating new ones */
if (Ogr_ds == NULL) {
if (!strcmp (frmt_opt-answer, SQLite) ||
!strcmp (frmt_opt-answer, PostgreSQL)) ||
!strcmp (frmt_opt-answer, MySQL)) {
G_message(_(Attempting to open existing OGR data source.\n));
Ogr_ds =
OGR_Dr_Open(Ogr_driver, dsn_opt-answer, TRUE);
}
}
CSLDestroy(papszDSCO);
That way, things work for me using existing SQLite databases.
I am sure there are many more trouble candidates among the OGR
drivers, but those are the ones I could come up with at first
glance.
There seem to be more problems with v.out.ogr and database storage.
I'll try to give this some more testing now.
Cheers,
Ben
--
Benjamin Ducke
Senior Geospatial Consultant
Oxford Archaeology
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.
Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.du...@oxfordarch.co.uk
--
Files attached to this email may be in ISO 26300 format (OASIS Open Document
Format). If you have difficulty opening them, please visit http://iso26300.info
for more information.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] QGIS GRASS
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, but the grass searched from people is related to the vegetation mainly ;-) If you compare grass gis vs qgis (http://www.google.com/insights/search/overviewReport?cat=q=qgisgeo=date=gprop=clp=cmpt=q#q=qgis%2Cgrass%20giscmpt=q) you can see the trend with decreasing searches for grass and rising for qgis, but still it has limitations. becouse is the composition of two word and you can imagine how many words can be combined to search for G.R.A.S.S. Maybe web site hits statistics are more relevant? or number of download? :-D Paolo Cavallini wrote: Hi all. Even though these web statistics are always to be taken with caution: http://www.google.com/insights/search/overviewReport?cat=q=qgisgeo=date=gprop=clp=cmpt=q#q=qgis%2Cgrass giscmpt=q (thanks Maxim for pointing it out) I think they tell us several interesting things, particularly from the point of view of users (those most likely to use a search engine for the sw they are using/trying to use): - qgis is on the rise, grass is decreasing. I do not think this means there is competition between the two, but rather that people use the two programs as a toolset, doing what is best done with each of them. It seems that qgis is replacing grass for simpler (desktop) tasks, and grass is mainly used for more complex analyses - for both programs, the association between the two terms (qgis+grass) is among the top ranking search items; this confirms the above hypothesis - together, they are much more popular that their main alternative, gvSIG: http://www.google.com/insights/search/overviewReport?cat=q=qgisgeo=date=gprop=clp=cmpt=q#q=qgis%2Cgrass gis%2Cgvsigcmpt=q . Unfortunately, it seems that both qgis and grass devs are mainly concentrated on their core sw, with limited attention to the interaction between the two (eg the qgis-plugin-grass does not have a dedicated dev, and in grass a lot of dev effort has been put to implement a new UI, replicating many functionalities already usable in qgis (also for grass layers). I would therefore respectfully suggest devs, form the users perspective, to consider concentrating on the best of each world, reducing the duplication of efforts, and improving the (already good) interaction between the two programs. On the other hand, I would suggest users to invest some resources to go in the same direction. As a part of this, I'm investing some money (and I plan to do more in the future) to fix long standing bugs in qgis, personally mainly focusing on the qgis-plugin-grass: http://www.qgis.org/wiki/index.php/Bugs All the best. -- Dr. Eng. Massimiliano Cannata Responsabile Area Geomatica Istituto Scienze della Terra Scuola Universitaria Professionale della Svizzera Italiana Via Trevano, c.p. 72 CH-6952 Canobbio-Lugano Tel: +41 (0)58 666 62 14 Fax +41 (0)58 666 62 09 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] QGIS GRASS
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: http://www.faunalia.it/pc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [osgeo4w] #85: grass needs wxWidgets to compile some GUI tools
#85: grass needs wxWidgets to compile some GUI tools +--- Reporter: hamish |Owner: osgeo4w-...@lists.osgeo.org Type: enhancement | Status: new Priority: major|Component: Package Version: | Resolution: Keywords: grass| +--- Changes (by hamish): * keywords: = grass * cc: grass-dev@lists.osgeo.org (added) * summary: please make wx-config available = grass needs wxWidgets to compile some GUI tools Comment: added grass dev list to cc: see the ticket for jef's reply. -- Ticket URL: https://trac.osgeo.org/osgeo4w/ticket/85#comment:3 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer for the OSGeo stack.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] New Wiki page on Spatial SQL
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 tests have been a bit disappointing, but I hope to be able and sort out the issues with v.out.ogr soon and then bring that text into a form that's digestible for end users. Cheers, Ben -- Benjamin Ducke Senior Geospatial Consultant Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel: +44 (0)1865 263 800 (switchboard) Tel: +44 (0)1865 980 758 (direct) Fax :+44 (0)1865 793 496 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] new flags --g
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 be simplified to
grass.read_command('g.region', flags='p', shellstyle = True).
Shell style output is widely used in the scripts and at the end also
in the wxGUI. The global flag could simplify the usage. Moreover some
modules uses '-g' for other purposes which is quite confusing.
Martin
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #111: r.los fails in WinGRASS with high values for max_dis parameter
#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: major | Milestone: 6.4.0 Component: Raster| Version: svn-develbranch6 Resolution:|Keywords: wingrass r.los Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by aborruso): Hi Replying to [comment:18 hamish]: does it still break with 6.4.0rc4? Hamish I have made a test with 6.4.0SVN-r36903-1, and it does not crash. Andrea -- Ticket URL: https://trac.osgeo.org/grass/ticket/111#comment:19 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 python module
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 move out the include stuff at the same time). Markus ? Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.db.calc
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 work on string column. Don't remember - is there a ticket? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] QGIS GRASS
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 QGIS, too. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #570: startup problem with standalone GRASS install
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 need to compile your own wxPython using mingw. Also python-config is 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 (?) Okay, I'm going to hold off doing anything regarding Windows until that gets sorted out. Ultimately, one of the biggest problems facing the Windows version is that it's *still* a major hassle to compile GRASS on Windows. Anyone interested in having GRASS work well on Windows would be well advised to spend less time worrying about end users, and spend more time making life easy for developers. Otherwise, we're going to remain stuck in the situation where, at any given time, at most one person has the ability to compile GRASS on Windows, that one person spends their time focusing on end users, but they eventually get fed up and quit because they're having to do it all themselves. -- 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] Re: [GRASS GIS] #570: startup problem with standalone GRASS install
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 hassle to compile GRASS on Windows. Anyone interested in having GRASS work well on Windows would be well advised to spend less time worrying about end users, and spend more time making life easy for developers. Agreed. 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 python binaries are available and optionally also python-config. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass python module
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. Currently, those modules are named swig.grass, swig.vector, etc. That was done to avoid a collision over import grass. But swig is a rather generic prefix to use. I had thought about changing it from swig.* to grass.*, and renaming grass to e.g. grass.script. The question is whether e.g. grass.vector should contain the functions from grass.py or the SWIG functions for the vector library. IOW, which one gets precedence? Or should we make them equal and just have grass.script.vector and grass.swig.vector? And should swig even be visible, or should it be e.g. grass.lib.vector? -- 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] Re: [GRASS GIS] #570: startup problem with standalone GRASS install
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 python binaries are available and optionally also python-config. Whatever works, really. Preferably, whatever works with the wxPython binary packages from wxpython.org, rather than requiring a GRASS-specific version. -- 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] v.db.calc
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 string column. Don't remember - is there a ticket? fwiw, the wrote: quoting has gotten a bit misaligned. my vote is to play conservative and stay with dbf in grass6.x for now, but move to sqlite for grass7. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
