Hi Gerd I'll investigate index problems and Format6 a bit next week to see what MapInstall does and if there is a correct way to represent the strings that Mdr places, or to say what encoding they are in. Fixing, extending and simplifying the Format6Decoder is worthwhile, along with the CodeFunctionsTest changes, so I've made another patch that rewords the OPTIONS and stops the Format6Encoder doing lower-case, but leaves the mechanisms there. It will encode the extra chars "`{|}". Ticker On Tue, 2021-11-30 at 15:15 +0000, Gerd Petermann wrote:
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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev