Fix issue with vertical lines not visible in the elevation profile tool

[ptitjano]

Description

This PR reverts commit ce96dee.

This commit was introduced to gain some performance when the
tolerance is set by using request.setDistanceWithin instead of
request.setFilterRect. However, in that case, the providers either
use GEOS::distance or GEOS::distanceWithin which is not able to
handle the Z component of a Geometry.
For example, a purely vertical line, i.e.: LineString(X Y Z1, X Y Z2) will always be to an infinite distance of any geometry according
to GEOS.

In practice, this means that a purely vertical line will never be
visible in the elevation profile when the tolerance is set. Indeed,
the provider will always discard such geometry because of the usage
of setDistanceWithin. This issue is fixed by always using
setFilterRect. This might introduce a performance penalty but this
ensures that the result is always correct.

Update October 10

`GEOSPreparedDistance_r` is not able to properly handle a purely
vertical line (LineString Z((X Y Z1, X Y Z2, ..., X Y Zn))). In that
case, it always `inf`. However, `GEOSDistance_r` works.

This issue is fixed by checking if one of the geometry is vertical 3d
line by introducing `isZVerticalLine`. This function checks if a
geometry is a 3d line. If that's the case, it loops through the points
of the line. If two points do not have the same X Y corrdinates, it
means that the line is not purely vertical.

If `geom` is a vertical line, it is replaced by its first point.
It the prepared geometry is a vertical line, fallback to the non
prepared case.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 2e5df52)

[nyalldawson]

However, in that case, the providers either
use GEOS::distance or GEOS::distanceWithin which is not able to
handle the Z component of a Geometry.
For example, a purely vertical line, i.e.: LineString(X Y Z1, X Y Z2) will always be to an infinite distance of any geometry according
to GEOS.

I think this special case should be handled in the iterator (or geometry) classes then, not specifically the elevation profile code

[ptitjano]

However, in that case, the providers either
use GEOS::distance or GEOS::distanceWithin which is not able to
handle the Z component of a Geometry.
For example, a purely vertical line, i.e.: LineString(X Y Z1, X Y Z2) will always be to an infinite distance of any geometry according
to GEOS.

I think this special case should be handled in the iterator (or geometry) classes then, not specifically the elevation profile code

Thanks for you message. However, I don't understand it. Do you mean that the iterator code of the providers should be changed? Or something else?

[nyalldawson]

. Do you mean that the iterator code of the providers should be changed?

I mean if the setDistanceWithin method for QgsFeatureRequest can't handle this situation, then it needs to be fixed in the iterator code. Otherwise other users of setDistanceWithin will remain broken.

So maybe the fix needs to apply in QgsGeos::distance / QgsGeos::distanceWithin instead, eg by detecting a vertical line and using a GEOS point geometry there instead...

[ptitjano]

. Do you mean that the iterator code of the providers should be changed?

I mean if the setDistanceWithin method for QgsFeatureRequest can't handle this situation, then it needs to be fixed in the iterator code. Otherwise other users of setDistanceWithin will remain broken.

So maybe the fix needs to apply in QgsGeos::distance / QgsGeos::distanceWithin instead, eg by detecting a vertical line and using a GEOS point geometry there instead...

Thanks for the suggestion. I have completely rewritten the PR to handle this is in QgsGeos.

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 9245434)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 9245434)

[nyalldawson]

Thanks @ptitjano , this approach looks much better to me! Just be aware of introducing any inefficiencies in these classes (like clones which aren't 100% required), as this is all performance critical code which needs to be as optimised as possible

[ptitjano]

Thanks @ptitjano , this approach looks much better to me! Just be aware of introducing any inefficiencies in these classes (like clones which aren't 100% required), as this is all performance critical code which needs to be as optimised as possible

Thanks. This should be good now.