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.

[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...