-
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
[traverse] reverse meaning of isolation in difference #887
Conversation
Note that I get an unrelated error
but maybe it's fixed in the meantime |
op.enriched.isolated | ||
= reverseMeaningInOp | ||
? prop.isolated == isolation_no | ||
: prop.isolated == isolation_yes; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is the fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first version did have prop.isolated == isolation_no
but that is the default, we should not revert all of them into yes.
But it now does not look symmetrical, theoretically there should be cases where reversal should be necessary - but we don't have them currently in our test set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you reverse one of the test cases? To make sure the other option also gets triggered by test suite?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We test all our difference operations in two ways, so both a - b
and b - a
. If that is what you mean.
Or you probably mean (what I call) inverse them, so make a large polygon around a polygon and make the polygon itself an interior of that. Yes, I could do that, I will try to construct a case where this should happen. I now know where I’m looking for. I will do that, but not today.
Thanks.
Also I get, unrelated:
|
@barendgehrels I don't know what's heppening with the first one because the code is behind Regarding the second one. This was already fixed: #878 |
I'm just calling |
I am also getting something similar with
|
@barendgehrels @vissarion AFAIU C++17 headers support was added to Boost.Config in 1.76. |
I have the following test case which was correct under the old version, but seems to be incorrect, after this patch: |
@awulkiew ah, of course, sorry. Will update soon, it's long ago indeed. |
Thanks! I will look at it soon |
LGTM. Is this a bugfix? Would you like to release it with 1.77 if possible? Could we merge #886 before this PR in case you wanted to postpone this one to 1.78? |
Wouter found a problem in another case, I’ve still to check that. Therefore it’s better to postpone it to 1.78 |
I can reproduce it and I've a reduced version for it. I will create a separate issue for this, to add this testcase, and will try to fix it (large input... it might take a while). |
yes, there is no need to rush to a fix. In many cases actually the sym_difference works well. I sort the input polygons now by size and if I do a sym_difference in this order the output is fine. So I really think it is a corner case and you don't want to break functionality working well for other users. |
a7c26dc
to
97f82d2
Compare
The regression in the two cases referred by #888 should be fixed now |
@@ -565,10 +591,83 @@ struct traversal_switch_detector | |||
} | |||
} | |||
|
|||
#if defined(BOOST_GEOMETRY_DEBUG_TRAVERSAL_SWITCH_DETECTOR) | |||
void debug_show_results() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this shows quite a neat list of results and I would like to keep it.
For example
BEGIN SWITCH DETECTOR (region_ids and isolation) REVERSE_2
ADD (s:0, m:0) TO REGION 1
ADD (s:1, m:0) TO REGION 2
ADD (s:1, m:1) TO REGION 3
END SWITCH DETECTOR
REGION 1 multiple [turns 0 1 2] regions { 2 : via [ 0 1 2 ] }
REGION 2 yes [turns 0 1 2 3] regions { 1 : via [ 0 1 2 ] } { 3 : via [ 3 ] }
REGION 3 yes [turns 3] regions { 2 : via [ 3 ] }
II 0 (50, 70) -> [0/1] (1 false) / (2 false)
II 1 (70, 70) -> [0/1] (1 false) / (2 false)
II 2 (70, 50) -> [0/1] (1 false) / (2 false)
II 3 (50, 50) -> [1/1] (2 true) / (3 true)
23a2aeb
to
4b3f655
Compare
This fixes #869 , the recently found problem in difference and interconnected interiors, and should fix similar cases too (though they were not yet in the test suite).
The root cause was that isolated interior rings were detected but in case of difference, it's meaning should be reversed.