Hi Beddhist,
Yes, when I zoom in the street shows up on the Nüvi satnav (and web openstreetmap.org). But I can’t search for it.
So the problem is that the name isn’t making it to the searchable index on the satnav. E.g. Eureka street in San Francisco.
I’ve switched to another tool to generate the MacOSX version due to a bug in the gmapi-builder script concerning TYP-files. The new tool is the commandline interface version of JaVaWa’s MapConverter. Many thanks for Jaco for providing this tool.
Both servers should now also be creating valid gmapi containers when a TYP file is included.
The first update after the second server has been added is underway and -you’ve probably guessed it- the update isn’t going as smooth as hoped. The version on the website was already updated before the files were distributed to the second server, about 10-20 people have requested maps that don’t contain any data. I’ve deleted these requests, so if your browser is returning 404 Not Found then it’s best to request your map again. I’m sorry for any inconvenience.
The map data for the generic map is now distributed successfully. The openfietsmap data is still being rendered and should be released in about 24 hours.
The problem in which the tiles of Paris France are misconfigured is still present in the new update 
Yeah it takes the same tile as Brussels
http://osm.pleiades.uni-wuppertal.de/garmin/generic/07-08-2012/63241989.img
In the OFM Lite it looks ok:
Paris tile http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/09-08-2012/63240194.img
Brussels: http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/09-08-2012/63240196.img
Since the generic and OFM use the same splitted files, why is then the Generic map corrupt?
Is the generic map containing too many nodes, more than the OFM lite? Is there a diferrence in mkgmap settings that is causing this?
Two more remarks:
-I notice that the one OFM Brussels map is split in two tiles in the generic map
-I have noticed that using -ea (enable assertions) sometimes generates an empty tile when only one road was corrupt in my maps, and therefore i dont use this option anymore. Maybe this is causing trouble too in the Paris area?
Almost. The base split is the same for both maps. I.e. the first run of splitter is splitting the planet using the max-nodes=1400000 parameter. The generic map and the OpenFietsMap render scripts then render and split these initial splitted tiles with every decreasing max-nodes parameters until everything is successfully rendered and the resulting tile is smaller then 8 MB. So some of the initial tiles are rendered only once for each map and some tiles are splitted/rendered many times before the result is accepted. This can (but doesn’t have to) result in a different final tile layout for each map type.
There are differences in Mkgmap settings between both map types.
Yes, this is probably a result of what the Mkgmap styles include or exclude.
I’m using the -ea option to ensure that Mkgmap doesn’t produce a tile when it’s not correct. Tiles that are 0 bytes are detected and automatically deleted. The smallest tile in both maps is 14kB in size.
Plan of action:
Find the initial tile that contains Paris
Enable as much logging as possible
Execute the rendering/splitting on that tile only
Analyze, analyze, analyze
If you provide the initial splitted tile for Paris online maybe we can help testing with that tile?
Probably post it also on mkgmap with the mkgmap settings you use?
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?