[GRASS-dev] [GRASS GIS] #754: Deep Vector Bug: Overlay
functionality flawed in v.select and v.in.ogr
GRASS GIS
trac at osgeo.org
Thu Sep 17 11:40:07 EDT 2009
#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr
-------------------------+--------------------------------------------------
Reporter: ploewe | Owner: grass-dev at 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.
Peter
peter.loewe at gmx.de
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/754>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list