Barend Gehrels wrote:

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.

So yes 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?