[mkgmap-dev] Format6Encoder/Decoder

Tue Nov 30 15:15:07 GMT 2021

Hi Ticker,

with r4821 I can still reproduce search problems with --code-page=0 when road names start with symbols ("@Road" or "#Street") (in MapSource). I guess the shift character is the problem.
With your patch it is much more likely that the first 4 characters contain such a shift byte.
Or maybe the sort order for these is wrong?

Did not try to find a solution for this and I have no Garmin map that uses 6bit encoding. Possibly we just can skip writing mdr17 as we do with unicode.

A few things are really confusing reg. the --code-page and --charset option.
1) if you specify e.g. --code-page=cp1252 or --code-page=ms932 mkgmap will silently change that to cp0. See getCodePage() in CommandArgs.
2) the option --charset is deprecated but still evaluated. Something like --charset=cp1252 --code-page=1254 probably causes trouble.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Dienstag, 30. November 2021 14:21
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder

Hi Ticker,

seems you are partly right. I created a map with cp0 and --lower-case and the search for road names starting with "augs" doesn't return Augsburger Strasse on the device.
Without -lower-case this works as expected. I've reverted r4820 for now, but maybe the combination never works well. Needs more testing.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 30. November 2021 12:15
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder

Hi Gerd

Building a map with --code-page=0 --index --gmapsupp --gmapi
(exactly same behaviour without --code-page=0)

Then, using raw mode editor to look at various components.

The LBL section of tiles, gmapsupp.img and gmapi looks encoded - I
can't find any recognisable strings.

However, the gmapsupp contains the 4-char prefixes (as per Mdr17) with
standard ascii encoding, the gmapi 00OSMMAP.MDR contains full names of
everything, again as ascii (probably Mdr15) and .typ file is also
ascii.

I can't find any ascii in the overview map (except the expected subfile
names and copyright), but my test area might not have anything named at
this level.

It is possible that MDR does this intentionally; avoiding the
"compressed" format that Mdr15.java / MdrDisplay mentions. This
compressed format might simply be Format6

Ticker

On Tue, 2021-11-30 at 10:20 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I also don't like that we still use e.g.  Charset.forName("ascii")
> instead of StandardCharsets.US_ASCII, esp. because "ascii" is also
> used as name for our own resource files.
>
> In what situation do you see wrong encoding of Mdr15/Mdr17?
>
> Gerd

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev