[GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other than '1' in gi s.m

[Michael Barton]

Trevor,

I won't belabor this, because I think you and Moritz both have important
points. But want mention a couple things.

Doing what you suggest *is* 'cleaner' in a pure database sense. However, you
can do that now by simply using GRASS tools to assign unique cat values to
layer 1, and forgetting about the other layers.

Layers *are* shortcuts, that are especially handy for one-to-many and
many-to-one relationships between vector objects and attribute records. They
make intermediary tables unnecessary and can help save space for vector
files with large numbers redundant objects linked to an attribute table with
few records (many-to-one join). They also save a link, sort of like a view
(see below), between vector objects and attribute table records so that you
can query with specifying one of the join clauses in a where statement. The
'where [vector key]=[table key]...' is implied once you've run v.db.connect.
But I suppose that this is where the cleaner joins that you mention come in.

It would be nice to be able to do multi-table joins. But I'm not sure you
cannot do that already if you're working with a DBMS that supports true SQL
queries, like PostgreSQL or SQLite. I think that GRASS will simply pass on
an SQL query to the DBMS. If so, then multi-table joins might be doable. Has
anybody tried this?

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL. A
dbf format table structure and database driver is included with the standard
GRASS build. However, the dbf tables link to vectors exactly like PostgreSQL
tables--via the key we call a cat value in a layer. They are
interchangeable, structurally, with PostgreSQL, MySQL, SQLite, etc. For each
of the supported DBMS's there needs to be a GRASS driver. The dbf driver is
fairly limited in terms of SQL, but the drivers for other systems are much
richer. But in any case, you can link different PostgreSQL tables to each
GRASS key field that you create as a layer (You probably already know that,
but others might want to have this clarified). We are seriously considering
switching to SQLite as the database driver and table structure that comes
with the default build. This would offer a much richer set of SQL, although
tables still have to link up with vector objects somehow.

It would indeed be nice to be able to save views, although this has nothing
to do with keys. By semi-permanently linking multiple tables with the
objects of a vector file, layers can sort of serve as views, but they don't
have the richness or flexibility of real views.

It would also be nice to be able to select vector objects and their linked
attribute records interactively from a map. This is one nice feature of
ArcGIS and MapInfo that GRASS lacks.

What I think Moritz is getting at is that you can simply ignore layers 2
through whatever and do exactly what you are proposing. Or you can use
layers as a short cut to joining multiple tables to vectors.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton