Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr

[ploewe]

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.

Peter peter.loewe@…

[ploewe]

Grey= Correct Overlay Red=No overlay/No Polygons

[martinl]

Sample data / Screenshots can be produced on request.

Yes, please attach sample data e.g., in GRASS ASCII vector format.

Thanks, Martin

[mmetz]

Replying to 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

[ploewe]

Input for overlay operation: Polygons in UTM 32

[ploewe]

Input for overlay operation: Polygons in UTM 33

[ploewe]

Result of v.overlay in grass6.4RC5

[ploewe]

Replying to mmetz:

Replying to 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.

Peter

Peter

[mmetz]

Replying to ploewe:

Replying to mmetz:

Replying to 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.

Markus M

[mmetz]

Replying to ploewe:

Replying to mmetz:

Replying to 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.

Closing ticket as invalid.

Markus M