lineSplit does not split horizontal lines that have more than 7 decimals in latitude

[ChristopherChudzicki]

Turf Version: 6.3.0

lineSplit does not split horizontal lines whose latitudes have more than 7 decimal places.

For example, the test below fails

test("turf-line-split -- splitting horizontal lines with more than 7 lat decimals", (t) => {
  const x1 = 0
  const x2 = 10;
  const y = 0.12345678;

  const xMid = (x1 + x2)/2;

  const line = lineString([[x1, y], [x2, y]]);
  const splitter = point([xMid, y]);

  const { features } = lineSplit(line, splitter);

  // these fail; real result is an un-split line: lineString([ [ x1, y ], [ x2, y] ])
  t.isEqual(features.length, 2)
  t.deepEquals(features[0], lineString([[x1, y], [xMid, y]]));
  t.deepEquals(features[1], lineString([[xMid, y], [x2, y]]));

  t.end();
})

[ChristopherChudzicki]

I looked into the cause a bit. As best I can tell, what's happening is:

• the splitter point is truncated to 7 decimals
• the line segments that make up the original line are loaded into rbush.tree without truncation.
• rbush.tree uses bounding boxes (I think?) and the truncated splitter point is outside the bounding box of the un-truncated line.

This seems like it could be an issue with very slightly sloped lines, too.

One idea for fixing : Just truncate the line segments that are loaded into rbush. One potential downside to this is that currently the LineString vertices returned by lineSplit exactly match the original geometry except at the split points. Truncating the segments into rbush might mean the new vertices are not exactly equal to the old vertices. I dunno how big a deal that is. My understanding is that GeoJSON does not specify a standard precision, but recommends 6 decimals. So maybe it's ok.