Boost.Geometry should follow the specs here. See my previous
email, Adam is right here.
About my proposed solution, it then should obviously also take the
turn-info into account... The file most documenting the turns is
probably get_turn_info.ppt in doc/other/test_cases (of trunk),
where most (or all) possible situations are clearly visualized.
Besides that you might look at the traverse.cpp unit test,
defining TEST_WITH_SVG. It then creates an SVG showing all turns
with turn-info in the SVG. For example
traverse_intersection_11_d.svg (but there are more)
Thanks for this! It'd be a lot harder if I had to analyze the code
and test how things work by myself.
now I completely understand you looking at touch (thanks for the
fix), which is similar but there a turn may only turn at the
outside, while here it may only turn at the inside.
I'm currently analyzing the examples trying to figure out which
combination of methods and operations will be good for within(). I
hope it will be sufficient to analyze it locally (not taking other
turns/points into account), like in the case of touch(). There is a
lot of special cases, like this one:
What do think we should do with self-intersecting polygons? This is
slightly modified traverse_intersection_52:
Is the blue polygon within the green one?