[GRASS-dev] Re: terminology issues in grass7

[Markus GRASS]

Michael Barton wrote:
>
>
> 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.
Just for the record, this can also be done with different "layers" in
one GRASS vector, with the advantage that spatial analysis with features
from different layers could be easier. 
>
> 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. 
Only if all roads have a category value assigned in each layer,
otherwise only roads with a category value in the given layer are
displayed, e.g. time series or town development, layer 1 shows roads
present in 2000, layer 2 roads present in 2001 and so on. GRASS network
analysis makes use of it, i.e. having only a subset of features present
in a layer, see e.g. manual for v.net.salesman, lines in layer 1, points
in layer 2.
> 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.
Can also be

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

As above, a GRASS vector layer is not meant to have all features present
in the vector. That can be but is in no way required.

>
> 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. 
Currently, cat 1 would refer to category 1 in a given "layer". Cat and
layer in current GRASS terminology are two different things, renaming
layer to cat would cause confusion unless cat is renamed to something
else. The cat value is more of an index that can link to a key field
(usually cat). The cat field in an attribute table and the cat index are
again two different things.

> 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. 
AFAIKT there is no text label field for layer 1, but it would be nice to
have such a text label going with each "layer" number. See also Radim's
TODO.
>
> So in normal GRASS terminology, what are currently called vector
> "layers" are in fact simply multiple "cat" fields for a vector.
I don't think it's that simple because these multiple layers are very
powerful and versatile, and that's probably where the confusion comes
from, not from the name. GRASS layers can be very similar to e.g.
different shapefiles, but then I guess that the term shapefile layers
has probably not been created by the inventors of the shapefile format,
shapefile as a layer is probably something OGR-specific. Maybe OGR did
some over-generalization there with the word "layer".
>
> 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.
Hmm, not sure if this is rather an example about how different geometry
features can share the same category and thus link to the same entry in
an attribute table instead of having a separate entry for each single
geometry feature. If this would not be possible you could just as well
have one layer with one big attribute table, then display the different
fields in the attribute table as different display layers.
> 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.
Cake layers are spatially related and their topological interactions are
very interesting :-) So it makes sense to not to deliver cake layers
separately. Same for stratigraphic layers.

The category index can be translated to a table with several cat fields
(plus lineid fields and line type fields), although it does not have a
tabular form, it rather conforms to an index tree. The cat field is
usually the field in an attribute table used to link to a category index
which in turn links to vector objects. The idea of linking different
pieces of information to the same set of vector objects comes more from
the GRASS vector ability to assign the same category value to different
objects. This concept can be combined with the layer concept, but layers
can also be used to handle a subset of objects present in the vector
(again, GRASS network analysis provides examples).
>
> 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.
Compared to other OGR layers, GRASS layers have more functionality, that
makes it difficult to come up with a name that describes it all. It's
not getting easier considering that there are many different kinds of
OGR layers, e.g. DFX, GPX, KML, POSTGIS, DODS/OPeNDAP, OGDI. "Layer" is
a rather broad concept in OGR, and since OGR is the interface of GRASS
it would make sense to try to stick to OGR terminology to avoid
confusion amongst users. There are different kinds of layers and
different kinds of maps, but choosing a completely new name could make
it more difficult to grasp the concept. It may be easier to stick to
layers, so a user could reason that different shapefiles or different
layers in a GPX file can be translated to GRASS layers, but there are
differences between GRASS layers, shapefiles and GPX layers. Starting
with similarities, it may be easier to cope with differences, the
strengths and weaknesses of each type of "layer", instead of starting
with differences (no, that's not a layer) and then trying to figure out
the best representation in a different format.

My impression is that GRASS is different enough from other GIS packages,
no need to pronounce that difference in new terminology. IMHO, GRASS
would only profit from keeping OSGEO and GDAL/OGR terminology.
Translated to the shapefile example: if a GRASS vector with all layers
can be converted to a single shapefile, the whole GRASS vector would be
an OGR layer; if it makes more sense to convert each GRASS vector layer
to a separate shapefile, only the GRASS vector layer would be an OGR layer.

No matter what the name will be in the end, I would like to have some
more documentation and examples about what can be done with GRASS
layers/cat fields/subsets...

Markus M