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

Mon, 03 Feb 2020 08:56:21 -0800

Hi,

some ways are inside and outside a polygone. if the way is split at the border of the polygone, you get 2 ways, one complete in and one comlete out.

@gerd 
y/n is better for the first understanding :)

Greets
Arndt
Gerd Petermann < [email protected]> hat am 3. Februar 2020 um 15:58 geschrieben:


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 < [email protected]> im Auftrag von Gerd Petermann < [email protected]>
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 < [email protected]> im Auftrag von Ticker Berkin < [email protected]>
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
-tp5954103p5954828.html
________________________________________
Von: mkgmap-dev < [email protected]> im Auftrag
von jan meisters < [email protected]>
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:
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
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to