conditional includes in style
Hi Felix, I've started a new thread for this as your post was a bit off topic here: http://gis.19327.n5.nabble.com/Patch-v5-correct-make-cycleways-tp5800981p580... I had the same idea when I tried to find a solution for the --make-opposite-cycleways option in the style, but then I thought that --make-opposite-cycleways should not be an option at all, these cycleways should be created in the default style if they don't cause any trouble. Your proposition sounds like #ifdef / #endif in a c /c++ prepro combined with defines passed to the compiler. I agree that this gives more flexibility, but it is also likely to reduce readability. The keyword includeoptional sounds more "include if you can find it". Are there other ideas out there? Gerd
On Thu, Mar 27, Gerd Petermann wrote:
Your proposition sounds like #ifdef / #endif in a c /c++ prepro combined with defines passed to the compiler.
This is what I'm doing with my style already. I use #ifdef/#endif and before executing mkgmap I create a local copy of the style with help of cpp. I like that more, because I can check the resulting style and find errors much easier then if I would need to guess what mkgmap is doing. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten,
This is what I'm doing with my style already. I use #ifdef/#endif and before executing mkgmap I create a local copy of the style with help of cpp. I like that more, because I can check the resulting style and find errors much easier then if I would need to guess what mkgmap is doing.
I agree that this is a good solution as long as you don't want to publish the input to cpp. If I remember correctly, the options to run different c++ compilers on different platforms are very different . Gerd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gerd, I quote a mail, which I wrote some month ago to the list:
while cycling in New Zealand I found out, thats a little bit to easy just taking a style (routing and map-look) and use it in parts of the world, which are very different to Central Europe. Eg. it's not that interesting if the road is a trunk or a unclassified, but it's very interesting to show if a road is sealed or unsealed.
If there are only small things, which are country-specific it's pretty easy to use just & mkgmap:country=???. But this will makes the style quite confusing to understand. So I thought it would be nice to have something like:
if ( <key>==<value> ) { <includes or style rules> }
I think such a if-clause would also in general makes style-files a little bit more readabel and shouldn't be that complex to implement (or am I wrong?).
What do you think about such a if-clause? Maybe there is a better way for it.
Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJTM9JDAAoJEPFgsWC7jOeTtzgIAIemvaXqXmSiR4G5p3DqaeCB Z/xjbDHOp81KebkDmh36f3s+zpewPPhNusOb1H4qTT27xevXGvBeDMkbYLCpnkoO Kdt+Ej9V5Bosmc6Yey0vs2uClAIC+2OUTXoulh2ZWy/3W4aYAJdtbIQH5IGPgUhY Lh4N77bvIxfQck7fEDbCtxbjuLd56Z0zASO65kAGwo9OPjyWBHYbkZBMS/IBpdyp pTTD89Gqf4MXgi6v1bHw/n/ePVD8l/4oV/p86mAtyUVaQk332YQr9Qoryq4PuDlY XGPvPiuGk8waqsl2ZtZyEh7m7y2Zb8njBuHC2gKguqEzNjnsgjbIy4Heg26yI6E= =O67V -----END PGP SIGNATURE-----
Hi Henning, where would you want to set the <value> for <key> ? Gerd
Date: Thu, 27 Mar 2014 08:24:51 +0100 From: osm@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] conditional includes in style
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Gerd, I quote a mail, which I wrote some month ago to the list:
while cycling in New Zealand I found out, thats a little bit to easy just taking a style (routing and map-look) and use it in parts of the world, which are very different to Central Europe. Eg. it's not that interesting if the road is a trunk or a unclassified, but it's very interesting to show if a road is sealed or unsealed.
If there are only small things, which are country-specific it's pretty easy to use just & mkgmap:country=???. But this will makes the style quite confusing to understand. So I thought it would be nice to have something like:
if ( <key>==<value> ) { <includes or style rules> }
I think such a if-clause would also in general makes style-files a little bit more readabel and shouldn't be that complex to implement (or am I wrong?).
What do you think about such a if-clause? Maybe there is a better way for it.
Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32)
iQEcBAEBAgAGBQJTM9JDAAoJEPFgsWC7jOeTtzgIAIemvaXqXmSiR4G5p3DqaeCB Z/xjbDHOp81KebkDmh36f3s+zpewPPhNusOb1H4qTT27xevXGvBeDMkbYLCpnkoO Kdt+Ej9V5Bosmc6Yey0vs2uClAIC+2OUTXoulh2ZWy/3W4aYAJdtbIQH5IGPgUhY Lh4N77bvIxfQck7fEDbCtxbjuLd56Z0zASO65kAGwo9OPjyWBHYbkZBMS/IBpdyp pTTD89Gqf4MXgi6v1bHw/n/ePVD8l/4oV/p86mAtyUVaQk332YQr9Qoryq4PuDlY XGPvPiuGk8waqsl2ZtZyEh7m7y2Zb8njBuHC2gKguqEzNjnsgjbIy4Heg26yI6E= =O67V -----END PGP SIGNATURE-----
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, maybe it gets a little bit clearer if I gave an example. if ( mkgmap:country=DEU ) { include 'deu_highway_rules'; } or if (mkgmap:country=DEU) { highway=primary { set mkgmap:access=no } highway=... {...} ... } Henning
That is also quite nice, my main problem with this approach is - can we by now assume that the mkgmap:country tag is 99.9% available correctly when using precompiled bounds? if not passing options from commandline is in this case more reliable - because if you know that you only have input from one country, then give options on commandline aobut include - and not read a tag from data. Also I would suppose this is quicker. Of course if you build a Europe map, or another multi country map - then better use from the style. But that's exactly why actually both conditional includes would be useful. As for C# - I would really prefer to have it handled by mkgmap as it's more universal and I would bet it will become quite popular/useful for many style(s)/style writers. On 27.03.2014 16:32, Henning Scholland wrote:
Hi Gerd, maybe it gets a little bit clearer if I gave an example.
if ( mkgmap:country=DEU ) { include 'deu_highway_rules'; }
or
if (mkgmap:country=DEU) { highway=primary { set mkgmap:access=no } highway=... {...} ... }
Henning
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Mar 27, 2014 at 07:59:24PM +0100, Felix Hartmann wrote:
That is also quite nice, my main problem with this approach is - can we by now assume that the mkgmap:country tag is 99.9% available correctly when using precompiled bounds? [snip]
if ( mkgmap:country=DEU ) { include 'deu_highway_rules'; }
Would this mkgmap:country be assumed to be constant for all map objects? If mkgmap builds a rectangular map tile that includes a bit of Germany, Austria and Switzerland, would this include be executed unconditionally, and each rule in it would be prefixed with the condition "mkgmap:country=DEU &"? If the include statement is dynamic, what if the first objects in the OSM extract happen to be outside Germany? Would you then skip the include for all of the map tile, skipping it for the German part of the tile? If the first objects are inside Germany (mkgmap:country=DEU holds), would the rules be applied to all subsequent map objects, no matter if mkgmap:country=DEU holds for them? Marko
2014-03-27 19:59 GMT+01:00 Felix Hartmann <extremecarver@gmail.com>:
That is also quite nice, my main problem with this approach is - can we by now assume that the mkgmap:country tag is 99.9% available correctly when using precompiled bounds?
I wouldn't take that for granted - I use my own Europe extract of Poland and border areas of neighbour contries, I generate precompiled boundaries but often a lot of places outside Poland get mkgmap:country assigned as 'POL' because I use --country-abbr=POL and level 2 administrative boundaries are so incomplete (as extract do not cover whole countries, only their parts) that mkgmap can't process them. best regards Michal Rogala
Hi Felix Am 27.03.2014 19:59, schrieb Felix Hartmann:
That is also quite nice, my main problem with this approach is - can we by now assume that the mkgmap:country tag is 99.9% available correctly when using precompiled bounds?
I haven't heard about any complaints about this.
if not passing options from commandline is in this case more reliable - because if you know that you only have input from one country, then give options on commandline aobut include - and not read a tag from data. Also I would suppose this is quicker.
I would assume it's quicker. But I'm also publishing my style and other people will (maybe) render a map of an region. It's a lot of easyer for them to just use the style, don't care about the region, instead of needing a option to set. Can you explain there is the difference between include in options-file and two or more styles? Via include you can create a "header-style" which only uses include. Eg. ger/lines include(adresses;) include(access;) include(routing_ger;) include(foobar;)
Of course if you build a Europe map, or another multi country map - then better use from the style. But that's exactly why actually both conditional includes would be useful.
If you build maps, which are not just country-maps, you'll need an style-based thing. But I can understand, that performace is a good argument. So I agree both is useful. But thinks like "default-name" or something like that shouldn't be set in options. Henning
Hi Gerd, here my idea: 1. Allow for nested conditions in style. For example current lines: mkgmap:country=NLD & mkgmap:region!=* ... mkgmap:country=NLD & mkgmap:city!=* ... could be rewritten as: mkgmap:country=NLD { do { mkgmap:region!=* ... mkgmap:city!=* ... } } 2. Allow for user defined tags in mkgmap options, for example: mkgmap.jar --style-option=topo;cycleways ... And use them in style like tags from data: style-option=topo { do { ... ... }} style-option!=cycleways { do { ... ... }} highway=residential & style-option=cycleways ... -- Best regards, Andrzej
First, the conditional rules or includes sounds like a good idea. I guess we should only allow the new syntax for key=value or maybe key=*. Should we introduce a new type of keys (global keys) that are not associated with any OSM object? Or, should the global keys be the default on every object? For example, after java -jar mkgmap.jar --add-default-way-tag=name=unknown every OSM way that did not already carry a name=* tag would be tagged with name=unknown. On Thu, Mar 27, 2014 at 12:15:14PM +0100, Andrzej Popowski wrote:
2. Allow for user defined tags in mkgmap options, for example:
mkgmap.jar --style-option=topo;cycleways ...
; would be a bad choice for a delimiter, because it is a shell meta-character in the conventional Unix shells (separating commands when you do not want to use line breaks). Also, I think that the option should be split already on the command line, like this: java -jar mkgmap.jar --style-option=topo --style-option=cycleways ... In many Unix shells, you can use short-hand notation which would be expanded to the above by the shell: java -jar mkgmap.jar --style-option={topo,cycleways} Best regards, Marko
Hi Marko,
Should we introduce a new type of keys (global keys) that are not associated with any OSM object?
This would be handy for conditional interpreting of style.
java -jar mkgmap.jar --add-default-way-tag=name=unknown
Or maybe that way: mkgmap.jar --style-option=default_name=unknown And then in style: highway=* & name!=* { add name = '${style-option:default_name}' } -- Best regards, Andrzej
participants (7)
-
Andrzej Popowski -
Felix Hartmann -
Gerd Petermann -
Henning Scholland -
Marko Mäkelä -
Michał Rogala -
Thorsten Kukuk