August 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

Drive-on-left
by Colin Smale 15 Nov '13

15 Nov '13

Hi, In the last couple of years I have been making maps with mkgmap for both the UK and various continental countries. One problem that I have never been able to fix until now is that the "drive-on-left" flag didn't seem to have any effect on roundabouts in the UK. The "impact" is limited because roundabouts are one way anyway, but the pictographic representations of roundabouts always assume drive-on-right so you appear to be directed to drive the wrong way. I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared! I am not really a Java programmer so I don't feel confident about trying to fix this myself, but it seems there is related code in TREHeader.java including the following declarations: public static final int POI_FLAG_TRANSPARENT = 0x2; public static final int POI_FLAG_STREET_BEFORE_HOUSENUMBER = 0x4; public static final int POI_FLAG_POSTALCODE_BEFORE_CITY = 0x8; I think it just needs something like this adding: public static final int POI_FLAG_DRIVE_ON_LEFT = 0x20; plus the code to set this bit depending on the drive-on-left flag. It would be great if this could be changed in mkgmap. If I should really be logging this elsewhere please accept my apologies and point to me to the right place and I will enter the details there. Best regards (and thanks everyone for a tremendous program!) Colin [1] https://sites.google.com/site/sherco40/imgtool [1] Links: ------ [1] https://sites.google.com/site/sherco40/imgtool

7 19

location-autofill=nearest breaks compiling
by Carlos Dávila 16 Oct '13

16 Oct '13

Compiling British Isles map with location-autofill=is_in,nearest throws the following error: Exception in thread "main" java.lang.AssertionError: Invalid label offset found 105 at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.java:86) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.readPoiInfo(LBLFileReader.java:351) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.<init>(LBLFileReader.java:74) at uk.me.parabola.mkgmap.combiners.FileInfo.lblInfo(FileInfo.java:326) at uk.me.parabola.mkgmap.combiners.FileInfo.lblInfo(FileInfo.java:313) at uk.me.parabola.mkgmap.combiners.FileInfo.imgInfo(FileInfo.java:259) at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:152) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:545) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.main(Main.java:119) Removing the "nearest" part of location-autofill it works fine. All other maps I compile with location-autofill=is_in,nearest also compile without problems. Any idea why this particular map may be going wrong?

4 11

[PATCH v1] Merge road network
by WanMil 29 Sep '13

29 Sep '13

mkgmap has a LineMergeFilter but that does not merge the road network. Attached patch performs a merging in the OSM data just before the road network is created. This has the advantage that the source code for the merging is quite easy. Turn restrictions and through routes are considered. I tested some data in germany and got a reduction of 5% to 12% (number of roads). I did not find any improvements but also no downgrades in routing. But I did not test long distance routing (> 600km). I think the merge results can be improved if the access handling and some other parts are moved from source code to the style files. This makes it easier for the merger to say that two roads have the same attributes and can be merged without problems. But that's a task for the future... I have already uploaded a compiled version: http://files.mkgmap.org.uk/detail/148 For anyone who is interested in the code: Please check the tag list (variable flatCompareTags) in the new RoadMerger. This taglist gives all tags that must be equal so that two roads can be merged. Is this list complete? Can I remove some tags from it? Have fun! WanMil

6 14

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 v2] Move maxspeed calculations to style file
by WanMil 13 Sep '13

13 Sep '13

The patch moves the road speed calculations based on the maxspeed tag to the style file. It uses the new maxspeedkmh function to calculate the new internal tag mkgmap:road-speed-class. This makes the ignore-maxspeeds option superfluous. Anyhow I have kept it to ignore the evaluation of the new tag mkgmap:road-speed-class. The second advantage is that maxspeed can be removed from the builtin-tag-list which meaans the maxspeed tag is not loaded if not referenced in the style file. WanMil

9 19

Check style AND type
by Bernhard Hiller 08 Sep '13

08 Sep '13

Is there a possibility to check a style together with the corresponding type file? For example, a type could contain a line/poi/area which is not used at all in the style. The other way round may be less important due to Garmin's default style, I think it should be possible to check that too. But most important is consistency: yesterday I stumbled upon a combination with POI 0x3007 being an embassy in the style file, and a prison in the type file. How can we easily detect such problems?

2 2

Use of ' include "points" from default; ' in custom style file
by Steve Brophy 05 Sep '13

05 Sep '13

I have been replacing my use of base-style with 'include' statements and encountered a problem using eg 'include "points" from default;'. When I do this, mkgmap reports that it can't find 'inc/address' , which is included in the default style points file. It turns out that mkgmap is looking for it in my style directory, rather than in the built-in inc location where the default style is located. To work around this, I had to copy the 'inc' directory from mkgmap.jar to my custom style directory. Not an ideal solution, since I would have to do this every time I update mkgmap. Is this a bug, or intended functionality? Regards, Steve

3 8

Serious mkgmap Bug - set unconnected type not respecting continue command!
by Felix Hartmann 02 Sep '13

02 Sep '13

Well the bug is quite serious and took me about 6 hours to find out why I'm missing roads in my maps. In case you have an "unconnected" type of a road that you set up a rule for, with " set mkgmap:set_unconnected_type=none" and [continue] - all subsequent commands for the object will be lost, if the set:unconnected becomes true. Reproduce: lines file (only this content needed). highway=motorway & bridge=yes {set mkgmap:set_unconnected_type=none} [0x13 road_class=1 road_speed=0 resolution 24 continue] highway=motorway [0x10001 resolution 24 continue] Now in all places that have a bridge, the motorway will be missing. If however the example is changed to the following, the bug is not present (as the unconnected type condition is not true): highway=motorway & bridge=yes {set mkgmap:set_unconnected_type=none} [0x13 road_class=1 road_speed=0 resolution 24 continue] highway=motorway [0x01 road_class=1 road_speed=0 resolution 24 continue] I don't know if there are any other problems related to this bug. However it is really defeating the purpose of set unconnected type right now, if working with overlays for bridges, routes, and many other things! -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 4