-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent integer overflow during segment touch ratio calculation #354
base: develop
Are you sure you want to change the base?
Conversation
Thanks @mcquay239 ! |
I did and I cought a regression in multiline/multiline intersection. вт, 26 июля 2016 г., 23:11 Barend Gehrels [email protected]:
|
OK - thanks again. If necessary we can also split this PR |
36d8a40
to
f6cd9a3
Compare
I've just fixed tests. The only notice is that a linestring, consisting of an isolated point (two equal points, actually), is not simple (really?). But as I understand it's an expected behaviour. Anyway all tests except broken earlier are passed. |
f6cd9a3
to
d863476
Compare
d863476
to
84ee247
Compare
384d4b4
to
9ad0fb4
Compare
Updated PR, checked tests once more, please apply |
e479132
to
613020e
Compare
613020e
to
3f34a01
Compare
@barendgehrels Considering you've made many changes in the strategy since 2016 is this PR still relevant? |
Indeed, I probably missed this. No, I don't think it's still relevant. Let's close it - or maybe still compare it |
I use boost/geometry clipping operations after snap rounding (to prevent robustness issues). So I have no intersecting segments in my areals, segments are intersecting with their endpoints. Integers are large (they can be about 2**30), but I use 64-bit integer coordinate type. So sides (side_info) are calculating perfectly, but when segment ratio calculation leads to integer overflow.
But we don't actually need to calculate these ratios, they are trivial.