[GRASS5] Layers in vectors

[Trevor Wiens]

Radim, Markus, others involved in architecture of new vector layers in
GRASS

In the list recently issues of vector layer support in v.what have
arisen. I created v.what by editing out the xdisplay specific
components of d.what.vect so I didn't worry about this issue. In
researching multilayer vector files and e-mails with Michael Barton
I've concluded there are two possible uses for this feature. Neither of
these seem particularly wise or properly justified for including it.
Perhaps there are other possible reasons for its inclusion in which
case the documentation of their purpose is lacking. I'm happy to help
provide that documentation if a compelling argument for their existence
is found. If not, I would suggest considering removing this "feature"
and replacing it with something else.

As far as I can see there are two possible uses for multilayer vector
files.

1. A convenient way to package multiple layers with similar themes into
a working group.

2. Providing multiple keys against a single set of GIS objects. This
would be achieved by duplicating a vector layer into multiple layers
and using different CAT values to link to different tables.

IMAO (In my arrogant opinion) these are both BAD IDEAS. In the
first case this means that all vector modules need to be modified to
support this feature (which as far as I know isn't complete yet) and
the same functionality could be more easily done with a simple group
facility as is provided for images. Less modification of vector modules
would be needed and it is much clearer. Before multilayer vector files
exists a layer meant one thing. Now it means two. A layer could be a
layer within a file or it could be a vector, raster or image file. This
is confusing and unnecessary. There are enough real obstacles to
learning GIS for people who need to use it without creating artificial
ones by creating semantic confusion. Names should mean one thing
whenever possible. 

In the second case, this means duplicating geographic features, which
might be changed and it is tremendously space inefficient for any
complex features. Further editing of features could lead to them
being edited in one layer and not another. This is a recipe for
disaster.

So in effect AFAIK there is one intended and valid use of multilayer
files, grouping like vector layers together into groups. This solution
to that problem is however overkill and worse it is confusing and
provides options for people to do bad things (case 2). 

Thus, I would like to hear why it was done and if the developers are
still convinced it is a good idea. If so, I'm happy to help with
documenting why they are useful. If people reconsider and decide the
are bad idea, then I would be happy to help with thinking out a more
appropriate solution (at this time I have to many things on the go to
code one - maybe in summer)

I look forward to hearing your comments.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)