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

Moritz Lennert mlennert at club.worldonline.be
Fri Sep 22 08:57:37 EDT 2006

Patton, Eric wrote:
> Just a correction, Moritz...
> I think you were quoting Trevor's responses below and attributing them to me
> ;)

Yes, sorry, it was late.

> I am still confused about how layers work in Grass. From what I remember in
> my brief time using Access, when a one-to-many table connection is made,
> each table must have a Primary Key column where the key identifies unique
> records in each table, AND the SAME Primary Key ID is used in all tables for
> one features' attributes. So the attributes of Primary Key ID #5 in table
> 'Sample_Stations' correspond to attributes of Key ID #5 in the tables
> 'Biology', 'Geology', 'Geochem', etc. All attached layers, in other words,
> have the SAME ID (cat) in each table that unites all attibutes for each
> vector geometry under one category ID (all tables have cat #5 for a
> particular sample station, say). 
> However, in your example below, you have DIFFERENT cat IDs in each attached
> table...so I'm confused about how Grass 'knows' that cat 1 in table 1
> matches cat 22 in table 2. How is this connection made if there is no common
> ID between various attributes in each table? Does Grass simply match on a
> row-by-row basis (i.e., record one in table one will be linked to record one
> in table two)? 

Each object in a GRASS map can, but does not need to, have one or more 
"category" value(s) assigned to it. These values are not necessarily 
unique, so you can have different objects with the same category value 
(i.e. you could have a map of roads with the category values 
representing the types of roads from 1 interstate to 5 local).

Categories can be organised by layers, in order to allow a logical 
organisation of information. You could use one layer to define road 
type, another layer to define administrative responsibilites (1 = 
federal, 2 = state, 3 = local), etc.

IIUC, the main aim of such organisation in layers, is to allow the 
combination of different types of objects (e.g. wells, rivers, roads and 
houses) into the same map and to allow the linkage of these different 
types of objects to different tables.

You can actually assign several category values to one object within the 
same layer. I don't really see the use of that (but I imagine there is one).

For each layer of a map, you can define one and only one connection to a 
data table. This makes sense, as otherwise, how should grass know which 
table to use (for example if you use d.vect map where=). GRASS is not an 
RDBMS, it is a geographical analysis system.

In order to link your objects (identified by layer+category 
combinations) to the table, you need to have within that table a 'key' 
column with the same values as the categories. So, the link between a 
map's layer and a table is one-to-one (one table for one layer). You can 
have a one-to-many relation for a map (i.e. many tables for one map) by 
using different layers.

To take your above example, if you want to link your map to all tables 
('Sample_Stations', 'Biology', 'Geology', 'Geochem', etc), you have two 

1) The most obvious, the easiest and in my eyes to most sensible 
solution is to combine the table within your database into one table or 
one view and to link this to the map.

2) Within the map you create a layer for each table, each layer 
containing the same category value for a given object. This is not easy 
to do and is definitely not what the layers were created for in the 
first place.

It would be interesting to hear how many people actually use layers and 
how they use them. I personally don't use them at all, as I normally 
don't mix different types of objects in the same map. Maybe others could 
give some use cases.

I think you have to see the whole vector attribute system as the product 
of GRASS' history. Before version 5.7/6.0, any vector map could only be 
linked to one single attribute list. So, there is obviously room for 
improvement (Radim has listed some here: 

That's also why I plea for _Trevor_ (this time I got it right ;-) ) to 
give some details about his ideas.

> On Wed, September 20, 2006 16:48, Michael Barton wrote:
>> You CAN link multiple tables to single vector objects. That is what
>> layers is all about. You need a separate CAT column for each table you
> link.
>> Each cat column is a "layer". It serves as a key to link the object with a
>> record in a table.
> So, does each cat column in each table need to have the SAME ID  for a given
> vector object?

No, you can give different category values to a given object in 
different layers and then link these layers to the respective tables.

I think once our minds become clearer about these layers, we should 
write a small text for the wiki... ;-)


More information about the grass-user mailing list