May 2014 - mkgmap-dev - The mkgmap lists

Mapsource crashes while calculating a route
by Andrzej Popowski 29 Sep '16

29 Sep '16

Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej

4 15

process-exits vs process-destination
by Franco Bez 08 Oct '15

08 Oct '15

Hi all, is there a way to combine the features process-exits and process-destination in a single style ? Based on my experience process-desitnation does a marvellous job when entering a motorway ( does it also work with also trunk roads ? ), while process-extis is perfect when leaving a motorway or trunk road. For instance the roundabout here http://www.openstreetmap.org/?lat=47.89665&lon=10.64805&zoom=17 has two exits towards the B12. Routing from the "Sudetenstraße" going North (maybe towards Augsburg) I would like the Garmin device to announce "5 th Exit - B12 (München)". On the other hand routing to the South (maybe Kempten) it should announce "2nd exit - B12 (Kempten)". Using process-exits this does not work, it's only "5th Exit - B12" resp. "2nd Exit - B12". I would have to use process-destination instead to get the desired messages displayed. Coming home from the trip, routing from the B12 towards "Sudetenstraße" I would like "exit to the right - Exit Kaufbeuren". Using process-exits this works perfectly. Would I use process-destination I would get "exit to the right towards B12 Verteilerring" or even "exit to the right towards Sudetenstraße" a really useless announcement as the sign on the trunk road reads "Kaufbeuren / Neugablonz / Mauerstetten". So this is why I would like to have an option that combines the functionality of process-exits and process-destination. Do you see any way to achieve this in one single style ? Ciao, Franco

7 6

multi-word street search
by Michał Rogala 18 Dec '14

18 Dec '14

Hello! I've a problem regarding street search. In Poland (and I suppose few more countries also may have this issue) person-named streets can have two forms - long one: Miroslawa Dudka or short one: Dudka there is no standard for tagging such names in OSM. Problem is that Garmin/Mapsource search function is matching names from the beginning of the string, so if I enter "Dudka" it will find all streets named "Dudka" but not "Miroslawa Dutka". Do you have any idea how can I deal with such issue? best regards Michal Rogala

12 67

Java tuning hint
by Gerd Petermann 24 Jul '14

24 Jul '14

Hi all, today I found a hint that seems to help mkgmap: http://java-performance.info/string-intern-in-java-6-7-8/ In short, try java run time parameter -XX:StringTableSize=100003 for mkgmap. Gerd

3 10

House numbers and styles
by Colin Smale 23 Jun '14

23 Jun '14

I have some rules which modify name, addr:street and mkgmap:street in "lines" and "points" which apply some transformations to the street names. The idea is to normalise the names by removing punctuation and standardising abbreviations. The resulting map is missing the house numbers for streets whose name I have modified. In the style rules, I apply identical transformations to the way (looking for highway=* & name=*) and points (looking for addr:street and mkgmap:street, separately of course). I expect that mkgmap can match up the address nodes with the street because the street names are still identical, but something is not working right. The modified street name is working fine - that is displayed and is in the index (i.e. I can search for it as a destination). However for these streets only, there don't seem to be any house numbers present. A search for a specific (existing) number on the road finds the road with no numbers, at the centroid of the street. Other streets whose names don't get changed, will allow me to find a specific house number and get the location right as well. Does anyone have any ideas what might be going wrong here? Am I trying to do something that can never work? Is it possible that something in the address handling in mkgmap is using the original street name, before the style has been applied? Is it possible that the styles don't get applied to address-only nodes? I have the following in "lines": # CS: normalise by getting rid of . in abbreviations highway=* & name ~ '.*[.].*' {set name='${name|subst:.-=>-|subst:.~> |subst: +~> }'} ... and the following in "points": # CS: normalise by getting rid of . in abbreviations #mkgmap:street ~ '.*[.].*' {set mkgmap:street='${mkgmap:street|subst:.-=>-|subst:.~> |subst: +~> }'; echo "fixed mkgmap:street ${mkgmap:street}"} mkgmap:street ~ '.*[.].*' {set mkgmap:street='${mkgmap:street|subst:.-=>-|subst:.~> |subst: +~> }'} #addr:street ~ '.*[.].*' {set addr:street='${addr:street|subst:.-=>-|subst:.~> |subst: +~> }'; echo "fixed addr:street ${addr:street}"} addr:street ~ '.*[.].*' {set addr:street='${addr:street|subst:.-=>-|subst:.~> |subst: +~> }'} Thanks in advance for any pointers! Colin

4 10

Bad performance because of complex boundary relation
by Gerd Petermann 17 Jun '14

17 Jun '14

Hi, this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary? Gerd

4 3

Unicode index and searching
by Steve Ratcliffe 02 Jun '14

02 Jun '14

Hi I've been working on implementing unicode sorting so that we can have a global index that supports address search with full unicode support. I've tested with a map mixing Germany and Poland and it seems to work at first sight, but I'm sure someone will find a bug quickly enough :) Get the latest from the unicode branch at the bottom of the download page: http://www.mkgmap.org.uk/download/mkgmap-unicode-r3284.zip try with --code-page=65001 to enable unicode. It should be OK with Greek, Arabic and Cyrillic characters too. But not with Chinese characters at the moment. ..Steve

3 6

Bug in subst
by Colin Smale 02 Jun '14

02 Jun '14

Hi, Is this the best way to make bug reports? I couldn't find a 'trac' for mkgmap... Using r3230, if I have the following in a style file: name=* & highway=* {set name='${name|subst:^(Doctor|Dokter) ~>Dr }'} then mkgmap crashes while loading the style files. After doing various tests my conclusion is that it is triggered by the "|" in the pattern. I tried escaping it with a backslash but it didn't change anything. I have found a kind-of workaround, by making the alternatives into separate calls to subst, but that will result in enormously long commands in the real use I have in mind. The example above is deliberately short to illustrate the bug. The stack trace is: java.lang.IllegalStateException: No match found at java.util.regex.Matcher.group(Unknown Source) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuilder.addFilter(ValueBuilder.java:168) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuilder.addTagValue(ValueBuilder.java:156) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuilder.compile(ValueBuilder.java:133) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuilder.<init>(ValueBuilder.java:45) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuilder.<init>(ValueBuilder.java:40) at uk.me.parabola.mkgmap.osmstyle.actions.ValueBuildedAction.add(ValueBuildedAction.java:30) at uk.me.parabola.mkgmap.osmstyle.actions.AddTagAction.<init>(AddTagAction.java:44) at uk.me.parabola.mkgmap.osmstyle.actions.ActionReader.readTagValue(ActionReader.java:169) at uk.me.parabola.mkgmap.osmstyle.actions.ActionReader.readActions(ActionReader.java:60) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.loadFile(RuleFileReader.java:117) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.checkCommand(RuleFileReader.java:192) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.loadFile(RuleFileReader.java:109) at uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:86) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:302) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:160) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readStyle(StyleImpl.java:554) at uk.me.parabola.mkgmap.reader.osm.RelationStyleHook.init(RelationStyleHook.java:38) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.pluginChain(OsmMapDataSource.java:185) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:153) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.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:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option Time finished: Wed May 28 08:37:41 CEST 2014 Total time taken: 1124ms Thanks for a great program! Regards, Colin

2 5

FW: Splitter defaulting on Japan
by Gerd Petermann 31 May '14

31 May '14

From: gpetermann_muenchen(a)hotmail.com To: extremecarver(a)gmail.com Subject: RE: [mkgmap-dev] Splitter defaulting on Japan Date: Sat, 31 May 2014 08:17:31 +0200 Hi Felix, thanks for reporting. I can reproduce the problem. It disappears when you remove the --precomp-sea option. I'll try to find out why. > Where is the log saved? Do I need to provide it? Splitter not fully up This message is printed to stderr for the case that you pipe stdout to a file like this: java -jar splitter .... > splitter.log Gerd > Date: Sat, 31 May 2014 05:33:06 +0200 > From: extremecarver(a)gmail.com > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: [mkgmap-dev] Splitter defaulting on Japan > > Failed to calculate areas. See log for details. > > Where is the log saved? Do I need to provide it? Splitter not fully up > to date - see compiled date (svn update just before)... > I'll retry with up to date splitter still... > > c:\OpenMTBMap\maps>java -Xmx9600m -jar c:\openmtbmap\splitter.jar > --precomp-sea=c:\openmtbmap\maps\sea.zip --max-nodes=1200000 > --output=pbf "--keep-complete" --max-areas=255 > --geonames-file=cities5000 --description=japan --mapid=65590000 c:\OpenMTBMa > p\osmpbf_geofabrik\japan.o5m > Splitter version unknown compiled 2014-05-28T18:16:29+0200 > boundary-tags=use-exclude-list > cache= > description=japan > geonames-file=cities5000 > keep-complete=true > mapid=65590000 > max-areas=255 > max-nodes=1200000 > max-threads=8 (auto) > mixed=false > no-trim=false > num-tiles= > output=pbf > output-dir= > overlap=auto > polygon-desc-file= > polygon-file= > precomp-sea=c:\openmtbmap\maps\sea.zip > problem-file= > problem-report= > resolution=13 > search-limit=1000000 > split-file= > status-freq=120 > stop-after=dist > write-kml= > Elapsed time: 0s Memory: Current 184MB (2MB used, 182MB free) Max 8533MB > Time started: Sat May 31 02:40:37 CEST 2014 > Map is being split for resolution 13: > - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) > - areas are multiples of 0x800 map units wide and high > Processing c:\OpenMTBMap\osmpbf_geofabrik\japan.o5m > Bounding box 122.56070000000001 20.08228 154.4709 45.80245 > 10'000'000 nodes processed... id=752184948 > 20'000'000 nodes processed... id=922482748 > 30'000'000 nodes processed... id=1233696234 > 40'000'000 nodes processed... id=1315824764 > 50'000'000 nodes processed... id=1421002430 > 60'000'000 nodes processed... id=1497506798 > 70'000'000 nodes processed... id=1751094845 > 80'000'000 nodes processed... id=2040104150 > 90'000'000 nodes processed... id=2350328457 > in 1 file > Time: Sat May 31 02:41:01 CEST 2014 > Counting nodes of precompiled sea data ... > Bounding box 144.84375 19.6875 145.546875 20.390625 > Bounding box 135.703124999 20.390625 136.406249999 21.09375 > Bounding box 144.84375 20.390625 145.546875 21.09375 > Bounding box 122.34375000000001 23.90625 123.04687499900001 24.609375 > > > ........ > cut away here... > ....... > Bounding box 142.734375 45.703125 143.4375 46.40625 > Bounding box 143.4375 45.703125 144.140625 46.40625 > Bounding box 149.0625 45.703125 149.765625 46.40625 > Bounding box 149.765625 45.703125 150.46875 46.40625 > Bounding box 150.46875 45.703125 151.171875 46.40625 > Added 835594 nodes from precompiled sea data. > Precompiled sea data pass took 1797 ms > Exact map coverage is (20.08227825164795,122.56068706512451) to > (45.80243110656738,154.47088479995728) > Rounded map coverage is (20.0390625,122.51953125) to > (45.8349609375,154.51171875) > Splitting nodes into areas containing a maximum of 1'200'000 nodes each... > Highest node count in a single grid element is 205'139 > Trying to find nice split for (20.0390625,122.51953125) to > (45.8349609375,154.51171875) with 98'482'055 nodes > searching for split with min-nodes 12000, learned 0 good partial solutions > Split was not yet succesfull. Trying to remove large empty areas... > Trying again with 1 trimmed partition(s), also allowing big empty parts. > Solving partition (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > Trying to find nice split for (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > searching for split with min-nodes 12000, learned 0 good partial solutions > Warning: No solution found for partition (23.818359375,122.6953125) to > (45.8349609375,153.0615234375) with 98'482'055 nodes > Final solution has 0 tile(s). The smallest node count is > 9223372036854775807 (0 %), the worst aspect ratio is near -1.0 > Failed to calculate areas. See log for details. > Failed to calculate areas. > Sorry. Cannot split the file without creating huge, almost empty, tiles. > Please specify a bounding polygon with the --polygon-file parameter. > Time finished: Sat May 31 02:41:04 CEST 2014 > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 5

splitter assumes no description
by A. Carlos 31 May '14

31 May '14

in version 395 and 396, the - description = assumes that determines the pattern is always the case # description: OSM Mapping the family field-id: I even informing any other value it always assumes the fixed value of family-id: 980, in previous vesões did right, what I determined nad description _______________________________________________________________________________________________________ Anor C. A. de Souza Concórdia SC

3 2