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@hotmail.com] Sent: 16 January 2020 10:22 To: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev