Re: [mkgmap-dev] Use of is_in in style

Hi all, I plan to document new option --is-in-landuse like this: --is-in-landuse=value[,value...] Tells mkgmap to calculate a tag for each given landuse area. 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:lu:. Example: If you specify --is-in-landuse=cemetery and an element is within a landuse=cemetery polygon mkgmap adds the tag mkgmap:lu:cemetery=x where x is either "yes" or the name of the cemetery. The program builds a spatial index for each listed landuse value to be able to compute this information before the style rules in lines and points are applied. The default for this option is residential. To disable the processing use --no-is-in-landuse or an empty list of values. 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. Please suggest improvements. I really had trouble to decide what to do with old styles using mkgmap:residential. The patch implements compatibility combined with a warning message to adapt the style. This allows to keep the style for a while. When the change is committed the old undocumented option --x-residential-hook=false is ignored with a corresponding warning. TODO: document the changes in the style manual. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Dezember 2019 16:20 An: jan meisters Betreff: AW: [mkgmap-dev] Use of is_in in style Hallo Jan, der patch hat den Code nicht dupliziert, sondern erweitert/verallgemeinert. Der Code ist auch nicht das Problem, sondern die Kompatibilität mit vorhandenen Styles und die Dokumentation. Ich kann auch mkgmap:landuse:xxx anstelle von mkgmap:is-in:xxx generieren. Wichtig ist mir dabei, dass - alle auf diese Art generierten Tags den gleichen Prefix haben und - auf keinen Fall andere bereits dokumentierte Tags "überschreiben" können Letzteres ist ein eher akademisches Problem, aber stell Dir vor, es gäbe ein landuse=street und jemand würde dass dann auswerten wollen. Ohne extra prefix hätten wir dann evtl. einen unsinnigen Inhalt wie "yes" in dem Tag, der eigentlich einen Straßennamen angibt. Wenn ich also aus mkgmap:residential jetzt ein mkgmap:landuse:residential mache, dann funktionieren alte Styles nicht mehr. Ein Kompromiss wäre, alle neuen Tags mit Prefix mkgmap:landuse: zu versehen und bei residential nur mkgmap: Das könnte ich dann auch irgendwie sinnvoll dokumentieren bei den "mkgmap internal tags" im Style manual. Gerd ________________________________________ Von: jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 13. Dezember 2019 16:00 An: Gerd Petermann Betreff: Re: [mkgmap-dev] Use of is_in in style Hallo Gerd, ich bin nicht sicher, ob ich das Problem richtig verstanden habe ;-) Du hattest, glaube ich, den Code von mkgmap:residential dupliziert, um damit landuse abfragen zu können. Aber eigentlich bräuchte man neuen Code für eine neue „Kategorie“ wie z.Bsp. mkgmap:is-in:, um diese, abgegrenzt von mkgmap:residential, über landuse hinaus abfragen zu können? Würde es denn helfen, wenn man Key und Tag für die neue Option zusammenfasst, also etwa mkgmap:landuse=cemetery? Sorry, mehr gibt meine Code-Unkenntnisse nicht her … Ich habe aber inzwischen ein lines-file angepasst, um cemetery und allotments sinnvoll „downzugraden“, ohne dabei zu viele Informationen zu zerstören. Idee war ja, diese oft mit Wegen überfrachteten und manchmal erratisch getaggten Gebiete von Hervorhebungen für Radfahrer (vehicle=no, cycle=yes, etc.) auszuschliessen. Das wurde zwar komplizierter als gedacht, und ist mit Kompromissen behaftet: Wege, die Gebietsgrenzen kreuzen, sind u.U. auch betroffen. Leider auch Wege, die die Gebiete nur schneiden. Das ist zwar unsauberer Zeichnung in OSM geschuldet, aber dennoch blöd. Dennoch: so, wie es ist, funktioniert es klasse - für mich immerhin. Missen möchte ich es eigentlich auch nicht mehr. Und bislang ist mir noch kein Gedanke gekommen, auch andere Keys wie z.Bsp. leisure oder amenity nutzen zu können. Andere mögen das aber wollen - also verstehe ich Dich, wenn Du das vor der Dokumentation sauber ausgearbeitet haben möchtest. Wirst Du —x-is-in denn vorher schon in der bestehenden Form in den releases belassen? Mich würds freuen. Schöne Grüße! Jan Am 10.12.2019 um 11:24 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>: Hi Jan, thanks for the quick feedback. I am not yet sure about the prefix for those calculated tags. Maybe I change it from mkgmap: to mkgmap:is-in: so that I can document this prefix in the style manual. A separate name space is probably better. Problem is the existing mkgmap:residential which would then be mkgmap:is-in:residential. Existing styles would no longer work. I'll think about this, any suggestions are welcomed... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23@gmx.net<mailto:jan_m23@gmx.net>> Gesendet: Dienstag, 10. Dezember 2019 11:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Gerd, thanks a lot! I tried the binary with the new option and it works exactly as I want it. To the .args-file I added x-is-in-landuse=residential,cemetery,industrial and to the beginning of lines highway=* & mkgmap:cemetery=* {set highway=path} Result is, as expected, the unified representation of lines inside the asked landuse. Other landuse-tags seem to work as well, I also played with allotments successfully: —x-is-in-landuse=residential,cemetery,allotments,industrial So, even with this „rough“ approach only for landuse, it´s a huge step ahead. Hopefully the option will remain in later releases. Unfortunately, me either am not able to dig into code to generalize the function. Jan Am 09.12.2019 um 17:28 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>>: Hi Jan, sorry, I compiled the binary before removing some debug code. Here is a clean one: http://files.mkgmap.org.uk/download/459/mkgmap.jar Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 16:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Jan, attached source could replace ResidentialHook. It implements new option --x-is-in-landuse so that one can use e.g. --x-is-in-landuse=residential,cemetery,industrial Without any option it works like the old ResidentialHook. For each given value, mkgmap checks if an element is inside a landuse with that value, if so, it adds the corresponding tag like mkgmap:residential or mkgmap:industrial This is all done before the style rules are executed, so all calculations are done for all elements. With a bit more work I can also add other polygon tags like natural=* or place=* but it would probably slow down mkgmap and require a lot more heap. A binary compiled with this is source is here: http://files.mkgmap.org.uk/download/458/mkgmap.jar Please try if it works for you. I'd prefer to have a general style function like is_in which could be used with is_in(landuse=cemetery) or is_in(natural=wood) but I have no idea how to implement the syntax parser etc. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 14:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Jan, the result of the is_in discussion was the ResidentialHook which computes the special tag mkgmap:residential. It would be possible to duplicate the code to calculate also a tag for landuse=cemetary. Not sure if that makes sense? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net> <jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net>> Gesendet: Montag, 9. Dezember 2019 13:15 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Use of is_in in style Can mkgmap use is_in to filter out objects inside specific (multi)polygons? In my case I´d like to unify ways inside cemeteries/grave-yards, e.g. highway=* & is_in:landuse=cemetery {set highway=path} Check-styles isn´t complaining of the syntax, but the rule has no effect. Similar has been discussed here, but without particular answer: http://gis.19327.n8.nabble.com/is-in-filter-td5890564.html#a5890836 Thanks _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <LanduseHook.java>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd This looks fine, but shouldn't the option change be to doc/options.txt rather than resources/help/options/en/options? Ticker On Sat, 2019-12-14 at 11:04 +0000, Gerd Petermann wrote:
Hi all,
I plan to document new option --is-in-landuse like this: --is-in-landuse=value[,value...] Tells mkgmap to calculate a tag for each given landuse area. 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:lu:. Example: If you specify --is-in-landuse=cemetery and an element is within a landuse=cemetery polygon mkgmap adds the tag mkgmap:lu:cemetery=x where x is either "yes" or the name of the cemetery. The program builds a spatial index for each listed landuse value to be able to compute this information before the style rules in lines and points are applied. The default for this option is residential. To disable the processing use --no-is-in-landuse or an empty list of values. 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.
Please suggest improvements. I really had trouble to decide what to do with old styles using mkgmap:residential. The patch implements compatibility combined with a warning message to adapt the style. This allows to keep the style for a while. When the change is committed the old undocumented option --x -residential-hook=false is ignored with a corresponding warning.
TODO: document the changes in the style manual. Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Dezember 2019 16:20 An: jan meisters Betreff: AW: [mkgmap-dev] Use of is_in in style
Hallo Jan,
der patch hat den Code nicht dupliziert, sondern erweitert/verallgemeinert. Der Code ist auch nicht das Problem, sondern die Kompatibilität mit vorhandenen Styles und die Dokumentation. Ich kann auch mkgmap:landuse:xxx anstelle von mkgmap:is-in:xxx generieren. Wichtig ist mir dabei, dass - alle auf diese Art generierten Tags den gleichen Prefix haben und - auf keinen Fall andere bereits dokumentierte Tags "überschreiben" können Letzteres ist ein eher akademisches Problem, aber stell Dir vor, es gäbe ein landuse=street und jemand würde dass dann auswerten wollen. Ohne extra prefix hätten wir dann evtl. einen unsinnigen Inhalt wie "yes" in dem Tag, der eigentlich einen Straßennamen angibt.
Wenn ich also aus mkgmap:residential jetzt ein mkgmap:landuse:residential mache, dann funktionieren alte Styles nicht mehr. Ein Kompromiss wäre, alle neuen Tags mit Prefix mkgmap:landuse: zu versehen und bei residential nur mkgmap:
Das könnte ich dann auch irgendwie sinnvoll dokumentieren bei den "mkgmap internal tags" im Style manual.
Gerd
________________________________________ Von: jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 13. Dezember 2019 16:00 An: Gerd Petermann Betreff: Re: [mkgmap-dev] Use of is_in in style
Hallo Gerd,
ich bin nicht sicher, ob ich das Problem richtig verstanden habe ;-) Du hattest, glaube ich, den Code von mkgmap:residential dupliziert, um damit landuse abfragen zu können. Aber eigentlich bräuchte man neuen Code für eine neue „Kategorie“ wie z.Bsp. mkgmap:is-in:, um diese, abgegrenzt von mkgmap:residential, über landuse hinaus abfragen zu können?
Würde es denn helfen, wenn man Key und Tag für die neue Option zusammenfasst, also etwa mkgmap:landuse=cemetery? Sorry, mehr gibt meine Code-Unkenntnisse nicht her …
Ich habe aber inzwischen ein lines-file angepasst, um cemetery und allotments sinnvoll „downzugraden“, ohne dabei zu viele Informationen zu zerstören. Idee war ja, diese oft mit Wegen überfrachteten und manchmal erratisch getaggten Gebiete von Hervorhebungen für Radfahrer (vehicle=no, cycle=yes, etc.) auszuschliessen. Das wurde zwar komplizierter als gedacht, und ist mit Kompromissen behaftet: Wege, die Gebietsgrenzen kreuzen, sind u.U. auch betroffen. Leider auch Wege, die die Gebiete nur schneiden. Das ist zwar unsauberer Zeichnung in OSM geschuldet, aber dennoch blöd. Dennoch: so, wie es ist, funktioniert es klasse - für mich immerhin. Missen möchte ich es eigentlich auch nicht mehr.
Und bislang ist mir noch kein Gedanke gekommen, auch andere Keys wie z.Bsp. leisure oder amenity nutzen zu können. Andere mögen das aber wollen - also verstehe ich Dich, wenn Du das vor der Dokumentation sauber ausgearbeitet haben möchtest.
Wirst Du —x-is-in denn vorher schon in der bestehenden Form in den releases belassen? Mich würds freuen.
Schöne Grüße! Jan
Am 10.12.2019 um 11:24 schrieb Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>:
Hi Jan,
thanks for the quick feedback. I am not yet sure about the prefix for those calculated tags. Maybe I change it from mkgmap: to mkgmap:is -in: so that I can document this prefix in the style manual. A separate name space is probably better. Problem is the existing mkgmap:residential which would then be mkgmap:is-in:residential. Existing styles would no longer work. I'll think about this, any suggestions are welcomed...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23@gmx.net<mailto:jan_m23@gmx.net>> Gesendet: Dienstag, 10. Dezember 2019 11:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Gerd,
thanks a lot! I tried the binary with the new option and it works exactly as I want it.
To the .args-file I added x-is-in-landuse=residential,cemetery,industrial and to the beginning of lines highway=* & mkgmap:cemetery=* {set highway=path}
Result is, as expected, the unified representation of lines inside the asked landuse. Other landuse-tags seem to work as well, I also played with allotments successfully: —x-is-in-landuse=residential,cemetery,allotments,industrial
So, even with this „rough“ approach only for landuse, it´s a huge step ahead. Hopefully the option will remain in later releases. Unfortunately, me either am not able to dig into code to generalize the function.
Jan
Am 09.12.2019 um 17:28 schrieb Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>>:
Hi Jan,
sorry, I compiled the binary before removing some debug code. Here is a clean one: http://files.mkgmap.org.uk/download/459/mkgmap.jar
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 16:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Jan,
attached source could replace ResidentialHook. It implements new option --x-is-in-landuse so that one can use e.g. --x-is-in-landuse=residential,cemetery,industrial Without any option it works like the old ResidentialHook.
For each given value, mkgmap checks if an element is inside a landuse with that value, if so, it adds the corresponding tag like mkgmap:residential or mkgmap:industrial This is all done before the style rules are executed, so all calculations are done for all elements. With a bit more work I can also add other polygon tags like natural=* or place=* but it would probably slow down mkgmap and require a lot more heap. A binary compiled with this is source is here: http://files.mkgmap.org.uk/download/458/mkgmap.jar Please try if it works for you.
I'd prefer to have a general style function like is_in which could be used with is_in(landuse=cemetery) or is_in(natural=wood) but I have no idea how to implement the syntax parser etc.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 14:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Jan,
the result of the is_in discussion was the ResidentialHook which computes the special tag mkgmap:residential. It would be possible to duplicate the code to calculate also a tag for landuse=cemetary. Not sure if that makes sense?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net> < jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net>> Gesendet: Montag, 9. Dezember 2019 13:15 An: mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Use of is_in in style
Can mkgmap use is_in to filter out objects inside specific (multi)polygons?
In my case I´d like to unify ways inside cemeteries/grave-yards, e.g. highway=* & is_in:landuse=cemetery {set highway=path}
Check-styles isn´t complaining of the syntax, but the rule has no effect.
Similar has been discussed here, but without particular answer: http://gis.19327.n8.nabble.com/is-in-filter-td5890564.html#a5890836
Thanks _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <LanduseHook.java>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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, thanks for the feedback. We always change both files, one is for the help option in mkgmap, the other for the online help. I don't have a (windows) tool to generate the first using the second. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 19:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style Hi Gerd This looks fine, but shouldn't the option change be to doc/options.txt rather than resources/help/options/en/options? Ticker On Sat, 2019-12-14 at 11:04 +0000, Gerd Petermann wrote:
Hi all,
I plan to document new option --is-in-landuse like this: --is-in-landuse=value[,value...] Tells mkgmap to calculate a tag for each given landuse area. 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:lu:. Example: If you specify --is-in-landuse=cemetery and an element is within a landuse=cemetery polygon mkgmap adds the tag mkgmap:lu:cemetery=x where x is either "yes" or the name of the cemetery. The program builds a spatial index for each listed landuse value to be able to compute this information before the style rules in lines and points are applied. The default for this option is residential. To disable the processing use --no-is-in-landuse or an empty list of values. 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.
Please suggest improvements. I really had trouble to decide what to do with old styles using mkgmap:residential. The patch implements compatibility combined with a warning message to adapt the style. This allows to keep the style for a while. When the change is committed the old undocumented option --x -residential-hook=false is ignored with a corresponding warning.
TODO: document the changes in the style manual. Gerd
________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Dezember 2019 16:20 An: jan meisters Betreff: AW: [mkgmap-dev] Use of is_in in style
Hallo Jan,
der patch hat den Code nicht dupliziert, sondern erweitert/verallgemeinert. Der Code ist auch nicht das Problem, sondern die Kompatibilität mit vorhandenen Styles und die Dokumentation. Ich kann auch mkgmap:landuse:xxx anstelle von mkgmap:is-in:xxx generieren. Wichtig ist mir dabei, dass - alle auf diese Art generierten Tags den gleichen Prefix haben und - auf keinen Fall andere bereits dokumentierte Tags "überschreiben" können Letzteres ist ein eher akademisches Problem, aber stell Dir vor, es gäbe ein landuse=street und jemand würde dass dann auswerten wollen. Ohne extra prefix hätten wir dann evtl. einen unsinnigen Inhalt wie "yes" in dem Tag, der eigentlich einen Straßennamen angibt.
Wenn ich also aus mkgmap:residential jetzt ein mkgmap:landuse:residential mache, dann funktionieren alte Styles nicht mehr. Ein Kompromiss wäre, alle neuen Tags mit Prefix mkgmap:landuse: zu versehen und bei residential nur mkgmap:
Das könnte ich dann auch irgendwie sinnvoll dokumentieren bei den "mkgmap internal tags" im Style manual.
Gerd
________________________________________ Von: jan meisters <jan_m23@gmx.net> Gesendet: Freitag, 13. Dezember 2019 16:00 An: Gerd Petermann Betreff: Re: [mkgmap-dev] Use of is_in in style
Hallo Gerd,
ich bin nicht sicher, ob ich das Problem richtig verstanden habe ;-) Du hattest, glaube ich, den Code von mkgmap:residential dupliziert, um damit landuse abfragen zu können. Aber eigentlich bräuchte man neuen Code für eine neue „Kategorie“ wie z.Bsp. mkgmap:is-in:, um diese, abgegrenzt von mkgmap:residential, über landuse hinaus abfragen zu können?
Würde es denn helfen, wenn man Key und Tag für die neue Option zusammenfasst, also etwa mkgmap:landuse=cemetery? Sorry, mehr gibt meine Code-Unkenntnisse nicht her …
Ich habe aber inzwischen ein lines-file angepasst, um cemetery und allotments sinnvoll „downzugraden“, ohne dabei zu viele Informationen zu zerstören. Idee war ja, diese oft mit Wegen überfrachteten und manchmal erratisch getaggten Gebiete von Hervorhebungen für Radfahrer (vehicle=no, cycle=yes, etc.) auszuschliessen. Das wurde zwar komplizierter als gedacht, und ist mit Kompromissen behaftet: Wege, die Gebietsgrenzen kreuzen, sind u.U. auch betroffen. Leider auch Wege, die die Gebiete nur schneiden. Das ist zwar unsauberer Zeichnung in OSM geschuldet, aber dennoch blöd. Dennoch: so, wie es ist, funktioniert es klasse - für mich immerhin. Missen möchte ich es eigentlich auch nicht mehr.
Und bislang ist mir noch kein Gedanke gekommen, auch andere Keys wie z.Bsp. leisure oder amenity nutzen zu können. Andere mögen das aber wollen - also verstehe ich Dich, wenn Du das vor der Dokumentation sauber ausgearbeitet haben möchtest.
Wirst Du —x-is-in denn vorher schon in der bestehenden Form in den releases belassen? Mich würds freuen.
Schöne Grüße! Jan
Am 10.12.2019 um 11:24 schrieb Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>:
Hi Jan,
thanks for the quick feedback. I am not yet sure about the prefix for those calculated tags. Maybe I change it from mkgmap: to mkgmap:is -in: so that I can document this prefix in the style manual. A separate name space is probably better. Problem is the existing mkgmap:residential which would then be mkgmap:is-in:residential. Existing styles would no longer work. I'll think about this, any suggestions are welcomed...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23@gmx.net<mailto:jan_m23@gmx.net>> Gesendet: Dienstag, 10. Dezember 2019 11:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Gerd,
thanks a lot! I tried the binary with the new option and it works exactly as I want it.
To the .args-file I added x-is-in-landuse=residential,cemetery,industrial and to the beginning of lines highway=* & mkgmap:cemetery=* {set highway=path}
Result is, as expected, the unified representation of lines inside the asked landuse. Other landuse-tags seem to work as well, I also played with allotments successfully: —x-is-in-landuse=residential,cemetery,allotments,industrial
So, even with this „rough“ approach only for landuse, it´s a huge step ahead. Hopefully the option will remain in later releases. Unfortunately, me either am not able to dig into code to generalize the function.
Jan
Am 09.12.2019 um 17:28 schrieb Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>>:
Hi Jan,
sorry, I compiled the binary before removing some debug code. Here is a clean one: http://files.mkgmap.org.uk/download/459/mkgmap.jar
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 16:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Jan,
attached source could replace ResidentialHook. It implements new option --x-is-in-landuse so that one can use e.g. --x-is-in-landuse=residential,cemetery,industrial Without any option it works like the old ResidentialHook.
For each given value, mkgmap checks if an element is inside a landuse with that value, if so, it adds the corresponding tag like mkgmap:residential or mkgmap:industrial This is all done before the style rules are executed, so all calculations are done for all elements. With a bit more work I can also add other polygon tags like natural=* or place=* but it would probably slow down mkgmap and require a lot more heap. A binary compiled with this is source is here: http://files.mkgmap.org.uk/download/458/mkgmap.jar Please try if it works for you.
I'd prefer to have a general style function like is_in which could be used with is_in(landuse=cemetery) or is_in(natural=wood) but I have no idea how to implement the syntax parser etc.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 9. Dezember 2019 14:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Use of is_in in style
Hi Jan,
the result of the is_in discussion was the ResidentialHook which computes the special tag mkgmap:residential. It would be possible to duplicate the code to calculate also a tag for landuse=cemetary. Not sure if that makes sense?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net> < jan_m23@gmx.net<mailto:jan_m23@gmx.net><mailto:jan_m23@gmx.net>> Gesendet: Montag, 9. Dezember 2019 13:15 An: mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Use of is_in in style
Can mkgmap use is_in to filter out objects inside specific (multi)polygons?
In my case I´d like to unify ways inside cemeteries/grave-yards, e.g. highway=* & is_in:landuse=cemetery {set highway=path}
Check-styles isn´t complaining of the syntax, but the rule has no effect.
Similar has been discussed here, but without particular answer: http://gis.19327.n8.nabble.com/is-in-filter-td5890564.html#a5890836
Thanks _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <LanduseHook.java>_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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
participants (2)
-
Gerd Petermann
-
Ticker Berkin