[GRASS5] Multiple attribute support in GRASS5.1:someconsiderations (long)

[Andrea Aime]

Frank Warmerdam wrote:
> 
> Radim Blazek wrote:
> > SQLite seems to be a good solution. The only problem I see is that there is no
> > GUI front-end which was one of my criteria. Dbf files may be edited in StarOffice
> > and MSAccess (including forms). I thing that we don't have human resources for developing
> > database front-end within grass and we don't want to reinvent wheel. So if such front-end
> > is available is important.
> 
> Radim,
> 
> It seems to me that if we use easily substitutable SQL based RDBMS systems
> then folks that need forms support and a GUI front end can choose an
> RDBMS that has them.  If we use DBF and depend on external gui front ends it
> still won't be possible to distribute GRASS database forms applications since
> different users might choose different target RDBMSes, right?
> 
> Is the GUI front end and forms requirement just so that users can see their
> data interactively, or so that substantial forms based applications can be
> built?
> 
> Someone mentioned the issue of having different programs for different
> databases.  I completely agree that if we integrate SQL support smoothly
> into GRASS that the applications should be insulated from the actual database
> backend by some sort of plugable library.  This might be based on an existing
> standard like ODBC or just a custom simplied database API.  I was impressed
> with the relative simplicity of the abstracted database interface in Python.
> 
> BTW, does Postgres have a nice gui front end?  I have always done my work from
> psql, but I would dearly love to try something a little more visual. :-)

Depending on your client you can choose among:
* pgAccess, tcl/tk interface for Unix desktop;
* pgAdmin, Visual Basic interface for Windows users; 
* phpPgAdmin (or something like this...), a web interface
.. need more?

> > BTW: SQLLite files are not portable (The key size thus depends on the size of
> > an integer on the host computer.) but that doesn't matter.
> 
> This is annoying.  In the short term I guess it would be necessary to do a
> database dump and reload to transport to different system types.  I would
> ideally like to see some sort of automatic translation be done at lower
> performance at some point.
> 

Uhm, I don't see it as a major problem, v.out.ascii can dump the table
along with the coordinates, and v.in.ascii do the opposite.
Regards
Andrea Aime

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'