July 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

Why is there a code-page in the .typ-file? And - is there a code-page a gmapsupp.img?
by Felix Hartmann 20 Mar '15

20 Mar '15

Hi Everyone 1. Switching to unicode I ask myself If I should also change the typ-file to code-page=65001 - is this only for the case that you want to label a line/poi/polygon using unicode characters - or should any .typ-file that is "bundled" by a unicode map, also be unicode? Does anyone know a garmin unicode map that has a .typ-file? 2. I couldn't notice any change on compiling a gmapsupp.img regarding a code-page set. Is there actually a code-page for a gmapsupp.img? Especially regarding address index. Or is the code-page only for the map.img files themselves? Felix -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

4 5

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

Splitter
by Lambertus 03 Nov '14

03 Nov '14

There is a ~20MB o5m file that needs to be split. But Splitter returns: "Cannot find a good split with exactly 2 areas" I hope a (the) dev can have a look at this? Thanks! The tile is here: http://osm.pleiades.uni-wuppertal.de/garmin/20140703/63240007.o5m See for more info and a link to the o5m file: http://forum.openstreetmap.org/viewtopic.php?pid=434024#p434024

4 7

Command to transliterate Characters/Cyrillic/Greek into latin1 even for Unicode maps?
by Felix Hartmann 04 Sep '14

04 Sep '14

The standard behavior so far for my maps in Japan or China was to use --latin1, and hope that all towns/cities/names if not name:en present - got transliterated decently into latin characters. However if using Unicode this is of course not happening. Could there be a command like {set name='${mkgmap:trans:name}' } That way one could build a map that is usable for people who do understand the local script/language, and who don't by setting all names e.g. name=('name:en|name:int|mkgmap:trans:name''(name in e.g. Japanese Script) ' Even better would of course be if there would be an additional function to check if "name" is already in two scripts - this is often the case for Japan or Thailand or Singapore... Dunno if that is easy to implement. I hope/guess the above /mkgmap:trans:name/ would be easy, as the code exists if you use e.g. --latin1. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

3 12

Merging pbf files before splitter/mkgmap fails
by paco.tyson＠free.fr 03 Aug '14

03 Aug '14

Hi all, I need help for a slightly offtopic problem. I've got a (huge) list of addresses in CSV format. I want to add them to the pbf file from geofabrik before running splitter/mkgmap. Those addresses aren't in OSM. I converted the CSV file to an .osm file. The script produces the addresses with a negative osm id. I then use osmconvert : ./osmconvert geofabrik.osm.pbf addresses.osm --out-pbf -o=complete.pbf No error returned. The complete.pbf file is correctly processed by the splitter/mkgmap toolchain. But the map doesn't show the addresses. I tried to look for the problem : - The .osm file seems correct, it opens correctly in JOSM. - Converting the .osm file to .pbf format before merging doesn't help - Something funny : after merging, the .pbf file is slightly smaller than the geofabrik one. osmconvert does a more efficient job at creating pbf files ? I guess that the problem lies in the merging part but I didn't find any inspection tool for the pbf format. Can anybody help ? Paco.

3 5

help needed
by Gerd Petermann 03 Aug '14

03 Aug '14

Hi all, I am still trying to find a better solution for the problem posted by Roger Calvert: http://gis.19327.n5.nabble.com/Incorrect-compilation-of-grid-lines-tp580950… We are using some approximations to speed up calculations, most of them work fine as long as distances are rather short. On the other hand, mkgmap doesn't check if distances are short, so in some cases we have rather large errors. I found two sources for formulas: http://www.movable-type.co.uk/scripts/latlong.html and http://williams.best.vwh.net/avform.htm The latter gives an example to verify the code. I've coded some lines in Java and got similar results as in the "worked example". I've then tried to verify the example in JOSM, esp. the cross-track-error. Unfortunately, when I try to draw a (nearly) perpendicular line from point A to line LAX-JFK, JOSM says the line is ~27.7 km long, while the example calculations are near 13.8 km or about 50% of the JOSM value. What am I getting wrong? Gerd

6 15

Curvy routing support: new function?
by Manfred Brenneisen 01 Aug '14

01 Aug '14

Hi all, Garmin offers "curvy roads" preferences for their zümo 390 and 590 devices. https://buy.garmin.com/en-US/US/on-the-road/motorcycles/zumo-390lm/prod1382… I'm thinking about creating motorcycle maps for old 200 series. Might it be useful to integrate a curviness() function so that mkgmap can optimize for curvy roads too? It might also help do determine a better default speed for curvy roads for use with car routing. The curviness() value might be the overall absolute turning angle (in degrees) of a road segment divided by the segment's length. What's your opinion? Cheers Manfred Pseudo code might look like this: function curviness() { oldpoint=points(0) foreach (point of a way segment as newpoint) { d_x=(newpoint.x-oldpoint.x)/360*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //in meters length+=sqrt(d_x**2+d_y**2) angle=arctan(d_y/d_x) d_angle=abs(angle-old_angle) sgn_x=sgn(d_x) sgn_y=sgn(d_y) if ((sgn_x*sgn_y*old_sgn_x*old_sgn_y)=-1 && (sgn_x!=old_sgn_x)) d_angle=pi-d_angle // 180 degrees correction, otherwise north-south roads show strange results if (point>1) sum_angle+=d_angle old_angle=angle oldpoint=newpoint old_sgn_x=sgn_x old_sgn_y=sgn_y } return sum_angle/length } // perhaps simple multiplication is faster than 4 times sgn() functions?

5 15

Commit: r3319: Give a warning for probable cases of files with wrong encoding.
by svn commit 31 Jul '14

31 Jul '14

Version mkgmap-r3319 was committed by steve on Thu, 31 Jul 2014 Give a warning for probable cases of files with wrong encoding. The default reading routines in Java cause bad characters in unicode input to be replaced with the unicode replacement character 0xfffd. We detect this in the TokenScanner, and print a message with the file and line number. This will apply to all files that are read using TokenScanner, so probably everything other than the maps themselves. It is possible for a file that is in the wrong encoding to still be valid utf-8 although this would be rare, and you can always add a comment with some accented characters that is likely to fail when in the incorrect encoding. It does mean that you can't genuinely have a replacement character in your input. I don't think that this is likely to be a real problem, but we did have a few ourselves already, which have been removed by this patch.

1 0