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

[Michael Barton]

On Mar 9, 2009, at 9:00 AM, <grass-user-request at lists.osgeo.org> wrote:

> Date: Mon, 09 Mar 2009 10:59:35 +0100
> From: Moritz Lennert <mlennert at club.worldonline.be>
> Subject: Re: [GRASS-user] Modelling 1:n and m:n relationships in GIS
> To: Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>
> Cc: grass <grass-user at lists.osgeo.org>,	qgis-developer
> 	<qgis-developer at lists.osgeo.org>,	Users and Developers mailing list
> 	<gvsig_internacional at runas.cap.gva.es>
> Message-ID: <49B4E887.9050405 at club.worldonline.be>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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.
>
>> and the fact that GIS relates
>> data by spatial overlay, not foreign fields. I realize that some GIS
>> (like GRASS) are somewhat more flexible in that they can attach more
>> than one attribute table to a layer, but I am really looking for more
>> portable ways to deal with this.
>>
>> - How do you deal with 1:n and m:n relations in GIS?
>>
>> - What do you do if there are no spatial representations for the
>> records on the "n" side? Can that be handled at all?
>
> Yes, the table you attach to your map can contain as many tuples as  
> you
> want for which there are no features in the geometry. You can even
> attach a table to a map in which there is no tuple whatsoever  
> related to
> a feature.
>
>> Any ideas are very welcome, indeed!
>
> It would help to have some concrete examples...
>
> 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. Here are some of the main features.

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