Worldwide routable Garmin maps: URL REMOVED

No problem: http://planetosm.oxilion.nl/~lambertus/garmin/routable/02-04-2009/ef27ca071f1ad72b8c7d1a2cb623e403

Well, it looks like the disk wasn’t full at the time your request was processed. It could be that the RoadTrip script is a bit too sensitive to errors like missing tiles (You included some missing tiles in your request) and simply gives up. I’ll look into that.

Yeah, I saw there were missing tiles, but I decided to try it anyway :slight_smile:

-peter

Excellent work, that page!
Already downloaded Germany and put the gmapsupp file on my Vista HCx,
looks fine, the only thing is that the sea has the same color as the land,
only the coastline is blue.

Hi Lambertus,

thank you for your use! Unfortunately, I understand something not.If I download a region, the card is not as current, as shown on the website! Why? Thanks for the information in advance,
Gruß, Stefan

The website is updated on a daily basis while these Garmin maps are updated once a week. In a worst case scenario it is possible that a change in the OSM database will be visible on the Garmin map after two weeks.

Thank you for the quick reply. Hm, I have a file on 12.04.09 and the other loaded today. On the website was linked to two days, the current map, as the downloaded file. So it says in 2 weeks to try again?

If you uploaded the change to the OSM database before last wednesday then the change should be in the Garmin maps that will be released next week. If you uploaded after last tuesday then you will have to wait at least a week before the change is visible in the Garmin map.

But the changes (roads, pathways) are shown on the map on the website already exists. Only in the downloaded map, they are absent. But still I wait 2 weeks. Thank you.

Der Findemechanismus für die Garminkarten funktioniert schon, aber beim errechne der Route stürzt mein Edge 705 und GPSMAP60CX ab.
Da muß es einen Fehler geben.

The Findingmechanism for Adresses seems to work, but my Edge705 und GPSMAP60CX is freezing when it calculates the Route to the Adress.
This should be a Bug

Gruß Sven S.

Concerning the Romanian characters; sorry for the long delay.

What works for me is
–xcode-page=1250 --charset=windows-1250
However, another problem arises: there are some cases where the same letter is represented with two different characters from two different encodings: for instance there is s with cedilla in ISO 8859-2 (latin-2 or codepage 1250) and s with comma underneath in ISO 8859-16 (latin-10). And guess what: they are both present on the OSM maps of Romania. I could find a workaround by replacing in a hex editor latin-10 characters with latin-2 (I used the OSM format), and the result looks well on my nüvi 255. Maybe this replacement could be done directly in mkgmap.

And for the maps on your server, maybe it is better in this case to leave mkgmap make the conversion to ASCII, it is easier to read a map where is written “Manastur” instead of “M?n??tur”. Can your script do this only for the tiles concerned?

All those different charsets, they really give me a headache :frowning: So it appears that the correct charset for each Garmin device/software may vary which would make it really difficult to make maps for.

It is possible to specify different mkgmap parameters for each file, but I’m afraid that there is just no single perfect setting for each tile like you describe. Question as I’m not an expert on charsets; would it be possible to enforce a definitive charset in the OSM database? I assume mkgmap is not the only application encountering this problem…

What could be a workaround is to use the mkgmap option to prioritize the name tag so that the ‘int_name’ value will be chosen over the ‘name’ value so that the maps become internationally usable, e.g.

--name-tag-list=int_name,name:en,name

Offtopic rant:
What’s up with German speaking people’s state of mind in general? Every time a really large request is made (like all of Africa and Europe and Asia or the America’s or even the whole world) and I check the email address it’s bound to be one that ends with .de or .at or .ch. Currently there is even one German requesting the whole world three times but with minor differences. This causes enormous delays for users that also want to download just a few tiles. Are they traveling so often and far to really need all those tiles?

There’s a notice on the top of the website for over a week that asks users to restrain themselves, but if this behavior continues then i’ll have to implement tilecount limits or take the site down because of excessive bandwidth usage. So again, please download only what you really need…

I had to add a limit on the number of tiles unfortunately, it is really needed if this service is to last any longer. There are so many users requesting e.g. all of Europe, Asia, Oceania and Africa combined that storage is a permanent problem and bandwidth usage is excessive.

I’m really sorry I had to do this but there are simply too many people who are apparently going on a journey around the world.

Is it possible for you then to create a Garmin map of the whole world, which can be downloaded separately?

In gmapsupp.img format or for MapSource/RoadTrip? Are Garmin GPS devices capable of loading the whole world anyway?

A more relevant question would be: “Why would you really need the whole world?”

I don’t know why someone would need the whole world… but apparently there are people who need it. So, I would suggest to create all files for the whole world, this decreases the server load because it isn’t needed to create a new mapset every time. If people request too much tiles then, it is possible to send them to the file of the whole world.

There already was such a simple ‘catchall’ where every request with more then 70% of the tiles would request all the tiles automatically (thus those requests could be cached). But all of Europe, Asia, Africa and Oceania is only 1/3 of all available tiles (maybe even less) and there are many variants in requesting all those tiles (one tile more or less is a different request) so such a simple optimization is not working for those requests.

An alternative could be to prepare precombined maps of e.g. the continents which I can perfectly do ofcourse, but Rullzer’s question intrigues me as well: why do people want such large areas and do I need to cater for those needs?

Another alternative would be to provide a Java webstart application that generates and compiles the Garmin maps on the user’ computer instead of the server. The server would only need to host the source osm files and the latest version of the Java application.

Lambertus, the main cause is the huge amount of data and the high update rate. As you offer a whole new world every week, it is very tempting to download it especially for those people with a high bandwidth. What’s the size of the world? I’d guess it’s around 4GB – that’s nothing for a fast DSL connection and a flat rate.

As rullzer said correctly, nobody really needs the whole world. Maybe we see something that goes back to the “good old” Navteq days where new maps were emitted just once a year. “Back then” it perfectly made sense to put all the data onto the satnav and wait until the next update. Garmin now offers new maps every three months – I wonder how long it takes until people get annoyed because each new map is virtually the same as the previous one.

What can be done about all this? First of all I strongly suggest that you change your update policy from weekly to monthly. The OSM maps are only useful when a region already is mapped quite well, which in turn implies that there aren’t too many changes/updates.

Second, I wonder how your script is really working because you suggest a client side map creation that involves downloading osm files. mkgmap can combine several img files to a gmapsupp.img, so you just need precompiled images on the server. The question is, however, whether your server is short on CPU power or on network bandwidth.

Third, the theoretically best approach would be a revision control like that from CVS or subversion. You only have to download tiles that have changed since the last access. I am not sure if this would really be feasible because a single edit (such as a POI) would mark the complete tile as changed.

Last, the most practical solution could be to divide the world into some useful areas like Europe or North America and provide precompiled individual MapSource maps for these. This, along with a limit on the update rate, could reduce both CPU and bandwidth requirements on the server. At the same time, users could still compile one gmapsupp.img from all the continents using MapSource.

I was wondering if people want to publish a mirror list for each region to ease the bandwidth for your server
eg is you have common requests for updates based on regions they could download weekly and then people would be directed to local mirror