[GRASS-dev] Re: terminology issues in grass7

[Moritz Lennert]

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

Moritz