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 <[email protected]> im Auftrag von Gerd
Petermann <[email protected]>
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 <[email protected]> im Auftrag von Ticker
Berkin <[email protected]>
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
[email protected]
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
