lineOffset function returns random numbers for coordinates for polylines with 180 degree turns

[aj8k]

Hi! Your lib is a life saver for my work. So first of all thank you :)

And now let's go down to the business. I have found a wierd behaviour of lineOffset functions for some polylines. I have narrowed problem to problems with floating points precision.

Small example for reproduce (line has a 180 degrees turn on third point):

turf.lineOffset(turf.lineString([
    [
      30.59357475489378,
      50.4496289184317
    ],
    [
      30.593773238360882,
      50.44968524482101
    ],
    [
      30.593875162303448,
      50.44971743132919
    ],
    [
      30.593773238360882,
      50.44968524482101
    ],
    [
      30.59357475489378,
      50.4496289184317
    ],
]), 5, {units: 'meters'})

Result

{
  "type": "Feature",
  "properties": {},
  "geometry": {
    "type": "LineString",
    "coordinates": [
      [
        30.59358703078247,
        50.44958566053822
      ],
      [
        30.593786149427643,
        50.44964216718077
      ],
      [
        -6465589.797091965,  <-- Problem is
        -2041724.4105408227  <-- here
      ],
      [
        30.593760330107745,
        50.44972832325972
      ],
      [
        30.59356247900509,
        50.44967217632518
      ]
    ]
  }
}

I tried to find the problem by myself. And looks like the issue is in function isParallel.
For inputs

A = [ [ 30.593867037896306, 50.44974315861847 ], [ 30.59376511395374, 50.44971097211029 ] ]
B = [ [ 30.593780985000908, 50.449659398236854 ], [ 30.59388328671059, 50.449691704039914 ] ]

It calculates angle between them

CrossProduct = -3.049318610115481e-19

And to be parallel this crossProduct should be equal to 0.
If I try some delta instead (0.000000001 for example), looks like nothing breaks and it fixes the problem. I didn't spend too much time on sources exploration so I don't know if it is a valid fix.
turf.truncate can help in some cases, but not always.

[rowanwins]

Hi @aj8k

Thanks for the report and bug hunting. Yeah the line-offset has got a few reports of errors so fingers crossed this might do the job of fixing a number of them.

I'm currently working on a fairly major overhaul related to #1432 so it would be great to get this addressed as part of that work.

Thanks

[rowanwins]

Just quickly @aj8k - can you share a diagram of the expected output in your case would be? And how did you apply the delta?

[aj8k]

@rowanwins
Here is result that I got with applied fix

Result

{
  "type": "Feature",
  "properties": {},
  "geometry": {
    "type": "LineString",
    "coordinates": [
      [
        30.59358703078247,
        50.44958566053822
      ],
      [
        30.593786149427643,
        50.44964216718077
      ],
      [
        30.59386162162488,
        50.449760310144654
      ],
      [
        30.59376032729412,
        50.449728322461254
      ],
      [
        30.59356247900509,
        50.44967217632518
      ]
    ]
  }
}

Here is my variant of the fix (has changed custom delta to more fundamental constant Number.EPSILON)
Original function:
https://github.com/Turfjs/turf/blob/master/packages/turf-line-offset/lib/intersection.js#L98-L102

function isParallel(a, b) {
    var r = ab(a);
    var s = ab(b);
    return (crossProduct(r, s) === 0);
}

Fixed variant:

function isParallel(a, b) {
    var r = ab(a);
    var s = ab(b);
    return (Math.abs(crossProduct(r, s)) < Number.EPSILON);
}

[rowanwins]

Phew @aj8k - i ended up with the same thing!

[aj8k]

@rowanwins Looks like #1432 is delaying. If I push fix in separate branch will it be merged before this big update? Will npm module be updated?

For now I have created some workaround fix for this issue (don't want to use custom library build) but it would be great to fix it in the turf library so everything start working in my project as expected.