The tiles for Alaska haven’t been updated since June 13th. This used to happen more often, on the order of 7 days. Is there an abnormally high user load these days or is there some other issue that’s slowing this down? I’m not complaining, just asking.
I’m trying to download the “Routable Bicycle” map but it seems that the one tile I need in Northeast Ohio, United States is red and cannot be selected. Am I out of luck? Is there an older version I can grab? “Generic routable” has the missing tile, but I’d prefer the Bicycle map if possible. Thanks!
The updates are started manually and only maintained by one person (Lambertus). Some people think there is a whole company behind this site but its all voluntary work. No idea why this tile is missing or why the gps version of Russia is empty, you’ll have to wait for another update until Lambertus is back from holidays.
That is correct, Bill: there are two queues, one for countries (or states) and one for custom maps.
The time per map is just a rough average, some maps are quicker to build then others.
In the generic_new typ file a section start (one line) was missing and that caused Mkgmap to exit prematurely. This has now been fixed for new maps.
The gmapsupp.img is missing because the newer Mkgmap versions are stricter regarding the map description length (max. 50 characters). Maps with long country names exited prematurely with the result that the gmapsupp.img is missing. This has now been fixed by replacing the full country name by it’s ISO three-letter abbreviation.
I was on holiday the past two weeks and didn’t bring my laptop (and loved being without it :p).
For some (as of yet) unknown reason this tile didn’t compile or split. There is no older verison available so you’'re indeed out of luck if you really need the bicycle optimized map.
Once again I need advice. I downloaded the generic routable map for Italy using the instruction I got last time. My wife took it in our Garmin Nuvi to Italy where she travels in a car with the family. She complains, however, that the device cannot be used (she ended up buying a new GPS in a local store) because it always sends her to rural roads (sometimes even closed for car traffic) instead of freeways. It appears to me that there is a default setting for bikes. How can it be overwritten? I assume the generic maps can be optimized for cars.
Thanks!
Welcome back Lambertus. You certainly deserve a vacation, without a laptop, and I hope it was good. Thank you very much for all you do.
The generic routable map is optimized more for cars then for bicycles, so your observations puzzle me. Is it not possible that the routing profile of the GPS is set to ‘bicycle’ instead of ‘car’ or that the ‘avoid highways’ option is enabled?
Or, it is set to ‘shortest distance’ instead of ‘fastest route’.
Thanks Lambertus. I wish I could see the device to answer. I believe that we never set those 2 options as we never use GPS for other than car, and we never attempt to avoid freeways. I’d rather suppose that the device has set some of those 2 options automatically when it encountered the new map. Would it be possible if you could please suggest where in the device menu those 2 options can be found to check and possibly change? However awkward it looks, I’ll forward your response to my wife. Even though she has a new working device, I would like to have this problem resolved for future travel.
From memory as I don’t have the thing at hand, on my GPSMap60CSx the option is under: press button ‘Menu’ twice and then look for ‘Routing’.
Jorge, there are dozens of nüvi models, all with different kind of menu settings. Please check youtube or in your manual how to do it.
hello lambertus
thank you very much for having fixed the problem on the russian federation
one more question:
I’m on macintosh with basecamp and I install russianfederation2014.gmap and it works
but I cannot see now russianfederation2013.gmap because in basecamp menu MAP, I see only “OSM generic routable”
and I have well 2 files installed
is there a software like JaVaWa IMGname for changing the name of file .gmap ?
thanks
There are still two red tiles on the latest OFM (also a small part on London).
Lambertus, can you check in your error logs what went wrong? Maybe I can examine those two osm files to see where/if it crashes on my OFM styles? Could be a mkgmap, OFM or OSM bug.
great !!!
thank you very much for javawa GMTK
I’ll try to look into this tonight. I suspect is has something to do with the recent changes in Splitter algorithms as it was updated at the end of May from r343 to r404 (and since then the latest version on each map update).
Edit:
I already took a peek in the log and, indeed, the initial file is too large for Mkgmap so needs further subsplitting but Splitter cannot find a suitable split configuration 
Edit:
Possibly there is something else going on that eventually triggers the above. Take a look on the website at Cleveland, Ohio, USA in the OFM lite map. The tiles are getting really small there which suggests that Mkgmap has problems rendering the area which results in further subsplitting. The root cause could be actually something in Mkgmap, OSM data and/or the style.
What I don’t understand is why the other generic maps dont have such tiny tiles. Does this subsplitting is carried out after mkgmap fails to process this tile? If so, the OFM style might get stuck on maybe a certain OSM element. Maybe I can investigate that tile further. If this doesnt depend on mkgmap and my OFM style but a huge number of nodes, maybe this area contains too many nodes and the splitter tries to get below a certain number of nodes? Maybe those nodes are not even used in my OFM map. In that case, maybe it’s better to carry out the mkgmap process after a 2nd or 3rd subsplit, no matter how many nodes there are in a tile. I always use --max-nodes=1600000 and until so far hardly saw that a tile was skipped (and the last time was a few years ago).
All the maps are rendered using the same build scripts, source data, applications and the same initial tile splits. So if there is different behavior then it’s either a map specific setting (e.g. max-nodes) or the style. I’ll link to the source data later.
The generic routable also has problems, the new generic routable is fine.
Edit:
Initial spliit setting -max-nodes=1500000
The problem initial tile is: 63440523.o5m which is unsuccessfully rendered with the following commandline:
ulimit -t 900 && java -Xmx1792M -XX:StringTableSize=100003 -ea -jar /home/lambertus/garmin/utils/mkgmap/mkgmap.jar --family-id=20011 --product-id=1 --draw-priority=20 --description=‘Openfietsmap Lite’ --series-name=‘Openfietsmap Lite’ --style-file=‘/home/lambertus/garmin/utils/styles/’ --style=‘ofm_lite’ --bounds=‘/home/lambertus/garmin/utils/bounds.zip’ --reduce-point-density=4 --reduce-point-density-polygon=8 --precomp-sea=‘/home/lambertus/garmin/utils/sea.zip’ --generate-sea=land-tag=natural=background --show-profiles=1 --add-pois-to-lines --index --location-autofill=is_in,nearest --latin1 --remove-short-arcs --min-size-polygon=10 --merge-lines --add-pois-to-areas --preserve-element-order --process-destination --process-exits --route --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --x-housenumbers --copyright-message=‘Map data \A9 openstreetmap.org, Map layout \A9 openfietsmap.nl’ --input-file=63440523.o5m
Which gives:
java.lang.AssertionError
at uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.getWayIds(RestrictionRelation.java:604)
at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.retrieveWays(LinkDestinationHook.java:149)
at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.end(LinkDestinationHook.java:727)
at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79)
at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:49)
at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Exiting - if you want to carry on regardless, use the --keep-going option
Then my script tries to subsplit until everything is rendered which ultimately leaves a tiny tile that cannot be rendered: 63442037.o5m
As a sidenote:
I also see this error for OFM Lite:
SEVERE (StyledConverter): 63440363.o5m: routable type 0x08 is used with a non-routable way which was also added as a routable way. This leads to routing errors. Try --check-styles to check the style.
I havent examined the problem yet, but I notice one important difference: -ea (enable assertion).
In the past map generation broke on tiny errors on osm when enabling this. After I removed this option, I never had any errors/empty tiles. See https://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg10947.html
Another problem is showing up with the generic map: A rendered tile is judged to be too large by my build script and is subsequently subsplit, but Splitter is unable to generate at least two subtiles. The succesfully rendered tile is removed because it is too large but there is no replacement available so the area turns up as a red square in the website. I think this needs to be reported to the Splitter devs.
ulimit -t 900 && java -Xmx1792M -XX:StringTableSize=100003 -ea -jar /home/lambertus/garmin/utils/mkgmap/mkgmap.jar --family-id=2000 --product-id=6 --draw-priority=20 --description=‘OSM Generic Routable’ --series-name=‘OSM Generic Routable’ --style-file=‘/home/lambertus/garmin/utils/styles/’ --style=‘default’ --bounds=‘/home/lambertus/garmin/utils/bounds.zip’ --reduce-point-density=4 --reduce-point-density-polygon=8 --precomp-sea=‘/home/lambertus/garmin/utils/sea.zip’ --show-profiles=1 --add-pois-to-lines --index --location-autofill=bounds,is_in,nearest --latin1 --remove-short-arcs --min-size-polygon=10 --merge-lines --add-pois-to-areas --preserve-element-order --make-opposite-cycleways --process-destination --process-exits --route --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --input-file=63240007.o5m
Time started: Mon Jun 30 09:23:22 CEST 2014
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Mon Jun 30 09:24:38 CEST 2014
Total time taken: 75772ms
09:24:38 Processing file 63240007.o5m failed (result=0, exists=1, size=13342208)
09:24:38 Removing 63240007.img
09:24:38 Acquire the split lock
09:24:38 Splitting 63240007 with nodes=1500000, starting at 63242034. Max id was 63242033, level = 1
Cannot find a good split with exactly 2 areas
The lines in italics come from my script and the underscored line is coming from Splitter. The other lines come from Mkgmap.
The original source tile that somehow cannot be subsplit further is: 63240007.o5m
The commandline for Splitter-r412 is:
java -Xmx7000m -ea -jar ~/garmin/utils/splitter/splitter.jar --output=o5m --keep-complete=true --no-trim=true --mapid=1 --max-nodes=1500000 --max-areas=1024 --write-kml=$split_dir/initial.kml --geonames-file=/home/lambertus/garmin/utils/cities15000.zip /home/lambertus/planet.openstreetmap.org/planet-latest.o5m
Edit:
I changed the build script to render the problem tile again when Splitter cannot subsplit further and just not check the result but continue rendering the next tile.