[GRASS-user] Importing polygon maps with overlapping features

GRASS GRASS user
1

Thanks for your clarification, Moritz, that makes perfect sense
from the data model point of view.

The only trouble this gives me in practice arises when I need to
import data created in non-topological GIS (e.g. ArcView Shapefiles)
that contains overlapping polygons. Granted, those should not exist
in the first place, but bad data quality and faulty topology is a
constant reality in my field of work. With overlapping polygons,
centroids cannot always be related to exactly one polygon, so the
topology building fails for those cases and attribute data does
not get attached "correctly".

Are there any bright ideas on how to allow v.in.ogr to import maps
with overlapping polygons and still manage to create a GRASS map
that has all area objects and the right attribute table row linked
to each one of them? Export would also need to work in the same way.
My gut feeling is some patching of v.[in|out].ogr would be required...

Cheers,

Ben

Moritz Lennert wrote:

To be quite honest, I have always been a bit bewildered about the
choice of using a centroid point for linking attributes to area
features. Could anyone here fill me in on what advantage that has?

In a topological model where a boundary is boundary of two adjacent
polygons, you cannot link polygon attributes to the boundary as there
would be ambiguity as to which polygon these attributes are referring
to. So you need some way of unambiguously identifying the polygon. A
pseudo-centroid (i.e. not the geometric centroid, but one that in all
cases lies within the polygon) is one way of doing it and the one chosen
in GRASS's vector model. There might be other ways, but I'm no expert on
that.

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel.: ++44 (0)1865 263 800
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

2

On Wed, January 7, 2009 12:58, Benjamin Ducke wrote:

Thanks for your clarification, Moritz, that makes perfect sense
from the data model point of view.

The only trouble this gives me in practice arises when I need to
import data created in non-topological GIS (e.g. ArcView Shapefiles)
that contains overlapping polygons. Granted, those should not exist
in the first place, but bad data quality and faulty topology is a
constant reality in my field of work. With overlapping polygons,
centroids cannot always be related to exactly one polygon, so the
topology building fails for those cases and attribute data does
not get attached "correctly".

Are there any bright ideas on how to allow v.in.ogr to import maps
with overlapping polygons and still manage to create a GRASS map
that has all area objects and the right attribute table row linked
to each one of them? Export would also need to work in the same way.
My gut feeling is some patching of v.[in|out].ogr would be required...

The question is what you want to do with the data. If it is for mapping,
you can just use v.external. But if you want to actual do GIS analysis,
the ambiguities created by the overlaps have to be lifted at one point.
Overlapping polygons is a fundamental error in the classical 2D model as
for a particular point in space, you cannot say for sure which attributes
are linked to it.

v.clean tries to repare this (v.in.ogr uses the same routines and you can
parameter them), but in the end it is the responsibility of the user to
make the decisions...

So, I'm not sure it can be easily handled by a "patch" to v.in.ogr.

Moritz

3

Hello,
GRASS vector model is advanced, but sometimes it fails for simple
usage. It's one of best features is also it's point of failure.
Vector areas support in GRASS is built around bogous assumption, that
areas can not overlap. Such assumption holds true for many vector
usages (i.e. property boundaries don't overlap), but fails for other
vector usage patterns.
Let's assume one GRASS user wants to create vector area map with
suitable animal habitat areas. Does gay wolf and brown bear habitat
areas may overlap in real world? Yes they can. Can they overlap in
GRASS? No. User is forced to adapt semantics (habitat area) to data
storage limitations (one map per species).

Probably this is not the best example, simply I could not make better one fast.

Sorry for language and trolling,
Maris.

2009/1/7, Benjamin Ducke <benjamin.ducke@oxfordarch.co.uk>:

The only trouble this gives me in practice arises when I need to
import data created in non-topological GIS (e.g. ArcView Shapefiles)
that contains overlapping polygons. Granted, those should not exist
in the first place, but bad data quality and faulty topology is a
constant reality in my field of work. With overlapping polygons,
centroids cannot always be related to exactly one polygon, so the
topology building fails for those cases and attribute data does
not get attached "correctly".

Cheers,

Ben

4

Hello there,

yes this can be seen as a limitation of grass, or more precisely of the
topological data model. But I think one must remind of the strict border
that should lie between geometry and a "semantic" contents.

With a relational database structure you can of course overlap various
characteristics of a single area : on one hand you have a set of
adjacent -- that is topologically clean -- polygons, on the other hand a
table or a set of related tables holding the complexity of attributes ;
the cat value of a centroïd has a univoque link with a row of a table,
then you can define associations of polygons (ajacent, included,
non-adjacent).

Grass does not provide tools for directly manipulating let's say
'multi-polygon' objects, but the ability to link a database to simple
geometry allows the handling of complex objects.

______

(a bit out of context : for those who worked with ArcInfo, it is
sometimes frustrating not to have in Grass a feature class like
REGION-SUBCLASS, which is to my mind a far better solution than
multipolygons (the OGC standard geographic features))

Yours,
Vincent.

Le mercredi 07 janvier 2009 à 14:47 +0200, Maris Nartiss a écrit :

Hello,
GRASS vector model is advanced, but sometimes it fails for simple
usage. It's one of best features is also it's point of failure.
Vector areas support in GRASS is built around bogous assumption, that
areas can not overlap. Such assumption holds true for many vector
usages (i.e. property boundaries don't overlap), but fails for other
vector usage patterns.
Let's assume one GRASS user wants to create vector area map with
suitable animal habitat areas. Does gay wolf and brown bear habitat
areas may overlap in real world? Yes they can. Can they overlap in
GRASS? No. User is forced to adapt semantics (habitat area) to data
storage limitations (one map per species).

Probably this is not the best example, simply I could not make better one fast.

Sorry for language and trolling,
Maris.

2009/1/7, Benjamin Ducke <benjamin.ducke@oxfordarch.co.uk>:

>
> The only trouble this gives me in practice arises when I need to
> import data created in non-topological GIS (e.g. ArcView Shapefiles)
> that contains overlapping polygons. Granted, those should not exist
> in the first place, but bad data quality and faulty topology is a
> constant reality in my field of work. With overlapping polygons,
> centroids cannot always be related to exactly one polygon, so the
> topology building fails for those cases and attribute data does
> not get attached "correctly".
>

> Cheers,
>
> Ben
>
>
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

5

Maris Nartiss wrote:

> The only trouble this gives me in practice arises when I need to
> import data created in non-topological GIS (e.g. ArcView Shapefiles)
> that contains overlapping polygons. Granted, those should not exist
> in the first place, but bad data quality and faulty topology is a
> constant reality in my field of work. With overlapping polygons,
> centroids cannot always be related to exactly one polygon, so the
> topology building fails for those cases and attribute data does
> not get attached "correctly".

GRASS vector model is advanced, but sometimes it fails for simple
usage. It's one of best features is also it's point of failure.
Vector areas support in GRASS is built around bogous assumption, that
areas can not overlap.

That's not an assumption, it's a design decision. Vector maps are
supposed to tessellate 2D space. Any given point should always be in
exactly one area (possibly the exterior area, which is the area not
covered by any explicit areas).

Such assumption holds true for many vector
usages (i.e. property boundaries don't overlap), but fails for other
vector usage patterns.
Let's assume one GRASS user wants to create vector area map with
suitable animal habitat areas. Does gay wolf and brown bear habitat
areas may overlap in real world? Yes they can. Can they overlap in
GRASS? No. User is forced to adapt semantics (habitat area) to data
storage limitations (one map per species).

If you have multiple disjoint areas, they need to be separate vector
maps. You can no more have a point contained by multiple areas in a
vector map than you can set a single raster cell to multiple values.

--
Glynn Clements <glynn@gclements.plus.com>