@ligfietser, related to the correction on the Motieweg, I have a question. See the Dutch part in this forum.
Sorry, that was my mistake, I changed the url first, then copied it to my post, so requests to osm2 return urls on osm2 and osm to osm just as you said. However, I did 2 tries on osm2 and 1 on osm, but got only 1 mail from osm2 and 1 from osm, and then this morning one more that the request was queued and a download location (both on osm so I suspect you or someone else clicked my request, will remove my email from that post now). So either the mail server thought 1 email for 2 identical requests for the same email was enough (smart in a way) but then again, those 0 minutes took a long time 
So to summarize: I did 3 requests and got only two mails the request was completed, but it did work in the end.
[UPDATE] I do notice a difference in the files on osm and osm2 by the way. osm does list a typ file while osm2 doesn’t. With openfietsmap this should be included automatically shouldn’t it?
Apparently not… I just noticed the following log messages:
Splitting nodes into areas containing a maximum of 200,000 nodes each...
Area (48.779296875,2.373046875) to (49.130859375,2.548828125) contains 3,126,220 nodes but can't be split further
1 areas:
Area 63242086 covers (0x22b000,0x1b000) to (0x22f000,0x1d000) FR-Montreuil
So Paris simply cannot be subsplit further to get tiles that are max. 8 MB large because the area of these tiles would become too small. The corresponding code in Splitter is (SplittableDensityArea.java):
if (densities.getWidth() < 4 && densities.getHeight() < 4) {
System.out.println("Area " + bounds + " contains " + Utils.format(densities.getNodeCount())
+ " nodes but is already at the minimum size so can't be split further");
return Collections.singletonList(bounds);
}
So I’m trying to detect this situation in the script and -when encountered- ignore the 8MB limit to get (hopefully) a correct tile at least.
Lambertus, I remember a situation with a tile with the same issue, it couldnt be processed by mkgmap no matter how less nodes I used.
The fault was in a small way which was corrupt. When I left -ea out of the mkgmap parameters, everything went fine.
It seems you can split the tile Paris because the OFM tiles get rendered, so ignore the max size and just try to run mkgmap without -ea?
But I’m not running Splitter with the -ea Java parameter and the error + surrounding code is very clear. However I find it odd that some other Paris tiles are less wide and and others are less high:
At least the added cleanup stuff seems to be working as expected now…
The maximum tilesize for the generic map this is 8MB, for openfietsmap this is 23 MB. This difference is probably why the tile gets rendered in OFM.
Why are your tiles so small (8 mb), I know mkgmap can produce larger tiles (my largest OFM tiles are indeed around 23 MB, Full version).
Is that size intended for users with small internal memory devices?
Bingo! 
This was probably a glitch, not much I can do about it.
Yes, openfietsmap should include a typ file automatically. I’ll check for differences between both servers again.
Thanks for reporting!
Dear Lambertus,
I have downloaded the latest update (i.e. dated 2012-08-16) as I was very curious about ‘the hole in Paris’. I’ve been following the forum and I have to admit that I had the easy part in it … i.e. reporting. This version has my latest OSM updates (dated 2012-08-02), AND the hole in Paris has disappeared. It looks good. I really hope that the problem is solved.
THANKS A LOT.
Hi all,
First of all: Fantastic service, Lambertus!
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)”)
Is this a known issue? Is there a workaround?
Best Regards,
–
Jakob
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.
Hi Lambertus,
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.
Best Regards,
–
Jakob
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?).
Hello Lambertus,
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.
Many thanks,
Frans
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.
Isn’t that odd …
… the same issue exists for Netherlands and Belgium maps.
Some streets can be searched and found, some streets - which ARE shown on the map - are not found.
Just as well I haven’t dumped my Tomtom yet 
Well, in the end: after downloading the new version the problem is solved indeed. Routing along Motieweg in Open Fietsmap works again.
Thanks again.
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.
@Carnut: I get strange results when searching for Prinsengracht, too (tested in Mapsource):
Prinsengracht, Barrio Judio, Amsterdam, NLD
Prinsengracht, Ciudad de los Museos, Amsterdam, ABC
The Openfietsmap Lite shows other errors:
Prinsengracht, Jordaan, Amsterdam, NLD
Why the Jordaan? Why the Spanish names?
This has something to do with the wrong assignment of streetnames to districts, provinces and countries.
Lambertus, what are your mkgmap settings?
I use
bounds: bounds
location-autofill: bounds,is-in,nearest
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.
tks,
Piet.