[GRASS-dev] Re: terminology issues in grass7

[Michael Barton]

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