[GRASS5] Layers Clarification

[Trevor Wiens]

Thanks you all for your comments.

I want to make sure I understand so I will reiterate what I
understand you to have said.

1. What is a vector file "layer".

In a GRASS vector file there is a single collection of spatial objects.
Those spatial objects can be associated with one or more keys (called
layers in current terminology). The use of these multiple keys allow
for grouping of topologically related objects in a single layer that
are thematically different (forests and lakes or lines and nodes). This
also allows for linking different series of attribute data to a single
object.

In no way whatsoever are the spatial objects duplicated by the use of
multiple keys (layers).

2. Naming.

Lots of other software uses this ambiguous terminology so GRASS
developers followed this to remain compatible.

Now my comments.

What this multiple keys feature in GRASS represents is an effort to
provide partial DBMS support for attribute management. The initial
choice of a dbf backend necessitated this as it has no such
functionality. For some users, real databases like PostgreSQL are
overkill and too challenging, so making that the default environment
and letting people manage their multiple tables in that way was not
possible. 

Now, as someone who has many years of database programming experience,
I think if this were to be done over, the DBMS end should have been
managed in a single environment like SQLite or PostgreSQL. It is
cleaner and clearer and provides a single interface for functionality
without duplication. Now no matter what we do, users will always face
using the limited DBMS functionality of GRASS for normal use but have
the additional facilities provided by PostgreSQL and SQLite which won't
be directly supported in GRASS proper. 

However the situation is that the current limited DBMS functionality
(one to one and many to one joins) is done and working. To rewrite and
reduced database backends to only SQLite and other SQL solutions is
probably too limiting for most users and requires rewriting existing
code that works. 

As messy as the current situation remains, I can understand and
support not changing it for the time being, although I would suggest
that in the future, should we need to seriously modify vectors again,
we split off DBMS functionality to make things nice and clean.

What does remain however is what I see as very poor naming. Perhaps if
one is not a native English speaker or one has a regular working
knowledge of the other tools using this ambiguous terminology, then it
maybe it doesn't sound so bad or odd. However to me and I would guess
to most English speakers with some GIS background, but not GRASS,
this would be very confusing. I'm not suggesting that English speakers
should rule the world or anything but since we are discussing the
English naming, I think that normal word usage in English is pertinent
to the discussion.

In terms of naming I can see two ways to look at it. Under the current
GRASS environment, layers was approximately equivalent to files.
However, my understanding of Radim's comments is that under QGIS GRASS
vector keys show up as separate layers when composing a map. If we were
to do the same thing in GRASS, then perhaps using the same or a
modified terminology would be reasonable. However, since we currently
select layers for display as files and then set limits on what is
shown from that file, then using a terminology like keys or classes is
more appropriate and intuitively obvious. So as part of deciding if
"layers" needs to be renamed, we should consider how we want to present
the visual map concept of layers to users as part of that discussion.

I look forward to hearing more comments. 

Thanks again.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)