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

Thu Jan 16 13:54:34 GMT 2020

Hi Gerd, although quiet on this thread so far, I think that returning a
coded bitstring would be less than ideal. 

I suggest using something like the following:

is_in(all_inside) -> return true only if the whole object is inside the area
is_in(touching) -> return true if the object is either all inside, or some
of it is inside and some of it is touching
is_in(all_touching) -> return true if the object is all inside, or some
inside and some touching, or all touching
is_in(some_inside) -> return true if any of the object is inside
is_in(some_touching) -> return true if any of the object is inside or
touching

As you can see, the return values are cumulative, with a keyword returning
true for the preceding keywords and adding some extra, so for example
all_touching returns true for an object that has all its points touching the
area, as well as for an object that would return true for all_inside or for
touching.

The inverses might also be required as in:

is_out(all_outside) -> return true only if the whole object is outside the
area
is_out(touching) -> return true if the object is either all outside, or some
of it is outside and some of it is touching
is_out(all_touching) -> return true if the object is all outside, or some
outside and some touching, or all touching
is_out(some_outside) -> return true if any of the object is outside
is_out(some_touching) -> return true if any of the object is outside or
touching

I can't see any use for non-cumulative use (e.g. return true only if some of
it is inside and some of it is touching) , except for one case that possibly
might be useful:

is_in(coincident) -> returns true only if all points of the object match all
points of the area

However, if really required, one could always use something like
is_in(touching) & !is_in(all_inside) to handle very obscure cases.

I think this approach would give more useful functionality.

Regards,
Mike
-----Original Message-----
From: Gerd Petermann [mailto:gpetermann_muenchen at hotmail.com] 
Sent: 16 January 2020 10:22
To: Ticker Berkin <rwb-mkgmap at jagit.co.uk>; Development list for mkgmap
<mkgmap-dev at lists.mkgmap.org.uk>
Subject: 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