You can compile them yourself with mkgmap or look for a map provider that makes them. I know there are OSM garmin maps in Japanese, but I dont know any maps in Chinese. See http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download
Maybe ask and look around in the Chinese OSM community.
you asked me via Mail, if I can see Chinese words on Garmin. Sorry, I’m not using Garmin. I’m using Osmand on Android. This can display Chinese as well. You can select the language you prefere.
Hello, thanks for the great map generation service!
Unfortunately, the bug of not creating gmapsupp.img files has returned. I’ve tried creating generic routable, generic routable modern style, and generic routable maps starting with UK selected. In all three cases I’m getting groups of individual img files, but no gmapsupp.img file.
One map process was run last night, the other two this morning. Here are the map notices:
One of the maps from tim_time uses the following tiles from generic_new:
63240776.img
63240777.img
63240781.img
63240782.img
63240783.img
63240784.img
63240785.img
From the buildlog:
Mkgmap version for rendering is: r3605
Mkgmap version for map building is: r3492
Apparently I forgot to update Mkgmap on the map building server…this might be a hit to the problem. However, the red tiles near Strasbourg and in Northern Germany indicate a problem during the render stage. The logfile of the render stage is 19GB! Talking about a haystack…
Edit:
The tiles above rendered without any problems. No subsplitting needed and no Mkgmap MapFail- nor Exit-exceptions. This suggests that the difference in Mkgamp version is the culprit: I’ve updated the Mkgmap version on the build server.
Edit:
I’ve requested a custom map covering most of Germany and the resulting map compiled fine. So it looks like this problem is solved.
Searching for the cause of the problem with Strasbourg I notice the following error in the logfile:
This error repeats many times and it seems it keeps Mkgmap in a loop because Mkgmap get’s killed by my script due to a timeout after 900s (15 minutes). A normal tile render takes about 50 seconds.
The OSM source file is then subsplit and each individual tile is rendered. Now I get the following error many times:
And the process repeats itself. The result is the small missing tile near Strasbourg.
Edit:
Looking for the error I get more hits in the logfile, e.g.:
Edit:
Source file 63241604.o5m contains such problem addresses as does 63241741.o5m.
Latest on February this year I made a download of Germany (whole country, from the dropbox)
with garmin.openstreetmap.nl
Everything was ok.
Today I wanted to do the same. Normally I got the message “Download map now”, but now the
map has to be build at first, and an info will be sent via email.
When I got the email and clicked the shown URL, the file “osm_generic_gmapsupp.zip” for direct
use on the SD card is missing.
When I was checking Austria or UK this file is provided, for instance for France it is missing, too.
Does this perhaps belong to the two red marked tiles (one to the right of the town Schwerin in
Germany, one to the left of Strasbourg in France)?
Many thanks for this! I’ve just downloaded New England and California/Nevada/Arizona to compliment my CNNA v8. Is there any way to rename the map set from **OSM generic routable **to something more descriptive?
Hello,
Thanks for your support with the gmapsupp.img problem. It is not working yet, but there do appear to be improvements. I now get a file link that correctly shows the file directory. Previously, there were not as many file entries as I am used to seeing. The osm generic folder has a reasonably sized gmapsupp.img file, but when I put the file on my garmin it does not recognize it as a valid file. I also tried the file on a newer garmin that allows multiple map files at one time, and it sees all the map files except my currently made one. I tried making a map file last night, and other today, but neither one is working correctly. Here’s the most recent map request:
I found it interesting that the link was identical to the map request made last night. Perhaps the server is smart enough to realize it has already made this map, and just re-sends the link? But if this was the case, why would it take some time to build the map?
My GPSMap60 does not complain about the gmapsupp.img.
Yes, the server is smart enough to notice it already created the map. The waiting time is simply because your request lingers in the queue for a while until earlier requests are finished.