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@mkgmap.org.uk <mailto:svn@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi What needs to be clarified is if the way, possibly closed, has to be fully within the specified area, or just partially. Maybe this can be represented as the value of the the created mkgmap:{areaTag}:{areaValue} tag. Ticker On Tue, 2019-12-17 at 11:15 +0000, 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@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 11:53 An: mkgmap-dev@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@mkgmap.org.uk<mailto:svn@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 13:08 An: Gerd Petermann; mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 11:53 An: mkgmap-dev@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@mkgmap.org.uk<mailto:svn@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, attached is the complete patch which keeps the basic logic. To fix the problem with insideness it tests now first if the center is within a polygon, if yes, it tests all other points. If any of them is not inside or on the boundary the special tag is not added, so this is slower. For unclosed ways, still only the (n/2) th point is checked. The option is now described as --is-in-hook=tag[,tag...] Tells mkgmap to calculate a tag for each area with the given key=value tag. Allows to identify eg. buildings within a landuse=residential or ways within a landuse=cemetery. If an element is within the given landuse area, the information is stored in special tags with prefix mkmap:is-in:. Example: If you specify --is-in-hook=landuse=cemetery and an element is within a landuse=cemetery polygon mkgmap adds the tag mkgmap:is-in:landuse-cemetery=x where x is either "yes" or the name of the cemetery. The program builds a spatial index for each listed tag to be able to compute this information before the style rules for nodes and ways are applied. The default for this option is landuse=residential. To disable the processing use --no-is-in-hook or an empty list of tags. If the style uses the tag mkgmap:residential which was set by earlier versions of mkgmap a warning is printed and the old tag is generated. If I hear no complains I'll commit this tomorrow. ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 17. Dezember 2019 15:40 An: Pinns UK; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...] Hi all, I've implement a quick hack to change -is-in-landuse option to -is-in-hook. My first test already showed the problem with the lazyness of the test: I used it with this --x-is-in-hook="landuse=cemetery,amenity=grave_yard, amenity=hospital, leisure=pitch" and a rule mkgmap:is-in:leisure-pitch=* {echotags "x"} and got (besides others) Way 103535225 [leisure=park, mkgmap:admin_level2=DEU, mkgmap:admin_level4=Niedersachsen, mkgmap:admin_level6=Landkreis Oldenburg, mkgmap:admin_level8=Wildeshausen, mkgmap:is-in:leisure-pitch=yes, mkgmap:postcode=27793, surface=grass] I wondered why a park is inside a pitch. And it is not, only its centre is because the pitch is inside the park. Of course the same problem occurs with r4397, so I have to change the code to test more (maybe all points), not just the center. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Dienstag, 17. Dezember 2019 14:32 An: Pinns UK; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...] 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@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 13:08 An: Gerd Petermann; mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 11:53 An: mkgmap-dev@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@mkgmap.org.uk<mailto:svn@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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=4397 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> 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 <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 13:08 An: Gerd Petermann; mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Dienstag, 17. Dezember 2019 11:53 An: mkgmap-dev@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@mkgmap.org.uk<mailto:svn@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@lists.mkgmap.org.uk<mailto: mkgmap-dev@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@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev