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

[Patton, Eric]

I'm resending this message as I entered the wrong address in for Trevor, and
it way not have gotten to grass.itc.it either. Sorry for the re-post if it
did... 

-----Original Message-----
From: Patton, Eric
To: 'Moritz Lennert '
Cc: 'interbaun.com'
Sent: 9/22/2006 9:30 AM
Subject: RE: [GRASS-user] RE: Problem querying layers other than '1' in
gis.m

Moritz,

Thanks for your patience in explaining this. 

Moritz:
>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,

I just don't understand this last sentence. I can't escpae from the idea
that a category should be a unique identifier for each vector object.
The idea that a vector can have many cats seems really counterintuitive
to me - like saying that a vector object can have many different AND
unique IDs.

Moritz:
>...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).

I understand this, how many vectors can have the same cat, but not how
ONE vector can have MANY cats.

Moritz:
>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...

Me neither.

Moritz:
>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.

I'm with you here.

Moritz:
>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.

Ok, so far so good.

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

>choices:

>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.

Ok, this is what I thought layers were for all along. So I guess I have
to go with step #1 then.

Moritz:
>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 only use layers when a new dataset arrives for a pre-existing vector,
and I want to append the new analyses onto the existing vector without
creating a new one. In my example, we typically collect ocean bottom
sample data during field season, in which the types of data that get
collected and populated in table 1 would be:

Day of Year
Timestamp
Latitude
Longitude
Sample Type
Survey_ID
..etc

Several months down the road, we usually get sediment grainsize
analyses, geochemistry analyses, etc. that all come to me as separate
spreadsheets. It seems easier to me to integrate all these tables as
separate layers within ONE Grass vector than create one Grass vector for
every analysis (i.e., Sample_Bio, Sample_Geo, Sample_Chem, etc.). So
that was what I was trying to acheieve.

Moritz:
>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: 
>http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&
c
>ontent-type=text/vnd.viewcvs-markup).

Yes, I wish I new C so I could help out in that regard.

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

Me too. I would be good to keep the ball rolling on this discussion to
settle on some way of simplifying the terminology used. 

~ Eric.