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

[Michael Barton]

Good ideas!

Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Mar 9, 2009, at 11:39 AM, Markus Metz wrote:

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