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
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
