On Sat, Dec 04, 2010 at 12:48:10PM +0700, garvan&maew wrote:
I first tried using the option --name-tag-list=name:en, name
I have never tried that option, so I don't know if it affects relations. I guess I could easily test it by checking Finnish/Russian boundary on my map. For what it is worth, I would not use the option in 'production', because some areas in Finland use Swedish name (and may have name:fi) while most areas use Finnish name (and may have name:sv). I would want to keep the name, except maybe when it is neither Swedish nor Finnish (e.g., the Russian names that even require a character set conversion). I do not know how to express this in --name-tag-list. And even then, I could get problems with foreign-language objects, such as embassies and historic things like name='Deutscher Soldatenfriedhof' (name==name:de, not name:fi or name:sv). I guess that we could benefit from a 'black list' of languages. If transliteration is needed for name, try to use another name:*, e.g., --replacement-name-list=name:en,name:fi,name:sv.
expecting that the boundaries would now use the name:en tag, but this had no effect that I could see. Next I tried editing the line style, and I got the tags to display in English by commenting out this line:
boundary=administrative { name '${mkgmap:boundary_name}' }
This appears to be setting the name of administrative boundaries to mkgmap:boundary_name, so I was wondering where mkgmap:boundary_name gets its value?
As Charlie Ferrero suggested, it should get the value from the name of the boundary relation. The question is if relations ignore the name-tag-list option. # Names of administrative boundaries. # We could want to sort the relations in ascending order of admin_level # and alphabetically by name first. # Currently, the matching relations will be processed and the names # appended to the boundary lines in an arbitrary order. (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } As a workaround for the possible --name-tag-list bug, you could try replacing ${name} in the above rule with ${name:en}. If it does not help, check that relations actually carry a name:en. Ideas for tweaking the style language so that the resulting name list will be sorted are welcome. Best regards, Marko