Opened 13 years ago

Closed 10 years ago

#754 closed defect (invalid)

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

Reported by: ploewe Owned by: grass-dev@…
Priority: critical Milestone: 6.5.0
Component: Vector Version: 6.4.0 RCs
Keywords: v.overlay Cc: martinl
CPU: Unspecified Platform: Linux

Description

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

Attachments (4)

grassbug.png (17.5 KB ) - added by ploewe 13 years ago.
Grey= Correct Overlay Red=No overlay/No Polygons
input_utm32.zip (20.9 KB ) - added by ploewe 13 years ago.
Input for overlay operation: Polygons in UTM 32
input_utm33.zip (9.6 KB ) - added by ploewe 13 years ago.
Input for overlay operation: Polygons in UTM 33
overlay_result.zip (30.1 KB ) - added by ploewe 13 years ago.
Result of v.overlay in grass6.4RC5

Download all attachments as: .zip

Change History (9)

by ploewe, 13 years ago

Attachment: grassbug.png added

Grey= Correct Overlay Red=No overlay/No Polygons

in reply to:  description ; comment:1 by martinl, 13 years ago

Cc: martinl added
Keywords: v.overlay added

Sample data / Screenshots can be produced on request.

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

Thanks, Martin

in reply to:  1 ; comment:2 by mmetz, 13 years ago

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

by ploewe, 13 years ago

Attachment: input_utm32.zip added

Input for overlay operation: Polygons in UTM 32

by ploewe, 13 years ago

Attachment: input_utm33.zip added

Input for overlay operation: Polygons in UTM 33

by ploewe, 13 years ago

Attachment: overlay_result.zip added

Result of v.overlay in grass6.4RC5

in reply to:  2 ; comment:3 by ploewe, 13 years ago

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

in reply to:  3 comment:4 by mmetz, 13 years ago

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

in reply to:  3 comment:5 by mmetz, 10 years ago

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.