[mkgmap-dev] test files to figure out Garmin encodings?

Mon May 18 13:16:58 BST 2009

On Mon, May 18, 2009 at 08:03:47AM -0400, Greg Troxel wrote:
> 
> It seems there is a table of a lot of Garmin codepoints, and I wonder if
> havinga test file that has a POI with each possible codepoint, and
> similarly for roads, would help determine the behavior/meanings for the
> rest of them.  Perhaps things are 100% figured out, but it feels like
> not.

I made an experiment on my Edge 705 a couple of weeks ago, generating
some non-ASCII labels in cp1252, and many code points were displayed as
a substitution character.  I think that it would be useful to test each
Garmin code page on as many devices as possible to find out which code
points are really supported.

> The basic idea is to take a lat/lon to start (to make the map 'near'
> someone working on this) and then to have a grid of points spaced 50m,
> roughly square, that has each possible codepoint in some range known to
> exist.  Then a second grid with a N-S road and then every 50m E-W roads
> of every type on the left and on the right some normal road with every
> access combination.  They could be be labeled with names that have the
> codepoint, and eventually the meaning, drawing from the database of
> meaning/codepoint mappings.
> 
> Once this was written other people could more easily experiment to add
> knowledge.

It seems to me that the easiest way to achieve this could be to
write a script that generates an *.osm file and translate the file
with mkgmap.  That would also enable some regression testing later,
if we archive the generated output.

For this to succeed, there should be a way to bypass the character set
translations in mkgmap and to specify the code page.  (For example,
mkgmap --latin1 would translate UTF-8 "ß" into "ss", even though the
correct translation is 0xdf in cp1252.)

	Marko