September 2011 - mkgmap-dev - The mkgmap lists

Suggestion for more flexibility in locator part of mkgmap
by Clifford Nolan 19 Sep '12

19 Sep '12

Hi Greg, Just to clarify ... the admin_levels for Ireland described here http://wiki.openstreetmap.org/wiki/Ireland/Boundaries#Boundary_Types don't seem to mention things like village boundaries - there's a big gap between admin_level=8 and admin_level=10. In situations like this, maybe the locator could be more flexible and use other kinds of boundaries too. Regards, Cliff

3 7

Overview map
by Steve Ratcliffe 19 Jun '12

19 Jun '12

Hi I have started to implement adding features into the overview map. You can find ready built jar files on the download page and in the 'overview' branch in subversion. It creates the overview map from the .img (as before) and so it is very quick to try out even on a set of tiles covering a whole country. There is no configuration yet, it just takes everything (lines and polygons) that is in the least detailed layer of the detailed maps and adds it into the overview. You will immediately notice a big problem in that the overview map shows up even when the detailed maps are being displayed, so you get ugly jagged lines across the top of the map. I remember this happening the last time we has an overview map and I wonder if anyone can remember if there was a solution then? I'm going to start by trying the (so-called) POI flags, as one of those has been noted to be set differently on detail and base maps before. ..Steve

5 15

[PATCH v1] Subdivision splitting
by WanMil 28 May '12

28 May '12

Attached patch should fix (all?) subdivision splitting problems. Error like "Area too small to split at ..." cannot occur any more because the way how subdivisions are split is changed. I think it's still not the optimal way but there should be no loss in highly densed areas any more. This is a first patch not ready to commit because there are some performance penalties which can be reduced. But I want you to test the patch before optimization. WanMil

5 13

NSIS 64bit installer
by Valeriy Pekarskyy 24 May '12

24 May '12

Hi All! So, the bug is that NSIS generates installers that work only at 32bit Windows systems (can anyone confirm?), so I developed a patch for latest version of mkgmap which includes changes to default nsi script and NsisBuilder.java. Can anyone look through? The main difference is that Registry path should be changed if that is x64. Patch link: http://dl.dropbox.com/u/11265861/nsis.patch or http://pastebin.com/pwnptH27 Best Regards, Larry0ua

3 4

manipulating gmapsupp.img
by Rich 24 Jan '12

24 Jan '12

is it possible to manioulate gmapsupp.img contents if it has multiple maps included ? that is, listing, removing, updating included maps ? listing might have to show those 'mapnames' that have to be unique to be really useful, i guess. i tried searching around, but the search terms seem to be a bit too generic to return useful results :) -- Rich

3 5

Country names
by WanMil 24 Jan '12

24 Jan '12

Hi all, I am thinking about the country names that mkgmap puts into the map. (The following lines are valid for the locator branch but the differences to the trunk are quite small) At the moment the country name is taken from the country relation using the tag order defined by the name-tag-list option. This name is looked up in the LocatorConfig.xml. If there is a match (there should be one), the name defined in the LocatorConfig.xml is used as map wide country name. There is the shortcoming that this name need not be the same as specified by the name-tag-list option. So there is some work to do if you want to build a french map that uses french country names only. Would it make sense to use the LocatorConfig.xml just as a mapping tool for the three letter code (name:en => three letter code) and the real name is taken as defined by the name-tag-list option? This has the shortcoming that the relation names contains some administrative stuff "Federal Republic of Germany" instead of "Germany". Any thoughts? WanMil

4 12

License text
by Ralf Kleineisel 01 Jan '12

01 Jan '12

Is it possible to change the license info which is embedded in the IMG header? Now it reads "OSM Street map http://www.openstreetmap.org/ Map data licenced under Creative Commons Attribution ShareAlike 2.0 http://creativecommons.org/licenses/by-sa/2.0/", but this is not correct when making maps from other data sources. For example contour line layers made of SRTM data do not contain any OSM data.

6 14

exclude words from city / state
by Felix Hartmann 10 Dec '11

10 Dec '11

Using the locator branch, I noticed that many cities in Austria are not findable anymore. The problem is that there are words like "Gemeinde Mödling" or "Bezirk Mödling" or "county XYZ". There should be a list where one can enter words that get deleted. That is because for the boundary it is the correct name, but not for searching a street. Also there are problems in Austria in Vienna. Vienna is a state and a city, and ideally it should be possible to enter either the district or the city into the city field, in order to find a street. Currently it is not possible to properly separate cities outside Vienna from districts inside Vienna, as they have the same admin_level. But for the ise tags, there is a correct specification telling you that districts are not cities (from the standpoint of the admin_level, it is correct however to classify them the same as small cities outside of Vienna). So in effect if one does not enter specific rules for Vienna, address search can never work as expected. Admin_level was never intended to be used for address searching, hence taking it is flawed and will not provide correct results. Ise is intended for address searching, but mkgmap does not use it. In general after using the locator branch, I more and more think, that the whole matching is completly the wrong way of doing. Much better to support real addresses as entered in OSM, and not do so much guessing. Especially support housenumbers, as at least in Germany and Austria housenumbers including full ise tags are becoming the norm, and not the exception. Only footways, pathes, or tracks should be matched, as they usually have no real address - but then it's rare that one searches for a specific path/track/footway, only real use would therefore be

10 24

Short mkgmap HowTo
by WanMil 22 Nov '11

22 Nov '11

Hi, I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time. Please have a look on it if I have forgotten something or if something is wrong. Thanks! WanMil

11 28

Problems with latest splitter versions
by Michael Prinzing 12 Nov '11

12 Nov '11

Hi, I am getting the splitter from svn, compiling and running it unter Windows XP SP3 using JDK 1.6.0_25. There are 2 problems if I am using a splitter version newer than r161 (tryed until r167 so far). 1.) germany.osm.pbf from geofabrik cannot be split -------------------------------------------------- Invoking the splitter with java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --geonames-file=cities1000.zip germany.osm.pbf The data is split into 76 areas, so there are 2 passes to go. First, everything looks fine, but then, at the and of the first pass, the splitter "falls asleep", the CPU load for the corresponding JVM drops to 0% and there ist no further progress (except the memory stats being printed periodically). The output looks like this (cut a lot of lines): cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 17:11:11 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.050779999000001 55.14777 10.000.000 nodes processed... id=283576079 20.000.000 nodes processed... id=355168786 30.000.000 nodes processed... id=495365986 40.000.000 nodes processed... id=699656373 50.000.000 nodes processed... id=998291790 60.000.000 nodes processed... id=1127935431 1.000.000 ways processed... id=25049151 2.000.000 ways processed... id=28822644 Elapsed time: 1m 59s Memory: Current 247MB (20MB used, 227MB free) Max 1484MB 3.000.000 ways processed... id=34073254 4.000.000 ways processed... id=40593158 5.000.000 ways processed... id=49931588 6.000.000 ways processed... id=61188933 7.000.000 ways processed... id=83211109 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 100.000 ways processed... id=1124462 in 1 file Time: Wed Mar 02 17:14:00 CET 2011 Exact map coverage is (47.26541519165039,5.864403247833252) to (55.147762298583984,15.05077600479126) Trimmed and rounded map coverage is (47.28515625,5.8447265625) to (55.1513671875,15.029296875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,7.470703125) to (47.9443359375,8.7451171875) contains 663.137 nodes. DONE! [...] Area (53.8330078125,11.77734375) to (54.931640625,14.2822265625) contains 996.051 nodes. DONE! 76 areas: Area 63240001 covers (0x246800,0x4b000) to (0x24d800,0x4f800) DE-Dusseldorf [...] Area 63240076 covers (0x223000,0x63800) to (0x228800,0x70000) DE-Reutlingen Writing out split osm files Wed Mar 02 17:14:03 CET 2011 Processing 76 areas in 2 passes, 38 areas at a time Starting pass 1 of 2, processing 38 areas (63240001 to 63240038) Making SparseMultiMap Making SparseMultiMap Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.050779999000001 55.14777 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap MAP occupancy: 832878 MAP occupancy: 158237 MAP occupancy: 8339 MAP occupancy: 546 MAP occupancy: 1652236 MAP occupancy: 326019 MAP occupancy: 19669 MAP occupancy: 2076 MAP occupancy: 2474023 MAP occupancy: 491531 MAP occupancy: 31585 MAP occupancy: 2861 MAP occupancy: 3272326 MAP occupancy: 668457 MAP occupancy: 53049 MAP occupancy: 6168 Elapsed time: 3m 59s Memory: Current 267MB (121MB used, 146MB free) Max 1484MB MAP occupancy: 4072409 MAP occupancy: 847909 MAP occupancy: 73212 MAP occupancy: 6470 MAP occupancy: 4870695 MAP occupancy: 1026785 MAP occupancy: 94770 MAP occupancy: 7750 MAP occupancy: 5673776 MAP occupancy: 1203597 MAP occupancy: 111531 MAP occupancy: 11096 10.000.000 nodes processed... id=283576079 [...] 60.000.000 nodes processed... id=1127935431 MAP occupancy: 37091591 MAP occupancy: 8145968 MAP occupancy: 704292 MAP occupancy: 58149 MAP occupancy: 37918126 MAP occupancy: 8301600 MAP occupancy: 722028 MAP occupancy: 58246 MAP occupancy: 38711472 MAP occupancy: 8485566 MAP occupancy: 744601 MAP occupancy: 58361 Writing ways Wed Mar 02 17:26:02 CET 2011 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap 1.000.000 ways processed... id=25049151 MAP occupancy: 798645 MAP occupancy: 184591 MAP occupancy: 15271 MAP occupancy: 1493 Elapsed time: 15m 59s Memory: Current 1484MB (705MB used, 779MB free) Max 1484MB 2.000.000 ways processed... id=28822644 [...] 7.000.000 ways processed... id=83211109 Elapsed time: 20m 2s Memory: Current 1484MB (928MB used, 556MB free) Max 1484MB MAP occupancy: 4795349 MAP occupancy: 1103602 MAP occupancy: 94312 MAP occupancy: 6736 MAP occupancy: 1 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 MAP occupancy: 5597978 MAP occupancy: 1283033 MAP occupancy: 110757 MAP occupancy: 8231 MAP occupancy: 1 Writing relations Wed Mar 02 17:32:01 CET 2011 100.000 ways processed... id=1124462 coords occupancy MAP occupancy: 39240504 MAP occupancy: 8605635 MAP occupancy: 752197 MAP occupancy: 58361 ways occupancy MAP occupancy: 5634593 MAP occupancy: 1292952 MAP occupancy: 111321 MAP occupancy: 8235 MAP occupancy: 1 Elapsed time: 22m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 24m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 26m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 28m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 30m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB At this point, nothing more happens, no second pass is done. 2.) File containing contour data cannot be processed ---------------------------------------------------- When generating my maps, I usually add data to draw contour lines. The file containing that data is available from http://osm.arndnet.de/contourdata.osm.gz (not my site!). It is in OSM format 0.5. When buildig a map, I am combining this data with the OSM data (please note that the contour data file contains node IDs starting at 2^31, so they collide with the IDs from "real" OSM data if used unchanged). But even when I am trying to split this file without additional OSM data, the same as above happens and the splitter stops at the end of the first and only pass: java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --mixed --geonames-file=cities1000.zip contourdata.osm.gz cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=true no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 17:43:31 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing contourdata.osm.gz 2.500.000 nodes processed... 5.000.000 nodes processed... 7.500.000 nodes processed... 10.000.000 nodes processed... 12.500.000 nodes processed... 15.000.000 nodes processed... 17.500.000 nodes processed... in 1 file Time: Wed Mar 02 17:45:08 CET 2011 Exact map coverage is (47.2760796546936,5.877492427825928) to (55.02375841140747,14.999899864196777) Trimmed and rounded map coverage is (47.28515625,5.86669921875) to (55.0634765625,15.00732421875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,6.7236328125) to (49.1748046875,8.525390625) contains 958.841 nodes. DONE! [...] Area (52.822265625,10.17333984375) to (54.7119140625,14.47998046875) contains 885.962 nodes. DONE! 22 areas: Area 63240001 covers (0x23c000,0x54c00) to (0x247800,0x5ec00) DE-Koblenz [...] Area 63240022 covers (0x21c800,0x61000) to (0x22f800,0x6e800) DE-Stuttgart Writing out split osm files Wed Mar 02 17:45:10 CET 2011 Processing 22 areas in a single pass Starting pass 1 of 1, processing 22 areas (63240001 to 63240022) Making SparseMultiMap Making SparseMultiMap Processing contourdata.osm.gz Making SparseMultiMap Writing ways Wed Mar 02 17:45:14 CET 2011 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Elapsed time: 1m 59s Memory: Current 1484MB (1090MB used, 394MB free) Max 1484MB MAP occupancy: 783578 MAP occupancy: 190519 MAP occupancy: 25903 MAP occupancy: 1545344 MAP occupancy: 394559 MAP occupancy: 60097 MAP occupancy: 2398068 MAP occupancy: 533001 MAP occupancy: 68931 2.500.000 nodes processed... MAP occupancy: 3315227 MAP occupancy: 615842 MAP occupancy: 68931 MAP occupancy: 4195362 MAP occupancy: 728752 MAP occupancy: 75886 5.000.000 nodes processed... [...] [...] Elapsed time: 7m 59s Memory: Current 1484MB (1197MB used, 287MB free) Max 1484MB MAP occupancy: 16438198 MAP occupancy: 3986436 MAP occupancy: 575366 MAP occupancy: 17300217 MAP occupancy: 4121087 MAP occupancy: 578696 17.500.000 nodes processed... coords occupancy MAP occupancy: 17896316 MAP occupancy: 4149555 MAP occupancy: 578696 ways occupancy MAP occupancy: 180407 MAP occupancy: 43178 MAP occupancy: 6700 MAP occupancy: 21 MAP occupancy: 1 Elapsed time: 9m 59s Memory: Current 1484MB (1013MB used, 471MB free) Max 1484MB Elapsed time: 11m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB Elapsed time: 13m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB Elapsed time: 15m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB ***** Full GC ***** Elapsed time: 18m 1s Memory: Current 1484MB (923MB used, 561MB free) Max 1484MB Elapsed time: 20m 1s Memory: Current 1484MB (924MB used, 560MB free) Max 1484MB Elapsed time: 22m 1s Memory: Current 1484MB (924MB used, 560MB free) Max 1484MB and so on. I've then converted the data to OSM format 0.6 and sorted it (using --migrate and --sort-0.6 for osmosis) and stored it as .osm.bz2 and .osm.pbf. When I am trying to split these files, I am getting an exception: java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --geonames-file=cities1000.zip contourdata06.osm.bz2 cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 19:28:48 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing contourdata06.osm.bz2 2.500.000 nodes processed... 5.000.000 nodes processed... 7.500.000 nodes processed... Elapsed time: 2m 0s Memory: Current 247MB (81MB used, 166MB free) Max 1484MB 10.000.000 nodes processed... 12.500.000 nodes processed... 15.000.000 nodes processed... Elapsed time: 4m 0s Memory: Current 247MB (61MB used, 186MB free) Max 1484MB 17.500.000 nodes processed... in 1 file Time: Wed Mar 02 19:34:21 CET 2011 Exact map coverage is (47.2760796546936,5.877492427825928) to (55.02375841140747,14.999899864196777) Trimmed and rounded map coverage is (47.28515625,5.86669921875) to (55.0634765625,15.00732421875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,6.7236328125) to (49.1748046875,8.525390625) contains 958.841 nodes. DONE! [...] Area (52.822265625,10.17333984375) to (54.7119140625,14.47998046875) contains 885.962 nodes. DONE! 22 areas: Area 63240001 covers (0x23c000,0x54c00) to (0x247800,0x5ec00) DE-Koblenz [...] Area 63240022 covers (0x21c800,0x61000) to (0x22f800,0x6e800) DE-Stuttgart Writing out split osm files Wed Mar 02 19:34:24 CET 2011 Processing 22 areas in a single pass Starting pass 1 of 1, processing 22 areas (63240001 to 63240022) Making SparseMultiMap Making SparseMultiMap Processing contourdata06.osm.bz2 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Start index (-30655339) is negative at it.unimi.dsi.fastutil.Arrays.ensureFromTo(Arrays.java:45) at it.unimi.dsi.fastutil.objects.ObjectArrays.ensureFromTo(ObjectArrays.java:351) at it.unimi.dsi.fastutil.objects.ObjectArrays.fill(ObjectArrays.java:313) at it.unimi.dsi.fastutil.objects.ObjectArrayList.size(ObjectArrayList.java:308) at uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2ShortMapInline.java:96) at uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:123) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81) at uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31) at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:208) at uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:118) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:243) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:57) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at uk.me.parabola.splitter.Main.writeAreas(Main.java:355) at uk.me.parabola.splitter.Main.split(Main.java:188) at uk.me.parabola.splitter.Main.start(Main.java:116) at uk.me.parabola.splitter.Main.main(Main.java:105) Both files (the original file in OSM format 0.5 and the converted .osm.bz2 in OSM format 0.6) could be split without a problem using splitter r161. Any ideas what is going wrong there? Anything I could try? Michael

4 3