Bug report #5617
Unexpected results from "union" and "intersection" tool, maybe others
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Processing/QGIS | ||
| Affected QGIS version: | master | Regression?: | |
| Operating System: | Easy fix?: | ||
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 15188 |
Description
dear all.
we discovered that there is an incorrect behavior with the geoprocessing functions in qGis with a particular shape of polygons:
when we try to do an "union" function between the shapefile called A and shapefile called B,
the result it is NOT CORRECT.
you can find attached the test data related to this problem
containing:
- shapefile A (input of Union);
- shapefile B (input of Union);
- shapefile C (NOT CORRECT output of QGIS of Union A + B, same result as Union B + A);
- shapefile D (CORRECT output Arcgis of Union A + B);
the problem is when the shape of the polygon in B shapefile produces island in the polygon in shapefile A, and the border of these islands in B is concident with the border of the polygon in A.
we are trying with:
- SO: winxp;
- versions of qGis: 1.7.x (until 1.7.4-5), last dev (1.9.90) and 1.8, installed with osgeo4w installer or standalone installer;
- gdal: 1.8 or 1.9, same behavior;
- plugin: ftools & geoprocessing
- functions: union, intersect (we tried just these two...);
the incorrect behaviour is that in the output shapefile C lacks one (or more) parts of the part of the polygon B falling in the polygon A.
we hope that this is clear, in other case we can explain better.
we think that this problem is very important, we are sending to you a simplified shapefiles, but in our institution we discovered this bad behavior was discovered on a real polygons, creating serious problems to our efforts to share qGis internally with our colleagues.
thanks a lot.
Associated revisions
fix #5617. Patch submitted by Salvatore Larosa, thanks!
History
#1
Updated by Giovanni Manghi over 12 years ago
- Category set to 44
- Status changed from Open to Feedback
I'm not sure it is a QGIS issue at all: as this operations are done through the GEOS library it may be a GEOS issue after all, but as I'm not really an expert I would like to ear about more experienced people, that I added to this ticket as watchers.
Anyway I can confirm the issue: it seems that if the two polygons "share" a segment the result is not the expected one.
I tested (intersection) also PostGIS and if the two polygons "share" a segment then the result is a geometry collection that as we know is not handled by QGIS so is necessary to extract the elements of a specified type for example with ST_CollectionExtract.
Again in PostGIS if the two polygons have only overlapped nodes (and not segments) then the result is multigeometry that can be viewed in QGIS and is correct, on the other hand the same situation with shapefiles (and intersection) come out empty.
#2
Updated by Giovanni Manghi over 12 years ago
- Subject changed from PROBLEM with the geoprocessing functions with particular polygon shapes to Unexpectes results with the "union" and "intersection" tools, maybe others
#3
Updated by Jürgen Fischer over 12 years ago
- Subject changed from Unexpectes results with the "union" and "intersection" tools, maybe others to Unexpected results from "union" and "intersection" tool, maybe others
#4
Updated by Salvatore Larosa over 12 years ago
Also, I tested Line Intersection and Clip tools but w/out success I always get a blank vector!
In PostGIS, as Giovanni said, ST_Intersection generates a GEOMETRYCOLLECTION with 1 LINESTRING and 3 POLYGON,
but expected is 2 LINESTRING and 3 POLYGON!!!
Maybe I am wrong but I think the shared segment on the left has some problem!
I do not exclude that there may be a GEOS bug!!
#5
Updated by Giovanni Manghi over 12 years ago
Salvatore Larosa wrote:
Also, I tested Line Intersection and Clip tools but w/out success I always get a blank vector!
In PostGIS, as Giovanni said, ST_Intersection generates a GEOMETRYCOLLECTION with 1 LINESTRING and 3 POLYGON,
but expected is 2 LINESTRING and 3 POLYGON!!!
Maybe I am wrong but I think the shared segment on the left has some problem!
Hi Salvatore,
probably the "shared" segment on the left is not perfectly overlapped between the two polygons, so this may explain why the result has just 1 linestring. In any cse I repeated the "exercise" with polygons digitized by me, similar to the provided ones, but with perfectly overlapping segments and the result (with shapefiles) is the same.
#6
Updated by Salvatore Larosa over 12 years ago
Giovanni Manghi wrote:
Hi Salvatore,
probably the "shared" segment on the left is not perfectly overlapped between the two polygons, so this may explain why the result has just 1 linestring. In any cse I repeated the "exercise" with polygons digitized by me, similar to the provided ones, but with perfectly overlapping segments and the result (with shapefiles) is the same.
Yes, I know! but if the final resulted is the D shapefile, I supposed that is perfectly overlapped!
Anyway, today I worked on this issue and I solved many problems! It seems be not a GEOS bug!
I'll do a git pull request on!
Also I noticed that Clip, Union and Intersect tools do not work properly if provider of input layers is PostGIS, can you confirm?
#7
Updated by Giovanni Manghi over 12 years ago
Anyway, today I worked on this issue and I solved many problems! It seems be not a GEOS bug!
I'll do a git pull request on!
cool!
Also I noticed that Clip, Union and Intersect tools do not work properly if provider of input layers is PostGIS, can you confirm?
yes, anything used as input in the ftools tools.
#8
Updated by Alexander Bruy over 12 years ago
- Status changed from Feedback to Closed
Fixed in changeset 049f5ca83a93b5900d2c828b213db566c4f7ac9c.
#9
Updated by Giovanni Manghi over 7 years ago
The "ftools" category is being removed from the tracker, changing the category of this ticket to "Processing/QGIS" to not leave the category orphaned.