In general the device is able to diplay all(?) latin1 characters:
But: When compiling the map, mkgmap changes all street names to uppercase
(unless you use the --lower-case option). But there is no upper case
for the “ß”, so it is converted to “SS”.
The Garmin device convertes back to lower case in the tooltips and in other fields.
If the --lower-case option is used, the street names are displayed
as A… in the map (only first letter is shown).
Chris you are talking about what mkgmap can/does. But I want to know something about the Garmin. I asked if you had/knew an .img file which contained a ß. Does not matter who put in in.
But your picture shows something very nice. Just above the Süntelstasse hint: ÄËäÜß.
Isn’t that a ß at the end? Did you type it in for a waypoint?
For place name there is not much to do as mostly all have also name:en or int_name. This is the list of names that were transliterated. The same file is displayed in three difefrent programs (on XP): wordpad, notepad and firefox.
Wordpad does not understand utf8 so it displays all bytes as if they were characters, notepad understand that it is utf8 and converts to the right character but then misses the font. Firefox understands everything (without telling it that it is utf8).
From all programs I copypasted the first three lines to this post. (you never how which conversions are applied using the clipboard).
Yes I do already for Turkish. I did not yet bother for German. But then the 60Cx can display Ü and Ö. Or not rotated?
At second thougth: If in utf8 the Turkish ö is coded with the same byte values as the German ö (and i think that will be the case) then if translit keeps the tables per area then the transliteration could be different. But i think that in short i will do away all areas (the .gpx files) and only use one transliterationtable for the whole world as i do now already for the 's.
In Greece many places have already an int_name or en:name. Whats left are 652 nodes with a place and name tag that need transliteration. Well translit thinks so and it does a transliteration of the utf8 encoded string. If the transliteration result is the same as the utf8 encoded string than the name was already in ansi. Translit counted 559 name’s already in ansi. So only 90 tags were added.
For ways these counts were 7097, 5644 and 1439.
On the maps for greece you can see that very often the name is both spelled in greece and internalional.
Here some transliteration results:
The weekly updated img files on http://garmin.na1400.info/routable.php now contain transliterations for 21 Areas:
albania, belarus, bulgarije, cyprus-turkish, czech-republic, estonia, georgia, greece, hungary, kaliningrad, latvia, lithuania, macedonia, moldavie, poland, romania, russia, serbia, slowakia, turkey and ukraina. Attentioen only 's with a valid place AND a name tag are transliterated when needed. (valid place |town|city|suburb|village|hamlet|).
The program at the moment is restricted to do 's. When 's and 's are also transliterated publication would make sense. Lambertus is the only one who uses (and tests) it. If translit does what I want it to do I will offer it to the community. In which way I still don’t know.
Adding to mkgmap is a different story. I never looked into the source of mkgmap so I do not know in which way the code could be integrated. But of course integration in mkgmap is preferred over functioning as a frontend. An extra option --translit which forces mkgmap to trow away all codepages and just take one transliterationtable (the one from translit for instance) would be nice.
Would it make sense to introduce a name:translit tag for transliterated names and let mkgmap choose one of them, e.g., mkgmap --name-tag-list=name:en,int_name,name:translit,name or (for native users) just mkgmap --name-tag-list=name:translit,name? The transliteration could be implemented as a separate preprocessing step or integrated in mkgmap so that it can be executed on the fly, when a substitution of name:translit is requested.
ISO 15924 and IANA define some language subcodes, such as sr-Cyrl and sr-Latn for Serbian written in Cyrillic or Latin, but I did not find any subcode for transliterated Russian or Greek, for instance. We could of course invent such codes ourselves, but it could be controversial to add, say, name:gr-Latn and name:ru-Latn to each Greek or Russian location in the OpenStreetMap database. (It could provoke edit wars, because not everyone is following the current version of ISO 9.)