[GRASS5] Re: Layers Clarification

[Michael Barton]

Trevor,

You have stated the situation very clearly. I agree with your comments.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Trevor Wiens <twiens at interbaun.com>
> Date: Sat, 4 Mar 2006 14:53:55 -0700
> To: GRASS5 <grass5 at grass.itc.it>
> Cc: Radim Blazek <radim.blazek at gmail.com>, Helena Mitasova
> <hmitaso at unity.ncsu.edu>, Martin Landa <landa.martin at gmail.com>, Michael
> Barton <michael.barton at asu.edu>
> Subject: Layers Clarification
> 
> 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)