[GRASS-user] Re: grass-user Digest, Vol 35, Issue 25
benjamin.ducke at oxfordarch.co.uk
Wed Mar 11 15:03:26 EDT 2009
thanks a lot for your clarifications.
These do indeed help. I must admit I never took the
time to really look into GRASS' DBMS management and
am impressed by it's flexibility now.
----- Original Message -----
From: "Michael Barton" <michael.barton at asu.edu>
To: grass-user at lists.osgeo.org
Sent: Monday, March 9, 2009 5:42:23 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: [GRASS-user] Re: grass-user Digest, Vol 35, Issue 25
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
>> 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
> 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...
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
4) Finally, the SQLite, PostgreSQL, and MySQL drivers are SQL
compliant (dbf only partly), permitting complex joins between multiple
I hope this is helpful.
grass-user mailing list
grass-user at lists.osgeo.org
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
More information about the grass-user