[mkgmap-dev] Append Name with general rules via style-file

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