On Mar 9, 2009, at 9:00 AM, <grass-user-requ...@lists.osgeo.org> wrote:
Date: Mon, 09 Mar 2009 10:59:35 +0100
From: Moritz Lennert <mlenn...@club.worldonline.be>
Subject: Re: [GRASS-user] Modelling 1:n and m:n relationships in GIS
To: Benjamin Ducke <benjamin.du...@oxfordarch.co.uk>
Cc: grass <grass-user@lists.osgeo.org>, qgis-developer
<qgis-develo...@lists.osgeo.org>, Users and Developers mailing list
<gvsig_internacio...@runas.cap.gva.es>
Message-ID: <49b4e887.9050...@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
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
