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

Mon Feb 3 14:58:32 GMT 2020

Hi all,

so far I got no further feedback reg. is_in results for nodes or polygons :(

Arndt wrote in a private mail that he would prefer a solution where the line or polygon is split so that the parts do not cross the boundary. If that's not possible he would be happy with the 001...111 solution.

Instead of is_in(x,y,any)=true you would write is_in(x,y) ~ '1..'
Instead of is_in(x,y,any)=false you would write is_in(x,y) ~ '0..'
Instead of is_in(x,y,all)=true you would write is_in(x,y) ~ '1.0'
Instead of is_in(x,y,all)=false you would write is_in(x,y) ~ '0..'

Or should I use y and n (yes/no) instead of 1 and 0 to make clear that these are flags and not numbers?
Probably easier to understand.
The problem regarding polygons which are inners of multipolygons would remain unsolved:
is_in(landuse,residential)='010' doesn't tell you if your polygon is on the outer ring or on the inner ring of a multipolygon, although inner is more likely.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Donnerstag, 16. Januar 2020 11:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

Hi all,

For a single point we can compute 'inside', 'on boundary', or 'outside'.

reg. the results and the method options I thought about a very different alternative:
Instead of true or false the function might return a bit string containing three digits, e.g. 001
- 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one point inside found"
- 2nd bit 0 means "no point on boundary found", 1 means "at least one point on boundary found"
- 3rd bit 0 means "no point outside found", 1 means "at least one point outside" found
We can describe 2^3 combinations with that, but obviously the combinations 000 and 101 are impossible,  so we have the 6 cases on Tickers list
as
1: all of the line is outside the polygon -> 001
2: some of the line is outside and the rest touches or runs along the polygon edge -> 011
3: all of the line runs along the polygon edge -> 010
4: some of the line is inside and the rest touches or runs along -> 110
5: all of the line is inside the polygon 100
6: some is inside and some outside the polygon. Obviously some point is on -> 111

This would allow to remove the 3rd parameter, but user has to remember the order of the bits when writing the style rules.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Donnerstag, 16. Januar 2020 10:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev