Hi all, with r4398 I've reverted the changes from r4397. This needs much more effort to work as wanted. Even with the complete patch posted yesterday the results are only a good guess. For exact results we need very different algorithms and data structures, esp. it is not (yet) possible to find out if a node is on the boundary of a polygon. So, I think we should collect a few special cases first and try to find a common decision about the expected result. I'd try to put them into a unit test and maybe we find code that works.
Gerd ________________________________________ Von: mkgmap-dev <[email protected]> im Auftrag von jan meisters <[email protected]> Gesendet: Dienstag, 17. Dezember 2019 23:27 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...] Hi all, while testing up to r4397 with is-in I had a lot of erratic results, most of them due to overlapping or area-crossings. So - if reasonable - I opt for Tickers approach. Jan > Am 17.12.2019 um 19:39 schrieb Gerd Petermann > <[email protected]>: > > Hi Ticker, > > I can draw two triangles A and B in such a way that they are overlapping but > no point of A is in B and no point of B is in A. > > Of course I can also draw an unclosed straight way which lies almost > completely within an area but endpoints are outside. > So, as long as we don't perform much more complex tests we just get a good > guess. > > So, for a precise result I would not want to do the calculation for all > elements just in case the style might ask for it. > > Gerd > > ________________________________________ > Von: mkgmap-dev <[email protected]> im Auftrag von > Ticker Berkin <[email protected]> > Gesendet: Dienstag, 17. Dezember 2019 18:05 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option > --is-in-landuse=value[, value...] > > Hi Gerd > > I was thinking it would be slow to do the full test and I've seen your > summary of what you've implemented and have no problem with it. > > The meaning with either being multiPolygons would be almost impossible > to define, but otherwise I'd define it as such: > > Point: if within or on edge then IN otherwise OUT. > > Way/polygons: if all points are outside or on edge, then OUT, if some > are inside and some outside then STRADDLE, otherwise, ie at least 1 > point is inside, IN > > Ticker > > On Tue, 2019-12-17 at 13:32 +0000, Gerd Petermann wrote: >> Hi Ticker, >> >> I agree it would be good to know. >> Problem: it would require a completely different implementation and >> probably a lot more CPU power to compute that information. >> >> The current test is very lazy, it works like the one for the >> mkgmap:admin_level tags. It computes a single point that represents >> the OSM element >> and checks if that point is within or on the boundary of any >> landuse=x polygon. I think that was OK for the original problem >> (building inside landuse=residential), >> but it was already problematic with the idea to set a maxspeed value >> for a major highway "inside" a residential area. >> >> So, what results do we get? >> - A point is either outside, inside or on the boundary of a polygon. >> - A line or polygon can be outside, inside, on the boundary or partly >> overlapping a single polygon. What would be the result for a way that >> builds a part of the boundary of two natural=wood multipolygons? What >> would be the result when the way crosses such a boundary, but is >> always inside one of the natural=wood polygons? Also, a way can be >> inside one polygon and partly inside another, as OSM allows >> overlapping polygons. >> Think of a landuse=forest multipolygon with an inner way >> natural=water . Is the inner way inside, outside or on the boundary? >> Remenber, the hook doesn't "see" the multipolygon, it processes the >> results of the MultipolygonCutter. >> >> For JOSM I've implemented some area operators like a inside b or vice >> versa, also a not inside b, but they only work on nodes and polygons, >> and they are rather slow. >> See https://josm.openstreetmap.de/ticket/10391 >> I assume you have something similar in mind? >> >> Gerd >> >> >> >> >> ________________________________________ >> Von: Pinns UK <[email protected]> >> Gesendet: Dienstag, 17. Dezember 2019 13:08 >> An: Gerd Petermann; [email protected] >> Betreff: Re: AW: [mkgmap-dev] Commit r4397: implement and document >> new option --is-in-landuse=value[, value...] >> >> Hi Gerd >> >> That would be very useful >> >> r >> >> Nick >> >> On 17/12/2019 11:15, Gerd Petermann wrote: >>> Hi Nick, >>> >>> OK, I already expected this when I asked if landuse is enough... >>> I'll add code to support all polygons and see how to document it. I >>> guess it should be no problem when I revert the changes in r4397. >>> >>> Gerd >>> >>> ________________________________________ >>> Von: mkgmap-dev <[email protected]> im Auftrag >>> von Pinns UK <[email protected]> >>> Gesendet: Dienstag, 17. Dezember 2019 11:53 >>> An: [email protected] >>> Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new >>> option --is-in-landuse=value[, value...] >>> >>> Hi Gerd, >>> >>> Oops, I forgot to look at the documentation! >>> >>> Personally , I think it is such a useful option which will open up >>> a host of new possibilities when/if you are able to extend this to >>> include all polygons. >>> >>> Again, thanks for all your hard work! >>> >>> Nick >>> >>> On 17/12/2019 09:42, Pinns UK wrote: >>> >>> Hi Gerd >>> >>> I've been able to change footpaths on (some?) amenity graveyards >>> to paths by just setting the lu:cemetery to yes >>> >>> I first tried : >>> >>> amenity=grave_yard {set landuse=cemetry;echotags"change2landuse"} >>> >>> mkgmap:lu:cemetery=* & highway=footway {set highway=path} >>> >>> >>> however this did not work , ie footpaths on cemeteries didn't >>> change to paths and the echotags didn't show any :lu:cemetery >>> >>> then I tried >>> >>> amenity=grave_yard {set mkgmap:lu:cemetery=yes} >>> >>> mkgmap:lu:cemetery=* & highway=footway {set highway=path} >>> >>> This seems to work for some (?) graveyards (Haven't checked this >>> on 2 graveyards only) >>> >>> My question is ,does mkgmap check if highways cross a polygon as >>> soon as it parses mkgmap:lu:cemetery=* & highway=footway >>> >>> or are the checks done before 'Lines' are parsed? >>> >>> If the user can set the value then what ,if any ,are the effects - >>> ie >>> >>> natural=wood { set mkgmap:lu:cemetery=yes} >>> >>> If this works then Arndt seems to have a point? >>> >>> r >>> >>> Nick >>> >>> >>> Does mkgmap check if graveyard >>> >>> On 15/12/2019 12:28, Arndt Röhrig wrote: >>> is-in-landuse, nice function! >>> >>> with this new option i set acces=no for bicycles when the way is >>> within a cemetary. (& no tag say, that bicycle is ok) >>> >>> There are still a few polys where that could be used. >>> amenity=grave_yard, amenity=hospital, leisure=pitch .... >>> >>> maybe its better to name the option is-in-polygone:polygone=value >>> >>> Arndt >>> >>> >>> >>> svn commit < [email protected]<mailto:[email protected]>> hat am >>> 15. Dezember 2019 um 10:05 geschrieben: >>> >>> >>> Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019 >>> >>> implement and document new option --is-in-landuse=value[,value...] >>> - svn rename ResidentialHook.java to LanduseHook.java >>> - remove support for undocumented option --residential-hook=false >>> - warn if style uses mkgmap:residential which was replaced by >>> mkgmap:lu:residential >>> >>> >>> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=439 >>> 7 >>> _______________________________________________ >>> mkgmap-dev mailing list >>> [email protected]<mailto: >>> [email protected]> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> On 15/12/2019 09:05, svn commit wrote: >>> >>> Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019 >>> >>> implement and document new option --is-in-landuse=value[,value...] >>> - svn rename ResidentialHook.java to LanduseHook.java >>> - remove support for undocumented option --residential-hook=false >>> - warn if style uses mkgmap:residential which was replaced by >>> mkgmap:lu:residential >>> >>> >>> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=439 >>> 7 >>> _______________________________________________ >>> mkgmap-dev mailing list >>> [email protected]<mailto: >>> [email protected]> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >>> >>> >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> [email protected]<mailto: >>> [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 _______________________________________________ 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
