July 2013 - mkgmap-dev - The mkgmap lists

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

frig-roundabouts doesn't work
by GerdP 28 Sep '13

28 Sep '13

Hi, The option is described in the wiki, and I find a peace of source in the HighwayHook that evaluates it, but it doesn't work. What is missing? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/frig-roundabouts-doesn-t-work-tp5748545.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

[PATCH v1] garmin_area() style function
by WanMil 10 Aug '13

10 Aug '13

The patch adds a new style function called garmin_area(). garmin_area() returns the size of an area in garmin-units ^2. It works for polygons only. Unclosed ways return 0. Please test it and let me know: * Do you have a better name? * What to do with multipolygons? Should garmin_area() return the multipolygon size for all splitted parts of the mp? or: Should it be possible to use garmin_area() in the relations file? In this case it would be possible to add tags to all members which can then be used in the polygons file. Example: type=multipolygon & building=yes & garmin_area() > 20000 { apply { set mkgmap:bigbuilding=yes; } } Have fun! WanMil

5 12

Commit: r2661: Add sort source file for the cp1250 code page
by svn commit 03 Aug '13

03 Aug '13

Version 2661 was committed by steve on Tue, 30 Jul 2013 Add sort source file for the cp1250 code page

2 1

Address search problems with CP1250
by Andrzej Popowski 30 Jul '13

30 Jul '13

Hi, I observe following problems when using CP1250 in mkgmap options: - Address search in nuvi requires upper case characters input. If keyword contains lower case characters, no results are found. - If I use option "lower-case" in mkgmap, address search doesn't work in Mapsource. Mapsource accept only single character as an input in search form, subsequent characters are deleted. This could be mismatch in lower-upper case too. If I use CP1252 all works correctly. Note: CP1252 is hard-coded in TDB, but probably it doesn't matter. -- Best regards, Andrzej

3 9

Commit: r2660: Tdb file codepage was hardcoded, make it not.
by svn commit 30 Jul '13

30 Jul '13

Version 2660 was committed by steve on Tue, 30 Jul 2013 Tdb file codepage was hardcoded, make it not.

1 0

Re: [mkgmap-dev] Problems with --code-page=1251
by Лис 27 Jul '13

27 Jul '13

I did some tests. If street name starts with one of these letters “г д к л м н у х ц ч ш щ ъ ы ь э ю я”, they are not shown at the search results. There is no such problem with other letters “а б в е ё ж з и й о п р с т ф”. In the list all streets are present. 2013/7/27 Лис <horonitel(a)gmail.com> > On 26/07/13 16:29, Steve Ratcliffe wrote: > > > Could you try without --lower-case and see if that helps? > > > Best wishes > > ..Steve > > The problem there is > All was good on older versions, but I've updated the program and did not > keep the old version >

1 0

Problems with --code-page=1251
by Лис 26 Jul '13

26 Jul '13

On 26/07/13 16:29, Steve Ratcliffe wrote: > Could you try without --lower-case and see if that helps? > Best wishes > ..Steve The problem there is All was good on older versions, but I've updated the program and did not keep the old version

1 0

Problems with --code-page=1251
by Лис 26 Jul '13

26 Jul '13

I have a problems with search streets and adresses on my device in gmapsupp.img when i make it with --code-page=1251. I have: openSUSE 12.3 x64, java-1_7_0-openjdk, Garmin Dakota 20. My options for mkgmap: --style-file=default --gmapsupp --bounds=world-boundarys --route --index --add-pois-to-areas --tdbfile --lower-case --drive-on-right --code-page=1251 -c splitted/template.args default/openstreetmap.TYP I have no problem when I specify the option - code-page = 1252 Many streets in search not available when I specify the option - code-page = 1251 I tried the version r2659 r2656 r2654 r2653 r2648 r2643. Everywhere there is this problem. I do not have older versions.

2 1