[mkgmap-dev] Branch is_in ready for a first test

Thu Jan 16 09:48:36 GMT 2020

Hi

My earlier postings were to get an idea of what was wanted regarding
combinations of IN/ON/OUT for 'lines' and also what was reasonable to
implement.

I didn't like some of the method keywords that I had suggested either.

The advantages of the keyword, even if ugly/unwieldy, to say what is
wanted for the different 'line' cases, over a 'details' option are
that:
- for many methods, optimisation is possible (ie can stop early, handle
the target polygons one-by-one, etc)
- the result of the 'details' would probably have to be some ugly
composite string, maybe requiring a regex test to decipher.

My summary:

For 'polygons', methods 'all' and 'any' cover the requirements.

'points' hasn't been discussed. Are methods for IN, IN or ON, ON
needed? If so, what keywords to use; 'any' and 'all' are wrong...

'lines', as per 04-Jan posting with Jan's alternative.

a) some-in-none-out	IN and not OUT
b) all-in-or-on		(IN or ON) and not OUT 
c) all-on		ON and not (OUT or IN)
d) any-in		IN
e) any-in-or-on		IN or ON

So, are all cases required and what keywords to use?

'all' could be used for a) or b), but with the function being called is
-in, it would more naturally apply to a). Likewise 'any' for d) rather
than e).

Ticker

On Wed, 2020-01-15 at 06:38 +0000, Gerd Petermann wrote:
> Hi Jan,
> 
> thanks for testing.
> Reg. the ways: Yes, that's an error. I'll have a look at it.
> Reg. your rules: I would add the clause & isin!=* in the 2nd rule to
> avoid a 2nd execution of the is_in function.
> Reg. ON:
> The current implementation of is_in accepts only 'all' or 'any'. I
> think we can also detect the cases 2 and 3 on Tickers list (1) but I
> didn't like the suggested method 'all-on' in combination with the
> function name is_in and I did not yet find a better alternative.
> An alternative I was thinking about is to implement a 'details'
> option which might return one of the values in Tickers list. We just
> have to define values for points and polygons, as Tickers list is
> only for rules in lines.
> 
> Gerd
> (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook
> -tp5954103p5954828.html
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von jan meisters <jan_m23 at gmx.net>
> Gesendet: Dienstag, 14. Januar 2020 23:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
> 
> Hi Gerd, hi Ticker,
> 
> sorry for the delay, until the weekend I didn´t found time to test
> the new versions.
> 
> I´m very impressed, my results now are so precise that I could revert
> all the gaps I created for the first hook.
> Many thanks for all your efforts to realize this accuracy!
> 
> Still I´m only on lines inside cemetery/allotments, so I have no clue
> about the buildings in v4 samples, sorry.
> 
> I check for „all“ and for „any“, giving two new values and then
> reduce them to one if another match, ie:
> highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1}
> highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2}
> highway=* & isin=1 {set highway=path}
> highway=* & isin=2 bicyle=no {set highway=path}
> 
> That works as I expect: reduce all-in, and any-in only if specified.
> I didn´t understood yet : could ON still be a value to ask for, 
>  beside IN and OUT?
> Or has it become obsolete? In anyway, with my rule above I see no
> complaint about it.
> 
> Only one unclear example so far I found - probably caused by the
> multipolygon?
> The first line is not matched by the any-rule, but the second is.
> Both should match according to style:
> https://www.openstreetmap.org/way/117416117
> https://www.openstreetmap.org/way/117416120
> 
> As said, only one. With is_in render time is increased by only 5-10%,
> pretty cheap.
> Thanks to all for the ideas read here how to play with this wonderful
> new option.
> 
> Jan