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