[GRASS5] Layers in vectors

[Radim Blazek]

The multilayer concept makes possible effective and precise
storage and maintanance of topologicaly related layers.

Example 1 topographic map:
Fields, forests and lakes can be stored in one vector. Adjacent forest
and lake can share the same boundary, but they have separate attribute
tables. It is also possible to attach attributes to boundaries. For
example, the boundary between lake and forest is a road with different
attribute table. Try to download and explore this example mapset:
http://mpa.itc.it/radim/g51/g51test-12-multi.tar.gz

Example 2 network:
Network arcs (lines) are connected at nodes (points).
Lines and points have different attribute tables.

Example 3 timeseries:
Two tables are attached to each point:
1) general description and measurement summary
2) measurements for certain date (multiple for point)

The multilayer concept is supported by all GRASS modules
and third party applications (QGIS/OGR).
It is one of few advantages GRASS has over other data
formats. It is the same concept which is used by TIGER for example.
At present there is not good time to change the concept.


Radim


On 3/3/06, Trevor Wiens <twiens at interbaun.com> wrote:
> 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)
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>