Splitting Line Strings with Z interpolates strange values

[m-kuhn]

When a LineStringZ is split using the split feature tool, strange new Z values are inserted.

From a first assessment, what happens is, that the splitLine is made up of PointZ with Z=0.
Calling with a splitLine made up of QgsPointXY or QgsPoint without Z, interpolation works as expected.

---

To make things even trickier, right now it's only possible to call the (correctly working but deprecated) QgsPointXY overload from Python. The non-deprecated overload with QVector< QgsPoint > is not picked up by sip. So in order to get the following code to work that illustrates the issue, the deprecated overload has to be removed from qgsgeometry.sip.in.

# Create a line with 2 vertices with Z = 100 and 200
geometry = QgsGeometry.fromWkt('CompoundCurveZ ((2749546.2003820720128715 1262904.45356595050543547 100, 2749557.82053794478997588 1262920.05570670193992555 200))')

print(geometry.asWkt())

> CompoundCurveZ ((2749546.2003820720128715 1262904.45356595050543547 100, 2749557.82053794478997588 1262920.05570670193992555 200))

split_line = [QgsPoint(2749544.19, 1262914.79, 0), QgsPoint(2749557.64, 1262897.30, 0)]

result, new_geometries, point_xy = geometry.splitGeometry(split_line, False)

print(geometry.asWkt()) # Expected Z: something between 100 and 200 -> Actual Z: 62
> LineStringZ (2749546.2003820720128715 1262904.45356595050543547 100, 2749549.12207763036713004 1262908.37646559439599514 62.57167111346437594)

print(new_geometries)
> [<QgsGeometry: LineStringZ (2749549.12207763036713004 1262908.37646559439599514 62.57167111346437594, 2749557.82053794478997588 1262920.05570670193992555 200)>]

[haubourg]

cc @lbartoletti

[m-kuhn]

I think the Z values will need to be dropped from the split line before sending it to the splitGeometry function.
And the QVector<QgsGeometry> overload will need SIP_PYNAME. It's a pity that the version with the splitGeometry name is the deprecated one. It would be great if we could somehow preserve map the new signature to the same python name. One idea would be to have both methods with a SIP_PYNAME and a monkey patch a proxy method with the name splitGeometry, that checks the parameter for the type and then forwards to one of the two implementation methods. But that's quite some work, so I'll just leave it as an idea that can be dismissed.

[lbartoletti]

@m-kuhn I tried your example with master, seems fixed (with QgsPointXY). But not sure:

[...]
>>> result, new_geometries, point_xy = geometry.splitGeometry(split_line, False)
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<input>", line 1, in <module>
TypeError: index 0 has type 'QgsPoint' but 'QgsPointXY' is expected
>>> split_line = [QgsPointXY(2749544.19, 1262914.79), QgsPointXY(2749557.64, 1262897.30)]
>>> result, new_geometries, point_xy = geometry.splitGeometry(split_line, False)
>>> print(geometry.asWkt())
LineStringZ (2749546.2003820720128715 1262904.45356595050543547 100, 2749549.12207763036713004 1262908.37646559439599514 125.14334222692875187)
>>> print(new_geometries)
[<QgsGeometry: LineStringZ (2749549.12207763036713004 1262908.37646559439599514 125.14334222692875187, 2749557.82053794478997588 1262920.05570670193992555 200)>]

[m-kuhn]

@lbartoletti with QgsPointXY it always worked.

See

Calling with a splitLine made up of QgsPointXY or QgsPoint without Z, interpolation works as expected.

[ponceta]

Still an issue on nightly : 3.13.0-Master

[lbartoletti]

@ponceta I think it's not yet in master (commit merged 5hours ago). Please try wednesday.

[ponceta]

@lbartoletti, thanks for the info!

[ponceta]

Tried it this morning, works as expected! Thanks a lot!