Append Name with general rules via style-file
Some of you have already made patches for the "name" so maybe you know whether the following would be feasible. Currently add or set name will delete everything and put in the new text. the start-with used by Thilo's patches works AFAIK (I never tried it) also only following highway=* [0x?? level ?] What I would like is to have rules like: highway=* {name '${name} ${name1} (${ref})' | '${name1} ${ref}' | '${name1} ${name}' | '${name1}' | '${name} (${ref})' | '${ref}' | '${name}'} Where name1 is set in relations file. Currently name1 will simply replace name. I don't know why. Or highway=* & bridge=yes { name '${name} (${ref}) bridge' | '${ref} bridge' | '${name} bridge' } ....... (I would like to have a list of around 200 checks here, adding tracktype and similar to the name - so each rule should simply add itself on the name, currently not even having a single rule like the above works, so if one rule would work I would still excpect it to somehow fail or give surprising results as the rules are not run in order, but better a bit working than nothing.....) Which also currently does not work.
Hi Felix, This is not a comment on your proposed scheme but I do believe that the current handling of name and ref (and the highway shields, etc.) is completely fucked up. IMHO, munging the element name and its refs together in the style file is completely bogus. Cheers, Mark
Yeah that's true, but how to do it better? I would think a name-file where you can run rules for name, info sections , phone numbers, etc. seperate from the style-file would be best. Currently of my lines style-file which consists of 8.000 lines, 7.000 are basically only to get proper naming, ideally I have to blow it up million lines to get all attributes into the name that I would like to be stated there. As the name is in the route sections the only way to quickly check whether or not a route planned by autorouting (be it gps or mapsource) is nice or not. Felix Mark Burton wrote:
Hi Felix,
This is not a comment on your proposed scheme but I do believe that the current handling of name and ref (and the highway shields, etc.) is completely fucked up. IMHO, munging the element name and its refs together in the style file is completely bogus.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark Burton schrieb:
This is not a comment on your proposed scheme but I do believe that the current handling of name and ref (and the highway shields, etc.) is completely fucked up. IMHO, munging the element name and its refs together in the style file is completely bogus.
I think the problem (or at least part of it) is the fact, the mkgmap rules consist out of three parts: 1. The pattern part for identifying the applicable rule. This part is mandatory. 2. The action part. This part is optional. 3. The conversion part. This part again is mandatory. The name and reference handling in the style file now defines rules, consisting out of only the pattern and the action part and leaving out the conversion part. This can't be handled my mkgmap, so internally the incomplete rule is combined/mixed with some other rules in the style. In my mail from 31st of July I proposed a fix for this problem, but I didn't had the time yet, to implement/test such a modification. Gruss Torsten
Torsten Leistikow wrote:
Mark Burton schrieb:
This is not a comment on your proposed scheme but I do believe that the current handling of name and ref (and the highway shields, etc.) is completely fucked up. IMHO, munging the element name and its refs together in the style file is completely bogus.
I think the problem (or at least part of it) is the fact, the mkgmap rules consist out of three parts:
1. The pattern part for identifying the applicable rule. This part is mandatory.
2. The action part. This part is optional.
3. The conversion part. This part again is mandatory.
The name and reference handling in the style file now defines rules, consisting out of only the pattern and the action part and leaving out the conversion part. This can't be handled my mkgmap, so internally the incomplete rule is combined/mixed with some other rules in the style.
In my mail from 31st of July I proposed a fix for this problem, but I didn't had the time yet, to implement/test such a modification.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well I tested a bit more today. The big problem is that the rules don't allways work, sometimes they do, sometimes the same rule fails. This is in my overlays file: type=route & route=bicycle { apply {set route=bicycle; set name1='CRT ${name}'} } type=route & route=mtb { apply { set route=mtb; set name1='MRT ${name}'} } type=route & route=mountainbike { apply { set route=mtb; set name1='MRT ${name}'} } type=route & route=ferry { apply { set route=ferry; set name='Ferry ${name}'} } type=route & route=hiking { apply { set route=hiking; set name1='HKRT ${name}'} } type=route & route=foot { apply { set route=foot; set name1='FTRT ${name}'} } And this is supposed to catch it in the lines file, however it does not work every time, sometimes even the road name will be deleted and exchanged by the route name, sometimes the other way around. I'm a bit clueless why this happens, nearly every time the mtb:scale/mtb:scale:uphill part fails, though sometimes it does work (the commented try worked even worse.) ......: Can anyone see a bug in here? Lines-File: highway=* { name '${name} (${ref})' | '${ref}' | '${name}' } highway=* { name '${name} ${name1}' | '${name1}' | '${name}' } # highway=* {name '${name} ${name1} (${ref})' | '${name1} ${ref}' | '${name1} ${name}' | '${name1}' | '${name} (${ref})' | '${ref}' | '${name}'} mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 'mtbrt00' } mtb:scale=0 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt01 ${name}' | 'mtbrt01' } mtb:scale=0 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt02 ${name}' | 'mtbrt02' } mtb:scale=0 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt03 ${name}' | 'mtbrt03' } mtb:scale=0 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt04 ${name}' | 'mtbrt04' } mtb:scale=0 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt05 ${name}' | 'mtbrt05' } mtb:scale=1 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt11 ${name}' | 'mtbrt11' } mtb:scale=1 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt12 ${name}' | 'mtbrt12' } mtb:scale=1 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt13 ${name}' | 'mtbrt13' } mtb:scale=1 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt14 ${name}' | 'mtbrt14' } mtb:scale=1 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt15 ${name}' | 'mtbrt15' } mtb:scale=2 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt22 ${name}' | 'mtbrt22' } mtb:scale=2 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt23 ${name}' | 'mtbrt23' } mtb:scale=2 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt24 ${name}' | 'mtbrt24' } mtb:scale=2 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt25 ${name}' | 'mtbrt25' } mtb:scale=3 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt33 ${name}' | 'mtbrt33' } mtb:scale=3 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt34 ${name}' | 'mtbrt34' } mtb:scale=3 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt35 ${name}' | 'mtbrt35' } mtb:scale=4 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt44 ${name}' | 'mtbrt44' } mtb:scale=4 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt45 ${name}' | 'mtbrt45' } mtb:scale=5 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt55 ${name}' | 'mtbrt55' } mtb:scale:uphill=0 & route=mtb { name 'mtbrt.0 ${name}' | 'mtbrt.0' } mtb:scale:uphill=1 & route=mtb { name 'mtbrt.1 ${name}' | 'mtbrt.1' } mtb:scale:uphill=2 & route=mtb { name 'mtbrt.2 ${name}' | 'mtbrt.2' } mtb:scale:uphill=3 & route=mtb { name 'mtbrt.3 ${name}' | 'mtbrt.3' } mtb:scale:uphill=4 & route=mtb { name 'mtbrt.4 ${name}' | 'mtbrt.4' } mtb:scale:uphill=5 & route=mtb { name 'mtbrt.5 ${name}' | 'mtbrt.5' } mtb:scale=0 & route=mtb { name 'mtbrt0. ${name}' | 'mtbrt0.' } mtb:scale=1 & route=mtb { name 'mtbrt1. ${name}' | 'mtbrt1.' } mtb:scale=2 & route=mtb { name 'mtbrt2. ${name}' | 'mtbrt2.' } mtb:scale=3 & route=mtb { name 'mtbrt3. ${name}' | 'mtbrt3.' } mtb:scale=4 & route=mtb { name 'mtbrt4. ${name}' | 'mtbrt4.' } mtb:scale=5 & route=mtb { name 'mtbrt5. ${name}' | 'mtbrt5.' } mtb:scale=0 & mtb:scale:uphill=0 { name 'mtb00 ${name}' | 'mtb00' } mtb:scale=0 & mtb:scale:uphill=1 { name 'mtb01 ${name}' | 'mtb01' } mtb:scale=0 & mtb:scale:uphill=2 { name 'mtb02 ${name}' | 'mtb02' } mtb:scale=0 & mtb:scale:uphill=3 { name 'mtb03 ${name}' | 'mtb03' } mtb:scale=0 & mtb:scale:uphill=4 { name 'mtb04 ${name}' | 'mtb04' } mtb:scale=0 & mtb:scale:uphill=5 { name 'mtb05 ${name}' | 'mtb05' } mtb:scale=1 & mtb:scale:uphill=1 { name 'mtb11 ${name}' | 'mtb11' } mtb:scale=1 & mtb:scale:uphill=2 { name 'mtb12 ${name}' | 'mtb12' } mtb:scale=1 & mtb:scale:uphill=3 { name 'mtb13 ${name}' | 'mtb13' } mtb:scale=1 & mtb:scale:uphill=4 { name 'mtb14 ${name}' | 'mtb14' } mtb:scale=1 & mtb:scale:uphill=5 { name 'mtb15 ${name}' | 'mtb15' } mtb:scale=2 & mtb:scale:uphill=2 { name 'mtb22 ${name}' | 'mtb22' } mtb:scale=2 & mtb:scale:uphill=3 { name 'mtb23 ${name}' | 'mtb23' } mtb:scale=2 & mtb:scale:uphill=4 { name 'mtb24 ${name}' | 'mtb24' } mtb:scale=2 & mtb:scale:uphill=5 { name 'mtb25 ${name}' | 'mtb25' } mtb:scale=3 & mtb:scale:uphill=3 { name 'mtb33 ${name}' | 'mtb33' } mtb:scale=3 & mtb:scale:uphill=4 { name 'mtb34 ${name}' | 'mtb34' } mtb:scale=3 & mtb:scale:uphill=5 { name 'mtb35 ${name}' | 'mtb35' } mtb:scale=4 & mtb:scale:uphill=4 { name 'mtb44 ${name}' | 'mtb44' } mtb:scale=4 & mtb:scale:uphill=5 { name 'mtb45 ${name}' | 'mtb45' } mtb:scale=5 & mtb:scale:uphill=5 { name 'mtb55 ${name}' | 'mtb55' } mtb:scale:uphill=0 { name 'mtb.0 ${name}' | 'mtb.0' } mtb:scale:uphill=1 { name 'mtb.1 ${name}' | 'mtb.1' } mtb:scale:uphill=2 { name 'mtb.2 ${name}' | 'mtb.2' } mtb:scale:uphill=3 { name 'mtb.3 ${name}' | 'mtb.3' } mtb:scale:uphill=4 { name 'mtb.4 ${name}' | 'mtb.4' } mtb:scale:uphill=5 { name 'mtb.5 ${name}' | 'mtb.5' } mtb:scale=0 { name 'mtb0. ${name}' | 'mtb0.' } mtb:scale=1 { name 'mtb1. ${name}' | 'mtb1.' } mtb:scale=2 { name 'mtb2. ${name}' | 'mtb2.' } mtb:scale=3 { name 'mtb3. ${name}' | 'mtb3.' } mtb:scale=4 { name 'mtb4. ${name}' | 'mtb4.' } mtb:scale=5 { name 'mtb5. ${name}' | 'mtb5.' } highway=path { name '${name} pth' | 'pth' } highway=footpath { set toll=yes; name '${name} fp' | 'fp' } highway=track { name '${name} trk' | 'trk' } highway=unsurfaced { name '${name} unsf' | 'unsf' } highway=unclassified { name '${name} uncl' | 'uncl' } highway=minor { name '${name} minr' | 'minr' } highway=byway { name '${name} bywy' | 'bywy' } highway=bridleway { name '${name} brdlwy' | 'brdlwy' } highway=cycleway { name '${name} cwy' | 'cwy' } cycleway=lane { name '${name} cln' | 'cln' } cycleway=track { name '${name} ctrk' | 'ctrk' } highway=footway { set toll=yes; name '${name} ft' | 'ft' } highway=service & access=yes { name 'BK ${name} ser' | 'BK ser' } highway=service & access=no { name 'XBK ${name} ser' | 'XBK ser' } highway=service { name '${name} ser' | 'ser' } highway=construction { name 'constrction ${name}' | 'under construction' } highway=road { name '${name} RD' | 'RD' }
Felix Hartmann schrieb:
mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 'mtbrt00' }
As I have state above: This is an incomplete mkgmap rule, since the conversion part is missing. Mkgmap will combine this rule with some other rule with a conversion part, but most probably not in the intended way. Gruss Torsten
Torsten Leistikow wrote:
Felix Hartmann schrieb:
mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 'mtbrt00' }
As I have state above: This is an incomplete mkgmap rule, since the conversion part is missing. Mkgmap will combine this rule with some other rule with a conversion part, but most probably not in the intended way.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes I know, but I end up with a style-file of around 100.000 lines if not more if I try to get the posted rules enacted on every street! Also processing time of mkgmap will be about 10x then. The problem is that those "incomplete rules" are simply dropped, not even merged.....
Hi everybody. Some comments to this thread: 1. The 'start-with' patch works with every variable, so you can use it anywhere you like. But I don't think it can contribute to the solution of Felix's problem. 2. Felix's problems with his lines file: First one should understand that the 'name' action does not set the $ {name} variable! Just look at the source code (it's in StyledConverter.java and there the functions preConvertRules and postConvertRules mangle the names). Second as I do understand it only one action will match to a given osm element. So with highway=* you will already match most of the elements and the actions for the mtb:scale etc. will never be applied (but I'm not 100% sure about that). Maybe that's already an explanation for what is happening, but if it is not: 3. One line in the mkgmap style files consists of three components: - the rule part (like highway=primary) - the action part (enclose by { ... }) - the type part (enclose by [ ... ]) A rule part is always needed, but only one of the action and type parts must be present. So the line
mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 $ {name}' | 'mtbrt00' }
is not incomplete, btw. If you do not believe me just look into RuleFileReader.java: // If there is an action list, then we don't need a type The problem with understanding the actions is that looking at the syntax one would assume that the action part and the type part are handled at the same place in mkgmap. But they are not! The handling of the action part is actually quite complicated to understand (just look at the code and you see what I mean), but works fine most of the time. They get applied to an element each time a resolveType(element) is called for that element. Some logic then makes sure that only the 'proper' action gets applied. This will break down for example for "self-modifying" rules, where you modify a tag so that it should match another rule (as you do in your style file). That simply won't work (other than in the relations style file, where you can do that for rules in the other style files). 4. Mark wrote that the current handling of names is completely f*cked up. I would just like to point out a problem that we get with the new and highly useful 'continue'-patch. As the actions get applied separately from the type parts, the name for all Garmin elements generated from a single OSM element is the same. This is a shame, because with the 'continue' you want most of the time different names for the Garmin elements. Be it to generate route overlays (that should have the name of the route and not the streetname of the underlying way) or POIs where you for example have one POI for the pub with the name of the pub and one POI for the WLAN hotspot with the name of the hotspot provider. Another topic to think about is internationalisation. If you start heavy mangling of the names you will probably do that differently depending on the locale. If you write your own style files this is not a big deal, but if there should be one 'default style' that actually uses all the nice name-mangling feature it will have to have some kind of internationalisation. 5. As the name mangling might get really complex how about factoring the mkgmap code in a way that makes it easy to write your own name mangling code in Java? One could for example introduce another keyword for the type part that selects a 'namefinder' for that part. The namefinder would be a Java routine that will be compiled as part of mkgmap. Probably everybody discussing in this thread here compiles his own version of mkgmap anyway. Writing a name mangling function in Java might actually be easier than coming up with some super-powerful syntax for the style files. Useful namefinder routines could then be integrated into trunk for general usage. Example for that: mtb:scale=0 & mtb:scale:uphill=0 & route=mtb [0x?? namefinder=MTBROUTE road_class=? road_speed=? level ?] mtb:scale=0 & mtb:scale:uphill=1 & route=mtb [0x?? namefinder=MTBROUTE road_class=? road_speed=? level ?] mtb:scale=0 & mtb:scale:uphill=2 & route=mtb [0x?? namefinder=MTBROUTE road_class=? road_speed=? level ?] mtb:scale=0 & mtb:scale:uphill=3 & route=mtb [0x?? namefinder=MTBROUTE road_class=? road_speed=? level ?] ... highway=path [0x?? namefinder=HIGHWAY road_class=? road_speed=? level 1] Here the namefinder MTBroute is a Java routine that compiles the name from all the mtb:scale... tags. The namefinder HIGHWAY would simply attach the proper extension depending on the highway type. All the action rules are gone, because the namefinder is just added to the type part. And this part you need anyway. What do you think about that? Regards Thilo
On Wed, Aug 05, 2009 at 12:23:48AM +0200, Thilo Hannemann wrote:
5. As the name mangling might get really complex how about factoring the mkgmap code in a way that makes it easy to write your own name mangling code in Java? One could for example introduce another keyword for the type part that selects a 'namefinder' for that part. The namefinder would be a Java routine that will be compiled as part of mkgmap. Probably everybody discussing in this thread here compiles his own version of mkgmap anyway. Writing a name mangling function in Java might actually be easier than coming up with some super-powerful syntax for the style files. Useful namefinder routines could then be integrated into trunk for general usage.
Example for that:
mtb:scale=0 & mtb:scale:uphill=0 & route=mtb [0x?? namefinder=MTBROUTE road_class=? road_speed=? level ?]
+1 for that. One of the built-in name finders (I can contribute it) would embed name, operator, ref, (shelter|covered)=(yes|no), fee=(no|*) in the name. This would be useful for bus stops, parking, and various amenities. The resulting label could be something like this: name (ref) [operator] [+-][$!] The + or - would correspond to (covered|shelter)=(yes|no), and the ! or $ would correspond to fee=no or fee=*. Any of the components could be absent. E.g., a parking place with no name, operator or fee would be named "!" (and given the parking place symbol). Later on, we might want to pass a format string to the namefinder routine, for localization purposes, e.g., for using a different currency symbol. Marko
Hi Felix, I am trying to work out what doesn't work here. In general anything that relies on the order that actions are run in will not work reliably (see my previous post). I will put each question/comment in a separate post to keep things clear and separate. The following part of the file could be much reduced:
mtb:scale=0 & mtb:scale:uphill=0 & route=mtb { name 'mtbrt00 ${name}' | 'mtbrt00' } mtb:scale=0 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt01 ${name}' | 'mtbrt01' } mtb:scale=0 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt02 ${name}' | 'mtbrt02' } mtb:scale=0 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt03 ${name}' | 'mtbrt03' } mtb:scale=0 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt04 ${name}' | 'mtbrt04' } mtb:scale=0 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt05 ${name}' | 'mtbrt05' } mtb:scale=1 & mtb:scale:uphill=1 & route=mtb { name 'mtbrt11 ${name}' | 'mtbrt11' } mtb:scale=1 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt12 ${name}' | 'mtbrt12' } mtb:scale=1 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt13 ${name}' | 'mtbrt13' } mtb:scale=1 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt14 ${name}' | 'mtbrt14' } mtb:scale=1 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt15 ${name}' | 'mtbrt15' } mtb:scale=2 & mtb:scale:uphill=2 & route=mtb { name 'mtbrt22 ${name}' | 'mtbrt22' } mtb:scale=2 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt23 ${name}' | 'mtbrt23' } mtb:scale=2 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt24 ${name}' | 'mtbrt24' } mtb:scale=2 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt25 ${name}' | 'mtbrt25' } mtb:scale=3 & mtb:scale:uphill=3 & route=mtb { name 'mtbrt33 ${name}' | 'mtbrt33' } mtb:scale=3 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt34 ${name}' | 'mtbrt34' } mtb:scale=3 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt35 ${name}' | 'mtbrt35' } mtb:scale=4 & mtb:scale:uphill=4 & route=mtb { name 'mtbrt44 ${name}' | 'mtbrt44' } mtb:scale=4 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt45 ${name}' | 'mtbrt45' } mtb:scale=5 & mtb:scale:uphill=5 & route=mtb { name 'mtbrt55 ${name}' | 'mtbrt55' }
mtb:scale:uphill=0 & route=mtb { name 'mtbrt.0 ${name}' | 'mtbrt.0' } mtb:scale:uphill=1 & route=mtb { name 'mtbrt.1 ${name}' | 'mtbrt.1' } mtb:scale:uphill=2 & route=mtb { name 'mtbrt.2 ${name}' | 'mtbrt.2' } mtb:scale:uphill=3 & route=mtb { name 'mtbrt.3 ${name}' | 'mtbrt.3' } mtb:scale:uphill=4 & route=mtb { name 'mtbrt.4 ${name}' | 'mtbrt.4' } mtb:scale:uphill=5 & route=mtb { name 'mtbrt.5 ${name}' | 'mtbrt.5' }
mtb:scale=0 & route=mtb { name 'mtbrt0. ${name}' | 'mtbrt0.' } mtb:scale=1 & route=mtb { name 'mtbrt1. ${name}' | 'mtbrt1.' } mtb:scale=2 & route=mtb { name 'mtbrt2. ${name}' | 'mtbrt2.' } mtb:scale=3 & route=mtb { name 'mtbrt3. ${name}' | 'mtbrt3.' } mtb:scale=4 & route=mtb { name 'mtbrt4. ${name}' | 'mtbrt4.' } mtb:scale=5 & route=mtb { name 'mtbrt5. ${name}' | 'mtbrt5.' }
mtb:scale=0 & mtb:scale:uphill=0 { name 'mtb00 ${name}' | 'mtb00' } mtb:scale=0 & mtb:scale:uphill=1 { name 'mtb01 ${name}' | 'mtb01' } mtb:scale=0 & mtb:scale:uphill=2 { name 'mtb02 ${name}' | 'mtb02' } mtb:scale=0 & mtb:scale:uphill=3 { name 'mtb03 ${name}' | 'mtb03' } mtb:scale=0 & mtb:scale:uphill=4 { name 'mtb04 ${name}' | 'mtb04' } mtb:scale=0 & mtb:scale:uphill=5 { name 'mtb05 ${name}' | 'mtb05' } mtb:scale=1 & mtb:scale:uphill=1 { name 'mtb11 ${name}' | 'mtb11' } mtb:scale=1 & mtb:scale:uphill=2 { name 'mtb12 ${name}' | 'mtb12' } mtb:scale=1 & mtb:scale:uphill=3 { name 'mtb13 ${name}' | 'mtb13' } mtb:scale=1 & mtb:scale:uphill=4 { name 'mtb14 ${name}' | 'mtb14' } mtb:scale=1 & mtb:scale:uphill=5 { name 'mtb15 ${name}' | 'mtb15' } mtb:scale=2 & mtb:scale:uphill=2 { name 'mtb22 ${name}' | 'mtb22' } mtb:scale=2 & mtb:scale:uphill=3 { name 'mtb23 ${name}' | 'mtb23' } mtb:scale=2 & mtb:scale:uphill=4 { name 'mtb24 ${name}' | 'mtb24' } mtb:scale=2 & mtb:scale:uphill=5 { name 'mtb25 ${name}' | 'mtb25' } mtb:scale=3 & mtb:scale:uphill=3 { name 'mtb33 ${name}' | 'mtb33' } mtb:scale=3 & mtb:scale:uphill=4 { name 'mtb34 ${name}' | 'mtb34' } mtb:scale=3 & mtb:scale:uphill=5 { name 'mtb35 ${name}' | 'mtb35' } mtb:scale=4 & mtb:scale:uphill=4 { name 'mtb44 ${name}' | 'mtb44' } mtb:scale=4 & mtb:scale:uphill=5 { name 'mtb45 ${name}' | 'mtb45' } mtb:scale=5 & mtb:scale:uphill=5 { name 'mtb55 ${name}' | 'mtb55' }
mtb:scale:uphill=0 { name 'mtb.0 ${name}' | 'mtb.0' } mtb:scale:uphill=1 { name 'mtb.1 ${name}' | 'mtb.1' } mtb:scale:uphill=2 { name 'mtb.2 ${name}' | 'mtb.2' } mtb:scale:uphill=3 { name 'mtb.3 ${name}' | 'mtb.3' } mtb:scale:uphill=4 { name 'mtb.4 ${name}' | 'mtb.4' } mtb:scale:uphill=5 { name 'mtb.5 ${name}' | 'mtb.5' }
mtb:scale=0 { name 'mtb0. ${name}' | 'mtb0.' } mtb:scale=1 { name 'mtb1. ${name}' | 'mtb1.' } mtb:scale=2 { name 'mtb2. ${name}' | 'mtb2.' } mtb:scale=3 { name 'mtb3. ${name}' | 'mtb3.' } mtb:scale=4 { name 'mtb4. ${name}' | 'mtb4.' } mtb:scale=5 { name 'mtb5. ${name}' | 'mtb5.' }
To the following which says 'if either mtb:scale or mtb:scale:uphill are given then construct the name from the values. If either one is absent, replace it with a dot'. Does that accurately reproduce what you want? I realise that might not currently work with other things in the file, but I am trying to take this a step at a time. (mtb:scale=* | mtb:scale:uphill=*) & route=mtb { name 'mtbrt${mtb:scale|def:.}${mtb:scale:uphill|def:.} ${name}' | 'mtbrt${mtb:scale|def:.}${mtb:scale:uphill|def:.}' } (mtb:scale=* | mtb:scale:uphill=*) & route!=mtb { name 'mtb${mtb:scale|def:.}${mtb:scale:uphill|def:.} ${name}' | 'mtb${mtb:scale|def:.}${mtb:scale:uphill|def:.}' If there are invalid values for mtb:scale, then this will give different results for that case, but if that is important then perhaps we can deal with that separately. Regards, ..Steve
With these two rules, even if they are run in same order as they are written, the second one could never have an effect if ${name} is defined.
highway=* { name '${name} (${ref})' | '${ref}' | '${name}' } highway=* { name '${name} ${name1}' | '${name1}' | '${name}' }
This is because you can only set the name once. If ${name} is set then the name will be set in the first rule and so the only way that the second rule can be used is if ${name1} is set and ${name} is not set. You could fix that by doing everything together, if that is the effect you want: highway=* { name '${name} (${ref})' | '${ref}' | '${name} ${name1}' | '${name1}' | '${name}' } ..Steve
Steve Ratcliffe wrote:
With these two rules, even if they are run in same order as they are written, the second one could never have an effect if ${name} is defined.
highway=* { name '${name} (${ref})' | '${ref}' | '${name}' } highway=* { name '${name} ${name1}' | '${name1}' | '${name}' }
This is because you can only set the name once. If ${name} is set then the name will be set in the first rule and so the only way that the second rule can be used is if ${name1} is set and ${name} is not set.
You could fix that by doing everything together, if that is the effect you want:
highway=* { name '${name} (${ref})' | '${ref}' | '${name} ${name1}' | '${name1}' | '${name}' }
..Steve
The problem ist that generating a list that does everything together will become to complex, say you have to write down all combination for 10 keys. Or am I missing something? The problem is that if I write everything into one line, and one key listed there is not present on highway=* it will fail. highway=* { name '${name} (${ref})' | '${ref}' | '${name} ${name1}' | '${name1}' | '${name}' } would become for one more value highway=* { name | '${ref} ${name} ${name1} ${name2}' | '${name} ${name1} ${name2}' | '${ref} ${name1} ${name2}' | '${ref} ${name} ${name2}' | '${ref} ${name} ${name}1' | '${ref} ${name} | '${ref} ${name1} | '${ref} ${name2} | '${name} ${name1} | '${name} ${name2} | '${name1} ${name2} | '${name}' | '${name1}' | '${name2}' | '${ref}' } Adding one more and it gets even worse....... but adding 10 more keys and this list will grow into eternity..... Now the problem is that I don't want to have the value of the key in the name itself each time, but on presence of a key I wan't to have another value inside. so if route=mtb is present I want to have mtbrt in the name, or for route=bicycle I would like to have cyrt and so on. So I have to run some tests whether values are present or not, which would make the task to put everything into on line even more difficult...
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix
highway=* { name | '${ref} ${name} ${name1} ${name2}' | '${name} ${name1} ${name2}' | '${ref} ${name1} ${name2}' | '${ref} ${name} ${name2}' | '${ref} ${name} ${name}1' | '${ref} ${name} | '${ref} ${name1} | '${ref} ${name2} | '${name} ${name1} | '${name} ${name2} | '${name1} ${name2} | '${name}' | '${name1}' | '${name2}' | '${ref}'
}
In this case you could give each value a default value of nothing, so it would always match with just the one rule { name '${ref|def:} ${name|def:} ${name1|def:} ${name2|def:}' } But you would get extra spaces when any of the value were empty. You should also be able to do this to append any number of things with only one line for each thing to be appended: highway=* { set fullname=''; set fullname='${ref}'; set fullname='${fullname} ${name}'; set fullname='${fullname} ${name1}'; set fullname='${fullname} ${name2}'; name '${fullname}'; } But I see that didn't work because of a bug. That is now fixed and so the example will build up a string with spaces only where needed. The only problem would be that if ref doesn't exist, then there will be a space at the start. I can't see a way around this at the moment, but we could add something for that. ..Steve
Hi Steve,
In this case you could give each value a default value of nothing, so it would always match with just the one rule
{ name '${ref|def:} ${name|def:} ${name1|def:} ${name2|def:}' }
But you would get extra spaces when any of the value were empty.
You should also be able to do this to append any number of things with only one line for each thing to be appended:
highway=* { set fullname=''; set fullname='${ref}'; set fullname='${fullname} ${name}'; set fullname='${fullname} ${name1}'; set fullname='${fullname} ${name2}'; name '${fullname}'; }
Thank you very much, I will try either approach for naming the bus stops. The attributes I'm planning to include are name, ref, operator, shelter=yes/no, possibly even amenity=waste_basket. Marko
On Sat, Aug 08, 2009 at 03:48:41PM +0100, Steve Ratcliffe wrote:
In this case you could give each value a default value of nothing, so it would always match with just the one rule
{ name '${ref|def:} ${name|def:} ${name1|def:} ${name2|def:}' }
But you would get extra spaces when any of the value were empty. [...] The only problem would be that if ref doesn't exist, then there will be a space at the start. I can't see a way around this at the moment, but we could add something for that.
What about a more generic SubstitutionFilter that would execute a list of regexp replacements and also allow optional "else" and "default" substitutions? Something like this (but preferrably more readable, perhaps in the style of the Perl /x regexp modifier that allows white space and comments within the regexp) and something that leaves the traditional regexp meta-chars alone): highway=bus_stop { name '${name|def:}${shelter|replace:yes=+:no=-:=::=?}' } This would transform shelter=yes into a '+' suffix, shelter=no into '-' and any other value of shelter=* into the empty string. If there is no shelter attribute, the suffix would be '?'. For what it is worth, the attached rules for naming bus, train and tram stops work rather nicely. The only drawback is that when all attributes are missing, the name will appear blank (consisting of spaces). Is the name | operator also available in assignments? For instance, I can say {name '${name}' | '${ref}' } but can I say { set $fullname='${name}'|${ref}'; name '${fullname} } and get the same result ($fullname undefined if both $name and $ref are undefined)? Best regards, Marko
On Aug 3, 2009, at 22:43, Felix Hartmann wrote:
Or highway=* & bridge=yes { name '${name} (${ref}) bridge' | '${ref} bridge' | '${name} bridge' }
I'm not sure I understand correctly. Does the above statement not work at all, or does it just not work when there was a previous matching statement? For example, I have the following in my lines file: tracktype=* {name '${name} (${tracktype})' | '${tracktype}' | '$ {name}' } This will produce, as expected, name such as the following: Mühlweg (Grade4) Or is the problem that you would like to accumulate names? (For example to append the surface type in a later statement?) Are you using one of the patches to provide "continue" functions to the style files? Cheers.
participants (7)
-
Clinton Gladstone -
Felix Hartmann -
Mark Burton -
Marko Mäkelä -
Steve Ratcliffe -
Thilo Hannemann -
Torsten Leistikow