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!
Relax, the maps are being uploaded since yesterday evening which takes 13 hours with my current internet connection (1 Mbit uplink).
Edit: the upload is finished.
This version has some new features: better address search (autocompletion support using the MDR file) and a new MapSource installer (Mkgmap’s built-in one, instead of my own). The maps now have a family id and are installed in another directory. I hope it doesn’t introduce new bugs.
It’s probably best to cleanup previously installed OpenStreetMap routable world maps first before you install the new one
AWESOME!!! SWEET! You are doing an awesome job! I’m still new with this, so please forgive me!
No problem, just remember we’re all volunteers and spare time is scarce for everyone