QGIS Expression - overlay_intersects

[pigreco]

What is the bug or the crash?

I noticed that using the return_details and sort_by_intersection_size options does not give the expected results.

If the object to evaluate has more parts or is multipart, the output is incorrect, that is, the output returns only the length (or area) of the largest part.

In the image below I highlight the fact that the L-shaped segment is calculated only the length of the longest segment.

In the case of Multipolygon with separate parts, the area of ​​the largest overlap is calculated and not the overall area.

Steps to reproduce the issue

I attach an example project (use the views to correctly display the two cases)I attach an example project (use the views to correctly display the two cases)

progetto_overlap.zip

https://discourse.osgeo.org/t/espressione-di-qgis-overlay-intersects/111118/1

Versions

Versione di QGIS	3.41.0-Master
Revisione codice QGIS	fda2aa46e9
Librerie
Versione Qt	5.15.13
Versione Python	3.12.7
Versione GDAL/OGR	3.11.0dev-b281c45d9a
Versione PROJ	9.5.0
Versione database del Registro EPSG	v11.016 (2024-08-31)
Versione GEOS	3.13.0-CAPI-1.19.0
Versione SQLite	3.46.1
Versione PDAL	2.8.1
Versione client PostgreSQL	16.2
Versione SpatiaLite	5.1.0
Versione QWT	6.3.0
Versione QScintilla2	2.14.1
Versione SO	Windows 11 Version 2009
Questa copia di QGIS scrive messaggi di debug.
Plugins Python attivi
DataPlotly	4.2.0
felt	3.1.5
gps_replay	0.0.5
HCMGIS	24.10.20
mmqgis	2021.9.10
nominatim_locator_filter	0.3.2
profile-manager	0.31
qconsolidate	1.1.0
qduckdb	1.0.1
quick_map_services	0.19.34
relazioniplugin	1.1
SelectionFilter	1.0
db_manager	0.1.20
MetaSearch	0.3.6
processing	2.12.99

The problem is present on QGIS 3.34.12, QGIS 3.40.0 and the master

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[pigreco]

I add a demo:
note that the L-shaped sides

2024-11-11_14h03_45.mp4

[agiudiceandrea]

@elpaso, may you have a look at this?
From the docs and from the description of your PR #46683 it is unclear what the value of the 'overlap' key is supposed to contain exactly when the return_details parameter is set to true.

I would assume it should contain the area / length of the geometry resulting from the intersection between the current feature's geometry and each intersecting feature from the layer whose intersection is checked.

When the geometry resulting from the intersection is composed by a single part, that assumption seems correct.
When the geometry resulting from the intersection is composed by more then one part, then it looks like the value of the 'overlap' key contains the area / length of only (the greatest) one of the geometry's parts, instead of the area / length of the whole geometry.

Moreover, when the geometry resulting from the intersection is composed by e.g. a polygon and a line (i.e. a GeometryCollection), then the resulting array item is missing in the function result.

[elpaso]

It's been a while but looking at the specifications the overlap value is supposed to return the maximum value in case of multiple matches (at least for linestring case).

The goal of this implementation was to have a tool to identify small (difficult to catch by eye) imperfections in the digitized shapes, to be corrected manually, having the max value allows to filter for intersections that are below a small given value.

When the result of an intersection is a geometry collection of different geometry types the design decision was to return nothing.

So, it seems to me that this is the expected behavior, perhaps we can clarify it in the documentation.

[elpaso]

@andreasneumann maybe you remember better than me if this is the expected behavior.

I am happy to fix this if it is confirmed to be a bug.

[andreasneumann]

@andreasneumann maybe you remember better than me if this is the expected behavior.

I am happy to fix this if it is confirmed to be a bug.

@elpaso I used this at my previous employer Kanton Solothurn. They care only about area/area overlaps and did not care about the length of lines in the intersection areas. So we did not test this behaviour back then.

So I think it would be good to fix this, if the behaviour is like @pigreco describes.

[elpaso]

@andreasneumann maybe you remember better than me if this is the expected behavior.
I am happy to fix this if it is confirmed to be a bug.

@elpaso I used this at my previous employer Kanton Solothurn. They care only about area/area overlaps and did not care about the length of lines in the intersection areas. So we did not test this behaviour back then.

So I think it would be good to fix this, if the behaviour is like @pigreco describes.

Happy to fix it as I said, but the thing is that I am having an hard time to understand what would be the expected behavior (i.e. if there is a bug or not).

Returning the total length of the overlapping segments at first makes sense but it would be different than the behavior for polygons which by design returns the biggest overlapping part (so that you can easily filter for overlaps below a certain threshold).

As far as geometry collections are the result of an intersection what should we return instead of nothing: the length, the area or both?

[elpaso]

Summarizing: we have two separate topics here:

1. in case of multiple intersects with the same geometry type the result is by design to return the biggest/largest intersecting part measurement length or area (this is not a bug: it was by design)
2. in case the multiple intersects are of different geometry type the choice was to return nothing (again: not a bug because there isn't a choice that makes sense except maybe to return null, or 0 or -1 instead of nothing at all).

[agiudiceandrea]

@elpaso, I'm not sure to understand the purpose of such design logic.

Please see the following examples:

1. 'L1' blue: Polygon ((0 0, 0 6, 6 6, 6 0, 0 0)) | 'L2' green: Polygon ((6 0, 6 2, 4 2, 4 4, 6 4, 6 6, 12 6, 12 0, 6 0))
   

   overlay_intersects('L1',@id) (on L2) correctly returns [ 1 ]
overlay_intersects('L1',@id,return_details:=true) (on L2) incorrectly returns [ ] like there was no intersection.

2. 'L1' blue: Polygon ((0 0, 0 6, 6 6, 6 0, 0 0)) | 'L2' green: Polygon ((7 0, 7 1, 5 1, 5 2, 7 2, 7 3, 4 3, 4 5, 7 5, 7 6, 12 6, 12 0, 7 0))
   

   The intersection of the two geometries is a multi-part polygon with an area of 5 units, composed by a part with an area of 4 units and another part with an area of 1 unit.
   overlay_intersects('L1',@id,return_details:=true) (on L2) returns [ { 'id': 1, 'overlap': 4, 'radius': 1, 'result': 1 } ]: the returned overlap value is 4 units (only the area of the biggest part) while in my opinion it should be 5 units (the total area).
   Even considering the described use case ("you can easily filter for overlaps below a certain threshold"), then the correct returned overlap value should be 1, i.e. the area of the smallest part, otherwise, if I want to filter the intersections containing overlaps below the value of e.g. 2, this intersection will be incorrectly missed.

3. 'L1' blue: LineString (0 0, 1 1, 2 1, 3 1, 4 0) | 'L2' green: LineString (0 2, 1 1, 2 1, 3 1, 4 2)
   

   The intersection of the two geometries (the green / blue dashed line) is a line with length of 2 units.
   overlay_intersects('L1',@id,return_details:=true) (on L2) returns [ { 'id': 1, 'overlap': 1, 'result': 1 } ]: the returned overlap value is 1 unit instead of 2 units.

[pigreco]

My point of view:

in case the overlap is a line (even starting from two polygons), it must return the total length of the line and not its longest part, in fact as you can see from the screenshot, it doesn't make sense (for me) that it returns only the longest part.