Select by Location - Point that is snapped along a linestring, is only being selected when using 'Disjoint' predicate

[EranGeo]

What is the bug or the crash?

Although a point is snapped against a linestring segment, using the Select by Location processing tool with all predicates other than Disjoint toggled on, the point is not being selected. I would expect a selection to be made using the Intersection predicate.

Steps to reproduce the issue

1. Open a new project.
2. Create a new linestring scratch layer.
3. Create a new point scratch layer.
4. Create a new linestring feature with only one segment (e.g. 2 points only: start point and end point). Make sure that this segment is not completely horizontal nor completely vertical.
5. Enable snapping to segments behavior.
6. Create a new point feature snapped against the linestring feature. Make sure you snap it along the linestring segment and not on its vertices nor on its midpoint.
7. Open the Select by Location processing tool and fill in the following:
   • Select features from: point scratch layer
   • Where the features (geometric predicate): all but disjoint
   • By comparing to features from: linestring scratch layer
   • Modify current selection by: creating new selection
   • Hit Run

Observations

1. The point is not being selected.
2. When I revert my predicate selection to have only the Disjoint toggled on, the point gets selected.
3. This behavior doesn't happen if I snap the point to one of the linestring's vertices or its midpoint.
4. I was able to reproduce the issue using:
   • Different data provider (I used PostgreSQL)
   • Both projected and geographic CRSes for my layers and project (EPSG:3857 and EPSG:4326).
   • Before and after committing save edits to my newly created point and line features.

Versions

QGIS version | 3.28.8-Firenze | QGIS code revision | 5ac45272b58 -- | -- | -- | -- Qt version | 5.15.3 Python version | 3.9.5 GDAL/OGR version | 3.7.0 PROJ version | 9.2.1 EPSG Registry database version | v10.088 (2023-05-13) GEOS version | 3.11.2-CAPI-1.17.2 SQLite version | 3.41.1 PDAL version | 2.5.3 PostgreSQL client version | unknown SpatiaLite version | 5.0.1 QWT version | 6.1.6 QScintilla2 version | 2.13.1 OS version | Windows 10 Version 2009   |   |   |   Active Python plugins db_manager | 0.1.20 grassprovider | 2.12.99 MetaSearch | 0.3.6 processing | 2.12.99 sagaprovider | 2.12.99 QGIS version 3.28.8-Firenze QGIS code revision [5ac45272b58](https://github.com/qgis/QGIS/commit/5ac45272b58) Qt version 5.15.3 Python version 3.9.5 GDAL/OGR version 3.7.0 PROJ version 9.2.1 EPSG Registry database version v10.088 (2023-05-13) GEOS version 3.11.2-CAPI-1.17.2 SQLite version 3.41.1 PDAL version 2.5.3 PostgreSQL client version unknown SpatiaLite version 5.0.1 QWT version 6.1.6 QScintilla2 version 2.13.1 OS version Windows 10 Version 2009 Active Python plugins db_manager 0.1.20 grassprovider 2.12.99 MetaSearch 0.3.6 processing 2.12.99 sagaprovider 2.12.99 ### Supported QGIS version - [X] I'm running a supported QGIS version according to [the roadmap](https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule). ### New profile - [X] I tried with a new [QGIS profile](https://docs.qgis.org/latest/en/docs/user_manual/introduction/qgis_configuration.html#working-with-user-profiles) ### Additional context Some screenshots:  

[jdlom]

I think the problem is more a snapping problem than a selection by algorithm problem. Indeed, I had the same issue. When snapping a point on segment, the point is not on the line. Maybe a precision problem. I was able to check with the selection by algorithm and with postgres/postgis query. Anyway, snapping on vertex, middle of segments or endpoints works as expected but snapping on segment does not.

[EranGeo]

Thank you @jdlom for reproducing the issue.

Maybe a precision problem.

I wanted to check this thought so I conducted a test that had interesting results:

1. Create horizontal line segment with 2 coordinates: [0,0 3,0] (I used the advanced digitizing tool to do so). (I wanted these round figures to eliminate precision issues).
2. Create 2 points along that line with the following coordinates: [1,0] and [2,0]. (again, round figures).
3. Run the select by location tool as described in the main post.

The points are getting selected!

Yet I did another test to see what would happen if I freely snap points on that line (without a prefix X coordinate) and then run the tool again. These points also got selected! I was also able to reproduce the same behavior with points against a vertical line.

This means that the problem only occurs against a linestring segment which is not completely horizontal nor completely vertical. i.e. a 'diagonal' segment.

[EranGeo]

I was able to reproduce the issue also against a circular arc:

[lbartoletti]

This is not an issue with the algorithms being used, such as those from GEOS. The problem lies in the "quality" of the data. When the snapping option is enabled, the point is positioned "on" the segment with a precision determined by double-precision floating-point numbers. In cases like this, it would be advisable to apply a small buffer (for example, 1e-5 for Cartesian data) or preferably use topological editing functions. In this scenario, when a point is added to the snapped layer, its coordinates will match those of the snapped point, ensuring that spatial predicates function as expected.

[EranGeo]

Hi @lbartoletti , thank you for the comment.

it would be advisable to apply a small buffer (for example, 1e-5 for Cartesian data) or preferably use topological editing functions.

Both suggestions work but have some drawbacks, Using buffer: (a) the need to create additional layer; (b) predicates need to be altered. Using topological editing: (a) creates an additional vertex on the line. Yet, both are good suggestions. Thank you.

I'm wondering: this type of spatial-relation precision mismatch scenario, will happen as segments or arcs are being interpolated and derived from their respective start-end vertices - an interpolation that its precision might have been higher then the way that the snapping capture was made, leading to small number discrepancies. Alongside that, the operation may occur in scenarios for which different data providers, with different spatial precision, are being compared against each other. Does the spatial-relation algorithm takes into account some degree of tolerance upon comparing? Will tolerance lead to unwanted results?