Hi Gerd The two most common cases that I imagine users will want to match are lines inside the polygon(s) and lines outside. Inside lines will frequently meet the edge, and I don't think these should fail the inside test. Outside lines will, less frequently, meet the edge, and I don't think these should fail the outside test. Often there will be 2 lines, joining at edge of the polygon, that make a continuous highway that is the entrance to the polygon. Both of these will have an ON component. So, the flag test for inside lines should be "hasIn && !hasOut" and for outside lines should be "hasOut && !hasIn". Expressing the outside test as the negative, in keeping with the is_in() methods expressing in-ness, it becomes "hasIn || !hasOut". I had expressed this as "hasIn || !(hasIn || hasOut)", because "!(hasIn || hasOut)" is all_ON, and this matches the method being called, ambiguously, ANY_IN_OR_ON (ON_OR_ANY_IN would have been better) but they are logically equivalent. This expressing as in-ness seems to be the cause of these problems we are discussing and maybe now is the time to abandon it. I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the method string "none", like SOME_IN_NONE_OUT is referenced as "all". Ticker On Mon, 2020-02-17 at 19:16 +0000, Gerd Petermann wrote:
Hi Ticker,
I would except +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside, none is in or on the edge.
Or name it +all_out+ - if is_in(...,all_out)=true, all is outside, none is in or on the edge.
A method that returns true when all is either out or on the edge could be called +out-or-on+
Gerd