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
