[GRASS-dev] Re: [GRASS GIS] #754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr

[GRASS GIS]

#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                
Resolution:            |    Keywords:  v.overlay                
  Platform:  Linux     |         Cpu:  Unspecified              
-----------------------+----------------------------------------------------
Comment (by ploewe):

 Replying to [comment:2 mmetz]:
 > Replying to [comment:1 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 at aoi,country_germany_tiles_zone32 at 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

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/754#comment:3>
GRASS GIS <http://grass.osgeo.org>