logo separator

[mkgmap-dev] Work on is_in branch

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Feb 17 19:16:00 GMT 2020

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

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 17. Februar 2020 19:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

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
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list