June 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

Incorrect compilation of grid lines
by Roger Calvert 28 Jul '14

28 Jul '14

I have a file containing the British National Grid lines, as printed on Ordnance Survey maps. This can be found at http://www.rogercalvert.me.uk/osm/GBGrid/GBGrid.zip (this contains two files, they are the same except for the addition of the 'version' tag in the GBGrid06.osm file). I compile this file with mkgmap and overlay it on my GPS map. This works correctly with mkgmap 2654 and It displays correctly in JOSM. With mkgmap version 3241, the lines are misaligned and out of position. The behaviour is the same on MapSource, BaseCamp and my device. No error messages are produced. (I have not used any versions of mkgmap in between these two). My style file allocates codes in the 0x10300 range to these lines, but the effect is the same when I use code 0x21 (contour) for all lines. Attached are screen dumps for a small part of the map, from JOSM, mkgmap 2654 and mkgmap 3241, and also the batch file I used to compile it. I would greatly appreciate any advice. Many thanks, Roger -- ------------------------------------------------------------------------ Roger Calvert http://www.rogercalvert.me.uk ------------------------------------------------------------------------

5 11

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

building catch all
by chris66 19 Jul '14

19 Jul '14

Hi, at the end of polygons we have some catch all rule: (building=* | amenity=*) & area!=no [0x13 resolution 24] tourism=* & area!=no & waterway!=* [0x13 resolution 24] # man_made can be used on areas or lines man_made=* & area!=no & (man_made!=door & man_made!=embankment & man_made!=breakwater & man_made!=cable_line & man_made!=cutline & man_made!=cutting & man_made!=levee & man_made!=trench) [0x13 resolution 24] man_made=* & area=yes [0x13 resolution 24] This causes that following osm elements are mapped to building (0x13): tourism=camp_site (should be mapped to 0x17 or 0x19) amenity=grave_yard (should be mapped to 0x1a) So I think we should have more specific rules here instead a catch-all. Chris

4 8

Address boundary rules for South Africa
by Ben Konrath 03 Jul '14

03 Jul '14

Hi, Here's a patch to add address boundary rules for South Africa. Thanks, Ben

2 3

Unicode maps showing locked or not found on GPS units
by Felix Hartmann 02 Jul '14

02 Jul '14

Hi, could some people please test with their maps using unicode on their GPS (--code-page=65001) and maybe also report FID (family-ID) used for maps. I have the problem that some users report the maps show up as locked! (maps created with mkgmap version 3300 as of June 18) So far problematic: Garmin GPSMaps 64 - FID 6371 - sent from Mac OSx Basecamp/Map Install. Garmin Edge 1000 - FID=6531 - sent via?? Works as tested below ( sent via Mapsource, Mapinstall (Windows) and gmapsupp.img created by mkgmap.jar (java 1.7 windows) ): Garmin Oregon 600 - FID 6365 works... Garmin etrex 30 - FID 6365, works... Works without problems as long as no code-page other than latin1 characters are in the map AND is sent via Mapsource or MapInstall (Windows) - does not work if gmapsupp.img created by mkgmap! Problems - even German Umlauts (ÖÄÜ or "french" accents like é) are not displayed correctly anymore (instead split into two funky looking characters). Therefore for old units --latin1 is still the better option for old devices for most european countries. Garmin Vista HCx - FID=6365 So it's clear that there is something wrong in the way mkgmap.jar creates gmapsupp.img for maps with Unicode - though it does work for newer devices with full unicode support. Mind though I did not check on the unit itself if cyrillic or arrabic script is actually working. BTW 2. -- It would be great if there is a short-code like --latin1 for unicode too! E.g. --unicode instead of --code-page=65001, just for simplicity... -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

3 10

Edge Touring shows "loading maps"
by thesurveyor＠wolke7.net 30 Jun '14

30 Jun '14

1 0