March 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

vehicles in restriction relations
by GerdP 08 Apr '14

08 Apr '14

Hi all, I've just modified a routine that translates the vehicle types used in OSM to the ones used in Garmin restrictions: if(vehicle.equals("motorcar") || vehicle.equals("motorcycle") || vehicle.equals("motor_vehicle")) flag = RouteRestriction.EXCEPT_CAR; else if(vehicle.equals("psv") || vehicle.equals("bus")) flag = RouteRestriction.EXCEPT_BUS; else if(vehicle.equals("taxi")) flag = RouteRestriction.EXCEPT_TAXI; else if(vehicle.equals("delivery") || vehicle.equals("goods")) flag = RouteRestriction.EXCEPT_DELIVERY; else if(vehicle.equals("bicycle")) flag = RouteRestriction.EXCEPT_BICYCLE; else if(vehicle.equals("hgv") || vehicle.equals("truck")) flag = RouteRestriction.EXCEPT_TRUCK; if (flag == 0){ log.warn(messagePrefix, "ignoring unsupported vehicle class '" + vehicle + "' in turn restriction"); return false; } else { ...} I think that this should better be done in the style? I also wonder why the wiki lists different kinds of vehicles for restriction:<vehicle>=<turn> , type=restriction:<vehicle> , and except=* I hope it is okay to use the same code for all of them? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/vehicles-in-restriction-relations-tp5801618.… Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 21

invalid rule expression
by Minko 02 Apr '14

02 Apr '14

This rule does not work: highway ~ '(secondary|tertiary|unclassified|residential|minor|living_street|service)' & oneway=* & (cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no ) {set bicycle=no; set mkgmap:cycleway=yes} Only if I put oneway=* first, it works, why? oneway=* & highway ~ '(secondary|tertiary|unclassified|residential|minor|living_street|service)' & ( cycleway=opposite | cycleway=opposite_lane | cycleway=opposite_track | oneway:bicycle=no | bicycle:oneway=no ) {set bicycle=no; set mkgmap:cycleway=yes} The error message is: Error in style: Error: (lines:119): Invalid rule expression: (((($cycleway='opposite')|(($cycleway='opposite_lane')|(($cycleway='opposite_track')|(($oneway:bicycle='no')|($bicycle:oneway='no')))))&$oneway=*)&($highway~'(secondary|tertiary|unclassified|residential|minor|living_street|service)'))

2 9

Restriction relations and additional (cycle) ways
by GerdP 01 Apr '14

01 Apr '14

Hi, the via-ways branch is almost done, but I wonder what to do when make-opposite-cycleways is used or when the style creates multiple routable lines for one OSM way. The Garmin format for restrictions reqires nodes and arcs. The OSM format specifies from and to ways and via nodes or ways. Assume that a via way of an only_left restriction has also an opposite cycleway. Should mkgmap create all possible combinations of restrictions to make sure that also bicycles are only routed left ? Or should it make sure that the bicycle ways are not affected? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Restriction-relations-and-additional-cycle-w… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 17

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 68, Issue 97
by Paulo Carvalho 31 Mar '14

31 Mar '14

Greetings, Steve 2014-03-31 17:28 GMT-03:00 <mkgmap-dev-request(a)lists.mkgmap.org.uk>: > > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 16:23:46 +0100 > Subject: Re: [mkgmap-dev] Incorrect line number in error report > Hi > > As I was experimenting with the style files, I introduced an error >> in one of the rules. Then mkgmap naturally reported an error at, say >> "line 60:20", but the error line was actually several lines further >> down, say line number 73. >> > > This was reported a few days ago and I created a fix, but I can't see > that I sent it out. > > I've attached a patch and I will commit it soon anyway. > > ..Steve > Thanks, Steve. > ---------- Mensagem encaminhada ---------- > From: Steve Ratcliffe <steve(a)parabola.me.uk> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Date: Mon, 31 Mar 2014 20:49:34 +0100 > Subject: Re: [mkgmap-dev] Character decoding used by mkgmap when reading > style files > Hi Paulo > > highway=* & name ~ '(?i)pra[c็ว]a\s+.*' { add >> streettype:movedend='${name|subst:(?i)pra[c็ว]a\s+~>}, Pc.'} # >> > > I tried to reproduce this, but I could not. All seemed to work well > with my quick test. There was a bug that was fixed very recently > (in r3111 and later) about this very problem. Are you using the latest > version? > > Best wishes > > ..Steve > I'm using the latest stable release: 3138. Please, consider this a non-issue for now. I'll double check my procedures. Probably I was mistaken. all the best, Paulo

1 0

Possible mkgmap GPL v2 license infringement
by Paulo Carvalho 31 Mar '14

31 Mar '14

People, Recently "Projeto Tracksource" released a new version of its TSuite tool with Garmin compilation feature. Out of a sudden the JAR grew from 2.5MB to 4.5MB. Probably this tool incorporates mkgmap code. TSuite is distributed as close-source and does not mention mkgmap. TSuite JAR is obfuscated, which casts suspicion itself. But being obfuscated, it also makes proving GPL infringement difficult. Is there any other way to prove that a Garmin map has been compiled with mkgmap? Something like a water mark or some digital fingerprint? "Projeto Tracksource" website: http://www.tracksource.org.br . You can dowload the JAR file here: http://www.tracksource.org.br/index.php/desenvolvimento.html . Hit a button called "TSuite jar" to download it. regards, Paulo

2 1