[GRASS-dev] terminology issues in grass7

[roger at spinn.net]

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