Turf: lineSplit does not split a lineString if splitter is very close to a vertex point

[grundid]

The following test returns a feature collection with only one element.
I would expect two elements.

const lineString = turf.lineString([[9.2202022, 49.1438226], [9.2199531, 49.1439048], [9.2196177, 49.1440264]]);
const resultFc = turf.lineSplit(lineString, turf.point([9.219953175634146, 49.14390480825327]));
t.equals(resultFc.features.length, 2);

When I reduce the precision of the splitter the result is correct:

const lineString = turf.lineString([[9.2202022, 49.1438226], [9.2199531, 49.1439048], [9.2196177, 49.1440264]]);
const resultFc = turf.lineSplit(lineString, turf.point([9.2199531, 49.1439048]));
t.equals(resultFc.features.length, 2);

[stebogit]

@grundid it seems to be a matter of decimals in the splitter (point) coordinates:

const lineString = turf.lineString([[9.2202022, 49.1438226], [9.2199531, 49.1439048], [9.2196177, 49.1440264]]);
const resultFc = turf.lineSplit(lineString, turf.point([9.219953, 49.143905])); // coordinates truncated to 6 decimals
//={ "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": {}, "geometry": { "type": "LineString", "coordinates": [ [ 9.2202022, 49.1438226 ], [ 9.2199531, 49.1439048 ], [ 9.219953, 49.143905 ] ] } }, { "type": "Feature", "properties": {}, "geometry": { "type": "LineString", "coordinates": [ [ 9.219953, 49.143905 ], [ 9.2196177, 49.1440264 ] ] } } ] }

Turf follows GeoJSON recommendations by using 6 decimals to define coordinates.

@DenisCarriere we might want to truncate the coords of the splitter in@turf/line-split to avoid this issue?

[grundid]

If Turf follows the GeoJSON recommendations then maybe turf.point should not create a GeoJSON object with to many decimals. ;)

[DenisCarriere]

then maybe turf.point should not create a GeoJSON object with to many decimals

Might not be a good idea to add truncate to turf.point since that would add unnecessary overhead if it's not required.

we might want to truncate the coords of the splitter in@turf/line-split to avoid this issue?

👍 Agreed, for this scenario we might want to introduce truncate for the splitter, we can add this exact example to the test.js.

@grundid Good catch!

[DenisCarriere]

Fixed in the next minor release.

[grundid]

After the latest release lineSplit became somehow quite useless for my cases:

Case 1:

  const lineString = turf.lineString([[9.2202022, 49.1438226], [9.2199531, 49.1439048], [9.2196177, 49.1440264]]);
  const resultFc = turf.lineSplit(lineString, turf.point([9.2202022, 49.1438226]));

Returns two lines. One very short:
line1: [[9.2202022,49.1438226],[9.220202,49.143823]]
line2: [[9.220202,49.143823],[9.2199531,49.1439048],[9.2196177,49.1440264]]
Expected result would be to not cut at all.

Case 2:

  const lineString = turf.lineString([[9.2185956, 49.1450893], [9.2181343, 49.1443734], [9.2192501, 49.1438962]]);
  const resultFc = turf.lineSplit(lineString, turf.point([9.2181343, 49.1443734]));

Here the cut does not work. lineSplit returns one feature which is the original line.

[DenisCarriere]

@grundid Thanks for reporting this, could you add these test cases to the turf-line-split/test.js with your expected results, the PR should fail.

[stebogit]

Bug still somewhere... 🐛
See PR #892

[DenisCarriere]

Those pesky 🐛 🐞 !

[DenisCarriere]

This is fixed in the latest @turf/[email protected]

[IshanthaKamal]

Scenario 1

Expected Result

Scenario 2

I was trying to get split parts of 2 lines and get the merge.What I did was get line split in line1 vs line2 and again line2 vs line1. Issue is line splitting not working properly when splitting is close to vertex point as in above images.I noticed that line split is not giving proper splitter parts.In last scenario line splitting is giving only 2 splitter parts of line A instead of 3.