@turf/lineSlice expected precision

[mn-prp]

What is the expected precision of utilities like @turf/lineSlice. I certainly expect some floating point issues, but I noticed one relatively glaring

{
  "startPt": {
    "type": "Point",
    "coordinates": [
      1,
      2
    ]
  },
  "endPt": {
    "type": "Point",
    "coordinates": [
      4,
      2
    ]
  },
  "line": {
    "type": "LineString",
    "coordinates": [
      [
        -1,
        2
      ],
      [
        5,
        2
      ]
    ]
  },
  "result": {
    "type": "Feature",
    "properties": {},
    "geometry": {
      "type": "LineString",
      "coordinates": [
        [
          0.9999985123144755,
          2.0024376784603275
        ],
        [
          4.000001859181029,
          2.0015234321498467
        ]
      ]
    }
  }
}

The distance between [1,2] and [0.9999985123144755, 2.0024376784603275] is 0.17 miles, which is significant and much larger than I would have expected for a floating point precision drift in a single calculation.

This may be expected behavior, but if it is, I'd request that the library includes some documentation of the expected tolerances.

[smallsaucepan]

I reckon this will be due to earth curvature. Because you're working in the northern hemisphere, the great circle line between those two points will head fractionally north until the half way mark and then dip south again until it reaches the end point.

If you want to check, use turf-great-circle to get a better representation of the actual path. The distance will be more pronounced the further from the equator you go. Or reversed if you head to the southern hemisphere. If that doesn't account for the deviation, let us know and we'll dig into it more.

[mn-prp]

That seems to be it. Thanks for the context. During my testing, I noticed that lineSplit applied twice preserved the exact precision here. Can you clarify the difference between the two in terms of expected behavior? I looked at the documentation, but lineSlice just sounds like a specialization of lineSplit.

[smallsaucepan]

The intent of the two functions is a bit different.

lineSlice is for when you want a portion of the line between two points. For example, the part of a hike between two picnic grounds.

lineSplit is for when you just want to chop the line up somehow. For example, all the individual pieces of the hike broken up by the property boundaries it crosses.

Neither should really show any precision issues with repeated invocations though. The earth curvature aspect described above isn't a limitation. The deviation described is the way it's supposed to work. Though if I'm missing your point, please hit me with some concrete examples to work through.

[mn-prp]

I understand, and I'm not claiming there's a bug here. But our use case is topology-preserving manipulations that require finding a point on a planar line segment. The specific use case is (among other things) a map where the user can split a region into many zones and manipulate those zones (in an agricultural setting, where the map is typically of a field).

I was mostly just observing that the two functions (slice with two points vs split with two points) behaved differently, at least in this one test case.

In general, I've noticed some turf utilities are parameterized for planar vs geodesic calculations, while others are not. It can be a little tricky understanding what you're getting in a given case. I'd suggest (or contribute) documentation changes, but I'm also not entirely sure of the expected contract for each function.