Ticket #754 (closed defect: invalid)
Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
|Reported by:||ploewe||Owned by:||grass-dev@…|
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.