- mkgmap-dev - The mkgmap lists

Commit: r2582: name-tag-list_v2.patch: remove incomplete support for option name-tag-list in the style options file.
by svn commit 29 Apr '13

29 Apr '13

Version 2582 was committed by gerd on Mon, 29 Apr 2013 name-tag-list_v2.patch: remove incomplete support for option name-tag-list in the style options file.

2 1

one problem with splitter
by Bernd Weigelt 29 Apr '13

29 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi 'java -jar splitter.jar --help=options > splitter_options' print out very long lines, up to 267 characters. I found SplitterParams.java, but i don't now how to fix this I'm using openSUSE Linux as OS Bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9BW0ACgkQwCMdlf933K+1wQCfbzEvsrMVh/NygY0MtQTbes61 p7QAnib9CVWgZIZ70dzIJxL49nG/px4P =9+ti -----END PGP SIGNATURE-----

3 8

mkgmap style: resolutuion and level vs. GARMIN device: zoom and map-detail settings
by Franco Bez 29 Apr '13

29 Apr '13

Hi all, I wonder how these things are connected: On one hand we have the style settings in mkgamp. resolution and level. On the other hand we have the GARMIN device. Here we may use the + and - buttons to set the zoom level, and on the Nüvi in Settings - map - "map detail" , on the Oregon in Settings - map - "advanced map setup" - detail, we have the detail level. On the Nüvi 40 there are only 3 detail levels (less - normal - more), while the Oregon has 5 detail levels (least - less - normal - more - most). Does anyone know these settings are connected ? I suspect that the GARMIN device calculates some value based on the zoom and detail level, and then searches the gmapsupp.img for objects with a matching resolution setting. But this is merely a guess. Ciao, Franco

4 6

Commit: r2583: style-options-v1.patch: fix handling of --style-file and --style options:
by svn commit 29 Apr '13

29 Apr '13

Version 2583 was committed by gerd on Mon, 29 Apr 2013 style-options-v1.patch: fix handling of --style-file and --style options: - if --style-file points to a *.jar or *.zip file that contains multiple styles and --style is not given, stop with error message instead of using the first found style. - allow --style-file to point to a nested directory structure (e.g. containing mystyles/style1/version , mystyles/style2/version) - if --style-fie points to a directory or archive containing multiple styles, force the user to specify --style - if --check-styles is used with --style-file and --style, but the style is not found, issue an error message

1 0

[Patch v1] style-options
by Gerd Petermann 28 Apr '13

28 Apr '13

Hi all, attached is a patch to fix some problems regarding the style options: - if --style-file points to a *.jar or *.zip file that contains multiple styles and --style is not given, stop with error message instead of using the first found style. - allow --style-file to point to a nested directory structure (e.g. containing mystyles/style1/version , mystyles/style2/version) - if --style-fie points to a directory or archive containing multiple styles, force the user to specify --style - if --check-styles is used with --style-file and --style, but the style is not found, issue an error message The compiled binary can be found here: http://files.mkgmap.org.uk/download/116/mkgmap.jar If I here no complains I'll commit that tomorrow. Gerd

2 1

Commit: r2578: tweaks to option --check-styles:
by svn commit 28 Apr '13

28 Apr '13

Version 2578 was committed by gerd on Fri, 26 Apr 2013 tweaks to option --check-styles: - show style name first, don't show info - print all warnings to stdout (one was printed to stderr by mistake)

4 10

Transliteration
by Wolfgang Hammel 28 Apr '13

28 Apr '13

Hi, I'm trying to create two variant maps for Ukraine. The first one should show the labels in cyrillc letter. This works quite fine using mkgmap r2580 and the following command line options --code-page=65001 --name-tag-list=name:uk,name,name:ru,name:en,name:de Precedence is given to the ukrainian or russian labels if they are available and as a fallback english or german names are used. Since revision 2512 it is possible to user codepage 65001 to generate unicode maps and have a map that is not restricted to a single codepage. This map displays quite well on my Oregon 550, firmware 6.20 This thread helped a lot on that matter http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q1/017000.html The second variant of the map should give precedence to the english and german names if they are available. In case there is no english or german name, I would like to have the cyrillc name (name:uk, name, name:ru) to be transliterated to roman letters. Previously I was using mkgmap r2237 and the following command line options to achieve this. --latin1 --charset=windows-1252 --code-page=1252 --lower-case --name-tag-list=name:en,name:de,name:uk,name,name:ru Here I was using information from http://wiki.openstreetmap.org/wiki/Mkgmap/i18n With r2580 I still get the english an german names if they are available. But on elements that only have cyrillc names there are only question marks shown on the Oregon. So my questions are: How can transliteration from cyrillic to cp1252 be achieved in current releases of mkgmap? Can a transliterated map be generated using code page 65001 (ie unicode output)? Is there an option to externally provide transliteration tables to mkgmap or is this all hard coded inside mkgmap? Thanks Wolfgang

2 1

A question to Splitter
by Bernd Weigelt 28 Apr '13

28 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi is it possible to reduce output of splitter on stdout? Most infos are IMHO useless for DAUs like me and shut be on stderr or in a logfile like mkgmap's tia Bernd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9BXcACgkQwCMdlf933K9xlQCgoNYDX/NEAjMvcuimqFIFSvBi viQAn0BOh1tQKauTiHnW9V1o/bhNuhrC =zGGt -----END PGP SIGNATURE-----

4 6

Commit: r2581: print location of first point of a road in warning reg. non-routable type usage
by svn commit 28 Apr '13

28 Apr '13

Version 2581 was committed by gerd on Sun, 28 Apr 2013 print location of first point of a road in warning reg. non-routable type usage

1 0

problems with style-file option
by Gerd Petermann 27 Apr '13

27 Apr '13

Hi all, while fixing a problem in the check-styles option I found (again) some issues regarding the --style-file and --style option. The current implementation in mkgmap r2580 allows the following: 1) no --style-file option 2) --style-file=<path-to-directory> 3) --style-file=<path-to-single-file that is a zip (or jar) archive> 4) --style-file=<path-to-single-file with .style or .csv extension> a) no --style option b) --style=default c) --style=<any other style name> The combinations of these parms do not always give expected results. I tested this: a) copy the distributed styles to c:\mystyles b) create a copy of default in c:\mystyles\default_copy c) create a zip file c:\temp\mystyles.zip containing this directory d) create a zip file c:\temp\default_copy.zip containing directory default_copy and the corresponding files Results: D:\mkgmap\dist>java -jar mkgmap.jar --style-file=c:\mystyles e:\bremen\*.o5m gives error message "Could not open style c:\mystyles" I'd prefer that it would try to read directory default or that it detects the missing --style option. D:\mkgmap\dist>java -jar mkgmap.jar --style-file=c:\mystyles\xyz e:\bremen\*.o5m gives "Could not open style c:\mystyles\xyz" That's ok, maybe "style-file c:\mystyles\xyz doesn't exist" would be clearer? D:\mkgmap\dist>java -jar mkgmap.jar --style-file=c:\temp\mystyles.zip e:\bremen\*.o5m gives no error message, but used style contours_ft instead of default . That's not ok. java -jar mkgmap.jar --style=default --style-file=c:\temp e:\bremen\*.o5m gives "Could not open style default" That's ok. I did not yet try the variant 4) as this seems not to be documented very well and is probably not in use. Would it be ok to change mkgmap so that it works as I suggested? Ciao, Gerd

2 1