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

[Moritz Lennert]

Patton, Eric wrote:
> 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.

As I mentioned, I don't really see the use of this, but you could 
imagine something like this for a map of trees:

1: coniferous
2: broadleaved

10: pine
11: fir
12: oak
etc

Then, for an oak tree you could have, for example:

cat = 2 & 12

and for a pine

cat = 1 & 10

This would allow you to things like=

d.vect map cat=2 => show all broadleaved trees

and

d.vect map cat=12 => show all oaks.

But in my eyes, this is better done in the database, where you could 
just have a column type and do:

d.vect map where=type=1

The advantage of using the layers is probably speed as you don't have 
the overhead of communicating with a DB server. And then for consistency 
sake, it would probably be better to use layers:

oak tree:
layer 1: 2
layer 2: 12

and then

d.vect map cat=2 layer=1
d.vect map cat=12 layer=2

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

If you have a unique (integer) identifier for each sample and each of 
the analyses concern the same samples, then in my eyes, the easiest way 
to do this would be to have a map of the sample points with a very 
simple basic table linked to it (could be just the id's, or you could 
add x and y values if useful). Import your spreadsheets into the 
database as separate tables, and then whenever you need access to any or 
all of them combine them in a view using the id as key. Then link this 
view to the map. Or alter your basic map table to add the needed 
columns, then update the table to add the values to these columns.


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

Well, at this stage it seems that assessing the advantages and 
disadvantages of the current system and coming up with a solid proposal 
for revisal seems to be the first step. No need to know C for that.

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

I'm not sure that the terminology is really the problem. I think it is 
the attempt to mix GIS logic with RDBMS logic, but not doing it completely.

Moritz