[mkgmap-dev] Use of is_in in style

Sat Dec 14 11:04:52 GMT 2019

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 at 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 at 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 at hotmail.com<mailto:gpetermann_muenchen at 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 at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von jan meisters <jan_m23 at gmx.net<mailto:jan_m23 at 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 at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at 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 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 Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at 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 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 Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at 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 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 jan_m23 at gmx.net<mailto:jan_m23 at gmx.net><mailto:jan_m23 at gmx.net> <jan_m23 at gmx.net<mailto:jan_m23 at gmx.net><mailto:jan_m23 at gmx.net>>
Gesendet: Montag, 9. Dezember 2019 13:15
An: mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at 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 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
<LanduseHook.java>_______________________________________________
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>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: landuse2.patch
Type: application/octet-stream
Size: 14853 bytes
Desc: landuse2.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191214/76b7a42f/attachment-0001.obj>