Next: Sorry if my issue has been addressed before, but I have browsed through all 64 pages of this thread without locating the answer: I am trying to download a combined map of Denmark + Germany, but I think I might have hit an upper limit:
If I select Germany only: No problem (Germany is a cached download).
If I then turn manual selection on and try to add one (1) more tile, the server times out before responding.
(The actual answer in Chrome is “Error 324 (net::ERR_EMPTY_RESPONSE)”)
I suspect that this is somehow a capacity issue, as the URL is both long and includes 253 named tiles. (Something like
```
http://osm2.pleiades.uni-wuppertal.de/garmin/request-combine.php?map=generic&version=16-08-2012&typ=&country=&email=email%40address.com&tile0=63240004.img&tile1=63240008.img&tile2=63240016.img&tile3=63240024.img [...] &tile253=63242712.img
```
).
Sorry Jakob, an empty variable prevented the new update to be distributed to the custom map server. This is now fixed, requesting custom maps should work again.
If noone else has this error, of course it’s then an issue in my setup. It’s still there, and as I suspected the browser for mistreating the quite long URL, I have just tried with both Internet Explorer 8, Chrome 18.0.1025.162 and Firefox 14.0.1 with the same result:
When requesting a custom map with a lot of tiles in it (e.g. Germany and one extra tile = 253 tiles), the browser submits the request, waits for ~ 15-20 seconds and then responds that the connection to the server was reset. (Firefox states that the connection was reset “during download”, Chrome states that the connection was reset “by the server”).
I’ll continue locating the error (next step is to try the same from another internet location) and let you know.
Strange, I just tried that (Germany+one extra tile) and no problem at all here. Hopefully you’ll find the problem (could be a firewall/virusscanner thing maybe?).
First of all, I would like to express my appreciation for the services provided through this website, fantastic! Last Friday I purchased a Garmin Dakota 20, the immediate cause being a holiday trip to Iceland. The Iceland map shows a fair level of detail, no doubt it will prove useful.
As a trial I downloaded maps for Netherlands, Belgium and Germany and made a trip today in the Ardennes and Eifel area. Although not as convenient to use as my Tomtom, the Garmin works quite well for car navigation, and the maps are fine.
One question crops up. I downloaded the maps for Netherlands and Belgium as a zipped .img, for Germany I got the executable for Windows. In the Germany map I can search a city, but not a street (using my GPS device) whereas in the other maps streetnames can be searched. Is there a way to enable street search in the Germany map?
Also, please could you list the differences between just copying the .img to the GPS device versus installing a map through the .exe file using Basecamp.
Thanks for the compliments. No idea why the streetnames aren’t searchable in the Germany maps as every map is created with the same parameters. This points to some OpenStreetMap data problem or (dare I say it :p) user error…
If you leave me the choice I’d say it’s a data problem I tried again, and it turns out that when using a street name shown on the OpenStreetMap the search does work for some streets. On the other hand, it doesn’t find certain streets which can hardly be called alleys. Petuelring in Munich is one of those. I did check the spelling, of course, and this street IS shown on the map.
Just discovered that for some larger cities the map data includes multiple entries. For example, Amsterdam has 4, among which “Amsterdam, NLD” (A) and “Amsterdam, Amsterdam” (B). A search for “Prinsengracht” using (A) fails, whereas the same search using (B) resulted in a hit.
The solution could be not to specify a city when doing an address search - this works as long as the name of the destination street is not too common.
bounds file is from http://www.navmaps.eu/wanmil/ (The one I use in my OFM is from 22/01/2012, maybe later versions has some errors/holes?)
I suspect the map chooses too often the nearest district instead of the admin. country boundaries, maybe because they are broken in Wanmil’s latest database?
And why does it choose the Spanish names instead of the Dutch in the General map?
As a very grateful user of the maps provided by Lambertus, I loaded the UK map on my Garmin for our holiday in Scotland. As always excellent data, and those little things that were missing, well, we can live with those.
However, this time, when driving past Loch Ness, I suddenly realised it didnt show on my Garmin (you understand I was more looking for Nessie through the carwindow :D).
Back home I checked the map in Mapsource and Basecamp, and found this famous Loch doesnt show there either. It is in Openstreetmap, and shows on the website, but it seems there is something fishy with the data. I download the UK fresh, and loaded this new version in Mapsource, but with the same result.
I am not proficient enough to understand why it doesnt show. In the past I have seen this when a waterbody wasn’t ‘closed’, but that doesnt seem to be the case here. The only difference between Loch Ness and Loch Lochy (that does show correctly) is that the object Loch Ness shares nodes with other objects around it (e.g. wood, forest). Not sure if that is the cause of this error.
Appreciate if somebody can shed some light on this.
to your logging.properties file. Read http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging how to enable logging. The logfile contains one line for each OSM element (Node/Way, osm id, and the value for each admin level 11-1). So when you know the osm id of the wrong Prinsengracht you can check the logfile if the bounds values are assigned correctly.
I propose to compile only the tile containing the Prinsengracht because the logfile will become quite big
The latest boundaries are from July 8th so the redaction bot was not started yet.
If you cannot solve the problem yourself please give me exact details about the data and the mkgmap parameters you use. I can then have a look on it.
Thanks Wanmil, since it is not just a single street but seems very widespread all over the world, I have to know which mkgmap settings Lambertus is using.
About the issue from PJS, this seems also related to mkgmap and the splitter. I notice it happens with big polygons (lakes, forests) when they are located in different tiles.
Somehow the polygons are broken and so the lakes are dry or forests not green. Making the overlap higher (5000 or even 10000) can solve the problem, but this is a workaround. Is it possible to fix this in mkgmap or the splitter?
Wrong assignments of city/region/country to some streets
=> Use the mkgmap logger to track down the problem.
Some big polygons that overlap the tile bbox are not rendered.
=> In case the big polygon is a single polygon and not a multipolygon it should be rendered. Please post some details so I can have a look on it.
In case it is a multipolygon it is very difficult to fix. In this case the splitter would require a mulitpolygon handling which requires an additional pass and makes splitter much slower. There have been several discussions on the dev list without any good idea how to fix this…
Ok, I’ve had a look at Loch Ness myself. It is a single polygon so it should be rendered. Can you please give me the splitter areas.list file so that i can try to reproduce the problem? Thanks
I’ve checked Loch Ness. The reason that it does not appear in the map is located in the default style file. The relevant tags of Loch Ness are:
name=Loch Ness
natural=water
tourism=attraction
This matches the rule in the default style polygons file
tourism=* & area!=no & waterway!=* [0x13 resolution 24]
The rule for natural=water is contained in the waters style which is included by the default style. AFAIK included styles are processed after the style itself so the tourism rule matches first and the natural=water rule is not used for Loch Ness.
Thanks for the speedy replies, however not sure what the solution is.
Can the processing be changed so the natural=water will be processed, or should we just remove the tourism tag from Loch Ness. Its first and foremost a body of water, and there are more lochs that would qualify as an attraction, which arent tagged as such.
I don’t know the current tagging rules very good so I cannot say if it is a good solution to remove the tourism tag. I fear it’s not because “do not tag for renderers”…
I tried again, and it turns out that when using a street name shown on the OpenStreetMap the search does work for some streets. On the other hand, it doesn’t find certain streets which can hardly be called alleys. Petuelring in Munich is one of those. I did check the spelling, of course, and this street IS shown on the map.
