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

[Benjamin Ducke]

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
>>
>>
> 
> 


-- 
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.ducke at 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.