Use robust-predicates in signed area

[rowanwins]

Hey @w8r

I thought I'd take a look at using the robust-predicates lib in calculating the signed area to see if that would make any difference to any of the bugs

So far
Fixes

• martinez.union wrong response #90
• Wrong intersection depending on minor difference in coordinates #102
• Intersection may have badly ordered points. #99
• Crash: JavaScript heap out of memory #85

Doesn't fix

• Self intersecting edges in union #103
• Wrong result for two simple polygons #110
• infinite loop during intersection #98
• Simple intersection fails #97
• intersection throws an error, but works if the order of the polygons is reversed #95
  • is resolved by PR Prevent nextPos for connectEdges from accessing past end of array. #89
• Difference fails on shared edge case #80
• Overlapping edges still a problem #35

[w8r]

👍 this is quite incredible, also there's almost no performance drop:

martinez@master

Hole_Hole
Martinez x 33,283 ops/sec ±3.15% (89 runs sampled)
JSTS x 1,896 ops/sec ±27.46% (77 runs sampled)
- Fastest is Martinez

Asia union
Martinez x 10.76 ops/sec ±3.40% (29 runs sampled)
JSTS x 8.09 ops/sec ±4.95% (25 runs sampled)
- Fastest is Martinez

States clip
Martinez x 260 ops/sec ±1.47% (87 runs sampled)
JSTS x 111 ops/sec ±1.59% (72 runs sampled)
- Fastest is Martinez

martinez@use-robust-predicates

Hole_Hole
Martinez x 27,079 ops/sec ±34.50% (90 runs sampled)
JSTS x 1,386 ops/sec ±25.14% (69 runs sampled)
- Fastest is Martinez

Asia union
Martinez x 10.43 ops/sec ±3.81% (29 runs sampled)
JSTS x 8.15 ops/sec ±4.40% (25 runs sampled)
- Fastest is Martinez

States clip
Martinez x 255 ops/sec ±1.69% (85 runs sampled)
JSTS x 109 ops/sec ±2.49% (74 runs sampled)
- Fastest is Martinez

[bluenote10]

Hey @rowanwins !

Hm, now that is weird: To avoid shooting myself in the foot with further changes, I was trying to setup active test cases for old GitHub issues (as a test for #116). I thought I'd start with some of this PR, but for some reason, I have trouble reproducing them. I'm on commit 245c8d4, and my signedArea is defined based on oriente2d. But I'm getting for instance:

#102

#90

I hope I'm doing something wrong :(, but the codepen seems to be running 0.6.0 and also still looks wonky. Or are these result somehow machine dependent?

[rowanwins]

Hey @bluenote10

I was just using the test site to run my visual checks

• npm run start
• add the geojson in the test/fixtures folder
• add another case so that you can see the file via appending # to the url, eg I go to http://localhost:3000/demo/#issue102

The demo site compiles directly from the src directory.

Do you get different results using that approach?

[bluenote10]

Indeed that works!

Is there anything different with this approach in terms of e.g. input data preprocessing? If it wasn't for the codepen, I would have concluded that it is a difference browser vs nodejs. I'm not 100% sure the codepen includes the change though (I should mention that I'm not a JS programmer, so I'm not good at verifying these things).

[rowanwins]

Hmmm that's very strange, I just looked at the codepen and it looks to be setup correctly, I'll have to take a deeper look later...

[bluenote10]

Yeah, quite mysterious. I did a few more checks. I've added a

console.log(`${p0[0]}, ${p0[1]}, ${p1[0]}, ${p1[1]}, ${p2[0]}, ${p2[1]} => ${res}`);

in signedArea to get the output of both the demo in the browser and the nodejs equivalent. Looking at the diff I get (left is browser, right is node):

Unless console.log itself prints values differently in terms of precision, it looks like it is already the input data that has slightly less precision in the demo. I have no idea yet where this loss of precision is coming from. I found a JSON.parse + JSON.stringify and suspected that it might lose precision, but running it on the first value that differs I can't reproduce the precision loss:

[rowanwins]

Hmm ok so using node I am getting different results than what I'd expect for that codepen.... (eg it's wrong :( )