[mkgmap-dev] Append Name with general rules via style-file
From Thilo Hannemann thannema at gmx.de on Tue Aug 4 23:23:48 BST 2009
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
- Previous message: [mkgmap-dev] Append Name with general rules via style-file
- Next message: [mkgmap-dev] Append Name with general rules via style-file
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list