[GRASS5] To: Postgresql interface programmers...

GRASS GRASS developer
1

Hi, Eric, hi, all,
--- "Eric G . Miller" <egm2@jps.net> wrote:

Hi all,

I've been looking at some of the PostgreSQL
interface code and I have a
couple comments/suggestion/questions. First, there
is no way to ever
specify a password. If I wanted to connect to a
remote machine, I'd
have to resort to the unsecure 'export
PGPASSWORD=fiddlesticks' (or
whatever the variable's called). I realize a
password can't be securely
stored in ~/.grass5rc, but perhaps a flag could?

The postgres ident authentication, or the "password
passwd"? I tested both schemes, but the former was
found to be no good for the purpose. so do we send
password in clear?

Also, the code always
assumes the postgres username matches the system
user name. This
doesn't have to be the case (though it often is).

yes, i tink this has to be done.

Also somewhat problematic is, g.select.pg set host
to 'localhost' if no
host is specified. This causes libpq to use TCP
sockets rather than
UNIX sockets. It may be on a system, you don't want
the TCP sockets
open for postgres (or at least not without a
user/passwd authentication
since ident sucks). I would ask that people let
"PGHOST" be NULL. Or if
you use PQconnectdb(), it can be a zero length
string. Also, I noticed
several instances where code looked like:

  if((pghost = G_getenv("PGHOST")) == NULL) pghost =
NULL;

Unless I'm mistaken, that will *always* fail if
PGHOST is unset. My
reading is you need to use 'G__getenv()'. The
second assignment is, of
course, redundant.

I remember hitting into this. The way you propose
works well. Shall this be changed in all modules, so
good.

Anyway, I hope I don't sound like I'm lecturing
(it's late, I'm tired,
some other lame excuse...). I'd be happy to rewrite
module interfaces,
but I suspect some authors wouldn't like that.

hope i'm beyond the suspected. would be nice to have
people work together.
best regards,
alex

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

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

2

Alex,
  I wrote up a little generic pg_connect() interface that has all
the options of PQconnectdb() as individual char *. It also takes care
of reading the GRASS environment variables. It seems to work fine.

  However, I'm thinking if GRASS is about to enter feature freeze,
maybe better to put off dealing with the authentication issues until
later. All the *pg code seems to work at the moment, so changing it
now's not such a good idea. I can see the generic function handling
these questions (along with g.select.pg):

  Use username/password authentication?
    PG_USER = ...
    PG_PASS_REQ = 1
      Crypt password ?
        PG_USE_CRYPT = 1
  Use database?
    PG_DBASE = ...
  Use hostname?
    PG_HOST = ...
  Use port?
    PG_PORT = ...

  If a user elects to use username and password, then prompting for a
password will always be required. Modules or the generic interface
could provide this function. There should be no command line
password=<foo> since that is insecure. If PG_USE_CRYPT is set, then the
password will be sent with crypt(), otherwise plain text (not so secure,
but common). Password authentication will make it difficult for scripts
unless the author puts the password in the script file.

  Out of all the possible environment variables, the only one that
would absolutely be required is the name of the database (we'll assume
nobody puts real data in "template1"). PostgreSQL defaults should
handle all the rest unless the system requires authentication. No real
way to discover this except by testing in g.select.pg and catching the
"authentication required" error.

P.S. A while back, I worked on an M4 feature test macro for
finding/testing postgresql include paths and libraries. It /mostly/
worked. Shall I resurrect this for GRASS? It'll need a little more
work, since I uncovered some failure points with it (M4 macros are still
pretty alien to me).

--
/bin/sh ~/.signature:
Command not found

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

3

I wonder if putting Postgress along Grass is really good on the long
term. It seems to me that Grass could (should ?) be the (geo)graphical
interface to postgress, at least for the vector data (i.e. areas, lines
and sites), and that all attributes should be managed by the RDBMS.

The negative point of this approach is that Grass won't work without
PostgresSQL, but it will be something much more usable for "real work",
where the attributes are as important as the geometry of objects.

Michel Wurtz

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

4

On Fri, Sep 15, 2000 at 10:09:27AM +0200, Michel Wurtz wrote:

I wonder if putting Postgress along Grass is really good on the long
term. It seems to me that Grass could (should ?) be the (geo)graphical
interface to postgress, at least for the vector data (i.e. areas, lines
and sites), and that all attributes should be managed by the RDBMS.

The negative point of this approach is that Grass won't work without
PostgresSQL, but it will be something much more usable for "real work",
where the attributes are as important as the geometry of objects.

I don't think Postgres is appropriate for managing vector or raster data
that you're working on. Publishing it, or using it in some read-only
fashion (like spatial web-browser app) is not a bad idea. Postgres
geometry does not support topology. A problem, IMHO. Non-topological
GIS's can lead to really messed up vector coverages. I've looked at
this, and every solution with Postgres handling the data seems messy to
me. It'd be easier to export vector data to postgres for some other
application to make use of than to do the reverse. See all the problems
with v.in.shape for instance. Same thing here.

That said, I've got some ideas about having it manage vector attribute
data. GRASS definitely needs a better solution for this. I'm not sure
we should tie it to any external product *exclusively*. I think, better
to add some native flat-file attribute type database handling directly
in GRASS; then, tie in support for multiple external DBMSs (PostgreSQL,
RIM, Informix, Oracle, etc...). I think this is what the DBMI interface
is all about, no? Still, at a standalone level, GRASS needs to handle
attribute tables, not just category/labels.

While I'm at it... Think GRASS needs support for assigning colors to
areas and lines based on category numbers or ranges. This should work
similar to r.colors. Also, GRASS should be able to do selected subsets
from vector coverages for use in analysis and display. It's sort of
like a v.reclass and r.mask which would transparently function with
d.vect, or other vector query processing analyses. Need to work out a
protocol for making the selections, storing them on disk for later use,
and then modifying the vect libraries to make use of this info.

I'm not up to speed on what everyone is working on, so...

--
/bin/sh ~/.signature:
Command not found

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

5

"Eric G . Miller" wrote:

That said, I've got some ideas about having it manage vector attribute
data. GRASS definitely needs a better solution for this. I'm not sure
we should tie it to any external product *exclusively*. I think, better
to add some native flat-file attribute type database handling directly
in GRASS;

I think that this may be done also through new DBMI driver.

then, tie in support for multiple external DBMSs (PostgreSQL,
RIM, Informix, Oracle, etc...). I think this is what the DBMI interface
is all about, no? Still, at a standalone level, GRASS needs to handle
attribute tables, not just category/labels.

While I'm at it... Think GRASS needs support for assigning colors to
areas and lines based on category numbers or ranges. This should work
similar to r.colors. Also, GRASS should be able to do selected subsets
from vector coverages for use in analysis and display. It's sort of
like a v.reclass and r.mask which would transparently function with
d.vect, or other vector query processing analyses. Need to work out a
protocol for making the selections, storing them on disk for later use,
and then modifying the vect libraries to make use of this info.

We started to work on dig5.0 format with multi-category support (with
D. D Gray). I think that colors could be saved in reclassed files as
categories with some new number. For example link to database is in
category with number 1 (cat_num=1, cat=123) and to reclassed file is added
new category (cat_num=1, cat=123; cat_num=1001, cat=5) i.e. color number 5
from some color table or (cat=255000000) color is red.

Radim

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

6

On Fri, 15 Sep 2000, Eric G . Miller wrote:

> I wonder if putting Postgress along Grass is really good on the long
> term. It seems to me that Grass could (should ?) be the (geo)graphical
> interface to postgress, at least for the vector data (i.e. areas, lines
> and sites), and that all attributes should be managed by the RDBMS.

I don't think Postgres is appropriate for managing vector or raster data
that you're working on. Publishing it, or using it in some read-only
fashion (like spatial web-browser app) is not a bad idea. Postgres
geometry does not support topology. A problem, IMHO. Non-topological
GIS's can lead to really messed up vector coverages. I've looked at this,
and every solution with Postgres handling the data seems messy to me.
It'd be easier to export vector data to postgres for some other
application to make use of than to do the reverse. See all the problems
with v.in.shape for instance. Same thing here.

  I used to think that postgres would work because it supports graphic
shapes. After doing some minimal research, I also became convinced that we
need an object-oriented dbms rather than the object-relational dbms that
postgres is.

  I've also done some reading on spatial data structures and learned that
there are several approaches, all of which appear equally useful to me. But,
I'm not a computer scientist with a deep understanding of data structures
and GIS internals.

  What I do know is that Bruce has assembled a team at Baylor that includes
CS faculty with expertise in this subject. Perhaps we should ask the
database experts to design an attribute database that works with vector and
raster data and is specific to GRASS. This will not preclude tieing to any
other dbms (via ODBC, for example), but will put multiple table database
capabilities in GRASS for those of us end users who don't need to link to an
enterprise-level or university-level system.

  A multiple-table (probably relational) design is needed because not all
attributes of a single object should (can?) be stored in one table. Soils
data, for example.

  As long as we have this discussion, I'd like to see the database experts
show us some suggestions. I, for one, would be way over my head otherwise.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com

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

7

Rich Shepard wrote:

On Fri, 15 Sep 2000, Eric G . Miller wrote:

> > I wonder if putting Postgress along Grass is really good on the long
> > term. It seems to me that Grass could (should ?) be the (geo)graphical
> > interface to postgress, at least for the vector data (i.e. areas, lines
> > and sites), and that all attributes should be managed by the RDBMS.

> I don't think Postgres is appropriate for managing vector or raster data
> that you're working on. Publishing it, or using it in some read-only
> fashion (like spatial web-browser app) is not a bad idea. Postgres
> geometry does not support topology. A problem, IMHO. Non-topological
> GIS's can lead to really messed up vector coverages. I've looked at this,
> and every solution with Postgres handling the data seems messy to me.
> It'd be easier to export vector data to postgres for some other
> application to make use of than to do the reverse. See all the problems
> with v.in.shape for instance. Same thing here.

  I used to think that postgres would work because it supports graphic
shapes. After doing some minimal research, I also became convinced that we
need an object-oriented dbms rather than the object-relational dbms that
postgres is.

  I've also done some reading on spatial data structures and learned that
there are several approaches, all of which appear equally useful to me. But,
I'm not a computer scientist with a deep understanding of data structures
and GIS internals.

  What I do know is that Bruce has assembled a team at Baylor that includes
CS faculty with expertise in this subject. Perhaps we should ask the
database experts to design an attribute database that works with vector and
raster data and is specific to GRASS. This will not preclude tieing to any
other dbms (via ODBC, for example), but will put multiple table database
capabilities in GRASS for those of us end users who don't need to link to an
enterprise-level or university-level system.

My thinking goes in that direction and I will like to be in contact with those
at Baylor. GRASS GIS and attribute data are organised on file structure with
flat
files. We need to design a equivalent structure that can be implemented by any
database management software (DBMS). The metadata need to be in the DBMS.

  A multiple-table (probably relational) design is needed because not all
attributes of a single object should (can?) be stored in one table. Soils
data, for example.

We started to do work in this direction. We do our analysis using object
oriented approchs but we do relational implemtation. On a short term, SQL
interface is a viable approch to many DBMS.

  As long as we have this discussion, I'd like to see the database experts
show us some suggestions. I, for one, would be way over my head otherwise

8

Robert Lagacé wrote:

Rich Shepard wrote:
>
> [...]
> What I do know is that Bruce has assembled a team at Baylor that includes
> CS faculty with expertise in this subject. Perhaps we should ask the
> database experts to design an attribute database that works with vector and
> raster data and is specific to GRASS. This will not preclude tieing to any
> other dbms (via ODBC, for example), but will put multiple table database
> capabilities in GRASS for those of us end users who don't need to link to an
> enterprise-level or university-level system.
>

My thinking goes in that direction and I will like to be in contact with those
at Baylor. GRASS GIS and attribute data are organised on file structure with
flat
files. We need to design a equivalent structure that can be implemented by any
database management software (DBMS). The metadata need to be in the DBMS

9

----- Original Message -----
From: Rich Shepard <rshepard@appl-ecosys.com>
To: <grass5@geog.uni-hannover.de>
Sent: Friday, September 15, 2000 7:53 AM
Subject: Re: [GRASS5] Postgresql and Grass

<snip>

  A multiple-table (probably relational) design is needed because not all
attributes of a single object should (can?) be stored in one table. Soils
data, for example.

<snip>

I am familiar with the USDA NRCS soils database. Recently,
I coverted their schema to an Xml DTD schema. They are
going to post data to their users in both Access MDB format
as well as Xml format.

Going with a proprietary format makes software solutions
unattainable for those monetarily challenged. Plus, software
becomes obsolete (like Access). SQL server, Informix,
and Oracle are a large overhead. mySQL is low overhead;
however there is one other consideration...

The flat ASCII file format has the benefit of being portable.
If the meta data files are reasonably small, there is no large
performance penalty for reading them. Moving to an Xml
based format is a reasonable alternative IMHO.

I would be willing to assist in this direction.

John Huddleston

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

10

On Fri, Sep 15, 2000 at 01:47:26PM -0600, John Huddleston wrote:

----- Original Message -----
From: Rich Shepard <rshepard@appl-ecosys.com>
To: <grass5@geog.uni-hannover.de>
Sent: Friday, September 15, 2000 7:53 AM
Subject: Re: [GRASS5] Postgresql and Grass

<snip>
> A multiple-table (probably relational) design is needed because not all
> attributes of a single object should (can?) be stored in one table. Soils
> data, for example.
>
<snip>

I am familiar with the USDA NRCS soils database. Recently,
I coverted their schema to an Xml DTD schema. They are
going to post data to their users in both Access MDB format
as well as Xml format.

Is that a DTD or an XML Schema? The new XML Schema standard looks like
a better way than SGML/XML DTD's. It has better typing and pattern
matching constraints, to name a couple features. These are the kinds of
things needed for databases. It's pretty new, so there aren't many
tools to use it yet ;(

Going with a proprietary format makes software solutions
unattainable for those monetarily challenged. Plus, software
becomes obsolete (like Access). SQL server, Informix,
and Oracle are a large overhead. mySQL is low overhead;
however there is one other consideration...

The flat ASCII file format has the benefit of being portable.
If the meta data files are reasonably small, there is no large
performance penalty for reading them. Moving to an Xml
based format is a reasonable alternative IMHO.

Still, for any reasonably large database some kind of indexing scheme is
necessary for performance. Typing metadata is also desirable. As a
note: the preferred standard for XML is Unicode (get those high
characters). I'm sure all our European friends would appreciate not
limiting to ASCII.

I would be willing to assist in this direction.

Yes, I like this too.

--
/bin/sh ~/.signature:
Command not found

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

11

What I meant to say was... :slight_smile:

It is going off-track a bit, but you may recall that we had a thread on
the devel list a few months back about inclusion of external software.
This also relates to reusable components within GRASS. There are
actually a lot (at least a few) implementations of various spatial data
structures in various parts of the project. Many of these have been
developed to satisfy the needs of a particular large-scale module or set
of modules, often from a contributed project. What we need is a set of
routines for spatial data-structures where the API is well-exposed and
easy to use for modular development and pluggability.

There is already a generalised binary tree implementation in libgis
which modules can link to for most purposes with little or no
modification. What we need is similar libraries for handling R-trees and
octrees and similar structures. Also for actual spatial structures, such
as quad-edge. (The GNU Triangulated Surface library might be a good
plug-in)

I think however it is important not to confuse the roles played by an
RDBMS or ODBMS with the management of spatial data structures
themselves. An interface allowing connection to heavier databases is a
good thing to create and maintain, and we should perhaps think about
that for a future version, but a simple table based structure within
GRASS is also necessary for the day to day management of map associated
attributes, and it seems our dbmi is quite adequate for the job. Until
we deal with maps that have 10's of thousands of entities (eg polygons)
there is no great advantage to having anything beyond a `flat' data
access structure for day-to-day GIS operation. Then we just plugin our
binary tree to dbmi - or even use a btree implementation.

In the long term what would be good to see would be a system of spatial
data management deployed in a way similar to how linear algebra software
is managed now: Standard routines and structures for all the major
functions with optimisation for particular platforms and a well-exposed
standard API. This approach would be appropriate as spatial data
processing, like linear algebra, is an area where much of the intensive
number-crunching is bound up. Unlike linear algebra, unfortunately, the
spatial data field is very `proprietary', not at all public domain, and
if GRASS was to take on the development of such a standard, we would be
on our own. So I would agree that advice and guidance from experts in
spatial data structuring and storage would be an essential minimum
requirement for the task. I would be happy to be involved in such a
project, but I am in no way an expert in the field.

David

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

12

Hi,

i can only jump into this discussion now and i must admit that i have
very little experience with database/gis interoperability.

In my eyes the most needed things are:
- color support for vectors (please use the structure from raster maps
so that users do not have to learn another system)
- full category/attribute support for vectors,
- selection and reclassification of vectors based on attributes.
(- maybe inclusion of vectors in the raster based MASK selection in
GRASS?)
- metadata/history support for vectors.

I personally would prefer GRASS not to be tied to a specific database
server (PostgreSQL or any other). The Unix-ODBC is great, but limits the
connectivity to relational DBMS (?). I got the impression that the
object-oriented DBMS are not yet ready for wider use and wonder if there
is an open implementation for a object-oriented DBMS.

The flat-file approach of GRASS has many advantages for small datasets
and i think it should be possible to have both (flat-file database and
connection to DBMS) within GRASS.

GRASS vectors IMHO should be usable without a DBMS (with reduced
functionality).
I think that the main problem is that there are until now no widely
accepted, open data structures/formats for both data and metadata. Many
solutions are proprietary or only used by specific communities within
GIS.

XML seems to be an alternative, but i have no idea if it is possible to
use XML for data storage (speed considerations, indexing etc.) or if it
is only useful for data exchange.

I hope that the experts can give a draft on the alternatives so that
users without much background in computer science and database design
can comment on this.

cu,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

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

13

Hi Eric (grass5 list)

----- Original Message -----
From: "Eric G . Miller" <egm2@jps.net>
To: "grass5" <grass5@geog.uni-hannover.de>
Sent: Friday, September 15, 2000 2:33 PM
Subject: Re: [GRASS5] Postgresql and Grass

Is that a DTD or an XML Schema? The new XML Schema standard looks like
a better way than SGML/XML DTD's. It has better typing and pattern
matching constraints, to name a couple features. These are the kinds of
things needed for databases. It's pretty new, so there aren't many
tools to use it yet ;(

Xml Schema and DTD both were created . Actually there are several
good tools available. The one that meets my needs is Xml_Authority. See
http://www.extensibility.com/

There are many major players in the industry who already use Xml as a
way of businees. See http://www.xml.com/xml/pub/Guide/XML_Parsers
for those doing the parsers.

There are many sites including http://www.xmlsoftware.com/ which offer
support for those getting started. For free software and tools see
http://www.garshol.priv.no/download/xmltools/ and the search tool
http://www.garshol.priv.no/cgi-bin/searchform.py and my favorite by Lars
http://www.garshol.priv.no/download/xmltools/

Still, for any reasonably large database some kind of indexing scheme is
necessary for performance. Typing metadata is also desirable. As a
note: the preferred standard for XML is Unicode (get those high
characters). I'm sure all our European friends would appreciate not
limiting to ASCII.

As soon as I hit the send icon I knew I missed that. Yes Unicode is the
standard for Xml. Still portable, too.

List your priorities. One is portability. You want to be able to take
your datafile and use it on a different platform. For our time series
data, netCDF ftp://ftp.unidata.ucar.edu/ files are the choice. Xml is
useful for database schemas, transferring data, and more. Performance
is good except when you add a large overhead with middleware. We use
Xml in four different applications. Two of them are large databases,
see http://nasis.nrcs.usda.gov/ for the US National Soils Information System
link. Their plan is to put up one central web server for all to access.
Data will be served up in Xml format.

Let's see where we go with this. I have tools, experience, and can guide
us down this path if we wish to go there.

John Huddleston

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

14

On Sat, Sep 16, 2000 at 05:52:22PM +0200, Andreas Lange wrote:

Hi,

i can only jump into this discussion now and i must admit that i have
very little experience with database/gis interoperability.

In my eyes the most needed things are:
- color support for vectors (please use the structure from raster maps
so that users do not have to learn another system)

I'll add hatchure patterns and more line/marker styles (mostly for
ps.map ...).

- full category/attribute support for vectors,
- selection and reclassification of vectors based on attributes.

Yes, I like to see something similar to Arc/Info's RESELECT. The d.*.pg
commands kind of do this, but something with a little more persistence
might be in order.

(- maybe inclusion of vectors in the raster based MASK selection in
GRASS?)
- metadata/history support for vectors.

I personally would prefer GRASS not to be tied to a specific database
server (PostgreSQL or any other). The Unix-ODBC is great, but limits the
connectivity to relational DBMS (?). I got the impression that the
object-oriented DBMS are not yet ready for wider use and wonder if there
is an open implementation for a object-oriented DBMS.

Agree with (1), not sure about (2). Although it may be heresy to
suggest, there are at least a couple implementations for using "legacy"
Xbase type files. Including indices...

The flat-file approach of GRASS has many advantages for small datasets
and i think it should be possible to have both (flat-file database and
connection to DBMS) within GRASS.

GRASS vectors IMHO should be usable without a DBMS (with reduced
functionality).

I don't see why there needs to be "reduced functionality". Well, maybe
no concurrent writers!

I think that the main problem is that there are until now no widely
accepted, open data structures/formats for both data and metadata. Many
solutions are proprietary or only used by specific communities within
GIS.

Yep, everyone's rolled there own (including GRASS). Even the various
agencies with the U.S. Federal gov't have promulgated at least half a
dozen different vector file formats (not to mention rasters). However,
FGDC metadata is becoming quite common (and widely supported). I
believe there's a proposed ISO standard that's very similar (need to
check... confused with SDTS??).

XML seems to be an alternative, but i have no idea if it is possible to
use XML for data storage (speed considerations, indexing etc.) or if it
is only useful for data exchange.

I'm skeptical about XML for day-to-day. Seems to incur alot of parsing
overhead. Good for data exchange though.

I hope that the experts can give a draft on the alternatives so that
users without much background in computer science and database design
can comment on this.

Well, I'm no expert but I've got at least a vague idea of a directory
hierarchy for attribute tables in GRASS:

                 [mapset]
                     |
                   [tbl]
                     |
        ------------------------------------------------
        | | |
     [free] [vector] [cell]
        | | |
        |---table1 [map] [map]
        | | |
        |---table2 | cat
        | |---area
        ... |---line
                           |---site(?)
                           |---node(?)
                           |---network(?)
                           |---route(?)
            
Generally, the idea is, there's a 'tbl' directory. Under the table
directory there are three directories 'free', 'vector' and 'cell'.
'free' would refer to any extra table not bound to a spatial layer
through a cat #. Under both 'vector' and 'cell' would be a directory
for each raster or vector map. Only integer cells are considered, maybe
all types? Under vector, there'd be files for line attributes and area
attributes keyed on cat#. I don't know about sites or labels or
possible additions to the current vector model. At the top level
directory 'tbl' some kind of file listing 'tied' tables and their join
key(s) could be listed (so things like the USDA SSURGO database could be
accomodated).

This'd all take a bit more consideration... Definitely a post GRASS 5.0
stable thing.

--
/bin/sh ~/.signature:
Command not found

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