[GRASS-dev] Re: terminology issues in grass7

[Michael Barton]

On Jun 14, 2009, at 10:53 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Sun, 14 Jun 2009 18:18:51 +0200
> From: Maciej Sieczka <msieczka at sieczka.org>
> Subject: Re: [GRASS-dev] terminology issues in grass7
> To: Markus GRASS <markus.metz.giswork at googlemail.com>
> Cc: Helena Mitasova <hmitaso at unity.ncsu.edu>,   Martin Landa
>        <landa.martin at gmail.com>,       grass-dev list <grass-dev at lists.osgeo.org 
> >
> Message-ID: <4A3522EB.5030604 at sieczka.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Markus GRASS pisze:
>> Hamish wrote:
>
>>> (if it must be renamed, what's was wrong with going back to
>>> "field"?) [I remember Radim explained on-list why that was changed
>>> when it became "layer", ... need to dig out that thread]
>
>> Here are two interesting threads [1,2], the same discussion about
>> field/layer between Trevor Wiens, Radim Blazek, Michael Barton, and
>> Moritz Lennert in March 2006:
>>
>> [1] http://lists.osgeo.org/pipermail/grass-dev/2006-March/021646.html
>> and responses [2]
>> http://lists.osgeo.org/pipermail/grass-dev/2006-March/021659.html and
>> responses
>>
>> Maybe layer is not that bad after all... GRASS can import several OGR
>> layers into one vector, each OGR layer will become a separate GRASS
>> vector layer. The main difference to e.g. several shapefiles imported
>> as different layers into one GRASS vector is that GRASS builds and
>> maintains topology for all geometry objects in all shapefiles
>> combined.
>
>> OGR layers and GRASS vector layers are not a 100% match, but IMHO
>> pretty close.
>
> IMHO they are not close enough to call them the same name. GRASS
> vector layers most of the time have common geometry or "subject", OGR
> layers not necessarily. E.g. shapefiles in a directory don't need to
> have anything in common. They are just stored in the same place. But
> GRASS vector map layers are usually closely related to each other, in
> some way (I guess that's what they are for - to represent extra data
> which are so tightly related to the other data within the existing
> vector map, that it's more convenient to store them together, than in
> separate vector maps).
>
> Maciek
>

Terminology is important for expressing to users what a program and  
its functions are supposed to do. So it is very good that we are  
having this discussion now for GRASS 7.

The weekend discussion about vector layers (I was without computer  
access) shows the importance of terminology. Maciek is more correct  
about vector layers than Markus M.; it is a good example of why we  
should consider changing the name of the feature called vector layers.  
In fact, GRASS vector layers are not at all like OGR layers, and  
herein lies a lexical source of some of the confusion. So I want to  
try to add some clarification to the GRASS feature called vector layers.

OGR layers are akin to CAD layers (they ARE CAD layers in come  
cases),  where each layer stores a different set of vector objects,  
which in turn represent different sets of real world features. The  
objects in each layer can be superimposed to create a final drawing or  
map. All the layers are stored together in the same file for CAD. OGR  
extends this usage to include different vector files (e.g.,  
shapefiles) within a single directory. With OGR layers, for example,  
you can have a vector layer of buildings, a layer of roads, and a  
layer of electrical lines. Each layer contains a set of vector objects  
which can be linked to one or more DBMS attribute tables. These can  
all be superimposed to produce a map of a town.

GRASS vector layers are very different...and this is one of the  
problems with calling them layers. GRASS vector "layers" are simply  
cat values assigned to a single set of vector objects. A vector map of  
roads with layers 1 and 2 displays the same vector objects (i.e., the  
roads) regardless of whether layer 1 or layer 2 is chosen. The only  
difference between layer 1 and 2 is that the cat values assigned to  
each of the vector objects can differ between "layer" 1 and 2. That  
is, for road objects (polylines) with ID's 1, 2, & 3 you could have  
the following cat values assigned for layers 1 and 2 (L1 and L2):

ID     cat (L1)     cat (L2)
1       2                2
2       3                2
3       4                1

That's all it is. Same vectors, different cat numbers.

The history of this is that prior to GRASS 6, vectors had the same  
kind of attached information as rasters do: an integer cat value and a  
text label. That was it. However, by GRASS 5 (earlier?), it was  
possible to use the vector cat value as a **key field** to link a  
vector with a PostgreSQL database table. When Radim Blazek rewrote the  
vector architecture for GRASS 5.7 (which became 6.0), he simply...

1) extended the ability to use the cat value to be a key field linking  
to a PostgreSQL table to other DBMS (including MySQL, ODBC, DBF, and  
more recently SQLite), with a DBF format as a default for GRASS; and

2) made it possible for a vector to have multiple cat fields (integer  
only still) instead of just one.

The latter change (#2) made it possible to link a single vector file  
simultaneously to more than one attribute table. Why they were named  
layer 1, layer, 2, etc instead of cat 1, cat 2, etc I don't know. I'm  
not sure if there is a text label field that inherently goes along  
with layer 2, 3, etc like there still is with layer 1. In any case,  
this naming (layers vs. something else) has confused many people as to  
the actual operation of this feature. It was a couple years before I  
figured it out.

So in normal GRASS terminology, what are currently called vector  
"layers" are in fact simply multiple "cat" fields for a vector.

You could potentially create 10 such cat fields (i.e., 10 layers) and  
assign different integer codes to indicate different attributes  
associated with each vector object--e.g., the width coded in layer 1,  
pavement type coded in layer 2, speed limit coded in layer 3, year of  
construction coded in layer 4, etc for roads. In this sense, they  
*could* be used to display a single set of vector objects with  
different colors palettes to convey different kinds of information  
about tghat single set of vector objects--color the roads by width vs  
color the same roads by pavement type.

However, because of change #1 above, each cat field (AKA layer) can  
also serve as a key to link vector objects to an attribute table in a  
variety of DBMS--and this is how most people seem to use vector  
layers. When used in either way, vector layers are database/attribute  
features for a single set of vector objects

To me and other native english speakers, layers refers to things that  
are stacked up or superimposed--stratigraphic layers, cake layers,  
geospatial data (or map) layers for visualization, CAD (and OGR)  
layers. GRASS vector "layers" are not physically or conceptually  
stacked up or superimposed. They are different pieces of information  
(i.e., integer numbers) linked to a single layer of vector objects.  
The unfortunate choice in terminology some years back has meant that  
many users are unaware of this important attribute management feature  
of GRASS. So this is a good time to change it as we prepare for GRASS  
7. In the terminology of GRASS structure, vector layers are cat  
fields; in terms of how they are most commonly used, they serve as  
keys to link vector objects with attribute tables.

We can call this feature whatever we want of course, but I suggest  
that we call it something to make its function more transparent to  
users than it is now, so that it can be used more effectively.

Michael