Currently I use the Open FietsMap from garmin.openstreetmap.nl for cycling with the gps.
When I create a route (not a track) I notice that since the july version there is a strange point in the Motieweg (Holten). In this point routing stops, both Mapsource and Basecamp don’t let you pass this point anymore. The road goes from tertiary to unclassified and a path connects in the same point.
Other OSM maps (like OMTB map) don’t show this problem. Only Open FietsMap does.
In Potlatch I can’t see what could be the cause. Joining the nodes didn’t help.
Any idea?
Hi GRI, I have corrected the node in the Motieweg at the point where the footway connects. The end-node of the footway was placed on top of the Motieweg node, but was not connected. Routing should be ok now, but may take some time before it is effective in downloaded maps. http://www.openstreetmap.org/?lat=52.297415&lon=6.418943&zoom=18&layers=M
Well, after working through thousands of lines of logging again (one map update results in 127.000 lines of logging :/), the source of the problem for Paris is found: When Splitter still cannot split the initial Paris tile in at least two subtiles using the parameter max-nodes=100.000 (remember: the initial split is using max-nodes=1.400.000!) the script simply gives up. Apparently Paris is the most complex area in OSM and the script is giving up too early.
Random other tiles are included as tiles for Paris because not everything is cleaned-up after giving up (especially the XML files that contain the tile definitions from the splitting action).
Phiew, finally! 
The necessary changes to the scripts are made (lowest max-nodes is now 10.000 but the change to the code wasn’t as straight forward as it looks). A new update is underway. Hopefully I didn’t introduce new bugs…
BTW, it would increase the speed of the rendering tremendously when Splitter could simply be ordered to output N files instead of providing a max-nodes parameter. This would eliminate potentially up to 23 split attempts on each initial tile (currently the initial split results in about 1900 tiles and the final result consists of about 2700 tiles).
I tried to download a map of BeNeLux, DE and part of France, from server osm2, which sends a mail fine that my request was queued but then nothing happens. It says I’m #0 in the queue but I get no confirmation that my map is complete. Then I changed the url to point to osm instead of osm2 and now I’m at #1 instead of #0 which looks more healthy, now waiting for a confirmation that it finished compiling my map.
For completeness URL’s of my request on osm2:
http://osm2.pleiades.uni-wuppertal.de/garmin/request-combine.php?map=openfietsmap_lite&version=09-08-2012&typ=&country=&email=&tile0=63240004.img&tile1=63240008.img&tile2=63240012.img&tile3=63240016.img&tile4=63240020.img&tile5=63240024.img&tile6=63240028.img&tile7=63240032.img&tile8=63240036.img&tile9=63240040.img&tile10=63240044.img&tile11=63240048.img&tile12=63240052.img&tile13=63240056.img&tile14=63240060.img&tile15=63240064.img&tile16=63240068.img&tile17=63240072.img&tile18=63240076.img&tile19=63240080.img&tile20=63240084.img&tile21=63240088.img&tile22=63240092.img&tile23=63240096.img&tile24=63240100.img&tile25=63240104.img&tile26=63240108.img&tile27=63240116.img&tile28=63240120.img&tile29=63240122.img&tile30=63240124.img&tile31=63240126.img&tile32=63240128.img&tile33=63240132.img&tile34=63240134.img&tile35=63240136.img&tile36=63240140.img&tile37=63240142.img&tile38=63240148.img&tile39=63240152.img&tile40=63240156.img&tile41=63240158.img&tile42=63240160.img&tile43=63240164.img&tile44=63240172.img&tile45=63240174.img&tile46=63240176.img&tile47=63240180.img&tile48=63240184.img&tile49=63240188.img&tile50=63240190.img&tile51=63240192.img&tile52=63240194.img&tile53=63240196.img&tile54=63240204.img&tile55=63240206.img&tile56=63240208.img&tile57=63240212.img&tile58=63240216.img&tile59=63240220.img&tile60=63240222.img&tile61=63240224.img&tile62=63240228.img&tile63=63240234.img&tile64=63240236.img&tile65=63240238.img&tile66=63240240.img&tile67=63240244.img&tile68=63240248.img&tile69=63240252.img&tile70=63240254.img&tile71=63240256.img&tile72=63240258.img&tile73=63240260.img&tile74=63240268.img&tile75=63240270.img&tile76=63240276.img&tile77=63240284.img&tile78=63240286.img&tile79=63240288.img&tile80=63240292.img&tile81=63240300.img&tile82=63240302.img&tile83=63240304.img&tile84=63240308.img&tile85=63240318.img&tile86=63240320.img&tile87=63240322.img&tile88=63240324.img&tile89=63240334.img&tile90=63240340.img&tile91=63240342.img&tile92=63240344.img&tile93=63240352.img&tile94=63240354.img&tile95=63240356.img&tile96=63240362.img&tile97=63240366.img&tile98=63240368.img&tile99=63240372.img&tile100=63240376.img&tile101=63240382.img&tile102=63240384.img&tile103=63240386.img&tile104=63240388.img&tile105=63240398.img&tile106=63240404.img&tile107=63240408.img&tile108=63240414.img&tile109=63240416.img&tile110=63240420.img&tile111=63240430.img&tile112=63240432.img&tile113=63240436.img&tile114=63240440.img&tile115=63240446.img&tile116=63240448.img&tile117=63240450.img&tile118=63240452.img&tile119=63240464.img&tile120=63240468.img&tile121=63240472.img&tile122=63240478.img&tile123=63240480.img&tile124=63240484.img&tile125=63240496.img&tile126=63240500.img&tile127=63240504.img&tile128=63240510.img&tile129=63240512.img&tile130=63240514.img&tile131=63240516.img&tile132=63240532.img&tile133=63240537.img&tile134=63240549.img&tile135=63240553.img&tile136=63240561.img&tile137=63240585.img&tile138=63240593.img&tile139=63240597.img&tile140=63240613.img&tile141=63240615.img&tile142=63240617.img&tile143=63240619.img&tile144=63240635.img&tile145=63240639.img&tile146=63240645.img&tile147=63240647.img&tile148=63240663.img&tile149=63240667.img&tile150=63240671.img&tile151=63240677.img&tile152=63240679.img&tile153=63240681.img&tile154=63240683.img&tile155=63240695.img&tile156=63240699.img&tile157=63240709.img&tile158=63240711.img&tile159=63240715.img&tile160=63240727.img&tile161=63240731.img&tile162=63240735.img&tile163=63240741.img&tile164=63240743.img&tile165=63240745.img&tile166=63240747.img&tile167=63240751.img&tile168=63240759.img&tile169=63240763.img&tile170=63240773.img&tile171=63240775.img&tile172=63240779.img&tile173=63240791.img&tile174=63240795.img&tile175=63240799.img&tile176=63240807.img&tile177=63240809.img&tile178=63240811.img&tile179=63240815.img&tile180=63240823.img&tile181=63240827.img&tile182=63240837.img&tile183=63240839.img&tile184=63240841.img&tile185=63240843.img&tile186=63240847.img&tile187=63240861.img&tile188=63240863.img&tile189=63240869.img&tile190=63240871.img&tile191=63240873.img&tile192=63240879.img&tile193=63240895.img&tile194=63240901.img&tile195=63240903.img&tile196=63240911.img&tile197=63240913.img&tile198=63240927.img&tile199=63240933.img&tile200=63240935.img&tile201=63240937.img&tile202=63240943.img&tile203=63240959.img&tile204=63240965.img&tile205=63240967.img&tile206=63240983.img&tile207=63240989.img&tile208=63240997.img&tile209=63240999.img&tile210=63241001.img&tile211=63241015.img&tile212=63241029.img&tile213=63241031.img&tile214=63241047.img&tile215=63241061.img&tile216=63241063.img&tile217=63241065.img&tile218=63241079.img&tile219=63241093.img&tile220=63241095.img&tile221=63241097.img&tile222=63241111.img&tile223=63241117.img&tile224=63241125.img&tile225=63241127.img&tile226=63241129.img&tile227=63241143.img&tile228=63241157.img&tile229=63241159.img&tile230=63241161.img&tile231=63241175.img&tile232=63241189.img&tile233=63241191.img&tile234=63241193.img&tile235=63241207.img&tile236=63241215.img&tile237=63241219.img&tile238=63241235.img&tile239=63241237.img&tile240=63241251.img&tile241=63241269.img&tile242=63241279.img&tile243=63241283.img&tile244=63241285.img&tile245=63241299.img&tile246=63241301.img&tile247=63241311.img&tile248=63241315.img&tile249=63241317.img&tile250=63241321.img&tile251=63241331.img&tile252=63241333.img&tile253=63241343.img&tile254=63241347.img&tile255=63241363.img&tile256=63241365.img&tile257=63241379.img&tile258=63241395.img&tile259=63241397.img&tile260=63241407.img&tile261=63241411.img&tile262=63241431.img&tile263=63241435.img&tile264=63241455.img&tile265=63241463.img&tile266=63241495.img&tile267=63241499.img&tile268=63241527.img&tile269=63241559.img&tile270=63241563.img&tile271=63241583.img&tile272=63241591.img&tile273=63241603.img&tile274=63241623.img&tile275=63241627.img&tile276=63241639.img&tile277=63241655.img&tile278=63241659.img&tile279=63241687.img&tile280=63241691.img&tile281=63241703.img&tile282=63241719.img&tile283=63241723.img&tile284=63241735.img&tile285=63241751.img&tile286=63241755.img&tile287=63241767.img&tile288=63241783.img&tile289=63241787.img&tile290=63241799.img&tile291=63241803.img&tile292=63241815.img&tile293=63241819.img&tile294=63241831.img&tile295=63241835.img&tile296=63241847.img&tile297=63241851.img&tile298=63241863.img&tile299=63241867.img&tile300=63241879.img&tile301=63241883.img&tile302=63241895.img&tile303=63241899.img&tile304=63241911.img&tile305=63241915.img&tile306=63241927.img&tile307=63241931.img
Resulting URL (refreshing the request in the browser showed the caching works fine, I got the same URL twice):
http://osm2.pleiades.uni-wuppertal.de/garmin/status.php?id=f2950cc8f9d93309d294c0afc7b824f5
When I change osm2 to osm in the request URL I get the same queue URL except on server 1
[UPDATE] Finally got a confirmation mail from osm(1), which pointed me to a download location on osm2, which works fine, so I guess there is something wrong with the queue/processing on osm2, although it provides the files just fine.
Both servers are capable of generating each type of map (generic/openfietsmap and custom/country) but the website directs country map requests to server ‘osm’ and the custom map requests to server ‘osm2’. If you manually change the URL from ‘osm2’ to ‘osm’ and refresh you’ll get the same map but from a different server.
It is very unlikely that you got an email from ‘osm’ which points you to ‘osm2’ since the URL is hardcoded in the scripts. Can you forward the email including the headers to me?
When I request a custom map the osm2 server responds normally, so I cannot reproduce the behavior you describe.
Thanks.
However: routing over the Motieweg didn’t work (continuing from the tertiary part to the unclassified part). And only in Openfietsmap, latest 2 versions that I downloaded from garmin.openstreetmap.nl.
This sounds like another problem?
GRi, please read what Bikepc wrote:
The maps from garmin.openstreetmap.nl are not rendered every minute, it may take a week (or more) before the next update is available, so please be patient.
@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