[GRASS-user] Re: two questions on setting a new layer for for a vector

[Moritz Lennert]

On 22/11/11 08:44, G. Allegri wrote:
> I've solved my needs about the creation of a new layer, but I feel that
> the mechanism a bit counter-intuitive.
> A new layer can be created *only* through an intemediary vector
>
>  >> v.category input=rivers output=rivers_tmp layer=2
>  >> g.remove vect=rivers
>  >> g.rename vect=rivers_tmp,rivers
>
> Directly creating a new connection on a new layer produces the new
> layer, but the categories are not attached:
>
>  >> v.db.connect map=rivers table=rivers_clone layer=2
>
> and the vector *seems* to have a new layer, but it cannot be used.
> I see the same results if I create a new layer through the wxGUI (vector
> attributes window -> new layer). A new layer is shown, but it cannot be
> used (eg cannot be displayed). I will open a ticket on this.

Please note that this is not a bug, but apparently a misunderstanding of 
how the layer mechanism works.

Layers are not a database connection tool. The closest I can get in 
terms of a short definition of layers is that they are a tool for 
thematically grouping objects in a vector map. For example, you can have 
a series of field boundaries in a map and none of them have a category 
value in layer 1 as layer 1 is 'fields' and the category values of 
fields (= polygons) are with the centroids. However, if some of these 
boundary lines are also hiking paths, you can give them category numbers 
in layer 2 and thus layer 2 becomes the thematic layer "hiking paths". 
Another example would be weather stations for which you have a whole 
battery of measures every day and instead of putting them all into one 
attribute table, you wish to have one table per day. You could then 
create one layer per day and each station would then have to have a 
category number in each layer.

Any layer can, but does not have to, be connected to an attribute table. 
For any element in the map which has a category number in that layer, 
the system will then look into the attribute table and search for this 
category number in the key column. If that category number is not 
present in that column, then there are no attributes for that element.

So:

- You create a link between a layer and a table, but if no element in 
the map has a category value in that layer, then your link is useless. 
In other words, a layer only makes sense when you actually give category 
values to elements in your map in that layer.

- Layers can be useful without tables, and so one probably should see 
these two concepts (layers and database connections) as separate, though 
obviously linked.

The fact that v.category creates a new map with the results of the 
manipulation of the category values is probably a welcome security. If 
you delete all your category values by accident (e.g. you forget to 
specify the type when you want to delete category values from 
boundaries, but not centroids), the fact that the result is a new map 
reduces the chances for catastrophe. If you a sure that you will never 
make a mistake, you can always script the two steps (no need for the 
g.remove):

v.category input=rivers output=rivers_tmp layer=2
g.rename vect=rivers_tmp,rivers --o

I agree that it would be helpful to have an opion in v.category to copy 
the values from one layer to another (i.e. something like option=copy 
layer=2 sourcelayer=1).

Moritz