[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.
Daniel.
More information about the grass-dev
mailing list