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

[Daniel Calvelo Aros]

My first reaction would be: leave that to the QGIS front-end. I'm unsure
however that this is a viable solution in a production environment *today*.

Otherwise, if we wish to stick to a more internal solution, has anybody had
experience with TkTable?

The third-party tool approach may also be tackled through R, which (some)
people are already using in conjunction with GRASS.

BTW Moritz, are your colleagues by any chance ex-ArcViewers? I have the
feeling that trying to move GRASS in that visual/click/user-friendly arena is
a little off-putting, given GRASS' rather UNIXish philosophy. (Which, BTW
could be exploited a little further: not many commands are thought in terms of
piping, for instance.)

Also, note that the name is OpenOffice.org (OOo), including the ".org" for
trademark reasons.

Daniel.

-- Daniel Calvelo Aros

---------- Original Message -----------
From: Brad Douglas <rez at touchofmadness.com>
To: mlennert at club.worldonline.be
Cc: Grass Developers List <grass5 at grass.itc.it>
Sent: Mon, 23 May 2005 18:28:04 -0700
Subject: Re: [GRASS5] db.oodbfedit: a _very_ simplistic approach to dbf
attribute editing

> On Tue, 2005-05-24 at 01:27 +0200, Moritz Lennert wrote:
> > Hello,
> > 
> > Playing around with the question of how to allow spreadsheet-style attribute
> > editing from the GIS Manager - mostly to satisfy demand from colleagues, I
> > came up with this _very_ simplistic solution using openoffice.
> > 
> > This is more of a proof of concept than anything else. The question for me is
> > whether we should try to write a specific tcl routine to access the different
> > types of databases available, or whether we should just use existing tools
> > such as openoffice (but which probably won't be installed for many users).
> 
> I have little experience with TCL, so I don't know the complexity
> involved.
> 
> How difficult would it be to go with the simplistic approach (using
> existing tools) for 6.x and move toward an integrated approach in 7.x?
> 
> On that note, I am making the assumption that the 7.x branch will be 
> an evolving development/cleanup branch, unlike the current stable 
> 6.x series.
> 
> -- 
> Brad Douglas <rez at touchofmadness.com>
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
------- End of Original Message -------