Bug report #11986

Intersection returns the wrong result

Added by Evangelos Rozos over 9 years ago. Updated almost 7 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Processing/QGIS
Affected QGIS version:2.18.4 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:duplicate
Crashes QGIS or corrupts data:No Copied to github as #:20192

Description

This error happens when intersecting a layer prepared with dissolve. The resulting layer contains only intersections from the last shape of the dissolved layer (with all shapes of the other layer).

For example, I am starting with layers A and B. Layer A includes 1334 shapes, all of them having ids in the attribute table with values ranging from 1 to 3. Layer B includes 7 shapes. I am trying to create the layer BD.

1. Dissolve A to produce D (includes only 3 multi-polygon shapes with ids ranging from 1 to 3).
2. Intersect B with D.

The resulting BD does not include intersections corresponding to D shapes with ids 1 and 2.

IntersectDissolvedLayers.zip (147 KB) Evangelos Rozos, 2015-01-13 11:49 PM

Related issues

Related to QGIS Application - Bug report #14504: The QGIS intersection tool yields incomplete results Closed 2016-03-16

Associated revisions

Revision dbbbf610
Added by Matthias Kuhn over 7 years ago

Check validity of input geometries in intersection algorithm

Fail if invalid geometries are found.
And some easy performance wins. Just because.

Fix #11986

Revision 5ae0e784
Added by Matthias Kuhn over 7 years ago

Check validity of input geometries in intersection algorithm, take 2

Fail if invalid geometries are found.
And some easy performance wins. Just because.

Fix #11986

Revision 7734d72d
Added by Alexander Bruy almost 7 years ago

[processing] stop algorithm execution if geometry/feature error occured
(fix #11986)

Revision 6feed195
Added by Alexander Bruy almost 7 years ago

[processing] stop algorithm execution if geometry/feature error occured
(fix #11986)

Revision c620c7c3
Added by Alexander Bruy almost 7 years ago

[processing] stop algorithm execution if geometry/feature error occured
(fix #11986)

History

#1 Updated by Giovanni Manghi over 9 years ago

  • Subject changed from Intersecting with dissolved layer, only last shape of dissolved layer in intersections to Intersection returns the wrong result
  • Priority changed from Normal to Severe/Regression
  • Target version set to Version 2.8
  • Affected QGIS version changed from 2.6.0 to master

With the same input files the operation worked fine until QGIS 2.2, since 2.4 it returns the wrong result. It affects also the tool in the processig toolbox.

#2 Updated by Martin Dobias about 9 years ago

Hmm seems to work fine for me. Could you also attach the results you get (B, BD) ?

Which tools is actually the one causing the actual problem - dissolve or intersection or either? (e.g. if you dissolve with 2.2 will the intersection in master return correct result?)

#3 Updated by Giovanni Manghi about 9 years ago

Martin Dobias wrote:

Hmm seems to work fine for me. Could you also attach the results you get (B, BD) ?

Which tools is actually the one causing the actual problem - dissolve or intersection or either? (e.g. if you dissolve with 2.2 will the intersection in master return correct result?)

Hi Martin, the description is not very clear. Steps:

  • take A and make it multipart using the "ID" column
  • intersect the above with B using the (QGIS) instersection tool
  • result is wrong (largely incomplete)

just tested again on QGIS master.

#4 Updated by Evangelos Rozos about 9 years ago

Martin Dobias wrote:

Hmm seems to work fine for me. Could you also attach the results you get (B, BD) ?

Which tools is actually the one causing the actual problem - dissolve or intersection or either? (e.g. if you dissolve with 2.2 will the intersection in master return correct result?)

Hypothesis 1
The intersection is the problematic one. But, for this bug to be triggered, a layer prepared with dissolve should be used.

Hypothesis 2
Both dissolve and intersection are problematic. Dissolve produces a corrupted layer and intersection fails to detect it and produces unpredictable results.

#5 Updated by Giovanni Manghi about 9 years ago

Evangelos Rozos wrote:

Martin Dobias wrote:

Hmm seems to work fine for me. Could you also attach the results you get (B, BD) ?

Which tools is actually the one causing the actual problem - dissolve or intersection or either? (e.g. if you dissolve with 2.2 will the intersection in master return correct result?)

Hypothesis 1
The intersection is the problematic one. But, for this bug to be triggered, a layer prepared with dissolve should be used.

Hypothesis 2
Both dissolve and intersection are problematic. Dissolve produces a corrupted layer and intersection fails to detect it and produces unpredictable results.

the issue seems to be when one if inputs is multipart (and again, the qgis tool fail, others available in qgis don't).

#6 Updated by Martin Dobias about 9 years ago

Hi Giovanni

even if first run singlepart -> multipart (instead of dissolve operation), I still get correct results... Testing on linux 64bit / geos 3.4.2.

#7 Updated by Giovanni Manghi about 9 years ago

Martin Dobias wrote:

Hi Giovanni

even if first run singlepart -> multipart (instead of dissolve operation), I still get correct results... Testing on linux 64bit / geos 3.4.2.

Hi Martin, here a project, data and screencast of the issue.

#8 Updated by Martin Dobias about 9 years ago

Thanks a lot Giovanni - I just took A_multipart + B for intersection from your data - and unfortunately the intersection works correctly on my machine :-(

What is the version of GEOS library on your machine?

#9 Updated by Giovanni Manghi about 9 years ago

Martin Dobias wrote:

Thanks a lot Giovanni - I just took A_multipart + B for intersection from your data - and unfortunately the intersection works correctly on my machine :-(

What is the version of GEOS library on your machine?

I'm on ubuntu 14.04 and install everything from ubuntugis like most of the ubuntu/mint users. But anyway the same happens on osgeo4w/master.

QGIS version 2.7.0-Master QGIS code revision exported
Compiled against Qt 4.8.6 Running against Qt 4.8.6
Compiled against GDAL/OGR 1.11.1 Running against GDAL/OGR 1.11.1
Compiled against GEOS 3.4.2-CAPI-1.8.2 Running against GEOS 3.4.2-CAPI-1.8.2 r3921
PostgreSQL Client Version 9.3.4 SpatiaLite Version 4.1.1
QWT Version 5.2.3 PROJ.4 Version 480
QScintilla2 Version 2.8.1

#10 Updated by Giovanni Manghi about 9 years ago

  • Target version changed from Version 2.8 to Version 2.8.2

#11 Updated by Giovanni Manghi almost 9 years ago

  • Target version changed from Version 2.8.2 to Version 2.10

#12 Updated by Giovanni Manghi almost 9 years ago

see also #12949

#13 Updated by Anita Graser over 8 years ago

I followed Giovanni's screencast using OSGeo4W nightly and the results from QGIS/ftools intersect are correct for me.

QGIS version 2.11.0-Master
Running against GEOS 3.5.0-CAPI-1.9.0 r4084

#14 Updated by Giovanni Manghi over 8 years ago

  • Target version changed from Version 2.10 to Future Release - High Priority

Anita Graser wrote:

I followed Giovanni's screencast using OSGeo4W nightly and the results from QGIS/ftools intersect are correct for me.

QGIS version 2.11.0-Master
Running against GEOS 3.5.0-CAPI-1.9.0 r4084

Hi Anita, if you use the provided sample data (so a multipart layer as one of the inputs) then the result is still wrong in master.

cheers!

#15 Updated by Anita Graser over 8 years ago

You're right, sorry for the noise, can't make it work now ...

#16 Updated by Giovanni Manghi over 8 years ago

Result still wrong in master.
Can this be solved before releasing the LTR release?

#17 Updated by Giovanni Manghi about 8 years ago

see also #14504

#18 Updated by Giovanni Manghi almost 8 years ago

Giovanni Manghi wrote:

see also #14504

in the above ticket seems that there is a regression also in the Processing intersection/clip tools since 2.12.

#19 Updated by Anonymous over 7 years ago

  • Status changed from Open to Closed

#20 Updated by Evangelos Rozos over 7 years ago

Anonymous wrote:

Fixed in changeset dbbbf610cfcf3fa655118d73d27a197ac1b3b224.

I can see that sanity checks were added in Intersection. Strictly speaking, this resolves this bug. However, this suggests that the Dissolve function generated a layer with inconsistent geometry. This means another bug exists (see Hypothesis 2 in note 4 of this ticket).

When a release with this commit (dbbbf610cfcf3fa655118d73d27a197ac1b3b224) is ready (any estimations when?) I will try to investigate it.

#21 Updated by Giovanni Manghi over 7 years ago

  • Status changed from Closed to Reopened
  • Category changed from 44 to Processing/QGIS

This must be reopened: it seems to me that the fix/check is available on 2.18.1 but anyway it fails to return the proper warning. Try do intersection/union with the "sample1" data in

#15962

the problem is that one of the layers has a geometry with an auto-intersection. Upon running the "intersection" operation the wrong result is returned and the only thing that is returned is the following in the QGIS log (which is NOT enough):

2016-12-12T07:36:28 2 GEOS geoprocessing error: One or more input features have invalid geometry.
2016-12-12T07:36:28 0 Feature geometry error: One or more output features ignored due to invalid geometry.
2016-12-12T07:36:28 2 GEOS geoprocessing error: One or more input features have invalid geometry.
2016-12-12T07:36:28 0 Feature geometry error: One or more output features ignored due to invalid geometry.

Please notice that union operation returns wrong results, regardless of the input feature be ok (see images in the above thicket).

#22 Updated by Giovanni Manghi about 7 years ago

  • Affected QGIS version changed from master to 2.18.4
  • Target version changed from Future Release - High Priority to Version 2.18

#23 Updated by Giovanni Manghi about 7 years ago

  • Regression? set to Yes

#24 Updated by Giovanni Manghi about 7 years ago

  • Priority changed from Severe/Regression to High

#25 Updated by Giovanni Manghi about 7 years ago

  • Easy fix? set to No

#26 Updated by Alexander Bruy almost 7 years ago

  • Status changed from Reopened to Feedback
  • Description updated (diff)

Should we close this in favour of #15962?

fix/check is available on 2.18.1 but anyway it fails to return the proper warning

What is wrong with warnings? Is stopping algorithm in case of errors a better/preffered solution?

#27 Updated by Giovanni Manghi almost 7 years ago

What is wrong with warnings? Is stopping algorithm in case of errors a better/preffered solution?

no warnings other the messages in the LOG, Operation is NOT stopped, the user is left with the impression he/she has the right result.

#28 Updated by Giovanni Manghi almost 7 years ago

  • Resolution set to duplicate
  • Status changed from Feedback to Closed

Giovanni Manghi wrote:

What is wrong with warnings? Is stopping algorithm in case of errors a better/preffered solution?

no warnings other the messages in the LOG, Operation is NOT stopped, the user is left with the impression he/she has the right result.

merged with #15962

#29 Updated by Alexander Bruy almost 7 years ago

no warnings other the messages in the LOG, Operation is NOT stopped, the user is left with the impression he/she has the right result.

Warnings printed to the Processing log, this is how all other Processing tools behave. Additionally we can output them to the dialog's "Log" tab, not sure if this makes sense though.

So, am I right, that stopping algorithm execution when some feature/geometry error occurs will be correct solution? Note that this is different behaviour from fTools.

#30 Updated by Giovanni Manghi almost 7 years ago

Alexander Bruy wrote:

no warnings other the messages in the LOG, Operation is NOT stopped, the user is left with the impression he/she has the right result.

Warnings printed to the Processing log, this is how all other Processing tools behave. Additionally we can output them to the dialog's "Log" tab, not sure if this makes sense though.

So, am I right, that stopping algorithm execution when some feature/geometry error occurs will be correct solution? Note that this is different behaviour from fTools.

Hi Alex, I think that at some point in some (ex ftools) alg is was added a "stop" in case the operation could not be finished.
This is whzt we must aim for all the QGIS geoprocessing oprations:

1) stop if the operation can't be finished
2) show a clear warning, the LOG is not enough for the vat majority of users

This is the base minimum, QGIS should be able to do better, as other GIS packages do. I'm very in favor to replace this tools with pure SQL based ones, that have proven to be faster and more robust (especially if/when a check to clean geometries is added).

#31 Updated by Giovanni Manghi almost 7 years ago

Hi Alex, I think that at some point in some (ex ftools) alg is was added a "stop" in case the operation could not be finished.
This is whzt we must aim for all the QGIS geoprocessing oprations:

the tool that has an option that stops the operation in case of geometry errors is "difference". it has also an option to skip them instead of stopping.
I'm not aware of others tools having the same.

Really not ideal, but better that silently returning wrong results.

Also available in: Atom PDF