April 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

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

problem with address search and --code-page
by Michał Rogala 08 May '14

08 May '14

Hi! I'm creating 2 types of maps (covering Poland): - regular map (default code-page) - localized map (code-page 1250) first map is here: http://garmin.osmapa.pl/mapy/OSMapaPL-20140120V1.29_IMG.zip second map is here: http://garmin.osmapa.pl/mapy/OSMapaPL-OGONKI-20140120V1.29_IMG.zip problem is: map with code-page 1250 works well - I can search for any address - MapSource and GPSMap device show it. map without code-page 1250 (default setting) has incomplete index - I can't search for almost any street (only a few available, no housenumber search). One example is: City: Warszawa Street: Aleje Jerozolimskie Housenumber: 91 with --code-page=1250 I can find this address, without --code-page=1250 I can't. No regional characters are involved in this street name. Do you have any idea why this happens? I use mkgmap-r2998, r2979 had the same problem. No difference if I use --lower-case or not. My mkgmap arguments: --verbose --family-name=OSMapaPL --description=OSMapaPL --series-name=OSMapaPL --coastlinefile=./coastlines_europe.osm.pbf --read-config=./config/osmapa.config --bounds=./bounds --family-id=004 --product-id=004 --mapname=66004001 --overview-mapname=66004000 --style-file=./resources/styles/ --style=mapa --check-styles config file is: verbose max-jobs country-name=Polska name-tag-list=name:pl,name generate-sea location-autofill=is_in,nearest tdbfile index add-pois-to-areas link-pois-to-ways remove-short-arcs preserve-element-order country-abbr=POL route net gmapsupp nsis check-styles process-exits process-destination housenumbers overview-mapnumber=66007001 overview-levels=6:16,7:15 best regards Michał Rogala

3 44

mkgmap ToDo list
by Gerd Petermann 06 May '14

06 May '14

Hi all, the last months brought a lot of improvements, but there is still a lot to do: Before summer I only plan to improve readability/stability and maybe performance of code:use one internal representation for vehicles (mkgmap:car, mkgmap:bicycle,...) and only translate it to the img format when writingCreate a new class that combines a converted Way, the reference to the GType, and fields required for the creation of MapRoad objects. I think ConvertedWay is a good name for this. This should be used in StyledConverter, WrongAngleFixer, and RoadMerger.The RuleIndex might be a lot faster if we search for keys first and in a 2nd step for values. This would avoid millions of temporary StringBuilder objects. Other ideas that should not be forgotton: improve handling of motor_vehicle=* and vehicle=* in default style (WanMil and Mario Hantschke are working on that) manage drive-on-left/drive-on-right in resources\LocatorConfig.xmldetect sharp angles at road junctions and either change the heading values or add small arcsconditional includes in style files and/or if else statements error handling : set non-zero return code if the map (or at least one tile) is not usableimprove reader for polish input data: correct handling of mulitple DATAx lines rewrite MapSplitter so that overlaps are kept small. This should improve rendering speed in the devices. rewrite classes that hold information about map objects, esp. shapes. Idea: store information about outer way and holes as lists of points, similar to mp-relationsimplement methods that return the simplified object for a given resolution. If the area enclosed by the outer line is not visible at resolution x, ignore the object. If a hole is not visible at resolution x, ignore it. If both are visible, connect the simplified outer and inner lines so that holes are displayed in the map. This should all be doable without complex area operations.merge shapes before splitting the map into sub areasoptimize wrong angles in shapes with the same algo that is used for lines Expected result: fewer and less distorted shapes, smaller img file. The order of the 2nd list represents my assumption regarding complexity, not importance. I think the last 3 (bold) points can only be done together, but I'd like to be proven wrong. Is something important missing? @Steve: Maybe we should keep this list somewhere at http://www.mkgmap.org.uk/ and try to maintain it? Gerd

8 53

The --route option
by Gerd Petermann 03 May '14

03 May '14

Hi all, if I got that right, mkgmap doesn't create usable maps without the --route option (index is not complete) On the other hand, StyledConverter doesn't evaluate the option, it just analyses if a line could be routable . A lot of routines are only executed for routable ways, e.g. the housenumber code. I think we should remove (ignore) the --route option, as it is mandantory. If possible, we should allow to create maps that don't contain a NOD section, I think this is wanted by some users. Gerd

7 8

Bounds and Sea Data on mkgmap.org.uk -- still old creation process.
by Felix Hartmann 02 May '14

02 May '14

Just a question - is it planned to change the bounds and sea data that is available via mkgmap.org.uk to be update to the high precision format? or maybe put a link to Thorstens site if not? http://osm.thkukuk.de/data/ -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

3 4

r3239 in performance2 branch
by Gerd Petermann 02 May '14

02 May '14

Hi all, I've coded what I described here: http://gis.19327.n5.nabble.com/possible-tuning-for-evaluation-of-tags-tp580… Depending on the options and style I see improvements between 1 % and 15 %. (1% for default style and options --route --preserve-element-order, up to 15% for complex styles like those from Minko or Henning) The more complex the style the more improvement you should see. The cache works like this: - common expressions (e.g. the barrier=* term in my example) in rules are detected when the style is read in, each of them has an int field that identifies a valid cache and the result of the evaluation (true/false) - when a new element is processed, the cache is reset (this just means one int value is incremented) - when a common expression is evaluated for the first time, the normal evaluation happens and the result is cached. - when the same expression is evaluated again the cached value is returned if the cache was not already reset - if an action adds or changes or deletes a tag, the cache is reset again (the more often this happens the less efective is the cache) All this requires more or less no extra heap. One remark regarding rules in <finalize> section: If I got that right, they are all evaluated, no matter what tags the OSM element has. For the "normal" rules we use a filter so that rules which cannot match are not evaluated. If you have time, please check if the branch really is faster and - even more important at this point - produces equal output. Gerd

3 5

Commit: r3241: apply reverse-oneway-v3.patch
by svn commit 30 Apr '14

30 Apr '14

Version mkgmap-r3241 was committed by gerd on Wed, 30 Apr 2014 apply reverse-oneway-v3.patch This patch makes sure that multiple copies of an OSM way with different oneway=* tags are not treated the same. Without this patch the result is more or less unpredictable if you use something like this: xyz=* { add oneway=-1 } [0x1010 resolution 23 continue] xyz=* { set oneway=yes } [0x1011 resolution 23 continue] xyz=* { set oneway=-1 } [0x10 road_speed=1 resolution 23] todo: check code for restriction relations

1 0