June 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

Commit: r2654: Improve matching of street names for housenumber assignment
by svn commit 24 Jul '13

24 Jul '13

Version 2654 was committed by wanmil on Sun, 30 Jun 2013 Improve matching of street names for housenumber assignment The housenumber handling uses the style sheet generated name of streets and matches that to the addr:street tag of housenumbers. The style sheet name is now stripped by the shield information (usually a ref) and text within brackets (also usually the ref name). This increases the match rate of housenumbers especially for streets with a ref.

6 8

How to avoid coarse maps
by RheinSkipper 30 Jun '13

30 Jun '13

Hi! I am trying to make a map based on default style with levels = 0:24, 1:22, 2:20, 3:18 At zoom level 0 the map looks ok: http://files.mkgmap.org.uk/download/144/level0.JPG But at zoom level 1 and up it is very coarse: <http://files.mkgmap.org.uk/download/145/level1.JPG> http://files.mkgmap.org.uk/download/145/level1.JPG Optimization options --reduce-point-density=NUM --reduce-point-density-polygon=NUM seem to have no influence with NUM values between 0 and 10. How can I control the smoothness of the map?

2 2

[PATCH v1] Fix housenumber assignment for streets with refs
by WanMil 30 Jun '13

30 Jun '13

The patch strips the ref shields from the labels when comparing street names with addr:street tags of OSM elements. So also streets with sheidls can be used for housenumber search which was not possible before. Please note: the patch works only if the mkgmap:display_name is set to the raw street name in case the street has a shield. See the patched lines file. The patch also changes address search a bit. Please try and post your findings. @Steve: I found a comment in MDRFile.addStreet that tells me that the name including the shield is used for MDR7. I have changed that in the patch because I didn't understand why the shield is included. Can you check your comment and remember about your intention? ;-) WanMil

4 8

Commit: r2653: Add options documentation to doc.
by svn commit 28 Jun '13

28 Jun '13

Version 2653 was committed by steve on Fri, 28 Jun 2013 Add options documentation to doc. This is almost but not quite, generated from the help/en/options file.

1 0

British National Grid
by Roger Calvert 28 Jun '13

28 Jun '13

I have updated my OSM-compatible files of the British National Grid (http://www.rogercalvert.me.uk/OSM/GBGrid) by removing 100km grid squares which show nothing useful (such as empty sea), thus reducing the file size by about 35%. The outline can be seen at http://www.rogercalvert.me.uk/OSM/GBGrid/GBGridSquares.bmp. Contact me if there are any problems. Regards, Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

1 0

"This may break routing" warning query
by Eric Fernandez 27 Jun '13

27 Jun '13

Hi, Thanks a lot for adding the --check-style option. I got this message, using a custom style: Warning: routable type 0x0a is used for non-routable line with resolution 24. This may break routing. Style file lines, line 256 Warning: routable type 0x06 is used for non-routable line with resolution 24. This may break routing. Style file lines, line 259 Warning: routable type 0x1b is used for non-routable line with resolution 24. This may break routing. Style file lines, line 283 What actions am I supposed to do? I changed the resolution (which was not 24) at the line numbers mentioned above, but this did not make the warning disappear. What am I doing wrong? Thanks a lot, Eric

3 4

Polygon draw order, and routing across tiles
by Geoff Sherlock 23 Jun '13

23 Jun '13

Hi, This is not a bug report, but something I found interesting. I recently noticed a problem with polygon draw order in Mapsource; and on my Dakota 20. Sometimes a polygon was drawn correctly above another (according with the draw order specified in the TYP file), and at other times not. I don’t believe mkgmap actually processes the TYP file so I did not report it here. This morning I was playing with drawing dark lines around polygons to “fix” this, but found mkgmap created a 28000+ Kb file that was too large for Mapsource to show. When I reduced the –max-nodes option to produce smaller tiles I noticed it fixed some, but not all of the polygon draw order problems. So I reduced it further (from the original 1500000, to 750000) and found it fixed all the draw order problems I had noticed. >From previous posts and experience, I knew there was a problem routing across tile boundaries (which is why I had been using 1500000 to reduce the number of tiles produced, and thus the boundaries). So I found an area where 4 tiles met close to each other, and tried auto-routing across the boundaries in Mapsource. To my surprise reducing the max-nodes had now fixed this problem as well, and I could route anyway I liked E->W, W->E, N->S, S->N across the four boundaries. Auto-routing also worked fine on my device as well So if anyone is experiencing similar problems; I suggest trying to reduce the max-nodes and seeing if that helps. Geoff.

1 0