[GRASS5] Layers in vectors

GRASS GIS GRASS GIS developer
1

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

2

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@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@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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

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@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@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@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@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

4

Trevor,

I want to correct what seems to be a small, but possibly significant,
misconception. I guess I didn't explain this well enough in our off-list
discussions.

There is no duplication of vector objects. What layers mean is that a SINGLE
vector object can join with multiple tables, using different key fields (one
key field pair for each join). A single vector object can have multiple key
fields. Each key field permits it to establish a join with a different
attribute table.

These key fields must be unique in the attribute table, but do not need to
be unique for the vector object. That is AFAICT, GRASS supports one-to-one
and many-to-one joins, but not one-to-many or many-to-many joins.

So ONE set of vector points, representing towns, can have a key field
(layer1 cat) to join each point to an attribute table of that includes town
size and population. This would produce a one-to-one join.

The SAME set of vector points can have a 2nd key field (layer2 cat) that
joins it to an attribute table of county information (county population,
county area, etc.). In this case, several points would have non-unique
values in the 2nd key field (towns in the same county) making a many-to-one
join to the county attribute table.

A DIFFERENT map of vector areas, representing counties, could also join with
the county attribute table. In this case, its key field (layer1 cat) would
have unique values to create a one-to-one join with the county attribute
table.

Actually, any table can have more than one key field defined that allows it
to join with different tables relationally. So this is not unusual in that
sense.

I think perhaps that the terminology is what may be confusing. These
multiple key fields were originally calleds simply fields. But there was
confusion with the database term fields=columns. Now they're called layers,
but this may be confusing with the GIS concept of map layers.

Perhaps we should call them "keys" or something else to make it clearer what
these are.

Hope this clarifies things somewhat.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Trevor Wiens <twiens@interbaun.com>
Date: Thu, 2 Mar 2006 16:50:51 -0700
To: GRASS5 <grass5@grass.itc.it>
Subject: [GRASS5] Layers in vectors

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.

5

On 3/3/06, Michael Barton <michael.barton@asu.edu> wrote:

Trevor,

I want to correct what seems to be a small, but possibly significant,
misconception. I guess I didn't explain this well enough in our off-list
discussions.

There is no duplication of vector objects. What layers mean is that a SINGLE
vector object can join with multiple tables, using different key fields (one
key field pair for each join). A single vector object can have multiple key
fields. Each key field permits it to establish a join with a different
attribute table.

These key fields must be unique in the attribute table, but do not need to
be unique for the vector object. That is AFAICT, GRASS supports one-to-one
and many-to-one joins, but not one-to-many or many-to-many joins.

So ONE set of vector points, representing towns, can have a key field
(layer1 cat) to join each point to an attribute table of that includes town
size and population. This would produce a one-to-one join.

The SAME set of vector points can have a 2nd key field (layer2 cat) that
joins it to an attribute table of county information (county population,
county area, etc.). In this case, several points would have non-unique
values in the 2nd key field (towns in the same county) making a many-to-one
join to the county attribute table.

A DIFFERENT map of vector areas, representing counties, could also join with
the county attribute table. In this case, its key field (layer1 cat) would
have unique values to create a one-to-one join with the county attribute
table.

Actually, any table can have more than one key field defined that allows it
to join with different tables relationally. So this is not unusual in that
sense.

I think perhaps that the terminology is what may be confusing. These
multiple key fields were originally calleds simply fields. But there was
confusion with the database term fields=columns. Now they're called layers,
but this may be confusing with the GIS concept of map layers.

Perhaps we should call them "keys" or something else to make it clearer what
these are.

The layers in GRASS correspond well to layers in OGR
if you consider GRASS vector map to be a data source.
TIGER is represented in OGR in the same way.
Also in in QGIS the GRASS layers appear on the same level
as layers from other data sources.

Radim

Hope this clarifies things somewhat.

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> From: Trevor Wiens <twiens@interbaun.com>
> Date: Thu, 2 Mar 2006 16:50:51 -0700
> To: GRASS5 <grass5@grass.itc.it>
> Subject: [GRASS5] Layers in vectors
>
>
> 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.
>

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5