[GRASS5] db.oodbfedit: a _very_ simplistic approach to dbf attribute editing

Daniel Calvelo Aros dcalvelo at minag.gob.pe
Thu Aug 4 15:38:21 EDT 2005

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.


More information about the grass-dev mailing list