[GRASS5] Re: Layers Clarification

[Radim Blazek]

I can only repeate that the current use of 'layer' fits well to other
packages and OGC standards. The name was already changed once
(note that the original name 'field' was suggested by native english speaker).
In any case we cannot change module options in stable 6.x line
because that would break all users scripts, documentation etc.

If I get time, I would like to add support for dynamic reading from OGR
data sources (without v.external). The OGR data source will be used
as map name and OGR layer as GRASS layer. For example:
r.to.vect input='PG:dbname=mydb' layer=mytable
It would be very confusing to change the name for 'layer' in GRASS,
it is equivalent to OGR layer.

The GRASS layers looks exactly the same in QGIS as various
data types of Coverage in ArcView so it should not confuse users.

Radim


On 3/4/06, Trevor Wiens <twiens at interbaun.com> wrote:
> 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)
>