[GRASS-dev] single vs. multiple sqlite db files [was v.db.calc]

[Vincent Bain]

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 at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> >>
> > 
> > 
> 
>