- mkgmap-dev - The mkgmap lists

Correct use of codepages
by Nop 30 Mar '09

30 Mar '09

Hi! When one tries to create a map of greece and all names look good in the .osm but are garbled in the images, I guess the reason must be an improper use of the codepage parameter. How would you call mkgmap to translate greek characters correctly? thanks Nop

2 1

Motorway exits and the base map
by Toby Speight 30 Mar '09

30 Mar '09

Whilst looking at motorway exits on my Legend recently, I noticed that in "Find/Exits" the context menu lets you choose which map to use for exits (unlike all other searches). By default, "choose best maps" is selected; I don't know how it makes this choice - perhaps the map has some sort of resolution/accuracy field somewhere, and ours isn't marked as being more accurate than the base map? I know it's a bit late to add to this old discussion, but perhaps it might help.

2 1

Map name in MapSource
by Nop 28 Mar '09

28 Mar '09

Hi! When I install maps into mapsource, the map name there is always "OSM map" so that I cannot distinguish the different maps. What parameter do I need to use to set unique names there? thanks Nop

2 2

[PATCH?] Fix for german umlaut problem in style files
by Ulf Lamping 27 Mar '09

27 Mar '09

Hi! As I tried to follow the guide at: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map I stumbled over the following mkgmap error: Error in style: Error: (points:68): Invalid operation 'V' at top level After communicating this on osm talk-de, I recognized that this problem only seem to appear on Windows but works fine on Linux. The problematic style line: cuisine = kebap | cuisine = döner [0x2a19 resolution 24] contains a german umlaut ö (don't know if this char will be mangled by the mail transfer). The style file itself is an UTF-8 (without BOM) formatted file. I tried to convert the file to different character encodings, but always get the above error. As far as i understand this, its a problem of the character encoding for style files. I've tried to tell mgkmap to use UTF8 from command line -Dfile.encoding=UTF8 only getting an "unrecognized option" error. Then I digged deeper into the source code ... The attached patch fixes the problem on my Windows XP german machine. It tells JAVA to read the stylefile always in UTF-8 format, which is IMHO a good idea anyway ... This is the first time I looked into the mkgmap code, so I don't know if this patch will make problems on Linux, if it fixes the problem in all style cases and very certainly has a very ugly Exception handling. Couly someone have a look at it? Regards, ULFL Index: src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java (revision 987) +++ src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java (working copy) @@ -20,6 +20,9 @@ import java.io.File; import java.io.FileNotFoundException; import java.io.FileReader; +import java.io.InputStreamReader; +import java.io.FileInputStream; +import java.io.UnsupportedEncodingException; import java.io.Reader; import java.util.ArrayList; import java.util.List; @@ -53,7 +56,14 @@ */ public Reader open(String filename) throws FileNotFoundException { File file = new File(dir, filename); - Reader r = new FileReader(file); + + Reader r = null; + try { + r = new InputStreamReader(new FileInputStream(file), "UTF-8"); + } + catch(UnsupportedEncodingException uee) { + System.out.println("DirectoryFileLoader: Encoding UTF-8 not supported"); + } return new BufferedReader(r); }

2 2

[Fwd: [PATCH?] Fix for german umlaut problem in style files]
by Ulf Lamping 27 Mar '09

27 Mar '09

Hi! As I tried to follow the guide at: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map I stumbled over the following mkgmap error: Error in style: Error: (points:68): Invalid operation 'V' at top level After communicating this on osm talk-de, I recognized that this problem only seem to appear on Windows but works fine on Linux. The problematic style line: cuisine = kebap | cuisine = döner [0x2a19 resolution 24] contains a german umlaut ö (don't know if this char will be mangled by the mail transfer). The style file itself is an UTF-8 (without BOM) formatted file. I tried to convert the file to different character encodings, but always get the above error. As far as i understand this, its a problem of the character encoding for style files. I've tried to tell mgkmap to use UTF8 from command line -Dfile.encoding=UTF8 only getting an "unrecognized option" error. Then I digged deeper into the source code ... The attached patch fixes the problem on my Windows XP german machine. It tells JAVA to read the stylefile always in UTF-8 format, which is IMHO a good idea anyway ... This is the first time I looked into the mkgmap code, so I don't know if this patch will make problems on Linux, if it fixes the problem in all style cases and very certainly has a very ugly Exception handling. Couly someone have a look at it? Regards, ULFL Index: src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java (revision 987) +++ src/uk/me/parabola/mkgmap/osmstyle/DirectoryFileLoader.java (working copy) @@ -20,6 +20,9 @@ import java.io.File; import java.io.FileNotFoundException; import java.io.FileReader; +import java.io.InputStreamReader; +import java.io.FileInputStream; +import java.io.UnsupportedEncodingException; import java.io.Reader; import java.util.ArrayList; import java.util.List; @@ -53,7 +56,14 @@ */ public Reader open(String filename) throws FileNotFoundException { File file = new File(dir, filename); - Reader r = new FileReader(file); + + Reader r = null; + try { + r = new InputStreamReader(new FileInputStream(file), "UTF-8"); + } + catch(UnsupportedEncodingException uee) { + System.out.println("DirectoryFileLoader: Encoding UTF-8 not supported"); + } return new BufferedReader(r); }

1 0

Some questions about POI's addresses
by Carlos Dávila 27 Mar '09

27 Mar '09

I hadn't tested POI's addresses support since it was added to trunk till now (nuvi 300). After reading most messages about this matter in the list (still not all, so apologize if I ask something that has already been answered) I still have not clear how it works. Here are my doubts, questions, comments. *First I've noticed is that pois having is_in:region tag don't show region in nuvi. If region is taken from is_in rather that is_in:region it's a problem for countries like Spain, where information in this tag is completely erratic, i.e. you can find city, region, country, continent values in any order, some of them missing, separated by , or by ; etc. This way I can't find a way to set the region with regionOffset parameter in LocatorConfig.xml *About poiDispFlag in LocatorConfig.xml: -> Address display format: Default is 0 - How does it display? 0xc show street before street number - ¿and? - show zip before city *If I use template.args generated by splitter as -c argument for mkgmap, all pois (except road_name_pois) are duplicated; for those without address information in osm data one of the pois have "Fix my address" and city added and the other one not. This is my mkgmap command: java -Xmx500m -enableassertions -jar mkgmap.jar -c template.args --route --latin1 --code-page=1252 --description="OpenStreetMap-Iberia" --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --name-tag-list=ref,name --family-name="Open Street Map" --family-id=14 --product-id=314 --net --road-name-pois --ignore-osm-bounds --preserve-element-order --add-pois-to-areas --location-autofill=1 6*.osm.gz I'm using a customized LocatorConfig.xml that includes Spain (I'll send a patch after clarifying poiDispFlag). Regards Carlos

4 5

Splitter results
by Lambertus 27 Mar '09

27 Mar '09

Using a server with 64GB ram I was able split the latest planet dump with Splitter in about an hour. In the results however are some weird tiles: The first tile is 644 MB gzip compressed, clearly not something that Mkgmap is going to like much: 63240001: -4196352,-10010624 to 598016,-4046848 # : -90.043945,-214.804688 to 12.832031,-86.835938 There are also quite some tiles that go outside the expected -180 to +180 and -90 to +90 degree bounding box, like: 63240002: -4196352,-4046848 to -1943552,-2555904 # : -90.043945,-86.835938 to -41.704102,-54.843750 63240006: 598016,-10010624 to 1796096,-6334464 # : 12.832031,-214.804688 to 38.540039,-135.922852

4 3

[PATCH] splitter now reads directly .osm.bz2 files
by Johann Gail 27 Mar '09

27 Mar '09

Hi, I've just created a patch, which enables splitter to read .bz2 compressed files directly without need for external decompressing. This eases live for me, as I generally get my osm data from geofabrik, which is bzip2 compressed. It uses the CBzip2InputStream class from org.apache.tools.bzip2.* If you apply only part a of the patch, then you will need a jar file with this class in your classpath. You can get it e.g. at http://www.kohsuke.org/bzip2/ If you apply part b additionally, then it contains all you need. But I absolutely don't know if the apache license, which is valid for the CBzip2InputStream class allows including in other projects. Therefore I have splitted the patch into two parts. Please comment, should this patch be commited to svn? Greetings, Johann

3 2

[PATCH] splitter now reads directly .osm.bz2 files
by Johann Gail 26 Mar '09

26 Mar '09

Sorry, forgot to append the patches. Here they are

2 1

Include external TYP-File with mkgmap?
by Johann Gail 26 Mar '09

26 Mar '09

Hello, I would like to include a TYP file in my gmapsupp.img. I know that it is possible e.g. with sendmap. Is it possible (or at least planned in future) to include a typ file directly with mkgmap? Regards, Johann Gail

3 2