Yuri, all valid arguments I’m sure. But afaik greencaps has no intention of uploading the results of his script. His script can be used by Garmin mapmakers like me (but also others) to help in transliteration. I’m sure that some transliteration in the maps is better then having questionmarks (?) all over the place (I know, it’s especially a problem with my maps and Mkgmap).
Thank you for summarising considerations for adding transliterations to osm database. I understand your concerns. At the moment my goal is an on the fly transliterater which can be put in Lambertus’ build chain. Thank you for the links also. I will study them.
But meanwhile I will alo further develop my persistent updator.
That would be an option. But not enough as still the language had to be specified.
Agreed. I’m not familiar with vmap0, GNS and Geonames but will investigate when time comes… (Anybody who can give me a clue how to use them over the internet is kindly invited to give me a link or hint.)
I made a run for Belarus. There are 27956 nodes with place tags. 169 have name:be, 52 name:en and 11 int_name. It looks as if not to many people in Belarus are adding to osm. Why would not they write belarussian if they added by hand? By the way: looking for someone who can switch them? ;-).
Progress report.
Made a console version which reads from stdin and writes to stdout. As I have no program which would grab that output it was displayed in the console window. As I had no program also which would read the source and write it to stdout where I could read it from stdin I tested by reading from the file self.
Where my not console version takes ten minutes for 500MB the console needed an hour. But I think this is because cmd.exe displays it all in its console window.
What is your build time and how much would you give me?
Even if a tag name:ru is there like here:
119310785 Полоцк
119306895 Новополоцк
(I did not investigate how often this occurs.).
Ah, I see that you are developing under Windows… I hope you are writing portable code, because my map toolchain is running entirely under Linux…
I know from experience that displaying a lot of stuff takes a lot of extra time, so your 10 minutes-1 hour difference might have been caused by that. Don’t worrry about that too much then. Stdin and Stdout are filepointers just like a regular file under Linux.
One, two, three hours extra for processing all of Europe, Africa, Asia and Oceania is not a problem for weekly updates.
Just a word of warning for anyone about possibly using Geonames or GNS for adding to OSM …
Make sure the data for the country is up to date. I know for a fact that the names for Korea are out of date since the Korean government changed the romanization/transliteration scheme in 2000.
We are doing pretty well, though, in adding names to the Korean data. 
Robert
That is a pitty. It’s a lot of work to make it suitable for Linux.
Indeed. I rediscovered the > and < console redirecting operators. Under 10 minutes again.
Ehhh. In 3:20 the windows console version can handle a half GB file. (only copiing takes 2 minutes and twenty seconds). So for 80 GB that would be more than nine hours. Or is this a wrong calculation? Maybe it has to be done in this way: Handling time for 0.5 GB 1 min (3:20 - 2:20). So 80GB 160 min == more than 2 and the half hour. Reading/writing 7.3 GB one hour. Together three and a half hour. Add some time for uncompressing/compressing.
Ha… not two bytes. UTF-8 is multibyte (from one to six) just read the rfc 2279.
http://www.ietf.org/rfc/rfc2279.txt
From multibyte the conversion will -usually- first go to two byte unicode followed by a conversion to one byte ansi.
The Europe, Asia, Africa and Oceania split is about half the planet size. It would be interesting to see how long the conversion actually takes. Depending on the outcome I can decide to run the conversion every time or to do it once in a while. There might be room for optimization here and there as well, so an initial test run that takes a day is no problem. But your numbers are encouraging, 2.5 hours is not a problem for weekly updates.
What data does mkgmap need to make a map? I mean if I read this data from stdin:
would it be ok to only write to stdout:
Where my program takes extra time it could save the next in the link time by offering less data? Just an idea.
Notepad does also. Wordpad not. Firefox also.(no charset definition needed). Here on XP.
Tile 63240031 -covering part of Thailand- which I downloaded from Lambertus’ site contains also a lot of questionmarks. I suppose from unconverted Thai characters.
Is it possible or is the result readable/(usable in a navigator) if the characters are transliterated? If so then you could help me with defining a transliteration table. Please first confine if you want to do so. After that you will be presented a table to fill in.
Shall I split this transliteration subject off the discussion about my Garmin maps? I think this work deserves a separate topic…
That is ok for me.
But… this is all for your Garmin maps… what else?
You could use as subject: Frontend transliterator.
So, Lambertus.
Just wanted to say thank you sooo much for these maps. They make the GPS a whole lot better.
I am doing my part in helping update the map. I am a UPS driver, so I drive down multitudes of streets and see that a lot of them are named wrong in openstreetmap. But anyway, I keep my GPS in the truck with me and upload my traces to check for accuracy also.
Just wanted to say that I appreciate it and I want to do more. Is there a way I could help you update the routable maps so maybe we can get a steady weekly update?
Progress report:
The frontend transliterator runs under linux now too.
Thanks for offer but the newer Mkgmap versions have some serious changes in output which I need to accommodate. Just did not have the time to do so yet (busy integrating Nominatim in www.yournavigation.org). Probably this weekend.
Having a delivery job really enables you to do some serious tracklogging indeed. Isn’t every truck equipped with a company gps as well? If so, would it be possible to get an anonymized copy of available tracklogs? That would add an awful lot of traces…
Cool, I hope to be able to do some tests this weekend. Do you have a source or 64bit executable somewhere for download?
Every DIAD board has a GPS unit in it, but I do not believe that they use tracks. They are just in there so the supervisors can see where you are at the moment, not where you have been. Even so, I don’t have the authority to grab all the track logs, if they did track them.
Ehhh… It was not my intention to publish the source. And if I had that intention -maybe in the future- I first had to clean it up (undo from windows stuff and not for this project needed code and so on).
64 bit ?? I hear it now…
Compiled (a world of warning messages) and linked (not a single message; just refused(well until I got the right setup)) it under an old Mandrakre distribution which surely isn’t 64 bit. Would that run on your system though ?
Further my plan was to first let you try it out before it becomes public. So I wanted to send you the executable, a runtime lib (an old mandrake c++lib. On two modern live systems the executable would not run because that needed library failed. I did not yet test with that library supplied), and for about four countries the transliteration table files and boundary .gpx files.
Well, you could ask … 
Ok, if you don’t want to release the code that’s ok, it’s just that there are so many operating systems around that it might be simpler for you to provide the code instead of having to compile an executable for each os. For what it’s worth, if your application works well then I can imagine that it would be really be appreciated if you’d supply the source, so others can use and contribute to it as well.
Sorry that I didn’t tell you that my machine runs 64 bit (which I need because memory usage of many of the OSM applications requires more then 2GB), but afaik 32bit applications should work on a 64bit system. We’ll see soon enough when I try.
Still no update! :(. You must be busy. I totally understand! Hope to receive it soon!