Intersection A-B and C-D is not equal to intersection B-A C-D about geometry

[aayushs98]

Hey eyal0, it seems that the intersection point in this example is non-integral.
i.e- the PoI is actually: (4700000, -2665584.787245271)
What should be ideally done when there is a non-integral PoI for examples like these?
I am interested in further solving this bug, please guide on how to go about it.

[eyal0]

Just pick one of them but consistently. For example, do segment intersection in all 4 configurations and choose the result that has the lowest result.

[aayushs98]

I'm willing to solve this issue. So could you please point me to the file that I can look forward to for solving this issue?

[eyal0]

I don't know which file. I'm not familiar with the boost code. :-( i think that it might be in the euclidean directory...?

[barendgehrels]

Thanks - but it most probably is not so easy to fix, by just taking one file and make some edits. Besides that, the suggestion of doing segment intersection in all 4 configurations and taking the closest - will decrease performance by a factor 4 or so. We don't want that.

The user, if he uses integer coordinates as input, can ideally (that is the idea of the library, hope it works in this case) output the intersection point in floating point and then round himself as wished.

Alternatively, if the intersection point is indeed that mentioned floating point number, no matter of the order of calling, it actually should be rounded in the same way (which does not 4 calls) and that could be more easy to fix.

[eyal0]

In the end, I did it with floating point and rounding. In floating point the result is different depending on the order of the segments but after rounding, the results were the same in the test case above.

There might be a case where even doing it in floating point and then rounding still gives two different answers. I'm not sure. I would guess probably yes.