#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
-------------------------+--------------------------------------------------
Reporter: ploewe | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.5.0
Component: Vector | Version: 6.4.0 RCs
Keywords: | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Using GRASS' overlay capabilities produces the same class of error (at
least) in v.in.ogr and v.select. (-> bug in a related library ?) for the
described kind of datasets/geometries:
Assume two vector layers, each containing square polygons (each having a
centroid), arranged as a "chessboard" [real world case: topo map outlines
arranged according to UTM zones]
Each "chessboard" is slightly tilted towards the other [real world case:
each "chessboard" equals one of two neighbouring UTM zones.]
Both chessboards overlap on one side. The overlap-zone equals one to two
columns of the chessboard squares.
If the two "chessboards" are overlaid by some GRASS operation, an overlap-
zone is created where two to three polygons overlap.
For a yet unexplored reason, GRASS favors polygons in a left-right
-fashion: The leftmost polygons/squares are correctly represented in the
merged vector layer.
The rightmost polygons are DROPPED. Only the centroids are available in
the resulting vector layer.
This phenomenon shows in GRASS6.3 and GRASS6.4RC5. It can be replicated.
Tools like Arc G!S or OpenJump perform this kind of overlay/merging
functionality correctly.
Sample data / Screenshots can be produced on request.
#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
-----------------------+----------------------------------------------------
Reporter: ploewe | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.5.0
Component: Vector | Version: 6.4.0 RCs
Resolution: | Keywords: v.overlay
Platform: Linux | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by mmetz):
Replying to [comment:1 martinl]:
> > Sample data / Screenshots can be produced on request.
>
> Yes, please attach sample data e.g., in GRASS ASCII vector format.
>
+1, if the sample data are too large for attachment, please send them off-
list as attachment.
Could you also provide information about what were the exact commands you
used, what do you want to happen with the overlapping areas i.e. which
cleaning operations should be performed, and what should the desired
result look like.
#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
-----------------------+----------------------------------------------------
Reporter: ploewe | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.5.0
Component: Vector | Version: 6.4.0 RCs
Resolution: | Keywords: v.overlay
Platform: Linux | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by ploewe):
Replying to [comment:2 mmetz]:
> Replying to [comment:1 martinl]:
> > > Sample data / Screenshots can be produced on request.
> >
> > Yes, please attach sample data e.g., in GRASS ASCII vector format.
> >
> +1, if the sample data are too large for attachment, please send them
off-list as attachment.
>
> Could you also provide information about what were the exact commands
you used, what do you want to happen with the overlapping areas i.e. which
cleaning operations should be performed, and what should the desired
result look like.
>
> Thanks,
>
> Markus M
Done.
Two sample input data sets were attached as ESR! shapes to the ticket plus
the result from v.patch as generated by grass6.4R5.
Here's the challenge: The two tile grids provided in the two input
shapefiles partially overlap. The task is NOT to clean the topology (and
to create new sub-polygons in the overlap area), BUT to maintain the
current polygon pattern, which implies that a number of poylgons overlap.
In a naive approach, v.patch was used to accomplish this:
v.patch -e
input=country_germany_tiles_zone33@aoi,country_germany_tiles_zone32@aoi
output=patch33_32
Interestingly, the process generates "empty strips" within the resulting
data set: In these zones there are "failed" polygons, for which only
centroids exist.
In the above example (v.patch ... ... output=patch33_32) examine the
centroids/polygons with the categories 27658 and 13692 (or 27640 and
13674).
BTW: The same effect occurs when importing a larger dataset (Shape) into
GRASS with v.in.ogr which includes both UTM strips. Therefore I guess that
the problem isn't module- but library-specific.
#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
-----------------------+----------------------------------------------------
Reporter: ploewe | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.5.0
Component: Vector | Version: 6.4.0 RCs
Resolution: | Keywords: v.overlay
Platform: Linux | Cpu: Unspecified
-----------------------+----------------------------------------------------
Comment (by mmetz):
Replying to [comment:3 ploewe]:
> Replying to [comment:2 mmetz]:
> > Replying to [comment:1 martinl]:
> > > > Sample data / Screenshots can be produced on request.
> > >
> > > Yes, please attach sample data e.g., in GRASS ASCII vector format.
> > >
> > +1, if the sample data are too large for attachment, please send them
off-list as attachment.
> >
> > Could you also provide information about what were the exact commands
you used, what do you want to happen with the overlapping areas i.e. which
cleaning operations should be performed, and what should the desired
result look like.
> >
>
> Done.
> Two sample input data sets were attached as ESR! shapes to the ticket
plus the result from v.patch as generated by grass6.4R5.
> Here's the challenge: The two tile grids provided in the two input
shapefiles partially overlap. The task is NOT to clean the topology (and
to create new sub-polygons in the overlap area), BUT to maintain the
current polygon pattern, which implies that a number of poylgons overlap.
AFAICT, this is not supported by the GRASS vector topology model by
design. In order to attach a centroid to an area, at least some part of
that area must not be overlapped by any other area, otherwise there will
be areas without centroids and/or areas with duplicate centroids. In your
patched example, there are a number of areas that are completely
overlapped by other areas. There, centroids can neither be calculated nor
properly attached. Patching these two vectors together and maintaining
areas exactly as they are, with their category and attribute link, works
only in a non-topological vector environment.
Partially overlapping polygons are supported by GRASS, e.g. Landsat tiles
can be imported and maintained as they are if they are not cleaned,
because tiles overlap only at the edges and centroids can be properly
attached. As long as there is a small bit of the area not overlapped by
another area, you can manually move the centroid to there to remove
duplicate centroids. This is however impossible for a number of areas in
the overlap zone.
Replying to [comment:3 ploewe]:
> Replying to [comment:2 mmetz]:
> > Replying to [comment:1 martinl]:
> > > > Sample data / Screenshots can be produced on request.
> > >
> > > Yes, please attach sample data e.g., in GRASS ASCII vector format.
> > >
> > +1, if the sample data are too large for attachment, please send them
off-list as attachment.
> >
> > Could you also provide information about what were the exact commands
you used, what do you want to happen with the overlapping areas i.e. which
cleaning operations should be performed, and what should the desired
result look like.
> >
> > Thanks,
> >
> > Markus M
>
> Done.
> Two sample input data sets were attached as ESR! shapes to the ticket
plus the result from v.patch as generated by grass6.4R5.
> Here's the challenge: The two tile grids provided in the two input
shapefiles partially overlap. The task is NOT to clean the topology (and
to create new sub-polygons in the overlap area), BUT to maintain the
current polygon pattern, which implies that a number of poylgons overlap.
Overlapping polygons are not supported in topological vector models,
instead overlapping polygons are represented by areas with multiple
categories. In this paricular case, the two shapefiles need to be imported
at once with v.in.ogr, letting v.in.ogr do the topological cleaning.