February 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

Name-tag-list parameter not used in relations processing
by paco.tyson＠free.fr 30 Mar '14

30 Mar '14

Hi, I noticed that the name-tag-list parameter is ignored by mkgmap when processing relations with the "apply" directive. It works as expected for all the other types. If I hard-code the name:xx tag in my relations file, mkgmap uses it and the right language is displayed. I tried putting the parameter in the "-c" config file and on the command line, same buggy behaviour (tested on r2673 and r2889). Regards, Paco

3 11

question regarding MapRoad
by GerdP 25 Mar '14

25 Mar '14

Hi Steve, I'd like to change the way how MapRoad objects are handled in the sub division split process. Current implementation is like this: 1) StyledConverter creates a MapRoad instance with max. 250 points, if a road has more points, multiple instances are created, each with its own RoadDef. 2) When the sub divisions are created, a MapRoad is never split, so the final result is that each instance is written to exactly one sub division. The Garmin format seems to imply that we should rather split the MapRoad to match a given bbox of a sub division. This will produce smaller img files because the offsets to the sub division centers are smaller, and if we allow to start with MapRoad instances having > 250 points, we also have fewer NOD entries. I tried to implement this, but I can't find a nice way to store the information about the order of the segments of a road. This is needed when finally the RoadDef.addPolylineRef() method is called. I think that we either have to make sure that each part of a road is processed in the correct order, or we have to restore the order after all the filters where used. (For the different levels, a road will be split into different parts, if a road goes out and in we can have multiple segments in one sub div, not directly connected to each other) I have no idea yet how to do this. Can you help? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 10

default style and underground pipelines
by Gerd Petermann 14 Mar '14

14 Mar '14

Hi all, is it intended that these ways are placed in the map? sample: http://www.openstreetmap.org/way/60575011 man_made=pipeline type=water location=underground This rule in lines fires: man_made=cable|(man_made=* & man_made ~ '.*pipe.*') {name '${name} (${operator})' | '${name}' | '${operator}' } [0x28 resolution 23] Ciao, Gerd

3 9

Distorted lines
by Andrzej Popowski 05 Mar '14

05 Mar '14

Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej

10 40

additional arcs patch
by Gerd Petermann 03 Mar '14

03 Mar '14

Hi all, attached is a patch for r3065 in the high-prec-coord branch. It should improve long distance routing, as it adds additional arcs from minor roads to major roads (so called indirect links). Maybe the improvement is only seen on the device. It would be great to hear some test results (good or bad), compared to trunk r3057 and compared to r3065. A compiled binary is here: http://files.mkgmap.org.uk/download/179/mkgmap.jar Gerd

7 15