[GRASS5] Layers in vectors

[Martin Landa]

Hi,

another example:

During of writing of a special GRASS module v.in.vfk which allows user
to import data in Czech cadastral exchange data format I found this
vector model very very useful. An output vector map layer may contain
tens layers with linked correspondent number of attribute tables. The
vector model implemented in GRASS > 5.7 helped me a lot in this
work...

Best regards,

Martin

2006/3/3, Radim Blazek <radim.blazek at gmail.com>:
> 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
> >
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>