[GRASS5] Layers Clarification

[Moritz Lennert]

Dear Radim and Michael,

Michael Barton wrote:
> Moritz,
> 
> I want to embellish on Radim's response a bit.
> 
> ONE vector object can join with can be joined with ONE attribute table for
> EACH "layer" it has. If it has ONE layer, it can join with ONE table, if it
> has TWO layers, it can join with TWO tables.
> 
> Each "layer" is a data field or column (integer format) named "cat". Each
> vector object has at least 1 cat column ("layer 1") defined by default. You
> can optionally add more cat columns ("layer 2", "layer 3", ...). Each cat
> column serves as a key field to make a join with an attribute table.
> 
> The cat values in different layers can be completely different. For example,
> a particular vector point can have cat=1 for layer 1, cat=5 for layer 2, and
> cat=38 for layer 3.
> 
> The "cat" integers in a "layer" key field must match with a corresponding
> key field (integer format) in the attribute table you want to join. To
> continue with the above example, the vector point would join with a
> line/record in an attribute table whose key field has a value of 1 for layer
> 1, with a line/record in a DIFFERENT table with whose key field=5 for layer
> 2, and a line/record in a THIRD table whose key field=38 for layer 3.
> 
> In this way,  a single vector can be linked with (i.e., one-to-one or
> many-to-one) multiple attribute tables, *IF* you have defined multiple
> layers. But ONE layer, can only be joined with ONE attribute table.


Thanks for your explanations. I now think that I understand layers
correctly.

One question: is it possible to automatically create a second layer for
all features in a file, or does this have to be done via v.digit ?

> 
> I find this a very useful feature, but agree with Trevor that it needs to be
> documented better. I wrote up something on the GRASS WIKI that could be
> added to the docs but I haven't had time to do it yet.
> 

I agree that it seems an interesting feature, although I do agree with
Trevor that what you explain above is something you should also be able 
to deal with in the database (either putting all the variables into the 
same table with some objects having NULL values for some of the values 
(but I know that NULLs in databases are not acceptable to everyone), or 
you can work with foreign keys, views and more sophisticated select 
statements. This should actually not be too complicated with the current 
way GRASS works. Or am I still misunderstanding something ?

Maybe more concrete usage examples (and a bit more extensive than the
ones that Radim gave) might make it easier to understand the added value
of layers.

Moritz