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

Tue Jan 14 22:38:03 GMT 2020

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

> Am 12.01.2020 um 09:58 schrieb Gerd Petermann <gpetermann_muenchen at hotmail.com>:
> 
> Hi all,
> 
> the message "SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON" was produced for this node:
> https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529 <https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529>
> 
> The node is extremely close to the landuse=residential way 255452457. In OSM precision the node is inside the residential area, but in mkgmap precision it is outside.
> These special cases really cause trouble. To improve performance, the code first tests the result for the first point. If this result is IN and method is 'any' or when result is OUT and method is 'all' there should be no need to test any further nodes or edges, thus the corresponding result is returned.
> Now, with these special cases the quick result may be wrong.
> With r4116 I've disabled the quick test. The result is more likely to be correct but performance can be poor when complex areas are involved.
> 
> For normal cases the difference should be small, maybe a second per tile.
> 
> Gerd
> 
> 
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Arndt Röhrig <arndt at speichenkarte.de <mailto:arndt at speichenkarte.de>>
> Gesendet: Samstag, 11. Januar 2020 12:02
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
> 
> Good morning,
> 
> so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great.
> 
> I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc.
> 
> Thank you all for this work!
> 
> Problem #1:
> is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either.
> I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea?
> https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png
> 
> Problem, #2:
> r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON
> https://speichenkarte.de/88002007.osm.pbf
> 
> 
> greetings
> 
> Arndt
> 
> 
> 
> Gerd Petermann < gpetermann_muenchen at hotmail.com <mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com <mailto:gpetermann_muenchen at hotmail.com>>> hat am 10. Januar 2020 um 12:07 geschrieben:
> 
> 
> Hi Ticker,
> 
> thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 <http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412>
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev < mkgmap-dev-bounces at lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Ticker Berkin < rwb-mkgmap at jagit.co.uk <mailto:rwb-mkgmap at jagit.co.uk><mailto:rwb-mkgmap at jagit.co.uk <mailto:rwb-mkgmap at jagit.co.uk>>>
> Gesendet: Freitag, 10. Januar 2020 11:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
> 
> Hi Gerd
> 
> Here is patch that sets isLineRule in the package on the augmentsWith
> call.
> 
> I've also used default method for the augmentsWith... in Rule, Op,
> OsmConverter and backed out the changes that have now become
> unnecessary.
> 
> Ticker
> 
> On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote:
> Hi Ticker,
> yes, it would probably be better to know if the function is for a
> polyline or polygon. A patch would be welcomed.
> And yes, the expected result for the case you describe is not yet
> clear. See b13 and b14 in my example file.
> Gerd
> ________________________________________
> Von: mkgmap-dev < mkgmap-dev-bounces at lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag
> von Ticker Berkin < rwb-mkgmap at jagit.co.uk <mailto:rwb-mkgmap at jagit.co.uk><mailto:rwb-mkgmap at jagit.co.uk <mailto:rwb-mkgmap at jagit.co.uk>>>
> Gesendet: Freitag, 10. Januar 2020 09:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
> Hi Gerd
> I think the logic still needs to know if it is handling a closed way
> as
> a polygon rule or as a line rule.
> Firstly to be able to correctly handle the case where the rule.way
> runs
> around a hole in the target.polygon - all of the rule.line is in the
> target, but only part of the rule.polygon is in the target.
> Also there might be different method keywords for the two. For
> polygon
> rules, "any" and "all" are adequate, but for line rules others might
> be
> required.
> I've just svn updated the is_in branch. Is there still work to do on
> non-closed ways?
> Otherwise amazing.
> Ticker
> On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:
> Hi all,
> the branch version r4408 implements the style function is_in with
> three parameters tag-key,tag-value,method
> - tag-key can be something like landuse or natural or amenity
> - tag-value would be the expected value for that tag-key
> - method has to be "any" or "all".
> Example usage in lines:
> # no cycling within a cemetery
> highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add
> bicycle=dismount}
> Before any style rule is evaluated the function evaluates the list
> of
> all ways found in the input file. When a way matches the given tag
> (key+value) and is closed and complete the shape geometry is stored
> in a spatial index.
> With the current implementation this index is created for
> appearance
> of the is_in function in a style rule (subject to optimization)
> When the style function is called it retrieves the stored shape(s)
> which intersect the boundary of the element.
> If none is found "false" is returned.
> If there are multiple such shapes the are merged where possible, so
> that overlapping or touching shapes are combined to a single shape
> which may include holes.
> The list of (outer) shapes is then tested one after the other until
> one shape is found which either contains the element completely or
> -
> when "any" is used as method - partially. If none is found the
> value
> "false" is returned.
> If a match is found and the combined shapes have holes, a final
> test
> is done to find out if the element is within the hole.
> If method "any" is used and the shape is completey within one hole
> "false" is returned.
> If method "all" is used and the shape is partly within one hole
> "false" is returned.
> If we get here true is "returned"
> I've also slightly changed the behaviour of the LocationHook and
> the
> ResidentialHook. The results should be a bit more predictable now
> as
> searches are done with higher precsion. Still, both try to find a
> nearby boundary(shape) if none is found at the exact position.
> The ResidentialHook is now automatically disabled when the style
> doesn't use mkgmap:residential anywhere.
> TODO:
> - various possible special cases need more testing
> - maybe add more methods for cases where parts of the tested
> element
> touch the boundary of the shape.
> - tuning
> - unit tests
> As always with branch version the binary can be found at the bottom
> of the download page.
> http://www.mkgmap.org.uk/download/mkgmap.html <http://www.mkgmap.org.uk/download/mkgmap.html>
> I've tested this with the example file posted before, accept for
> b18
> all cases work as expected.
> Gerd
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk <mailto:mkgmap-dev at lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200114/6f23989d/attachment-0001.html>