Hi Gerd I was looking at encoders and noticed obvious mistake in Format6Decoder relating to lower-case, plus parts that can be simplified to be general and consistent with Format6Encoder. Format6Encoder can handle a bunch of other characters (the remains of the 'ascii' printables) + lower-case - I've implemented these. Patch attached Ticker
Hi Ticker, result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 18:49 An: mkgmap development Betreff: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd I was looking at encoders and noticed obvious mistake in Format6Decoder relating to lower-case, plus parts that can be simplified to be general and consistent with Format6Encoder. Format6Encoder can handle a bunch of other characters (the remains of the 'ascii' printables) + lower-case - I've implemented these. Patch attached Ticker
Hi Gerd Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't. Ticker On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
Gerd
Hi Ticker, with the 2nd version of the patch the --lower-case option is ignored. This was probably not intended but I think it really makes no sense to implement this. The img file is much bigger and German names like Hauptstraße is still translated to Hauptstrasse, "Am Düker" still gets "Am Duker", so the displayed names are typically the same, at least with Garmin software. Attached is my proposed fix if you still think --lower-case should be supported with codepage 0 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't. Ticker On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
Gerd
Hi Gerd Yes, my mistake that --lower-case got ignored; I had forgotten that LBLFile didn't call setUpperCase(false). After this, I decided that it was better to make the encoder's letter- case default the same as the other encoders and be explicit in CodeFunctionsTest as to what was required for the test to work, so this change is in the patch. I've also put in asserts to check that nothing has re-represented the test strings with/without the COMBINING DIAERESIS. It doesn't make much sense to use --lower-case with this encoder, but if that's what the user asks for (maybe there are other reasons), I think it should do it. FORMAT6 handles all the printable characters in the ASCII / 7-bit range. From my tests on UK devices/software, where there are spaces is the SYMBOL and LOWERCASE tables, the encoded value also shows as a space. It is possible they might be used for country specific chars, but, even if they do, mkgmap shouldn't use them. So what you see with accents etc is what I'd expect. Ticker On Sun, 2021-11-28 at 15:57 +0000, Gerd Petermann wrote:
Hi Ticker,
with the 2nd version of the patch the --lower-case option is ignored. This was probably not intended but I think it really makes no sense to implement this. The img file is much bigger and German names like Hauptstraße is still translated to Hauptstrasse, "Am Düker" still gets "Am Duker", so the displayed names are typically the same, at least with Garmin software.
Attached is my proposed fix if you still think --lower-case should be supported with codepage 0
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, maybe show a warning message (once) when --lower-case is used without --code-page or with code-page=0? I've modified the unit test: - actual/expected where reversed - better(?) explanation for length differences Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 29. November 2021 10:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd Yes, my mistake that --lower-case got ignored; I had forgotten that LBLFile didn't call setUpperCase(false). After this, I decided that it was better to make the encoder's letter- case default the same as the other encoders and be explicit in CodeFunctionsTest as to what was required for the test to work, so this change is in the patch. I've also put in asserts to check that nothing has re-represented the test strings with/without the COMBINING DIAERESIS. It doesn't make much sense to use --lower-case with this encoder, but if that's what the user asks for (maybe there are other reasons), I think it should do it. FORMAT6 handles all the printable characters in the ASCII / 7-bit range. From my tests on UK devices/software, where there are spaces is the SYMBOL and LOWERCASE tables, the encoded value also shows as a space. It is possible they might be used for country specific chars, but, even if they do, mkgmap shouldn't use them. So what you see with accents etc is what I'd expect. Ticker On Sun, 2021-11-28 at 15:57 +0000, Gerd Petermann wrote:
Hi Ticker,
with the 2nd version of the patch the --lower-case option is ignored. This was probably not intended but I think it really makes no sense to implement this. The img file is much bigger and German names like Hauptstraße is still translated to Hauptstrasse, "Am Düker" still gets "Am Duker", so the displayed names are typically the same, at least with Garmin software.
Attached is my proposed fix if you still think --lower-case should be supported with codepage 0
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I don't like the idea of these static warnings and I doubt if this combination is likely to be given. However I have added a note to options.txt and corrected / expanded the text in this area. I've incorporated you changes to the unit test. Not related to this patch, but to code-page naming generally, is that it is a mess. Sometimes "cp0" means 7-bit ASCII in 8 bits and "ascii" means Format6. Combiners/Mdr seems to have been confused by this and, when the LBL section is Format6, Mdr15 and Mdr17 (I think) contain 8- bit ASCII strings. Ticker On Mon, 2021-11-29 at 09:47 +0000, Gerd Petermann wrote:
Hi Ticker,
maybe show a warning message (once) when --lower-case is used without --code-page or with code-page=0?
I've modified the unit test: - actual/expected where reversed - better(?) explanation for length differences
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 29. November 2021 10:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Yes, my mistake that --lower-case got ignored; I had forgotten that LBLFile didn't call setUpperCase(false).
After this, I decided that it was better to make the encoder's letter- case default the same as the other encoders and be explicit in CodeFunctionsTest as to what was required for the test to work, so this change is in the patch. I've also put in asserts to check that nothing has re-represented the test strings with/without the COMBINING DIAERESIS.
It doesn't make much sense to use --lower-case with this encoder, but if that's what the user asks for (maybe there are other reasons), I think it should do it.
FORMAT6 handles all the printable characters in the ASCII / 7-bit range. From my tests on UK devices/software, where there are spaces is the SYMBOL and LOWERCASE tables, the encoded value also shows as a space. It is possible they might be used for country specific chars, but, even if they do, mkgmap shouldn't use them. So what you see with accents etc is what I'd expect.
Ticker
On Sun, 2021-11-28 at 15:57 +0000, Gerd Petermann wrote:
Hi Ticker,
with the 2nd version of the patch the --lower-case option is ignored. This was probably not intended but I think it really makes no sense to implement this. The img file is much bigger and German names like Hauptstraße is still translated to Hauptstrasse, "Am Düker" still gets "Am Duker", so the displayed names are typically the same, at least with Garmin software.
Attached is my proposed fix if you still think --lower-case should be supported with codepage 0
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
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
Hi Gerd Please ignore previous patch - I hadn't saved deletion of other changes Attached is good version Sorry about that Ticker
Hi Ticker, Committed with r4820. I already wondered about the doc for --code-page before. My concern is about users who are not able/willing to read the doc or the change log and simply don't expect that someting changes to the worse for their existing scripts. On the other hand they probably don't even notice the size change... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 29. November 2021 18:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd Please ignore previous patch - I hadn't saved deletion of other changes Attached is good version Sorry about that Ticker
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 ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 29. November 2021 18:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd I don't like the idea of these static warnings and I doubt if this combination is likely to be given. However I have added a note to options.txt and corrected / expanded the text in this area. I've incorporated you changes to the unit test. Not related to this patch, but to code-page naming generally, is that it is a mess. Sometimes "cp0" means 7-bit ASCII in 8 bits and "ascii" means Format6. Combiners/Mdr seems to have been confused by this and, when the LBL section is Format6, Mdr15 and Mdr17 (I think) contain 8- bit ASCII strings. Ticker On Mon, 2021-11-29 at 09:47 +0000, Gerd Petermann wrote:
Hi Ticker,
maybe show a warning message (once) when --lower-case is used without --code-page or with code-page=0?
I've modified the unit test: - actual/expected where reversed - better(?) explanation for length differences
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 29. November 2021 10:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Yes, my mistake that --lower-case got ignored; I had forgotten that LBLFile didn't call setUpperCase(false).
After this, I decided that it was better to make the encoder's letter- case default the same as the other encoders and be explicit in CodeFunctionsTest as to what was required for the test to work, so this change is in the patch. I've also put in asserts to check that nothing has re-represented the test strings with/without the COMBINING DIAERESIS.
It doesn't make much sense to use --lower-case with this encoder, but if that's what the user asks for (maybe there are other reasons), I think it should do it.
FORMAT6 handles all the printable characters in the ASCII / 7-bit range. From my tests on UK devices/software, where there are spaces is the SYMBOL and LOWERCASE tables, the encoded value also shows as a space. It is possible they might be used for country specific chars, but, even if they do, mkgmap shouldn't use them. So what you see with accents etc is what I'd expect.
Ticker
On Sun, 2021-11-28 at 15:57 +0000, Gerd Petermann wrote:
Hi Ticker,
with the 2nd version of the patch the --lower-case option is ignored. This was probably not intended but I think it really makes no sense to implement this. The img file is much bigger and German names like Hauptstraße is still translated to Hauptstrasse, "Am Düker" still gets "Am Duker", so the displayed names are typically the same, at least with Garmin software.
Attached is my proposed fix if you still think --lower-case should be supported with codepage 0
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 26. November 2021 22:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder
Hi Gerd
Patch attached that defaults Format6Encoder transliterator to UPPER. mkgmap unconditionally calls to set required mode but test environment doesn't.
Ticker
On Fri, 2021-11-26 at 18:40 +0000, Gerd Petermann wrote:
Hi Ticker,
result looks ok, but unit test CodeFunctionsTest fails. Maybe it was intended that codepage 0 ignores the --lower-case option?
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
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
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
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
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
Hi Gerd I was wondering if you have and can send me the SRT subfile from the TOPO map you are looking at for the compression. In the Turkish map the bits that seemed to be for selecting the correct variation of each expansion character made little sense. Thanks Ticker
Hi Ticker, here it it. Don't worry too much about the turkish map. I think it is full of errors, at least that was my impression when I played with it on my Oregon. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 15. Dezember 2021 11:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Format6Encoder/Decoder Hi Gerd I was wondering if you have and can send me the SRT subfile from the TOPO map you are looking at for the compression. In the Turkish map the bits that seemed to be for selecting the correct variation of each expansion character made little sense. Thanks Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Gerd Petermann -
Ticker Berkin