----- Original Message Follows -----
From: "Radim Blazek" <radim.blazek@gmail.com>
To: "Moritz Lennert" <mlennert@club.worldonline.be>
Cc: "Trevor Wiens" <twiens@interbaun.com>, GRASS5
<grass5@grass.itc.it>, "Helena Mitasova"
<hmitaso@unity.ncsu.edu>, "Martin Landa"
<landa.martin@gmail.com>, "Michael Barton"
<michael.barton@asu.edu>
Subject: Re: [GRASS5] Layers Clarification
Date: Mon, 6 Mar 2006 11:24:24 +0100
You cannot link one layer to 2 tables but you can link
one geometry object to 2 tables. I.e. the geometry must
have 2 categories in different layers.
That means you can link objects in one map to more tables
but objects in one layer are always linked to one table
only.
Radim,
I understand your point about the fact that layers is an
accepted term. I also understand you suggesting that things
can't be renamed immediately. I don't mean to be a jerk
here, but by your own word usage proves my point that the
term is ambiguous. You said, "objects in one layer", but the
objects are not IN any layer, because the layer is not a
topographic file but a classification of objects in a
topographic file. Your usage is normal and natural, but the
poor choice of name dictates inaccurate usage.
In truth what we are talking about here is thematic
representations of topology data using database keys. The
orginal name of field was actually very accurate and had it
been retained, simply modifying it to key field would have
removed most of the confusion, except that people would then
ask the obvious question of why not leave attribute
management in one place (which is essentially my point). In
which case if we were just dealing with thematic groupings
of data in the attribute table, then the term thematic layer
could have been used and viola, clarity and less code.
I would like to make a few other comments in response to
your other reply.
You continually reference how things are represented in
QGIS. Since this isn't the QGIS list, I fail to see the
relevance of this except as an indication of how we might
want to think of presenting "layers" to users in GRASS in
the future.
In terms of breaking documentation, I would suggest that the
documentation is already broken, because there is a serious
lack of clarity on what this feature is supposed to do and
how it works.
Unfortunately, however since OGC and other naming seem to
dictate what we do and you are clearly resistant to change,
the obvious solution becomes one of proper documentation.
I'm not sure where something like this should go, but I
wonder about short statement in the GRASS vector module
index page that would link to a more complete explanation.
An example statement might read like:
"In GRASS 6, vector files contain both topology data and
thematic representations of that data referred to as layers.
Layers do not actually contain any geographic objects but
provide links (database keys) between geographic objects in
the vector file and one or more attribute tables. In this
way topologically related but thematically contrasting data
can be stored in a single file. Essentially this feature
provides some attribute management for systems using DBF
files instead of an SQL database and is functionally
identical to a thematic layer."
In the long term, rather than adding to this feature I think
it should be removed and attribute management left with the
database where it belongs. However since I don't have the
time to commit to that level of work, my opinion obviously
shouldn't carry much weight.
To summarize, I'm happy to draft an explanation of this
feature and contribute it to the documentation. I look
forward to guidance as to the appropriate placement.
T
--
Trevor Wiens