[GRASS-dev] terminology issues in grass7

GRASS GRASS developer
1

Folks,

The terminology discussion has evolved into a discussion on usage.
That's constructive but it really doesn't do much to solve the initial
problem.

I noticed that most of the participants in the discussion are using the
term "layer" frequently and usually without problems in agreeing to its
meaning. Does that indicate that the term should continue in its
current usage?

It seems to me that most of you are talking about a "layer" as a visual
component of a map. The usage in the existing GRASS command is not a
visual component, but a database feature. Recent discussions have
revealed that the "layer=" feature by itself doesn't create a unique or
easily manipulated visual feature. That seems to confuse the usage.

The "layer=" feature of the commands seems to me to be largely if not
entirely superfluous. The function that it performs can be duplicated
by "where=" and/or "catlist=". Further, the term "layer" is widely used
with other meanings in fields where GIS is applied and that leads to
confusion.

I have a GUI of my own design that I use for GRASS. I used the term
"layer" frequently when I first wrote the scripts and it is still firmly
imbedded in the script, but after some confusion over the term I removed
it from all the widgets and documentation. I also had only a limited
need to replace the term with something else. The context was always
clear enough that I didn't need to use the term.

Roger Miller

2

On 17/06/09 14:58, Roger Miller wrote:

The "layer=" feature of the commands seems to me to be largely if not
entirely superfluous. The function that it performs can be duplicated
by "where="

This would mean mixing different types of objects into the same layer and thus the same attribute table. I.e. in the field boundaries = roads example, you would have to use the same table for the centroids characterising the fields and for the boundary line which (also) represents a road.
Not very clean in my understanding...

and/or "catlist=".

But this supposes that the user knows the cats, which often is not the case, and it eliminates the possibility of linking different types of objects to different attribute tables.

So, neither of these would really replace the current layer feature.

Further, the term "layer" is widely used
with other meanings in fields where GIS is applied and that leads to
confusion.

As has already been said, "layer" is used in different ways, even within the GIS world. The OGR definition of layers is not really identical to the definition used by some softwares. The choice in GRASS at the time was to attempt to stick as close to the OGR definition as possible, while providing, withing GRASS, additional possible uses of layers.

Just to make this more visual:

d.vect testlayers2 layer=1 fcol=green
d.vect testlayers2 layer=2 fcol=red icon=basic/circle size=10
d.vect testlayers2 layer=3 col=blue width=5 type=line

giving you

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

This is the "classical" CAD model. Main advantage: you only have to carry around one vector map, instead of three and you might be able to more easily work out topology between the different features (although I'm not sure this is true). But I agree that the advantages of this usage are debatable and one can argue that splitting up the three "themes" into three separate maps is cleaner.

However, consider this example:

d.vect testlayers3 layer=1 -c
d.vect testlayers3 layer=2 cat=1 width=3 col=blue
d.vect testlayers3 layer=3 size=10 type=point icon=basic/circle fcol=green

which gives you:

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

Here, the boundary between the two fields in layer 1 is also part of the path with cat 1 in layer 2. Or, said the other way around, it is the path which defines the boundary between the two fields.

Now, when this path is diverted, thus also changing the form of the field, you only have to move this line once to get something like this:

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

This example highlights the use of layers for ensuring data integrity, i.e. making sure that the path is always the same line as the boundary.

You will notice that I have not used any attribute tables in this example.

I think one of the problems is that many people are used to shapefiles and thus think of layers as separate files, each containing different types of objects, but that is a very restrictive, data-format driven understanding of layers and falls apart as soon as you look at DXF, DGN or (AFAIU) Tiger files.

Moritz

3

Moritz Lennert wrote:

Just to make this more visual:

d.vect testlayers2 layer=1 fcol=green
d.vect testlayers2 layer=2 fcol=red icon=basic/circle size=10
d.vect testlayers2 layer=3 col=blue width=5 type=line

giving you

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

This is the "classical" CAD model. Main advantage: you only have to
carry around one vector map, instead of three and you might be able to
more easily work out topology between the different features (although
I'm not sure this is true).

I'm pretty sure that topology is built and maintained for all geometry
objects in a vector irrespective of their cat and layer links. I guess
that was the whole idea ...

But I agree that the advantages of this usage are debatable and one
can argue that splitting up the three "themes" into three separate
maps is cleaner.

Probably depends on the features and purpose and personal preferences.
Sometimes it is cleaner, sometimes there is no advantage, IOW GRASS
vectors give you more possibilities than many other vector formats.

Markus M

4

Moritz Lennert writes:

On 17/06/09 14:58, Roger Miller wrote:

The "layer=" feature of the commands seems to me to be largely if not
entirely superfluous. The function that it performs can be duplicated
by "where="

This would mean mixing different types of objects into the same layer and thus the same attribute table. I.e. in the field boundaries = roads example, you would have to use the same table for the centroids characterising the fields and for the boundary line which (also) represents a road.
Not very clean in my understanding...

and/or "catlist=".

But this supposes that the user knows the cats, which often is not the case, and it eliminates the possibility of linking different types of objects to different attribute tables.

So, neither of these would really replace the current layer feature.

So to continue the usage discussion...

I agree that the first case would not be very clean. The problem in the example is that it uses one data set for two different purposes, which I would generally discourage; it will usually lead to other problems. If I understand the example correctly, then you might get the effect you need by drawing the boundaries and the areas with different d.vect commands, using the "type=" capability.

In the second case, GRASS provides several ways for the user to find the cats. I agree, it would be impossible to associate one vector "file" with more than one attribute table without the "layer=" capability. Again, that is a practice I discourage because of the data management problems it is likely to create. I would merge those attribute tables or I would copy the vector "file" to a second file and associate the second file with the second attribute table.

GRASS offers a lot of ways to generate visual layers in a map without using the "layer=" capability. Keeping the capability gives users more options, so I wouldn't argue that it should be removed, just that it should be renamed. I'm not a teacher, but it seems to me to be (in addition to the problem with the term overlapping in applications) a problem with clarity. Are students going to understand that visual layers can be created with i.e. "where=" and that they don't have to use "layer=" to get the layered visual they need?

If we are to use the term "layer" it would be better to restrict its usage to refer to a visual object, and to use a different term to refer to database features that may or may not be used to generate the visual.

Roger