[GRASS-user] Re: grass-user Digest, Vol 35, Issue 25

[Markus Metz]

Michael Barton wrote:
>
> On Mar 9, 2009, at 9:00 AM, <grass-user-request at lists.osgeo.org> wrote:
>
>>
>> On 09/03/09 00:00, Benjamin Ducke wrote:
>>> Dear all,
>>>
>>> I keep getting into situations where mapping 1:n and m:n relationships
>>> in relational DBMS to GIS vector models becomes a problem.
>>> The toughest restrictions of course are the 1:1 relation between map
>>> features and attribute table records
>>
>> Where do you see a 1:1 restriction ? In GRASS you can have several
>> features with the same category value, so related to one tuple in the
>> table and you can have several category values for one feature, so
>> related to several tuples in the table.
>>
[...]
>>
>> Moritz
>
> Following up with Moritz, actually GRASS is very flexible in this 
> regard. However, this flexibility is not very well known or understood 
> by most users.
This may be a bit hidden in vectorintro.html under Attribute management 
-> Categories. Although I have the suspicion that lengthy descriptions 
are not always read by a user, this (exceptional?) flexibility of the 
GRASS vector model could be emphasized a bit more under a separate 
heading, something like "Vector object IDs and relational DBMS", 
explaining that one vector object can have several IDs (categories) and 
several vector objects can share the same ID (category). The attribute 
table(s) connected to the vector can have entries for each category, but 
they must not have an entry for each category, similarly, the attribute 
table can hold information about categories not present in the vector. 
This is partially repeating what Michael wrote below. Maybe this is all 
redundant because it is already explained somewhere else, but I think 
vectorintro.html is a good place to hold all this information. Another 
suggestion would be that module manuals link to the vectorintro when 
appropriate. I know, the perfect user studies all intros first before 
using any module, and then first reads the manual for that module before 
using it, but IMHO this is unrealistic. At least I am not such a perfect 
user.

Markus M
>
> 1) Each vector object must have a category number (cat); that cat is a 
> key field that links the object to a line (with corresponding key 
> field, which may or may not be called "cat") in an attribute table. 
> BUT cat does NOT have to be unique for each object. That is, more than 
> one objects may have the same cat, such that you have a many:one 
> relationship between vector objects and database entries.
>
> 2) Each vector object can have more than one "layer". Each layer 
> represents a distinct connection to an attribute table. Each layer has 
> its own cat series. So, for example, in layer 1, objects a,b,c,d, and 
> e can all have cat=1 and link to a single line in the attribute table 
> connected to the vector via layer one. In layer 2, the same objects 
> can have cat=1 for a,b,c and cat=2 for d & e. Now, these objects are 
> linked to 2 lines in a DIFFERENT table (or even the SAME table via a 
> different connection and key field). That is, different layers can be 
> joins between vector objects and distinct tables, or different kinds 
> of joins between objects and the same table.
>
> 3) AFAICT, you are not prohibited from a situation where a single cat 
> in the vector file (whether for one or many objects) can match as a 
> key field with multiple lines in an attribute table, all of which have 
> the same key field. However, I don't know how the data parses in that 
> case.
>
> 4) Finally, the SQLite, PostgreSQL, and MySQL drivers are SQL 
> compliant (dbf only partly), permitting complex joins between multiple 
> attribute tables.
>
> I hope this is helpful.
>
> Michael
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>