[GRASS-dev] Re: terminology issues in grass7

GRASS GRASS developer
1

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

Date: Sun, 14 Jun 2009 18:18:51 +0200
From: Maciej Sieczka <msieczka@sieczka.org>
Subject: Re: [GRASS-dev] terminology issues in grass7
To: Markus GRASS <markus.metz.giswork@googlemail.com>
Cc: Helena Mitasova <hmitaso@unity.ncsu.edu>, Martin Landa
       <landa.martin@gmail.com>, grass-dev list <grass-dev@lists.osgeo.org>
Message-ID: <4A3522EB.5030604@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] [GRASS5] Layers in vectors
and responses [2]
[GRASS5] Layers Clarification 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

2

On Mon, 15 Jun 2009, Michael Barton wrote:

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.

Please correct me if I'm wrong, but is it not possible for certain features to have cat values assigned only in certain layers, and for certain vector modules to only operate on features that have cat values assigned to them?

For example, if you had a vector map containing both roads and buildings, and in layer 1 only the roads had categories assigned to them, and in layer 2 only the buildings had categories assigned to them: then if with d.vect you selected to display only layer 2 and only features with categories, you would only see the buildings?

If I've understood correctly, then it is not quite correct to state that the same vector features will always be displayed no matter which layer is selected - many modules only operate on features with cat values assigned (or have an option to do so) and if some features only have cat values
assigned in a certain layer then only those features will be "visible" to the modules operating on them when that layer is selected. IMHO the "layer" analogy fits this concept quite well.

Even less sure on this one, but I'd also suggest that it's a deficiency of the OpenGIS simple features format that each layer in a Shapefile has to have its own separate copy of the vector geometry - surely it would be more desirable to have shared geometry GRASS-style if it was technically possible?

Paul

3

On Jun 15, 2009, at 12:54 PM, Paul Kelly wrote:

On Mon, 15 Jun 2009, Michael Barton wrote:

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.

Please correct me if I'm wrong, but is it not possible for certain
features to have cat values assigned only in certain layers, and for
certain vector modules to only operate on features that have cat values
assigned to them?

For example, if you had a vector map containing both roads and buildings,
and in layer 1 only the roads had categories assigned to them, and in
layer 2 only the buildings had categories assigned to them: then if with
d.vect you selected to display only layer 2 and only features with
categories, you would only see the buildings?

I just tested it on Spearfish roads. You can indeed leave some cats blank in a "layer", but all the vectors still display. Only the ones with cat numbers can be colored or have their width varied. The remainder are the default thin black. (Note that this must be done from the command line as something is broken in the wxPython interface so that you can only select layers -1 [all] and 1).

This is functionally similar to the database query for display--either by cat number or with an SQL where statement on a linked attribute table. Without using layers, you can in fact display the same vector map twice, once with part of its features queried and visible and again with another set of its featured and visible. This is a useful way to build a visualization. But it's not the same as having a group of vector objects superimposed on a different set of vector objects. It's only the same vector objects displayed twice in thematically different ways.

GRASS vector layers are not a way to store multiple sets of vector objects in the same file. They are simply cat fields attached to a single file of vector objects. Each of the cat fields can be queried, just like any attribute field, but this doesn't make it 2 or more independent sets of overlaid vector objects as is found in CAD files (or multiple rasters in GeoTiff files). They are versatile and useful for a variety of database activities--querying and keys to link attribute tables--but I still maintain that they are misnamed as layers in the most commonly used senses of the word within GIS, CAD, and digital imaging.

Michael

If I've understood correctly, then it is not quite correct to state that
the same vector features will always be displayed no matter which layer is
selected - many modules only operate on features with cat values assigned
(or have an option to do so) and if some features only have cat values
assigned in a certain layer then only those features will be "visible" to
the modules operating on them when that layer is selected. IMHO the
"layer" analogy fits this concept quite well.

Even less sure on this one, but I'd also suggest that it's a deficiency of
the OpenGIS simple features format that each layer in a Shapefile has to
have its own separate copy of the vector geometry - surely it would be
more desirable to have shared geometry GRASS-style if it was technically
possible?

Paul

4

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 :slight_smile: 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

5

On Tue, 16 Jun 2009, Markus GRASS wrote:

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.

Thanks for the clarification - that's kind of what I had in mind too. Regarding what Michael was saying, with d.vect I think you need to use the option cats=1-999999 so only features with cats assigned are displayed.

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).

Good summary. And as you said, there may indeed be other applications we haven't thought of. It seems to me that the layer concept is so powerful that it's incredibly difficult to be able to "see the big picture" showing all its possibilities. But "layer" does seem to be a very good, sufficently general term to describe it.

Paul

6

On 15/06/09 22:55, Michael Barton wrote:

On Jun 15, 2009, at 12:54 PM, Paul Kelly wrote:

On Mon, 15 Jun 2009, Michael Barton wrote:

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.

Please correct me if I'm wrong, but is it not possible for certain
features to have cat values assigned only in certain layers, and for
certain vector modules to only operate on features that have cat values
assigned to them?

For example, if you had a vector map containing both roads and buildings,
and in layer 1 only the roads had categories assigned to them, and in
layer 2 only the buildings had categories assigned to them: then if with
d.vect you selected to display only layer 2 and only features with
categories, you would only see the buildings?

I just tested it on Spearfish roads. You can indeed leave some cats blank in a "layer", but all the vectors still display. Only the ones with cat numbers can be colored or have their width varied. The remainder are the default thin black.

All features without any cat value display in all layers. As Paul mentioned, you have to explicitely use the cat= parameter to only display features with cat values in that layer. It is debatable whether there should be a flag to indicate "only show features with cat values in the chosen layer", or whether this should actually be the default with a flag indicating "also show features without cat values". I think the first would be more appropriate and would be a more convenient way than using cat=1-9999.

This is functionally similar to the database query for display--either by cat number or with an SQL where statement on a linked attribute table. Without using layers, you can in fact display the same vector map twice, once with part of its features queried and visible and again with another set of its featured and visible.

This only really works when working with the same types of features, i.e. you work with a layer of polygons and you use the where= clause to only display a subset of them. However, when you mix different types of features, or if the same feature can have different meanings, then layers can come in handy. The classic example is the layer of polygons where one set of polygons are fields and the other are forests (this you can deal with using a "type" field in the attribute table, but some of the boundaries between polygons are roads. You could obviously give the relevant boundary segment a cat value in the same layer as the polygons and then add a "road" type in your attribute table, but that does not seem as clean as saying that in layer 1, the line is a boundary of polygons and in layer 2 it is a road. So you could then:

d.vect myvect where=type='field' col=yellow layer=1
d.vect myvect where=type='forest' col=green layer=1
d.vect myvect layer=2 col=red cat=1-9999

As Markus mentioned, another are where this is useful is the whole v.net.* suite where creating a network with lines in one layer and nodes in another makes handling and displaying these different features easier.

This is a useful way to build a visualization. But it's not the same as having a group of vector objects superimposed on a different set of vector objects. It's only the same vector objects displayed twice in thematically different ways.

Your example, yes, but that is not the idea behind GRASS layers. GRASS layers are meant to allow to mix different groups of vector objects superimposed, while sharing (at least in part) the same features and allowing to analyse topological relations between them.

So, I reinsist on what Paul and Markus have said: GRASS layers are exactly the same as the OGR layers or as layers in DXF files, etc. The fact that you can also link each layer to a different attribute table is only an additional fact, but not the main issue. This why I have always argued against a database-oriented interpretation and naming of layers.

GRASS vector layers are not a way to store multiple sets of vector objects in the same file. They are simply cat fields attached to a single file of vector objects. Each of the cat fields can be queried, just like any attribute field, but this doesn't make it 2 or more independent sets of overlaid vector objects as is found in CAD files (or multiple rasters in GeoTiff files). They are versatile and useful for a variety of database activities--querying and keys to link attribute tables--but I still maintain that they are misnamed as layers in the most commonly used senses of the word within GIS, CAD, and digital imaging.

As you can imagine, I disagree :slight_smile:

Moritz

7

Moritz Lennert wrote:

All features without any cat value display in all layers. As Paul
mentioned, you have to explicitely use the cat= parameter to only
display features with cat values in that layer. It is debatable
whether there should be a flag to indicate "only show features with
cat values in the chosen layer", or whether this should actually be
the default with a flag indicating "also show features without cat
values". I think the first would be more appropriate and would be a
more convenient way than using cat=1-9999.

It seems that this behaviour depends on the feature types defined with
type option. In a quick test with the spearfish dataset, boundaries
having no cats are always displayed by default, but if I select layer=2
type=area instead of type=point,line,boundary,centroid,area,face, I get
only the areas with a cat value in layer 2 and no boundaries, no lines,
nothing else is displayed, and it is not necessary to use cat=1-9999.

Markus M

8

On 16/06/09 14:29, Markus GRASS wrote:

Moritz Lennert wrote:

All features without any cat value display in all layers. As Paul
mentioned, you have to explicitely use the cat= parameter to only
display features with cat values in that layer. It is debatable
whether there should be a flag to indicate "only show features with
cat values in the chosen layer", or whether this should actually be
the default with a flag indicating "also show features without cat
values". I think the first would be more appropriate and would be a
more convenient way than using cat=1-9999.

It seems that this behaviour depends on the feature types defined with
type option. In a quick test with the spearfish dataset, boundaries
having no cats are always displayed by default, but if I select layer=2
type=area instead of type=point,line,boundary,centroid,area,face, I get
only the areas with a cat value in layer 2 and no boundaries, no lines,
nothing else is displayed, and it is not necessary to use cat=1-9999.

But how you deal with the situation I described, i.e. one boundary segment of the polygons has a cat value in layer 2 ? I.e.

GRASS 6.5.svn (spearfish60):~ > v.category testlayers option=report
Layer/table: 1/testlayers
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 2 1 2
area 0 0 0
all 2 1 2
Layer: 2
type count min max
point 0 0 0
line 0 0 0
boundary 1 1 1
centroid 0 0 0
area 0 0 0
all 1 1 1

d.vect testlayers layer=1
d.vect testlayers layer=2 type=boundary cat=1-9999 col=red width=3

gives:
http://geog-pc40.ulb.ac.be/grass/misc/testlayers1.png

I need to declare either the boundary type (or no type at all) to see anything in layer 2, but then it shows all boundaries:

http://geog-pc40.ulb.ac.be/grass/misc/testlayers2.png

Moritz

9

Moritz Lennert wrote:

It seems that this behaviour depends on the feature types defined with
type option. In a quick test with the spearfish dataset, boundaries
having no cats are always displayed by default, but if I select layer=2
type=area instead of type=point,line,boundary,centroid,area,face, I get
only the areas with a cat value in layer 2 and no boundaries, no lines,
nothing else is displayed, and it is not necessary to use cat=1-9999.

But how you deal with the situation I described, i.e. one boundary
segment of the polygons has a cat value in layer 2 ?

Probably in the way you describe :slight_smile: Apparently boundaries are by
default displayed for every layer if boundary is included in the type
option and the cat option is not used. AFAIKT, boundaries only get a cat
value if they are not only a boundary but also have a different meaning
e.g. a road. So it seems your example is a special case where you only
get the expected display with layer=2 type=boundary cat=1-9999. For
areas, the cat option is apparently not needed. I haven't done extensive
testing, but is seems that boundaries are treated a bit differently by
d.vect than other types.

Markus M

I.e.

GRASS 6.5.svn (spearfish60):~ > v.category testlayers option=report
Layer/table: 1/testlayers
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 2 1 2
area 0 0 0
all 2 1 2
Layer: 2
type count min max
point 0 0 0
line 0 0 0
boundary 1 1 1
centroid 0 0 0
area 0 0 0
all 1 1 1

d.vect testlayers layer=1
d.vect testlayers layer=2 type=boundary cat=1-9999 col=red width=3

gives:
http://geog-pc40.ulb.ac.be/grass/misc/testlayers1.png

I need to declare either the boundary type (or no type at all) to see
anything in layer 2, but then it shows all boundaries:

http://geog-pc40.ulb.ac.be/grass/misc/testlayers2.png

Moritz

10

I understand your examples here. And GRASS layers can indeed appear to function as CAD layers--as a way to control what gets displayed and what doesn't (although it seems from the various test reported that there is inconsistency in what happens if a cat for an object is null/empty for a layer).

However, in a CAD drawing, a particular vector object exists IN only 1 layer. That is, the "layer" serves to identify a subset of objects; a particular object cannot simultaneously exist in more than one layer. In GRASS every vector object has ALL layers. Each "layer" is attached to all objects, regardless of whether the cat value for a particular object in a particular layer is null or has a value.

CAD

Layer 1 ____ ID 1
              |___ ID 2

Layer 2 ____ ID 3
              |___ ID 4

In CAD, displaying Layer 1 shows ID's 1 & 2; displaying Layer 2 shows ID's 3 & 4. You cannot show ID 1 in Layer 2 unless you move it to Layer 2, in which case it could no longer be displayed in Layer 1. You can make a copy, of course, but then you have another object (ID 5).

GRASS

ID 1 ____ Layer 1: cat = 1
         |___ Layer 2: cat = 1

ID 2 ____ Layer 1: cat = 1
         |___ Layer 2: cat = 1

ID 3 ____ Layer 1: cat =
         |___ Layer 2: cat = 2

ID 4 ____ Layer 1: cat =
         |___ Layer 2: cat = 2

In GRASS, displaying Layer 1 will show all objects for some vector topologies, and only ID 1 and 2 for other topologies. However, by putting values into cat for Layer 1, you can also display ID's 3 & 4 for Layer 1. You can achieve the same effect by querying cat = 1 for Layer 2. The difference is that sometimes empty cats are displayed and sometimes they are not. To me this is kind of an automatic (inadvertent even) query. Some of this is only semantics, but I think we all agree that semantics can be important.

Many users writing to the lists seem baffled by GRASS layers. They are complicated to explain whatever we name them. My opinion--completely unsupported by any systematic data and only by anecdotal experience--is that these would be more understandable to more users if we used a term that emphasized the database nature of this feature rather than a term that suggests that it is most similar to multiple geospatial data layers combined into one file--the vector equivalent of a geotiff.

FWIW, each layer of a cake is baked separately and they are all put together at the end, like different geospatial data layers (AKA maps in GRASS). But the goodies (nuts, candies, etc) in one layer cannot also be simultaneously in more than one layer. Each layer has to have its own set of goodies (all the tastier). :wink:

Cheers
Michael

On Jun 16, 2009, at 6:58 AM, Moritz Lennert wrote:

On 16/06/09 14:29, Markus GRASS wrote:

Moritz Lennert wrote:

All features without any cat value display in all layers. As Paul
mentioned, you have to explicitely use the cat= parameter to only
display features with cat values in that layer. It is debatable
whether there should be a flag to indicate "only show features with
cat values in the chosen layer", or whether this should actually be
the default with a flag indicating "also show features without cat
values". I think the first would be more appropriate and would be a
more convenient way than using cat=1-9999.

It seems that this behaviour depends on the feature types defined with
type option. In a quick test with the spearfish dataset, boundaries
having no cats are always displayed by default, but if I select layer=2
type=area instead of type=point,line,boundary,centroid,area,face, I get
only the areas with a cat value in layer 2 and no boundaries, no lines,
nothing else is displayed, and it is not necessary to use cat=1-9999.

But how you deal with the situation I described, i.e. one boundary
segment of the polygons has a cat value in layer 2 ? I.e.

GRASS 6.5.svn (spearfish60):~ > v.category testlayers option=report
Layer/table: 1/testlayers
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 2 1 2
area 0 0 0
all 2 1 2
Layer: 2
type count min max
point 0 0 0
line 0 0 0
boundary 1 1 1
centroid 0 0 0
area 0 0 0
all 1 1 1

d.vect testlayers layer=1
d.vect testlayers layer=2 type=boundary cat=1-9999 col=red width=3

gives:
http://geog-pc40.ulb.ac.be/grass/misc/testlayers1.png

I need to declare either the boundary type (or no type at all) to see
anything in layer 2, but then it shows all boundaries:

http://geog-pc40.ulb.ac.be/grass/misc/testlayers2.png

Moritz

11

On Tue, 16 Jun 2009, Michael Barton wrote:

In GRASS, displaying Layer 1 will show all objects for some vector topologies, and only ID 1 and 2 for other topologies. However, by putting values into cat for Layer 1, you can also display ID's 3 & 4 for Layer 1. You can achieve the same effect by querying cat = 1 for Layer 2. The difference is that sometimes empty cats are displayed and sometimes they are not. To me this is kind of an automatic (inadvertent even) query. Some of this is only semantics, but I think we all agree that semantics can be important.

IMHO these are all side-effects of the inconsistent way layers are handled amongst different GRASS modules. It's an implementation problem (perhaps caused by confusion among developers as options were added and modified over the years), rather than a fundamental problem with the layer concept.

If we manage to come to a full understanding of the capabilities and possibilities of the concept of vector layers in GRASS (which I feel this discussion is really helping us to work towards, for me anyway), then it would be an exciting project to do an audit of all vector modules and the way they handle layers, and tidy up all the inconsistencies so that the meaning of layers is much more obvious, simply from the module options and flags. Perhaps too radical though.

Paul

12

On Jun 16, 2009, at 12:39 PM, Paul Kelly wrote:

On Tue, 16 Jun 2009, Michael Barton wrote:

In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by putting
values into cat for Layer 1, you can also display ID's 3 & 4 for Layer 1. You
can achieve the same effect by querying cat = 1 for Layer 2. The difference
is that sometimes empty cats are displayed and sometimes they are not. To me
this is kind of an automatic (inadvertent even) query. Some of this is only
semantics, but I think we all agree that semantics can be important.

IMHO these are all side-effects of the inconsistent way layers are handled
amongst different GRASS modules. It's an implementation problem (perhaps
caused by confusion among developers as options were added and modified
over the years), rather than a fundamental problem with the layer concept.

The inconsistent implementation is an issue certainly. I don't think that there is a problem with underlying concept of the layer feature. Indeed, it is a very powerful data management feature of GRASS. I just think that another name for the feature would help users to understand and make use of it better--especially since we also use the term layers in the GUI layer manager to refer to superimposed displays of distinct geospatial data files, a very common usage in GIS.

If we manage to come to a full understanding of the capabilities and
possibilities of the concept of vector layers in GRASS (which I feel this
discussion is really helping us to work towards, for me anyway), then it
would be an exciting project to do an audit of all vector modules and the
way they handle layers, and tidy up all the inconsistencies so that the
meaning of layers is much more obvious, simply from the module options and
flags. Perhaps too radical though.

Paul

I agree 100%.

Michael

13

CAD is just one example, OGR supports many different formats and
apparently it was decided by GDAL/OGR developers to use the term
"layers" in OGR whenever possible. Picking an example that suits best
doesn't really help here, rather an in depth analysis of all
OGR-supported formats and the use of the term "layer" by OGR. This
debate is also about how easy should GRASS vectors fit into the OGR
model, and if GRAS developers want to make it easier or more difficult.

The debate is essentially about seeking similarity to existing
terminology or coming up with something GRASS specific that has no
equivalent. I see it as a danger to say that GRASS vectors are very
different to any other OGR-supported format. If I would explain the
GRASS vector model to a new user, I would rather start first with
similarities, then moving to the differences. Regarding layers, you can
convert from OGR layer to GRASS layer and back, but GRASS layers can do
much more than most OGR layers. Start explaining on common ground and
common words is what I would suggest. It gets bad enough later on: areas
instead polygons but areas are topological meta-objects, boundaries vs.
lines, islands may or may not be holes, the difference between nodes and
vertices etc.

BTW, 0 is a valid category value. Cat 0 allows for "exact mapping from
OGR FID to GRASS cat" on the level of layers;-):

http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#Vector
http://sourceforge.net/mailarchive/message.php?msg_name=340505ef0601170244n1b5fe25bhd0a3eba7342b78d4%40mail.gmail.com
https://trac.osgeo.org/grass/browser/grass/trunk/doc/vector/TODO see OGR
interface

Markus M

Michael Barton wrote:

I understand your examples here. And GRASS layers can indeed appear to
function as CAD layers--as a way to control what gets displayed and
what doesn't (although it seems from the various test reported that
there is inconsistency in what happens if a cat for an object is
null/empty for a layer).

However, in a CAD drawing, a particular vector object exists IN only 1
layer. That is, the "layer" serves to identify a subset of objects; a
particular object cannot simultaneously exist in more than one layer.
In GRASS every vector object has ALL layers. Each "layer" is attached
to all objects, regardless of whether the cat value for a particular
object in a particular layer is null or has a value.

CAD

Layer 1 ____ ID 1
             |___ ID 2

Layer 2 ____ ID 3
             |___ ID 4

In CAD, displaying Layer 1 shows ID's 1 & 2; displaying Layer 2 shows
ID's 3 & 4. You cannot show ID 1 in Layer 2 unless you move it to
Layer 2, in which case it could no longer be displayed in Layer 1. You
can make a copy, of course, but then you have another object (ID 5).

GRASS

ID 1 ____ Layer 1: cat = 1
        |___ Layer 2: cat = 1

ID 2 ____ Layer 1: cat = 1
        |___ Layer 2: cat = 1

ID 3 ____ Layer 1: cat =
        |___ Layer 2: cat = 2

ID 4 ____ Layer 1: cat =
        |___ Layer 2: cat = 2

In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by
putting values into cat for Layer 1, you can also display ID's 3 & 4
for Layer 1. You can achieve the same effect by querying cat = 1 for
Layer 2. The difference is that sometimes empty cats are displayed and
sometimes they are not. To me this is kind of an automatic
(inadvertent even) query. Some of this is only semantics, but I think
we all agree that semantics can be important.

Many users writing to the lists seem baffled by GRASS layers. They are
complicated to explain whatever we name them. My opinion--completely
unsupported by any systematic data and only by anecdotal
experience--is that these would be more understandable to more users
if we used a term that emphasized the database nature of this feature
rather than a term that suggests that it is most similar to multiple
geospatial data layers combined into one file--the vector equivalent
of a geotiff.

FWIW, each layer of a cake is baked separately and they are all put
together at the end, like different geospatial data layers (AKA maps
in GRASS). But the goodies (nuts, candies, etc) in one layer cannot
also be simultaneously in more than one layer. Each layer has to have
its own set of goodies (all the tastier). :wink:

Cheers
Michael

On Jun 16, 2009, at 6:58 AM, Moritz Lennert wrote:

On 16/06/09 14:29, Markus GRASS wrote:

Moritz Lennert wrote:

All features without any cat value display in all layers. As Paul
mentioned, you have to explicitely use the cat= parameter to only
display features with cat values in that layer. It is debatable
whether there should be a flag to indicate "only show features with
cat values in the chosen layer", or whether this should actually be
the default with a flag indicating "also show features without cat
values". I think the first would be more appropriate and would be a
more convenient way than using cat=1-9999.

It seems that this behaviour depends on the feature types defined with
type option. In a quick test with the spearfish dataset, boundaries
having no cats are always displayed by default, but if I select layer=2
type=area instead of type=point,line,boundary,centroid,area,face, I get
only the areas with a cat value in layer 2 and no boundaries, no lines,
nothing else is displayed, and it is not necessary to use cat=1-9999.

But how you deal with the situation I described, i.e. one boundary
segment of the polygons has a cat value in layer 2 ? I.e.

GRASS 6.5.svn (spearfish60):~ > v.category testlayers option=report
Layer/table: 1/testlayers
type count min max
point 0 0 0
line 0 0 0
boundary 0 0 0
centroid 2 1 2
area 0 0 0
all 2 1 2
Layer: 2
type count min max
point 0 0 0
line 0 0 0
boundary 1 1 1
centroid 0 0 0
area 0 0 0
all 1 1 1

d.vect testlayers layer=1
d.vect testlayers layer=2 type=boundary cat=1-9999 col=red width=3

gives:
http://geog-pc40.ulb.ac.be/grass/misc/testlayers1.png

I need to declare either the boundary type (or no type at all) to see
anything in layer 2, but then it shows all boundaries:

http://geog-pc40.ulb.ac.be/grass/misc/testlayers2.png

Moritz

14

Michael Barton wrote:

On Jun 16, 2009, at 12:39 PM, Paul Kelly wrote:

On Tue, 16 Jun 2009, Michael Barton wrote:

In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by
putting
values into cat for Layer 1, you can also display ID's 3 & 4 for
Layer 1. You
can achieve the same effect by querying cat = 1 for Layer 2. The
difference
is that sometimes empty cats are displayed and sometimes they are
not. To me
this is kind of an automatic (inadvertent even) query. Some of this
is only
semantics, but I think we all agree that semantics can be important.

IMHO these are all side-effects of the inconsistent way layers are
handled
amongst different GRASS modules. It's an implementation problem (perhaps
caused by confusion among developers as options were added and modified
over the years), rather than a fundamental problem with the layer
concept.

The inconsistent implementation is an issue certainly. I don't think
that there is a problem with underlying concept of the layer feature.
Indeed, it is a very powerful data management feature of GRASS. I just
think that another name for the feature would help users to understand
and make use of it better--especially since we also use the term
layers in the GUI layer manager to refer to superimposed displays of
distinct geospatial data files, a very common usage in GIS.

You may notice that you have to specify a vector layer for d.vect in the
GUI layer manager, i.e. the GUI layer manager displays a vector layer
unless layer=-1. I bet you yourself use most of the time d.vect layer=1
and not layer=-1.

If we manage to come to a full understanding of the capabilities and
possibilities of the concept of vector layers in GRASS (which I feel
this
discussion is really helping us to work towards, for me anyway), then it
would be an exciting project to do an audit of all vector modules and
the
way they handle layers, and tidy up all the inconsistencies so that the
meaning of layers is much more obvious, simply from the module
options and
flags. Perhaps too radical though.

Tidying up inconsistencies is not radical but regular maintenance work IMHO.

Markus

15

On 16/06/09 18:50, Michael Barton wrote:

Many users writing to the lists seem baffled by GRASS layers. They are complicated to explain whatever we name them. My opinion--completely unsupported by any systematic data and only by anecdotal experience--is that these would be more understandable to more users if we used a term that emphasized the database nature of this feature rather than a term that suggests that it is most similar to multiple geospatial data layers combined into one file--the vector equivalent of a geotiff.

But this is _not_ - primarily - a database feature. It is a way of organising objects within the same file - thus allowing topological relationships - but with different meanings. The fact that you can then link these different meanings to different attribute table is just an additional - very useful - feature. But you can use the layer feature without connecting any of the layers to tables. In the examples Radim gives (for example in [1]), he always talks about attribute tables, but I never see them as central to the concept, but it is the possibility of attributing different "natures" to the same objects.

I think that when we think about layers as "purely" database-related, then we miss the main point, and it is actually debatable whether this database-related usage is best dealt with through a layers paradigm (see the thread starting with [2] and then moving to the -dev list with [3]

Yes, layers are complicated. I normally tell my students just to ignore them as when they come to a stage where they might actually need them, they should already be advanced enough in GRASS to be able to dig into the documentation/lists to learn more about them.

I also believe that many users will never need layers. They are useful for very specific needs, which are not database related. See [4] for an example.

Moritz

[1]http://lists.osgeo.org/pipermail/grass-dev/2006-March/021650.html
[2]http://lists.osgeo.org/pipermail/grass-user/2006-September/036284.html
[3]http://grass.itc.it/pipermail/grass5/2006-September/025907.html
[4]http://lists.osgeo.org/pipermail/grass-dev/2003-November/013091.html

16

On Jun 16, 2009, at 11:06 PM, Markus GRASS wrote:

Michael Barton wrote:

On Jun 16, 2009, at 12:39 PM, Paul Kelly wrote:

On Tue, 16 Jun 2009, Michael Barton wrote:

In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by
putting
values into cat for Layer 1, you can also display ID's 3 & 4 for
Layer 1. You
can achieve the same effect by querying cat = 1 for Layer 2. The
difference
is that sometimes empty cats are displayed and sometimes they are
not. To me
this is kind of an automatic (inadvertent even) query. Some of this
is only
semantics, but I think we all agree that semantics can be important.

IMHO these are all side-effects of the inconsistent way layers are
handled
amongst different GRASS modules. It's an implementation problem (perhaps
caused by confusion among developers as options were added and modified
over the years), rather than a fundamental problem with the layer
concept.

The inconsistent implementation is an issue certainly. I don't think
that there is a problem with underlying concept of the layer feature.
Indeed, it is a very powerful data management feature of GRASS. I just
think that another name for the feature would help users to understand
and make use of it better--especially since we also use the term
layers in the GUI layer manager to refer to superimposed displays of
distinct geospatial data files, a very common usage in GIS.

You may notice that you have to specify a vector layer for d.vect in the
GUI layer manager, i.e. the GUI layer manager displays a vector layer
unless layer=-1. I bet you yourself use most of the time d.vect layer=1
and not layer=-1.

I do. But that is because I prefer to use a linked attribute table to control what is displayed, what is not displayed, and what is used for labels--and usually only need to link a single table to do so. I prefer the linked table because the actual cat values that make up each layer table are more difficult to manage than an attribute table linked to the vector file via the cat values. There is no way that I know of to access and change these values directly--only through v.category or v.reclass. In both cases, these programs display the raster-like heritage of vector data management and layers, but we lack the equivalent of a d.rast.edit. This also makes layers as now structured difficult to use for differentially displaying sets of vector objects.

While I'm happy with the way vector layers work now, but think they should be called something different to avoid confusion with display layers and OGR layers, several commentators are expressing a preference for a function that does work like OGR layers to subset vector objects within a file for display or other manipulation. If we really want a structure that will subset a vector file into mutually-exclusive groups like CAD layers, we need to rework how GRASS vector layers actually work. In this sense, the database relationship should be 1 layer to many vector objects, rather than the current 1 vector object to many layers. Moreover, to make this truly useful, I suggest we also look at changing vector manipulation modules (v.distance, v.overlay, etc) so that selecting a layer works like a MASK in rasters by only carrying out the operation on the objects that are grouped into that layer. Other programs that use vector layers work in this way, allowing you to "lock" a layer so that objects in that layer are not altered during editing actions.

Michael

If we manage to come to a full understanding of the capabilities and
possibilities of the concept of vector layers in GRASS (which I feel
this
discussion is really helping us to work towards, for me anyway), then it
would be an exciting project to do an audit of all vector modules and
the
way they handle layers, and tidy up all the inconsistencies so that the
meaning of layers is much more obvious, simply from the module
options and
flags. Perhaps too radical though.

Tidying up inconsistencies is not radical but regular maintenance work IMHO.

Markus

17

I have doubts about many things I did in GRASS but not about the term
'layer'. It was in fact chosen to correspond better to OGR and usual
GIS terminology. And GRASS layer realy is OGR layer equivalent. As it
was mentioned already, GRASS layer is like shapefile and GRASS vector
is like a directory with more shapefiles. And also metioned, shapefile
is imported to GRASS layer and GRASS layer is exported to a shapefile
(or any other OGR layer e.g. PostGIS table). Giving to GRASS layer a
different name you make more confusion IMO.
Note also that GRASS layer could also be identified with a name (it is
partially coded).

Shortly:
  raster map -> layer is OK
  vector map -> layer is bad
  vector map -> anything reasonable except layer is OK
  vector layer -> anything else is bad
also mentioned in mails:
  vector cat -> GID is bad because one geometry may have more cats and
geometry id exists in fact inside but it is not accessible for users
(except debugging info)
  vector cat -> FID is quite good, cat is used just for historical reasons

I have not read everything but I think that Markus Metz understands
GRASS vectors in the same way I do, so he is speaking for me more or
less.

Radim

On Tue, Jun 16, 2009 at 9:21 AM, Markus
GRASS<markus.metz.giswork@googlemail.com> wrote:

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 :slight_smile: 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

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev