Skip to content
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

Merged
merged 3 commits into from
Jul 28, 2021

Conversation

barendgehrels
Copy link
Collaborator

@barendgehrels barendgehrels commented Jul 8, 2021

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.

@barendgehrels
Copy link
Collaborator Author

Note that I get an unrelated error

clang-linux.compile.c++.without-pch detail/bin/algorithms_visit.test/clang-linux-6.0.0/debug/visit.o
In file included from detail/visit.cpp:18:
../boost/geometry/geometries/adapted/std_any.hpp:42:16: error: no template named 'any_cast' in namespace 'std'; did you mean simply 'any_cast'?
        return std::any_cast<T>(any_ptr);
               ^~~~~~~~~~~~~
               any_cast
../boost/any.hpp:249:17: note: 'any_cast' declared here
    ValueType * any_cast(any * operand) BOOST_NOEXCEPT

but maybe it's fixed in the meantime

op.enriched.isolated
= reverseMeaningInOp
? prop.isolated == isolation_no
: prop.isolated == isolation_yes;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the fix

Copy link
Collaborator Author

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.

Copy link

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?

Copy link
Collaborator Author

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.

@barendgehrels
Copy link
Collaborator Author

Also I get, unrelated:

In file included from ../boost/geometry/strategies/convex_hull/cartesian.hpp:16:
../boost/geometry/strategy/cartesian/side_robust.hpp:53:20: error: non-constant-expression cannot be narrowed from type 'typename coordinate_type<point_xy<int, cartesian> >::type' (aka 'int') to 'double' in initializer list [-Wc++11-narrowing]
        vec2d pa { get<0>(p1), get<1>(p1) };

@awulkiew
Copy link
Member

awulkiew commented Jul 8, 2021

@barendgehrels I don't know what's heppening with the first one because the code is behind #ifndef BOOST_NO_CXX17_HDR_ANY. Maybe there is something wrong with clang-6 and we'd need a workaround. Are you setting -std?

Regarding the second one. This was already fixed: #878

@barendgehrels
Copy link
Collaborator Author

barendgehrels commented Jul 8, 2021

@barendgehrels I don't know what's heppening with the first one because the code is behind #ifndef BOOST_NO_CXX17_HDR_ANY. Maybe there is something wrong with clang-6 and we'd need a workaround. Are you setting -std?

Regarding the second one. This was already fixed: #878

I'm just calling b2 --toolset=clang and my clang version is clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
(I've also clang version 5.0.2 (tags/RELEASE_502/final) but that gives me other errors, and more)

@vissarion
Copy link
Member

@barendgehrels I don't know what's heppening with the first one because the code is behind #ifndef BOOST_NO_CXX17_HDR_ANY. Maybe there is something wrong with clang-6 and we'd need a workaround. Are you setting -std?
Regarding the second one. This was already fixed: #878

I'm just calling b2 --toolset=clang and my clang version is clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
(I've also clang version 5.0.2 (tags/RELEASE_502/final) but that gives me other errors, and more)

I am also getting something similar with gcc

gcc.compile.c++ ../../bin.v2/libs/geometry/test/algorithms/detail/algorithms_visit.test/gcc-5~c++14/debug/threading-multi/visibility-hidden/visit.o
In file included from test/algorithms/detail/visit.cpp:18:0:
../../boost/geometry/geometries/adapted/std_any.hpp:19:15: fatal error: any: No such file or directory
compilation terminated.

@awulkiew
Copy link
Member

awulkiew commented Jul 8, 2021

@barendgehrels @vissarion AFAIU C++17 headers support was added to Boost.Config in 1.76.
Which version of Boost.Config do you have?
When did you last update the whole Boost (all of the modules)?

@kleunen
Copy link

kleunen commented Jul 8, 2021

I have the following test case which was correct under the old version, but seems to be incorrect, after this patch:
https://wandbox.org/permlink/2zBpf9zFb1Uepu7n

@barendgehrels
Copy link
Collaborator Author

@barendgehrels @vissarion AFAIU C++17 headers support was added to Boost.Config in 1.76.
Which version of Boost.Config do you have?
When did you last update the whole Boost (all of the modules)?

@awulkiew ah, of course, sorry. Will update soon, it's long ago indeed.

@barendgehrels
Copy link
Collaborator Author

I have the following test case which was correct under the under the old version, but seems to be incorrect, after this patch:
https://wandbox.org/permlink/2zBpf9zFb1Uepu7n

Thanks! I will look at it soon

@awulkiew
Copy link
Member

awulkiew commented Jul 8, 2021

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?

@barendgehrels
Copy link
Collaborator Author

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

@barendgehrels
Copy link
Collaborator Author

I have the following test case which was correct under the under the old version, but seems to be incorrect, after this patch:
https://wandbox.org/permlink/2zBpf9zFb1Uepu7n

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).
It's a combination of complex input multipolygon - while the solved case is simple. So alternatively we can merge this already and (try to) fix it afterwards

@kleunen
Copy link

kleunen commented Jul 14, 2021

Wouter found a problem in another case, I’ve still to check that. Therefore it’s better to postpone it to 1.78

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.

@barendgehrels
Copy link
Collaborator Author

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()
Copy link
Collaborator Author

@barendgehrels barendgehrels Jul 14, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Sym difference may generate polygon with disconnected interior
4 participants