May 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

overview map
by GerdP 04 Jun '13

04 Jun '13

Hi all, finally I've merged r2629 into trunk. A brief description of the changes: 1) new or changed options --overview-levels like levels, specifies additional levels that are to be written to the overview map. Counting of the levels should continue. Up to 8 additional levels may be specified, but the lowest usable resolution with MapSource seems to be 11. --remove-ovm-work-files If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files. --polygon-size-limits=limits code Allows to specify different min-size-polygon values for each resolution. Sample: --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 11:0" If a resolution is not given, mkgmap uses the value for the next higher one. For the given sample, resolutions 19 to 24 will use value 12, resolution 17 and 18 will use 10, and so on. Value 0 means to skip the size filter. Note that in resolution 24 the filter is not used. 2) Optimizations: - The polygon filter allows larger polygons. - SeaGenerator generates fewer "sea-only" and "land-only" polygons when precomp-sea is used. Both reduce the img size, esp. for maps containing large "sea only" areas. 3) Changes regarding styles: - The support for the out-aged map-features.csv file was removed - Level ranges can now use min-max or max-min - Usage of polygon type 0x4a will be flagged with --check-styles 4) Other changes - A few checks are performed regarding the plausibility of the given options and input files to help beginners. -- View this message in context: http://gis.19327.n5.nabble.com/overview-map-tp5763471.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 4

mkgmap javadoc
by GerdP 03 Jun '13

03 Jun '13

Hi programmers, I tried to fix the warning which are produced with ant javadoc A few ones are left, I don't know how to handle them: ... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_43 [javadoc] Building tree for all the packages and classes... [javadoc] D:\mkgmap\src\uk\me\parabola\imgfmt\app\mdr\Mdr5Record.java:119: warning - Tag @see:illegal character: "123" in "{@link #setMdr20set(int[])}" [javadoc] D:\mkgmap\src\uk\me\parabola\imgfmt\app\mdr\Mdr5Record.java:119: warning - Tag @see:illegal character: "64" in "{@link #setMdr20set(int[])}" [javadoc] D:\mkgmap\src\uk\me\parabola\imgfmt\app\mdr\Mdr5Record.java:119: warning - Tag @see: reference not found: {@link #setMdr20set(int[])} [javadoc] D:\mkgmap\src\uk\me\parabola\mkgmap\gui\AppLayout.java:61: warning - @noinspection is an unknown tag. [javadoc] D:\mkgmap\src\uk\me\parabola\mkgmap\gui\FileOptions.java:138: warning - @noinspection is an unknown tag. [javadoc] D:\mkgmap\src\uk\me\parabola\mkgmap\gui\MainFileList.java:223: warning - @noinspection is an unknown tag. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating D:\mkgmap\doc\api\stylesheet.css... [javadoc] 6 warnings Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-javadoc-tp5763480.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

Handling of refs
by WanMil 02 Jun '13

02 Jun '13

Hi, I tried to remove the name from motorway_links and other _links. My first approach was simple: highway=motorway_link { delete name } This changed nothing! Mmmh, I looked into the source code and observed that the action { name 'abc' } is different to { set name='abc' } After using { name 'abc' } it is not possible to remove or to change the name using the style. So I changed all rules to { set name='abc' } This improved things a bit but the refs were still displayed. Then I noticed that there is a lot of automatic name handling in the StyledConverter: The ref is composed of the tags mkgmap:display_name, ref, int_ref, nat_ref and reg_ref. If there is no name set the composed ref is used as name. So the final rule to remove the name from the motorway_link is highway=motorway_link { delete name; delete mkgmap:display_name; delete ref; delete ref; delete int_ref; delete nat_ref; delete reg_ref } I think this is not very intuitive?! Without having a look into the source code I would have never been able to remove the name. I wonder if it would be better to implement these hard coded rules within the style so anybody can see what happens and can easily influence the naming: 1. Create a new mkgmap tag mkgmap:ref which is used to set the ref field in the garmin map. Without setting mgkmap:ref the ref field will be empty. This makes mkgmap:display_name superfluous. Another advantage is that the ref, nat_ref etc. tags can be removed from the builtin-tag-list. 2. Set the name using the tag mkgmap:name. Remove the { name 'abc' } action. This might be controversial and requires changes in all styles. What do you think? WanMil

5 8

Commit: r2636: ov_codepage_v2.patch: extract codepage and encoding type from *.img
by svn commit 31 May '13

31 May '13

Version 2636 was committed by gerd on Fri, 31 May 2013 ov_codepage_v2.patch: extract codepage and encoding type from *.img files and use them to create LBL file in overview map to make sure that labels are correct

1 0

overview-map and codepage
by Henning Scholland 31 May '13

31 May '13

Hi, I discoverd, that the overviewmap doesn't use the given codepage (see http://www.aighes.de/data/map.png and http://www.aighes.de/data/overviewmap.png ). Isthis a limitation of overview maps or is it just a bug? Henning

4 10

polygon type 0x4a
by Gerd Petermann 31 May '13

31 May '13

Hi all, I was able to reproduce the error messages reported by Felx : http://gis.19327.n5.nabble.com/SeaGenerator-in-overview2-branch-tp5761296p5… when I add something like this in the style\polygons file: natural=land [0x4a resolution 10] and use --precomp-sea. As I already wrote, the polygon type 0x4a is hardcoded in mkgmap: 1) mkgmap generates 0x4a polygons for the whole map when you don't use --transparent 2) polygons with type 0x4 are NOT divided by the PolygonSubdivSizeSplitterFilter I am not sure what to make of this. The default style doesn't assign 0x4a to a polygon, it doesn't even have a rule for the natural=land polygons generated by the SeaGenerator. I was already wondering why we generate them. I assume the special treatment of 0x4a in PolygonSubdivSizeSplitterFilter was added because of the bug that was fixed in r2612. This is what happens if I remove the special case for 0x4a: - With r2613 and the (unchanged) default style I see no change in any output file - With r2613 and the above modification I see that the error messages are gone So I guess I should just remove the special case? Gerd P.S. Felix, get well soon!

7 14

Commit: r2635: javadoc fix
by svn commit 31 May '13

31 May '13

Version 2635 was committed by steve on Fri, 31 May 2013 javadoc fix

1 0