[mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...]

Tue Dec 17 22:27:17 GMT 2019

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 <gpetermann_muenchen at hotmail.com>:
> 
> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> 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 <osm at pinns.co.uk>
>> Gesendet: Dienstag, 17. Dezember 2019 13:08
>> An: Gerd Petermann; mkgmap-dev at lists.mkgmap.org.uk
>> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>>> von Pinns UK <osm at pinns.co.uk>
>>> Gesendet: Dienstag, 17. Dezember 2019 11:53
>>> An: mkgmap-dev at lists.mkgmap.org.uk
>>> 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 < svn at mkgmap.org.uk<mailto:svn at mkgmap.org.uk>> 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
>>> mkgmap-dev at lists.mkgmap.org.uk<mailto:
>>> mkgmap-dev at lists.mkgmap.org.uk>
>>> 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
>>> mkgmap-dev at lists.mkgmap.org.uk<mailto:
>>> mkgmap-dev at lists.mkgmap.org.uk>
>>> 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
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev