Regarding the New Zealand problem where the map only shows at certain zoom levels, I too have been frustrated by it since September of last year and I have tried many different downloads but with the same result. I have since been using the NZ OpenGPS Maps and while they have been working fine and will suffice for an upcoming bicycle tour that I am planning for the next NZ summer season, I would prefer to use OpenStreetMap as there is more detail available (minor ferries are missing in NZ OpenGPS).
A thought occurred to me that perhaps the problem is with the eastern edge of the tiles being right at the 180 degree east line. Could you try a build with the tile edge at 179 degrees east and see if that fixes the problem?
Hi again. I just did a test and downloaded the Russian tile that borders the 180 degree East longitude and it exhibits the same behavior as does New Zealand in that I can see the coastline at the 500 km scale but when I zoom in it disappears. However when I select a small piece of coastline and move my mouse over it, it shows the name “Coastline” and names of other details, but not the map itself.
I strongly suggest that it is an edge of the world problem. (Here ye find dragons and other manner of strange beasts!) Perhaps the solution would be to tile to 179 degrees 59 minutes, not 180 degrees.
Peter, I’ve confirmed the problem by just looking at the NZ Auckland tile. It’s quite possible that the 180 degree line is the problem, but how and where (i.e. Splitter or Mkgmap). I’ll gather some data to test with and write about this to the Mkgmap dev list.
Funny thing is that I can zoom in normally to 100 km, but one step further and the map disappears. Then, if I move the map to the left (i.e. scroll towards the 180 degree line) the map shows up again and when I zoom in again the map disappears again. This process can be repeated a few times more, but you end up looking at the empty ocean off the east-coast of the Northern Island in closeup.
Thanks for your report.
Edit: Ah, now I see. The problem also appears if you zoom in on the western part of the tile. You can keep zooming in as long as you keep a tile edge visible in the screen, but this doesn’t apply for the top or bottom tile edge; only the vertical tile edges. As soon as you scroll the left or right tile edge out the window the map disappears.
I have encountered a problem with a new version of a map for MAPSOURCE. In the original map there are areas where the lines of a border of region collide with the lines of roads. When you convert OSM into MAPSOURCE theese colided road disappear. As a result in last version of map there is a lack of roads, really miss half of all roads. http://www.openstreetmap.org/?lat=-0.4005&lon=-78.54222&zoom=15&layers=M
That is unfortunate. I’m filtering all lower administrative borders from the OSM data (because they clutter the map) for a long time already. But when those lines are also used for roads… I’ll have to think about a solution…
Thanks for your work Lambertus. I have downloaded a custom map from the tiles covering my area (Canberra, Australia) and installed it via mapsource and then after removing that installation I tried using the version for direct copy to my Garmin directory on my device (Garmin Edge 800). Both times the map installed and appears on my device and is enabled but when I try to navigate with the device I get an error message telling me that there are no routable roads in my area. Could this be true? Any known issues with some Garmin devices such as Edge 800? Any suggestions?
I’ve downloaded and installed the Canberra tile in MapSource and I can route across Canberra just fine. Can you post the link to your custom map download?
but I have the same problem. The maps are on the device and enabled but if I attempt to navigate with my Edge 800 I get the error message that there are no routable maps in my area. The Edge 800 is fairly new release and the cynic in me wonders if Garmin has made it less than perfect with maps it does not sell.
Of course before I try another osm map I remove any previous one from the device.
You are a legend and I’m a goose. I read all the instructions and still managed to download the entire Australian land mass EXCEPT my area. I’ve downloaded just my area and yes, it works!! I’ve spent days on this. It’s cold and dark outside just now but I’m so tempted to jump on my bike and do a route. Thanks again so much for your help.
Sorry if you have been all thru this before but I’m confused.
I can pick a country and download osm_routable_gmapsupp.zip. I can extract the file and add it to the Garmin directory on my Edge 800 or on its SD card and it works fine. I want to download two other countries I will be riding through soon. There can only be one gmapsupp.img of course. Can I just rename them France.img, Switzerland.img, Austria.img and all will work or do I have to somehow use JaVaWa to change the names so the maps will work seemlessly? If I need to use JaVaWa the maps need to be installed on my computer first so I guess I need to download the osm_routable_mapsource.exe files for each country, install them in mapsource and then use JaVaWa to rename them. Is this correct?
No, because most of the simpler GPS’s only recognise one img and that’s “gmapsupp.img”. You need to merge the different maps together into one gmapsupp.img and upload that to the GPS. Only renaming won’t help.
Almost. Install a country map and rename it (change the product id too). Install a second map and do the same. Repeat until you have all the maps installed. Run MapSource and select all the tiles from the different maps and have MapSource merge them into a gmapsupp.img and upload it to the GPS.
Btw, there are other methods too (e.g. using MapSend or Mkgmap).
Well, I’m trying to do a weekly update so it’s not that the updates will be exactly on schedule every week.
The cause of this weeks delay perhaps a bit silly, but we have had some thunderstorms lately (also at night when I run the update mostly) and I have twice experienced a strike that destroyed my electric inventory (only an old bedside alarmclock survived both impacts) so I’m a bit paranoid when it comes to that. I don’t want to risk my shiny new Core i5 system. Anyway, the weather is better again so I’ll run upstairs now to start a new update.
There’s a new trick this time: I’ve updated the scripts to use Osmosis to update an older planet with changesets instead of downloading the entire planet everytime. So, in theory, I could start an update every day now instead of needing 4 days. I won’t do that, but at least I can start an update any day and have the latest data available.
Also, the planet file is in PBF format which is handled more quickly then the usual XML format and together with the new machine the setup can churn out an update in a day. Most of the time is now needed for uploading the update to one of the servers (over a 1 Mbit ADSL connection), it takes about 15 hours…
Thanks for the info. Not silly at all, you don’t want to risk your $$$ when you can safely do it another time.
What surprises me is that you don’t run the update processing on the servers. You do this at home? I always thought that this part was automated on the server.
Pre-processing has always been at home. The first server never had the disk space, memory or computing power to do an update while rendering maps for users at the same time. It came not even close.
With the arrival of the extra server (and hopefully yet another one later) this situation hasn’t really changed: disk space and computing power is now plenty available but it’s still not possible to run an update while at the same time producing maps due to memory restrictions (you’d need about 8GB ram to do that, at least more then 4), even though some of the tools like Splitter have become more memory friendly. Some of the larger user requested maps easily use 3 GB ram while combining the gmapsupp.img.
It’s possible though that, with a bit of management, the map update could run on one of the servers. I must add that I haven’t really looked at optimising things for such a situation.
The custom map server is now able to process multiple requests at the same time. The server has a quadcore CPU and till now the map generation speed was limited by the speed of a single CPU core processing a single request at the time. Now up to three requests are being rendered at the same time. This should reduce the queue on the custom map server even more and is now mostly restricted to the available disk space (if there isn’t enough free disk space the processing stops until enough disk space is available again).
Unfortunately, while making this possible, I introduced a bug in the last version just before going to bed the evening before yesterday. And it happened that this bug was rather nasty: the same request was being processed by ever more threads. As you can imagine, system memory ran out quickly and the whole server stopped dead in it’s track. It even managed to corrupt the filesystem.
The next day I discovered that the server didn’t respond anymore, so I emailed the administrator to ask what was going on and he told me there was some process eating all the memory…uh oh… you can imagine I got a nasty taste about that last update when he said that…
On top of that pressure at work was severely mounting so I couldn’t do anything while being there. So late yesterday evening I was finally able to stop the processing and fix the bug after the server was rebooted once more.
See the Munin screenshot below which shows the number of simultaneously running processes on the server:
Now there is probably one person in the world that I owe a very big apology. The bug probably caused the server to send a heck of a lot of emails to one email address telling that the map was ready over and over again. Unfortunate person, if you read this: I’m very sorry!
