#754: Deep Vector Bug: Overlay functionality flawed in v.select and v.in.ogr -----------------------+---------------------------------------------------- Reporter: ploewe | Owner: grass-dev@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_zon...@aoi,country_germany_tiles_zon...@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>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev