SQLite note (Re: [GRASS5] db.oodbfedit: a _very_ simplistic approach to dbf attribute editing)

Radim Blazek radim.blazek at gmail.com
Fri Aug 5 03:31:38 EDT 2005


There is also ogr database driver in GRASS (dbmi), 
Probably it is possible to use SQLite with GRASS vectors
via OGR, but I have no idea about limits/performance.

Radim

On 8/4/05, Daniel Calvelo Aros <dcalvelo at minag.gob.pe> wrote:
> From: Markus Neteler <neteler at itc.it>
> Sent: Thu, 4 Aug 2005 17:33:33 +0200
> >
> > On Wed, May 25, 2005 at 02:30:41PM +0200, Markus Neteler wrote:
> > > On Wed, May 25, 2005 at 10:33:28AM +0200, Moritz Lennert wrote:
> > > ...
> > > > All these different elements contribute to the idea that finally my idea
> > > > wasn't so great ;-)
> > > > I'll pursue the other path of creating easy frontends to db.execute.
> > >
> > > Maybe things should go into sqlite3 direction (there are tcl/tk bindings),
> > > and/or OGR SQL engine.
> > >
> > > sqlite3 could be interesting to manage raster time series as well etc.
> > >
> >
> > There is also a browser (or several):
> >  http://sqlitebrowser.sourceforge.net/screenshots.html
> 
> Furthermore, OGR can be compiled with sqlite3 support. It can then store a
> spatial database as one table with a WKT column.
> 
> I've been using this feature to convert dbf to sqlite: use ogr2ogr with a
> NONE geometry type and you have only the attributes in your sqlite db. The
> converse sqlite->dbf though cannot be accomplished through ogr2ogr since you
> have no geometry. You can use sqlite's dump and db.execute instead. I thought
> going this route for upgrading grass' sql capabilities, but the conversion
> process in ogr is rather slow.
> 
> BTW, Moritz, have you tried the current CVS for extended SQL capabilities?
> Please do so, and come up with wishes for extending it further. I've been
> griping with NULL/NAN handling, but have come up with nothing concrete yet.
> 
> Daniel.
>




More information about the grass-dev mailing list