August 2009 - mkgmap-dev - The mkgmap lists

list-styles
by frmas 01 Sep '09

01 Sep '09

Hello, Just added three different styles in my svn/resources/styles directory, then recompiled mkgmap, and now it gives me : java -jar mkgmap.jar --list-styles The following styles are available: arvernes 1.0: Style for OSM Maps contours 1.0: Style for OSM Maps default 1.0: Style for OSM Maps noname 1.0: Style for OSM Maps perso 1.0: Style for OSM Maps test 1.0: Style for OSM Maps It seems it takes the "summary" line of the first style info file and apply it for all of them. as an exemple, this is what I have in the info file of my arvernes style directory # # This file contains information about the style. # It is completely optional. # # A short one line description of the style # summary: Style for OSM Maps # Version of the style itself # version=1.0 # A longer description of the style. description { The arvernes style for ordinary maps downloaded from Geofabrik. } Francois --

2 1

Splitter --cache parameter
by Chris Miller 01 Sep '09

01 Sep '09

I've just checked in some changes to the splitter that add a new --cache parameter. This is designed to speed up the splitting process, especially on large splits that require multiple passes over the .osm file, or in situations where you run the splitter several times on the same .osm file with different parameters each time. If you want to enable the disk caching, you specify the cache location as follows: --cache=<directory> This will cause the splitter to generate several files in the specified directory during the first stage of the split (the areas.list calculation). These files contain the same information as the source .osm file(s) do, but in an optimised format that allow subsequent passes over the data to happen much more quickly. The more passes that happen in the second stage of the split, the greater the speedup you will see. Some benchmarks on my PC have shown the following speed improvements when running against uncompressed .osm files: 1 pass - 5% faster 2 passes - 25% faster 3 passes - 35% faster 4 passes - 40% faster 5 passes - 45% faster If you are using compressed .osm files (bz2 compression especially), the speed improvement should be greater still, since the decompression will only need to happen once rather than on each pass. Note however that these figures are very approximate; the actual performance will vary depending on your disk and CPU speed, the particular map being processed, and what other disk and CPU activity is taking place on your PC at the same time. In some cases you might find that splits that only require a single pass will run faster without the disk cache enabled. The disk cache can also be used across multiple runs of the splitter, as long as you are splitting the same .osm file(s) each time. For example suppose you ran a splitter as follows: java -Xmx4000m -jar splitter.jar --cache=. --max-nodes=1500000 europe.osm If you then run mkgmap and discover the max-nodes setting is too high, you can run the splitter again with a lower max-nodes value like so: java -Xmx4000m -jar splitter.jar --cache=. --max-nodes=1200000 Because the cache files already exist for europe.osm as a result of the first run, there's no need to specify europe.osm on the rerun. The data will be loaded from the cache instead and the split will run much faster. Be careful to delete the cache files if you want to rerun the splitter on a different .osm file, otherwise the previously cached data will be used from the original .osm file instead. (I'll probably add a check for this situation, but there's nothing in place to prevent it just yet.) Note that the disk cache can require a lot of disk space, typically about 20-25% of the space the uncompressed .osm file takes up. For example the 27GB europe.osm file generates a cache of just over 5GB. The --cache parameter is entirely optional. if you don't specify it, the splitter will work in exactly the same way it did previously. I hope the above explanation makes sense. Any questions, comments or suggestions are welcome. Cheers, Chris

5 13

Maximum map resolutions people use
by Chris Miller 01 Sep '09

01 Sep '09

I'm looking into building a density map to help improve the splitting (whether the splitting be automated or done via a GUI tool), and I'm trying to get a feel for what the memory and disk overhead will be using this approach. In particular, I'm interested in finding out what the highest number is that people are using for the --resolution parameter in the splitter. Is anyone using a value of 20 or higher? If so, what is the bounding box of the osm file that you are splitting? eg Europe's bounding box is (34.43055,-31.78259) - (82.35188,69.41235) while the whole planet file's bounding box is (-90,-180) - (90,180). If you're unable to view the start of the osm file due to its size or because it's compressed or whatever, just let me know which osm file it is and I'll figure it out from there. Many thanks, Chris

4 5

mkgmap r1160 Exception when facing multiple splitted files
by Gianmario Mengozzi 01 Sep '09

01 Sep '09

Hi List, mkgmap (r1160) fails giving me a new exception : C:\Users\.........\..........\mkgmap-r1160>java -jar mkgmap.jar -c options.args Exception in thread "main" java.lang.ClassCastException: java.util.concurrent.Ex ecutionException cannot be cast to java.lang.RuntimeException at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:307) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja va:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:101) This is my options.args: tdbfile style-file: stylejinx71 country-name: Italy country-abbr: ITA overview-mapname: 11111111 series-name: Italy Map 20090831 family-id: 52 remove-short-arcs: 5 route mapname: 63240001 input-file: 63240001.osm.gz mapname: 63240002 input-file: 63240002.osm.gz mapname: 63240003 input-file: 63240003.osm.gz mapname: 63240004 input-file: 63240004.osm.gz mapname: 63240005 input-file: 63240005.osm.gz mapname: 63240006 input-file: 63240006.osm.gz mapname: 63240007 input-file: 63240007.osm.gz mapname: 63240008 input-file: 63240008.osm.gz mapname: 63240009 input-file: 63240009.osm.gz mapname: 63240010 input-file: 63240010.osm.gz mapname: 63240011 input-file: 63240011.osm.gz mapname: 63240012 input-file: 63240012.osm.gz mapname: 63240013 input-file: 63240013.osm.gz mapname: 63240014 input-file: 63240014.osm.gz mapname: 63240015 input-file: 63240015.osm.gz mapname: 63240016 input-file: 63240016.osm.gz mapname: 63240017 input-file: 63240017.osm.gz mapname: 63240018 input-file: 63240018.osm.gz mapname: 63240019 input-file: 63240019.osm.gz 19 split files by splitter-r83 (java -Xmx1000m -jar splitter.jar --max-nodes=800000 italy090831_geofabrik.osm) I tried with a single .osm file and everything go well...... :(( may someone help me? thx Gianmario <http://www.mkgmap.org.uk/splitter/splitter-r83.tar.gz>

2 3

Commit: r1162: Fix the fixed fixed error reporting.
by svn commit 31 Aug '09

31 Aug '09

Version 1162 was commited by markb on 2009-08-31 21:47:54 +0100 (Mon, 31 Aug 2009) Fix the fixed fixed error reporting. Now it unwraps ExecutionExceptions, re-throws ExitExceptions and prints a stack trace and bombs (unless --keep-going is specified) for everything else.

1 0

Commit: r1161: Fix the fixed error reporting (until the next fix).
by svn commit 31 Aug '09

31 Aug '09

Version 1161 was commited by markb on 2009-08-31 21:21:07 +0100 (Mon, 31 Aug 2009) Fix the fixed error reporting (until the next fix).

1 0

Width of rivers
by Lambertus 31 Aug '09

31 Aug '09

Personally I never noticed it, but a forum.osm.org post [1] indicates that the default style does not use the width of waterways like rivers. Is this a bug, or does Mkgmap not support the width tag? [1] http://forum.openstreetmap.org/viewtopic.php?id=4612

1 0

Inter-tile routing
by Michael.TheBlackCat 31 Aug '09

31 Aug '09

Hi, i'm using all stable splitter and mkgmap versions in tha last weeks, but also the latest splitter r78 and mkgmap r1160 versions, where i recognize on my oregon 300, that inter tile routing does not work and breaks with the german error message 'Routenberechungsfehler'. There is no difference in the routing result, by loading the generated gmapsupp.img from mkgmap or by loading the tiles via mapsource to the garmin device. Now i've done a look into mapsource and found on the original garmin city navigator v9 cards, that there are special 'rounded' line ends near the cut lines (see attachments). Is this a sign for a special garmin cut and merge function for the cards that is still missing in mkgmap or is it something else? I really don't understand the building of garmin image maps, but i can envisage the necessity of a merging point at a cut position. I calculate the german map from www.geofabrik.de: http://download.geofabrik.de/osm/europe/germany.osm.bz2 unzip the file and do the following: java -Xmx5000M -jar splitter.jar --mapid=63000005 --max-nodes=1000000 ../../germany.osm java -Xmx5000M -jar /osm/mkgmap/mkgmap.jar --style-file=/osm/styles --description='OSM by mb' --country-name=germany --country-abbr=DE --family-id=59 --product-id=112 --series-name=OSM --family-name=OSM --area-name=DE --latin1 --lower-case --mapname=63000005 --overview-mapname=63000001 --draw-priority=10 --add-pois-to-areas --net --route --gmapsupp --ignore-osm-bounds --location-autofill=2 --remove-short-arcs=9 --frig-roundabouts=0.1 ../*.osm.gz /osm/types/d310809.TYP Cheers Michael

2 1

--make-all-cycleways oddity
by Valentijn Sessink 31 Aug '09

31 Aug '09

Hi list, hi Mark, First, a remark. Since the oneway=yes/cycleway=opposite roads have "(cycleway)" attached to their names, a GPS unit will randomly show either the regular name, or the (cycleway) name. Which isn't too bad for testing, I'd suggest you leave it this way until we're set and done with it, because now you can see *why* a certain road is accessible or inaccessible (i.e. it tells you where you're driving). Namely, here's one occasion where it came in handy: Yesterday I drove by car to one of those "cycleway=opposite" ways and to my surprise, my Garmin told me to turn right to "Hembrugstraat (cycleway)". I'm absolutely sure that the unit was set to "car" and not bike. So is there a bug in the opposite-way-code? (Or is this the strange idea of a Garmin that you can route the wrong way for some meters??) I had another Garmin unit with me with a regular Garmin map, that showed the right route; also, the route is nothing special, just about this: http://www.yournavigation.org/?flat=52.392997&flon=4.871082&tlat=52.391864&… Any ideas? (I'll recheck the routing later on, to see if this will also happen with positions further away in one-way-streets). Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579

6 19

Commit: r1159: Make the not operator in a style file
by svn commit 30 Aug '09

30 Aug '09

Version 1159 was commited by steve on 2009-08-30 22:51:15 +0100 (Sun, 30 Aug 2009) Make the not operator in a style file actually work.

2 1