Hello, I wonder if anyone has tried mkgmap-generated map on Garmin mobileXT (symbian). Text labels (POI and streetnames) are all abbreviated. Burger King appears as B K, but KFC is OK. A spell search on 'Burger' correctly returns 'B K'. Setting all labels as uppercase doesn't work though. I've tried different options (latin1, lower-case in mkgmap and upcase, codepage in osm2mp) but still the same problem. No such problem viewing the map in mapsource. I use osm2mp.pl to generate the mp file and the same mp file works OK when compiled at mapcenter2. Attached are screenshots of mkgmap and mapcenter2 generated maps for comparison. best regards, nyem
On Feb 12, 2009, at 20:45, nyem wrote:
I wonder if anyone has tried mkgmap-generated map on Garmin mobileXT (symbian). Text labels (POI and streetnames) are all abbreviated. Burger King appears as B K, but KFC is OK. A spell search on 'Burger' correctly returns 'B K'.
Setting all labels as uppercase doesn't work though. I've tried different options (latin1, lower-case in mkgmap and upcase, codepage in osm2mp) but still the same problem. No such problem viewing the map in mapsource.
For those affected by this problem, we found a work-around: Supply a code page on the command line: "--code-page=1252". This code page gets written to the header of the LBL file, while otherwise mkgmap just writes zero. Probably, mkgmap should make some effort to automatically write a sensible code page -- how are the options latin1, charset and code- page meant to work together? Does one affect input, the other output? Cheers Robert
Thanks! It's working OK. On Wed, Feb 18, 2009 at 7:30 PM, Robert Vollmert <rvollmert-lists@gmx.net> wrote:
On Feb 12, 2009, at 20:45, nyem wrote:
I wonder if anyone has tried mkgmap-generated map on Garmin mobileXT (symbian). Text labels (POI and streetnames) are all abbreviated. Burger King appears as B K, but KFC is OK. A spell search on 'Burger' correctly returns 'B K'.
Setting all labels as uppercase doesn't work though. I've tried different options (latin1, lower-case in mkgmap and upcase, codepage in osm2mp) but still the same problem. No such problem viewing the map in mapsource.
For those affected by this problem, we found a work-around: Supply a code page on the command line: "--code-page=1252". This code page gets written to the header of the LBL file, while otherwise mkgmap just writes zero.
Probably, mkgmap should make some effort to automatically write a sensible code page -- how are the options latin1, charset and code-page meant to work together? Does one affect input, the other output?
Cheers Robert
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
Probably, mkgmap should make some effort to automatically write a sensible code page -- how are the options latin1, charset and code-page meant to work together? Does one affect input, the other output?
Its mostly historical when I didn't fully understand what was required. The two things were selecting between the 6 bit format and the 8 bit format and then getting the correct character set for the 8 bit format. I need a charset to do the conversion, but I think that I can always create one from a code page number. latin1 is just a shortcut for charset=iso-8859-1. As codepage is used inside the file, everything should be done in terms of codepage so latin1 should be codepage=1251 etc. Cheers, ..Steve
On Thu, Apr 16, 2009 at 06:08:06PM +0100, Steve Ratcliffe wrote:
As codepage is used inside the file, everything should be done in terms of codepage so latin1 should be codepage=1251 etc.
Nitpicking: ISO 8859-1 is a subset of Microsoft/IBM Code Page 1252. But MySQL calls cp1252 "latin1" too. cp1251 is the Cyrillic alphabet. Do you know if the code page can be set per label, per tile or only per *.img file? Would it be possible to have both cp1251 and cp1252 in the same map tile or the same gmapsupp.img file? While we are at it, has any magic been implemented to translate name:language codes? e.g., name=Санкт-Петербург name:en=Saint Petersburg name:fi=Pietari name:de=Sankt Petersburg name:sv=Sankt Petersburg Does the Garmin format allow multiple names for the same place (selecting the name based on user language preferences)? Near the Finnish-Russian border (and near the former “iron curtain”) it would be useful to have some names in cp1251 and others in cp1252, no matter what the primary language of the map is. Sure, there is the fallback of translitteration (ISO 9 and many national standards), but the matter of fact is that many places have both Finnish and Russian names, e.g., name:ru=Примо́рск (Primorsk) is name:sv=Björkö and name:fi=Koivisto. A little further east, only bigger places have names in multiple languages, e.g., name:en=Moscow, name:de=Moskau, name:sv=Moskva, name:fi=Moskova for name:ru=Москва (Moskva). Marko
On Thu, Apr 16, 2009 at 09:42:55PM +0300, Marko Mäkelä wrote:
On Thu, Apr 16, 2009 at 06:08:06PM +0100, Steve Ratcliffe wrote:
As codepage is used inside the file, everything should be done in terms of codepage so latin1 should be codepage=1251 etc.
Nitpicking: ISO 8859-1 is a subset of Microsoft/IBM Code Page 1252. But MySQL calls cp1252 "latin1" too. cp1251 is the Cyrillic alphabet.
Arrg I meant 1252 of course. Currently --latin1 does mean iso-8859-1 but it should change to cp1252.
Do you know if the code page can be set per label, per tile or only per *.img file? Would it be possible to have both cp1251 and cp1252 in the same map tile or the same gmapsupp.img file?
It is per .img file.
While we are at it, has any magic been implemented to translate name:language codes? e.g., name=Санкт-Петербург name:en=Saint Petersburg name:fi=Pietari name:de=Sankt Petersburg name:sv=Sankt Petersburg
There is the --name-tag-list option that allows you to say which language should be preferred. So if you wanted to see Finnish names when they exit then you might use --name-tag-list=name:fi,name:sv,name That would use the Finnish name if there was one, or else try the Swedish or generic name if not. But did you have something else in mind?
Does the Garmin format allow multiple names for the same place (selecting the name based on user language preferences)?
No. Or at least not in the format as known to us. ..Steve
On Thu, Apr 16, 2009 at 08:55:42PM +0100, Steve Ratcliffe wrote:
Do you know if the code page can be set per label, per tile or only per *.img file? Would it be possible to have both cp1251 and cp1252 in the same map tile or the same gmapsupp.img file?
It is per .img file.
Per tile.img or per gmapsupp.img file?
While we are at it, has any magic been implemented to translate name:language codes? e.g., name=Санкт-Петербург name:en=Saint Petersburg name:fi=Pietari name:de=Sankt Petersburg name:sv=Sankt Petersburg
There is the --name-tag-list option that allows you to say which language should be preferred. So if you wanted to see Finnish names when they exit then you might use --name-tag-list=name:fi,name:sv,name That would use the Finnish name if there was one, or else try the Swedish or generic name if not.
OK, for Latin-based Europeans, --name-tag-list=...,name:en,name could "get rid of" Cyrillic and Greek strings, provided that there exists a name:en with a Latin translitterated name.
But did you have something else in mind?
Yes, the following.
Does the Garmin format allow multiple names for the same place (selecting the name based on user language preferences)?
No. Or at least not in the format as known to us.
That would have been too nice. I was thinking that there could be an escape code (like the \x04 that was discussed some time ago) for switching character sets or selecting accents. Say, for a Greek or someone from a Cyrillic country who is living or travelling in Latin Europe and who is familiar with both alphabets, it would be nice to see all names in the local alphabet. OK, as a fallback, you can drop the umlauts and accents to map cp1252 (latin1) to ASCII. Because ASCII is a subset of cp1251 (Cyrillic), you'd get both Latin (without accents) and Cyrillic at the same time. For Greek, you could do some ugly mapping to Cyrillic. That could be an acceptable solution for Cyrillic users (Russian, Bulgarian, parts of ex-Yugoslavia). For me personally, this doesn't matter much, as I'm mostly interested in my home country. I just happen to be interested in character sets and would like to see this problem solved. Marko
On Thu, Apr 16, 2009 at 06:08:06PM +0100, Steve Ratcliffe wrote:
Probably, mkgmap should make some effort to automatically write a sensible code page -- how are the options latin1, charset and code-page meant to work together? Does one affect input, the other output?
Its mostly historical when I didn't fully understand what was required. The two things were selecting between the 6 bit format and the 8 bit format and then getting the correct character set for the 8 bit format.
Is ENCODING_FORMAT9 the 8-bit format? What is ENCODING_FORMAT10 and which devices do support it? I just tried generating a map with --charset=unicode, but the Garmin Edge 705 appears to display non-ASCII characters as if they were UTF-8 encoded strings misinterpreted as cp1252 (latin1). For instance, 'ä' looks like 'ä' except that the generic currency symbol ¤ is displayed as the substitution character �. Where would you implement the fixups for unsupported cp1252 characters? I noticed that the code relies on java.nio.charset.Charset for doing the translations. Is it table-driven, and if so, is it possible to tweak the translation tables? Else, is there an efficient Java library function for replacing all occurrences of a given character (e.g., replacing 0x91 and 0x92 with 0x27)? Marko
On Wed, May 06, 2009 at 11:34:21PM +0300, Marko Mäkelä wrote:
On Thu, Apr 16, 2009 at 06:08:06PM +0100, Steve Ratcliffe wrote:
Probably, mkgmap should make some effort to automatically write a sensible code page -- how are the options latin1, charset and code-page meant to work together? Does one affect input, the other output?
Its mostly historical when I didn't fully understand what was required. The two things were selecting between the 6 bit format and the 8 bit format and then getting the correct character set for the 8 bit format.
Is ENCODING_FORMAT9 the 8-bit format?
Yes it is.
What is ENCODING_FORMAT10 and which devices do support it? I just tried generating a map with --charset=unicode, but the Garmin Edge 705 appears to display non-ASCII characters as if they were UTF-8 encoded strings
Certainly on my Legend there is no difference between format 9 and 10 either but it depends on the firmware for the device as far as I know.
Where would you implement the fixups for unsupported cp1252 characters? I noticed that the code relies on java.nio.charset.Charset for doing the translations. Is it table-driven, and if so, is it possible to tweak the translation tables? Else, is there an efficient Java library function for replacing all occurrences of a given character (e.g., replacing 0x91 and 0x92 with 0x27)?
Well if we know what is required we can do anything, if need be a new Charset could be created if the Garmins don't follow an existing one exactly. ..Steve
participants (5)
-
maning sambale -
Marko Mäkelä -
nyem -
Robert Vollmert -
Steve Ratcliffe