[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.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