Hi Gerd A simpler way of expressing it in the Style Manual would be:
+any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside, none is inside. What do you think? An alternative would be to re-phrase the keyword as something like 'some-out-none-in', testing for =true instead. But, with the function being called 'is_in', I wanted to have the methods expressing IN'ness as far as possible. Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5% for 'on' and ~1% for all. It just seems easy and sensible to stop when, if asking for 'any', a part is found IN, or, if asking for 'all', a part is found OUT, etc Ticker On Mon, 2020-02-17 at 17:13 +0000, Gerd Petermann wrote: > Hi Ticker, > > reg. result: > Please find a better explanation for this: > "This is useful for the negative - is_in(...,any_in_or_on)=false - > for processing a line that is outside the polgon(s) but might touch > an edge." > For me this sounds plain wrong. It would be okay without "but might > touch an edge". > > reg. performance: > I did not mean to remove early stop completely, I just don't believe > that it is worth to distinguish the different methods. > My original code also stops early when result is 7 (IN+ON+OUT). > > reg. special case b14: one reason why I don't like my code. It's > frustrating. OTOH nobody seems to care about the results for > polygons. > > Gerd _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
