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.
I tracked down what caused the tile of Cleveland did not process. I couldnt download your o5m files but with a small extract from Cleveland I was able to reproduce it.
If I remove -ea it will process normally (thats what I always do).
With -ea, mkgmap couldnt compile the tile.
If I use --ignore-turn-restrictions mkgmap will process the tile, so the bug was in one of the turn-restrictions.
I found out that the problem was this relation http://www.openstreetmap.org/relation/3490966
My style didnt seem to handle the type=restriction:motorcar very well so I changed the code (for a bike map I want to ignore this restriction, but somehow mkgmap crashed on this). I dont know if it’s a bug in mkgmap or in my styles but I think it will pass the next update without errors.
The file access forbidden was a dumb permission problem.
I remember -ea was once necessary to prevent Mkgmap generating broken maps but apparently this is no longer so. If the next update is still giving problems then I’ll remove this option.
The problem with the OFM-lite style seems to be resolved, Cleveland looks normal again.
The generic map still has red-tiles, a better work-around is now implemented and a new version should come online ~tomorrow. A report for Splitter is sent to the Mkgmap mailinglist.
OFM doesn’t have those red tiles anymore, but I do see a lot of red tiles in the generic map. I notice the tiles in the ocean are not matched together (because you use --no-trim=true). Any reason for this to use --no-trim? Maybe it helps to solve the splitter problem to leave this parameter out (the generic new map is fine).
The problem with the red-squares is solved, also for the generic map. The script now expects at least 2 tiles from Splitter on each subsplit and when just one new tile is found it will simply render this without further tests. This is a solid work-around that even works when Splitter eventually gets fixed.
Next up: reducing the number of map variants (Windows, gmapsupp, gmapi, tiles) to reduce the CPU load. Especially the NSIS installer for Windows uses a lot of CPU cycles. Ligfietser’s OFM map shows that it’s possible to combine a small installer with the tiles in a single zip-file, resulting in the need for only one file for both Windows as Linux.
Edit 22:00 CET:
I’m guessing about 40 tot 50 people are downloading at the same time from the country server, the harddisk is maxxed-out and 200+ MBit/s is pumped out the ethernet port…
I think it is a false positive, these things happen. You can check yourself by testing the website using online virusscanners like http://www.virustotal.com
Ligfietser, I have a first test map that includes a small installer in the _tiles.zip. BaseCamp shows the map alright.
Only difference is that this installer does not move+install the map in \Garmin\maps but simply in the directory where you unpacked the zip file. Do you think this a problem for end-users?
I know the tiles are just a random selection, this test is purely about the _tiles.zip file and the small install.exe
I understand this new approach takes a little more effort for the user than just click on the exe installer and let the installer do the job.
As long as we give them good instructions about the changes (perhaps in the wiki?) I dont think its a problem?
The only big difference is that the users need to do an extra step,
unpack it to the location where you want to put the map
look for the install.exe file and execute this
BTW another problem, the install.exe might be detected as false positive by some scanners
newbee question:
How can I give the maps in BaseCamp meaningful names?
I composed two maps for two trips. Now I get the osm_generic_new_gmapsupp…exe file, I use the Windows Version and execute it. After that I have one map in my basecamp. But now I want to install a second map of a different Region. How can I do this having meaningful names in the Basecamp Dropdown box???
I also installed the map on my Germin device copying the map to a SD Card and rename the .img file, this works fine.
With best regards
Gerhard
PS: Want end up with the tracks of all my trips and having all maps used for that trips in basecamp