Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd This basemap sort looks like generic junk. It uses 1/1 for the ids, chars <= 0x1d get zero sortorder, chars >= 0x20 get their own value as sortorder (no attempt at upper/lower case or anything), 0x1e & 0x1f get the same as ' ' Ticker On Tue, 2022-01-04 at 10:31 +, Gerd Petermann wrote: > Hi Ticker, > > here it is. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 4. Januar 2022 11:20 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > Hi Gerd > > This is related to your most recent post in the 'augment' thread. > > Attached is patch to SrtDisplay that adds to the comments and chooses > a > better looking "expand" character. > > Can you apply and run this on your basemap and send me the full > output. > > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in MdrCheck?
Hi Ticker, here it is. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 4. Januar 2022 11:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in MdrCheck? Hi Gerd This is related to your most recent post in the 'augment' thread. Attached is patch to SrtDisplay that adds to the comments and chooses a better looking "expand" character. Can you apply and run this on your basemap and send me the full output. Ticker On Mon, 2021-12-13 at 09:17 +, Ticker Berkin wrote: > Hi Gerd > > Yes, this seemed to be the result of a bit of code where someone was > starting to look at showing expansions and then stopped. The > information in this list is shown more clearly while it is being read > in the SRT 4 Character table. > > Ticker > > On Mon, 2021-12-13 at 09:00 +, Gerd Petermann wrote: > > Hi Ticker, > > > > the unpatched SrtDisplay shows this table at the end, the patched > > version doesn't. Is that intended? > > 0008 prim=0,sec=0,tert=0 > > 0009 prim=0,sec=0,tert=0 > > > ___ > 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
Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd
This is related to your most recent post in the 'augment' thread.
Attached is patch to SrtDisplay that adds to the comments and chooses a
better looking "expand" character.
Can you apply and run this on your basemap and send me the full output.
Ticker
On Mon, 2021-12-13 at 09:17 +, Ticker Berkin wrote:
> Hi Gerd
>
> Yes, this seemed to be the result of a bit of code where someone was
> starting to look at showing expansions and then stopped. The
> information in this list is shown more clearly while it is being read
> in the SRT 4 Character table.
>
> Ticker
>
> On Mon, 2021-12-13 at 09:00 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > the unpatched SrtDisplay shows this table at the end, the patched
> > version doesn't. Is that intended?
> > 0008 prim=0,sec=0,tert=0
> > 0009 prim=0,sec=0,tert=0
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/test/display/SrtDisplay.java
===
--- src/test/display/SrtDisplay.java (revision 580)
+++ src/test/display/SrtDisplay.java (working copy)
@@ -57,6 +57,11 @@
private final Map offsetToBlock = new HashMap<>();
+ private String srtDescription;
+ private int codepage;
+ private int id1;
+ private int id2;
+
protected void print() {
readCommonHeader();
readFileHeader();
@@ -119,9 +124,9 @@
d.setTitle("Description");
- String s = d.zstringValue("Description: %s");
+ srtDescription = d.zstringValue("Description: %s");
- long remain = description.getLen() - s.length() - 1;
+ long remain = description.getLen() - srtDescription.length() - 1;
d.rawValue((int) remain);
d.print(outStream);
@@ -138,10 +143,10 @@
d.setSectStart(start);
reader.position(start);
int len = d.charValue("sub header len %d");
- d.charValue("id1 %d");
- d.charValue("id2 %d");
+ id1 = d.charValue("id1 %d");
+ id2 = d.charValue("id2 %d");
- int codepage = d.charValue("codepage %d");
+ codepage = d.charValue("codepage %d");
if (codepage == 65001)
isUnicode = true;
Charset charset = Sort.charsetFromCodepage(codepage);
@@ -206,38 +211,82 @@
d.setTitle("--- Summary of ordering ");
Formatter chars = new Formatter();
- Formatter comment = new Formatter();
+ //Formatter comment = new Formatter();
+
+ // reproduce header like mkgmap resource/sort/cp*.txt entries
+ chars.format("\n\n\n");
+ chars.format("# Compare this with resource/sort/cp%d.txt.\n\n", codepage);
+ chars.format("codepage %d\n", codepage);
+ chars.format("id1 %d\n", id1);
+ chars.format("id2 %d\n", id2);
+ chars.format("description \"%s\"\n\n", srtDescription);
+ chars.format("characters\n\n");
+
CharPosition last = new CharPosition(0);
- last.first = -1;
+ //last.first = -1;
+ last.first = 0; // start first line with zero/ignore sortOrder
for (CharPosition cp : charmap) {
- if (cp.expands)
+ if (cp.expands > 0)
continue;
+ int unicodeChar = toUnicode(cp.val);
+ if (unicodeChar < 0) // no character defined for this position
+continue;
if (cp.first != last.first) {
//chars.format("# %s\n[%d] < ", comment, cp.first);
-chars.format("\n< ");
-comment = new Formatter();
+chars.format("\n < ");
+//comment = new Formatter();
} else if (cp.second != last.second) {
chars.format(" ; ");
-comment.format(" ; ");
+//comment.format(" ; ");
} else if (cp.third != last.third) {
chars.format(",");
-comment.format(",");
+//comment.format(",");
} else {
chars.format("=");
-comment.format("=");
+//comment.format("=");
}
last = cp;
- chars.format("%s", fmtChar(toUnicode(cp.val)));
- comment.format("U+%04x", cp.val);
+ chars.format("%s", fmtChar(unicodeChar));
+ //comment.format("U+%04x", cp.val);
}
chars.format("\n");
for (CharPosition cp : charmap) {
- if (cp.expands)
-continue;
- chars.format("%4s %s\n", fmtChar(toUnicode(cp.val)), cp);
+ if (cp.expands > 0) {
+chars.format("expand %s to ", fmtChar(toUnicode(cp.val)));
+for (int i = 0; i <= cp.expands; ++i) {
+ CharPosition ch = expansions.get(cp.first + i - 1);
+ // need to search for best char with this first/primary. Doesn't actually matter
+ // apart from the cosmetics of the sort/cp*.txt expand list because the secondary
+ // and tertiary binary sortOrders are chosen to avoid matching existing real chars.
+ // see mkgmap/srt/SrtTextReader.java for more info
+ if (ch.second > 7)
+ ch.second -= 7;
+ ch.third = ch.third >= 5 ? 2 : 1;
+ int charValue = -1;
+ for (CharPosition scanCp : charmap) {
+ if (scanCp.expands > 0)
+ continue;
+ if (scanCp.first == ch.first) {
+ if (scanCp.second == ch.second &&
+scanCp.third == ch.third) {
+charValue = scanCp.val;
+break;
+ }
Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd Yes, this seemed to be the result of a bit of code where someone was starting to look at showing expansions and then stopped. The information in this list is shown more clearly while it is being read in the SRT 4 Character table. Ticker On Mon, 2021-12-13 at 09:00 +, Gerd Petermann wrote: > Hi Ticker, > > the unpatched SrtDisplay shows this table at the end, the patched > version doesn't. Is that intended? > 0008 prim=0,sec=0,tert=0 > 0009 prim=0,sec=0,tert=0 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in MdrCheck?
1,tert=2 l prim=170,sec=1,tert=1 L prim=170,sec=1,tert=2 m prim=172,sec=1,tert=1 M prim=172,sec=1,tert=2 n prim=174,sec=1,tert=1 N prim=174,sec=1,tert=2 Ñ prim=174,sec=2,tert=1 ñ prim=174,sec=2,tert=1 o prim=177,sec=1,tert=1 O prim=177,sec=1,tert=2 º prim=177,sec=1,tert=3 ó prim=177,sec=2,tert=1 Ó prim=177,sec=2,tert=2 ò prim=177,sec=3,tert=1 Ò prim=177,sec=3,tert=2 ô prim=177,sec=4,tert=1 Ô prim=177,sec=4,tert=2 ö prim=177,sec=5,tert=1 Ö prim=177,sec=5,tert=2 õ prim=177,sec=6,tert=1 Õ prim=177,sec=6,tert=2 ø prim=177,sec=7,tert=1 Ø prim=177,sec=7,tert=2 p prim=182,sec=1,tert=1 P prim=182,sec=1,tert=2 q prim=184,sec=1,tert=1 Q prim=184,sec=1,tert=2 r prim=186,sec=1,tert=1 R prim=186,sec=1,tert=2 s prim=189,sec=1,tert=1 S prim=189,sec=1,tert=2 š prim=189,sec=4,tert=1 Š prim=189,sec=4,tert=2 ş prim=189,sec=6,tert=1 Ş prim=189,sec=6,tert=2 t prim=193,sec=1,tert=1 T prim=193,sec=1,tert=2 u prim=196,sec=1,tert=1 U prim=196,sec=1,tert=2 ú prim=196,sec=2,tert=1 Ú prim=196,sec=2,tert=2 ù prim=196,sec=3,tert=1 Ù prim=196,sec=3,tert=2 û prim=196,sec=4,tert=1 Û prim=196,sec=4,tert=2 ü prim=196,sec=5,tert=1 Ü prim=196,sec=5,tert=2 v prim=199,sec=1,tert=1 V prim=199,sec=1,tert=2 w prim=201,sec=1,tert=1 W prim=201,sec=1,tert=2 x prim=202,sec=1,tert=1 X prim=202,sec=1,tert=2 y prim=205,sec=1,tert=1 Y prim=205,sec=1,tert=2 ÿ prim=205,sec=2,tert=1 Ÿ prim=205,sec=2,tert=2 z prim=207,sec=1,tert=1 Z prim=207,sec=1,tert=2 µ prim=210,sec=1,tert=1 Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Sonntag, 12. Dezember 2021 14:01 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in MdrCheck? Hi Gerd I've had a go at display SrdDisplay so it reproduces output close to the mkgmap resource/sort/cp*.txt files Patch attached I've also attached the output from the Turkish 0848.SRT you sent and there are quite a few differences from ours. We should consider what to do with the version numbering (id2 I presume). There is something in the expansion flags that appears to control which secondary/tertiary variant should be selected and I haven't bothered with this. Ticker On Fri, 2021-12-10 at 13:37 +, Gerd Petermann wrote: > Hi Ticker, > > attached is the extracted *.srt. > The original link to the turkey download posted here no longer works: > https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026715.html > > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 10. Dezember 2021 10:37 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > Hi Gerd > > Working on the basis of guessing and resources/sort/README, we > shouldn't use the same id2 if our sort is different to one from > Garmin > (or elsewhere). A device will have a base-map that defines the sort > it > needs, represented by id1/id2. Addition maps shouldn't use the same > pair to represent a different sort. Maybe we should change id2 for > all > our maps to be some arbitrary higher number, or certainly do this > when > a conflict is spotted. > > Looking at the SrtDisplay "Summary of ordering" output, it should be > possible to hack the code a bit or edit the output to get back to > what > our sort tables look like. Assuming as the ? problem can be fixed, > the > significant question is what is the meaning of the lowest sortOrder. > In > our tables, everything before the first "<" gets zero and doesn't > contribute to the ordering, along with anything not defined. > SrtDisplay > puts everything after the first "<". > > Can you sent me the Turkish .SRT subfile and I'll have a look. > > Ticker > > > On Fri, 2021-12-10 at 08:15 +, Gerd Petermann wrote: > > Hi Ticker, > > > > Both have the same ids: > > 0044 | 02 | 0e 00 | id1 14 > > 0046 | 04 | 01 00 | id2 1 > > 0048 | 06 | e6 04 | codepage 1254 > > > > reg. SrtDisplay: > > Our file looks very different compared to the "Summary of ordering" > > report. I don't understand most of the details, and for sure I > > don't > > know which one is better. > > I think the summary cannot be used as input for mkgmap because it > > contains several '?' where characters coulnd't be converted to > > unicode. > > (same problem when I create a map with --codepage=1252 and use > > SrtDisplay on that. > > > > Gerd > > > >
Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd I've had a go at display SrdDisplay so it reproduces output close to the mkgmap resource/sort/cp*.txt files Patch attached I've also attached the output from the Turkish 0848.SRT you sent and there are quite a few differences from ours. We should consider what to do with the version numbering (id2 I presume). There is something in the expansion flags that appears to control which secondary/tertiary variant should be selected and I haven't bothered with this. Ticker On Fri, 2021-12-10 at 13:37 +, Gerd Petermann wrote: > Hi Ticker, > > attached is the extracted *.srt. > The original link to the turkey download posted here no longer works: > https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026715.html > > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 10. Dezember 2021 10:37 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > Hi Gerd > > Working on the basis of guessing and resources/sort/README, we > shouldn't use the same id2 if our sort is different to one from > Garmin > (or elsewhere). A device will have a base-map that defines the sort > it > needs, represented by id1/id2. Addition maps shouldn't use the same > pair to represent a different sort. Maybe we should change id2 for > all > our maps to be some arbitrary higher number, or certainly do this > when > a conflict is spotted. > > Looking at the SrtDisplay "Summary of ordering" output, it should be > possible to hack the code a bit or edit the output to get back to > what > our sort tables look like. Assuming as the ? problem can be fixed, > the > significant question is what is the meaning of the lowest sortOrder. > In > our tables, everything before the first "<" gets zero and doesn't > contribute to the ordering, along with anything not defined. > SrtDisplay > puts everything after the first "<". > > Can you sent me the Turkish .SRT subfile and I'll have a look. > > Ticker > > > On Fri, 2021-12-10 at 08:15 +, Gerd Petermann wrote: > > Hi Ticker, > > > > Both have the same ids: > > 0044 | 02 | 0e 00 | id1 14 > > 0046 | 04 | 01 00 | id2 1 > > 0048 | 06 | e6 04 | codepage 1254 > > > > reg. SrtDisplay: > > Our file looks very different compared to the "Summary of ordering" > > report. I don't understand most of the details, and for sure I > > don't > > know which one is better. > > I think the summary cannot be used as input for mkgmap because it > > contains several '?' where characters coulnd't be converted to > > unicode. > > (same problem when I create a map with --codepage=1252 and use > > SrtDisplay on that. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Donnerstag, 9. Dezember 2021 12:51 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > > > Hi Gerd > > > > The alternative would be to use test.display.SrtDisplay to generate > > a > > different version of our resources/sort/cp1254.txt that matches > > theirs, or maybe have versions findable by id1/id2 that match. > > > > Ticker > > > > > > On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote: > > > Hi devs, > > > > > > I think there is a bug in MdrCheck, probably also in other Check > > > programs. The program doesn't read the SRT file content from the > > > map, > > > instead it uses the corresponding data from mkgmap. > > > If the builtin sort order in mkgmap doesn't match the SRT file > > > content the program will report errors about wrong order or > > > missing > > > repeat flags etc. > > > I guess this explains why MdrCheck complains about the Garmin > > > demo > > > map for Turkey? > > > > > > I once started to implement a SrtFileReader but I don't know if > > > that > > > can be used instead. > > > > > > Gerd > > > > > > > > > ___ > > > mkgmap-dev mailing list > > > mkgmap-dev@lists.mkgmap.org.uk > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > ___ > > mkgmap-dev mailing list >
Re: [mkgmap-dev] Error in MdrCheck?
Hi Ticker, attached is the extracted *.srt. The original link to the turkey download posted here no longer works: https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q2/026715.html Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Freitag, 10. Dezember 2021 10:37 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in MdrCheck? Hi Gerd Working on the basis of guessing and resources/sort/README, we shouldn't use the same id2 if our sort is different to one from Garmin (or elsewhere). A device will have a base-map that defines the sort it needs, represented by id1/id2. Addition maps shouldn't use the same pair to represent a different sort. Maybe we should change id2 for all our maps to be some arbitrary higher number, or certainly do this when a conflict is spotted. Looking at the SrtDisplay "Summary of ordering" output, it should be possible to hack the code a bit or edit the output to get back to what our sort tables look like. Assuming as the ? problem can be fixed, the significant question is what is the meaning of the lowest sortOrder. In our tables, everything before the first "<" gets zero and doesn't contribute to the ordering, along with anything not defined. SrtDisplay puts everything after the first "<". Can you sent me the Turkish .SRT subfile and I'll have a look. Ticker On Fri, 2021-12-10 at 08:15 +, Gerd Petermann wrote: > Hi Ticker, > > Both have the same ids: > 0044 | 02 | 0e 00 | id1 14 > 0046 | 04 | 01 00 | id2 1 > 0048 | 06 | e6 04 | codepage 1254 > > reg. SrtDisplay: > Our file looks very different compared to the "Summary of ordering" > report. I don't understand most of the details, and for sure I don't > know which one is better. > I think the summary cannot be used as input for mkgmap because it > contains several '?' where characters coulnd't be converted to > unicode. > (same problem when I create a map with --codepage=1252 and use > SrtDisplay on that. > > Gerd > > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 9. Dezember 2021 12:51 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > Hi Gerd > > The alternative would be to use test.display.SrtDisplay to generate a > different version of our resources/sort/cp1254.txt that matches > theirs, or maybe have versions findable by id1/id2 that match. > > Ticker > > > On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote: > > Hi devs, > > > > I think there is a bug in MdrCheck, probably also in other Check > > programs. The program doesn't read the SRT file content from the > > map, > > instead it uses the corresponding data from mkgmap. > > If the builtin sort order in mkgmap doesn't match the SRT file > > content the program will report errors about wrong order or missing > > repeat flags etc. > > I guess this explains why MdrCheck complains about the Garmin demo > > map for Turkey? > > > > I once started to implement a SrtFileReader but I don't know if > > that > > can be used instead. > > > > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 0848.SRT Description: 0848.SRT ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd Working on the basis of guessing and resources/sort/README, we shouldn't use the same id2 if our sort is different to one from Garmin (or elsewhere). A device will have a base-map that defines the sort it needs, represented by id1/id2. Addition maps shouldn't use the same pair to represent a different sort. Maybe we should change id2 for all our maps to be some arbitrary higher number, or certainly do this when a conflict is spotted. Looking at the SrtDisplay "Summary of ordering" output, it should be possible to hack the code a bit or edit the output to get back to what our sort tables look like. Assuming as the ? problem can be fixed, the significant question is what is the meaning of the lowest sortOrder. In our tables, everything before the first "<" gets zero and doesn't contribute to the ordering, along with anything not defined. SrtDisplay puts everything after the first "<". Can you sent me the Turkish .SRT subfile and I'll have a look. Ticker On Fri, 2021-12-10 at 08:15 +, Gerd Petermann wrote: > Hi Ticker, > > Both have the same ids: > 0044 | 02 | 0e 00 | id1 14 > 0046 | 04 | 01 00 | id2 1 > 0048 | 06 | e6 04 | codepage 1254 > > reg. SrtDisplay: > Our file looks very different compared to the "Summary of ordering" > report. I don't understand most of the details, and for sure I don't > know which one is better. > I think the summary cannot be used as input for mkgmap because it > contains several '?' where characters coulnd't be converted to > unicode. > (same problem when I create a map with --codepage=1252 and use > SrtDisplay on that. > > Gerd > > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 9. Dezember 2021 12:51 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Error in MdrCheck? > > Hi Gerd > > The alternative would be to use test.display.SrtDisplay to generate a > different version of our resources/sort/cp1254.txt that matches > theirs, or maybe have versions findable by id1/id2 that match. > > Ticker > > > On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote: > > Hi devs, > > > > I think there is a bug in MdrCheck, probably also in other Check > > programs. The program doesn't read the SRT file content from the > > map, > > instead it uses the corresponding data from mkgmap. > > If the builtin sort order in mkgmap doesn't match the SRT file > > content the program will report errors about wrong order or missing > > repeat flags etc. > > I guess this explains why MdrCheck complains about the Garmin demo > > map for Turkey? > > > > I once started to implement a SrtFileReader but I don't know if > > that > > can be used instead. > > > > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in MdrCheck?
Hi Ticker, Both have the same ids: 0044 | 02 | 0e 00 | id1 14 0046 | 04 | 01 00 | id2 1 0048 | 06 | e6 04 | codepage 1254 reg. SrtDisplay: Our file looks very different compared to the "Summary of ordering" report. I don't understand most of the details, and for sure I don't know which one is better. I think the summary cannot be used as input for mkgmap because it contains several '?' where characters coulnd't be converted to unicode. (same problem when I create a map with --codepage=1252 and use SrtDisplay on that. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 9. Dezember 2021 12:51 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Error in MdrCheck? Hi Gerd The alternative would be to use test.display.SrtDisplay to generate a different version of our resources/sort/cp1254.txt that matches theirs, or maybe have versions findable by id1/id2 that match. Ticker On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote: > Hi devs, > > I think there is a bug in MdrCheck, probably also in other Check > programs. The program doesn't read the SRT file content from the map, > instead it uses the corresponding data from mkgmap. > If the builtin sort order in mkgmap doesn't match the SRT file > content the program will report errors about wrong order or missing > repeat flags etc. > I guess this explains why MdrCheck complains about the Garmin demo > map for Turkey? > > I once started to implement a SrtFileReader but I don't know if that > can be used instead. > > 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
Re: [mkgmap-dev] Error in MdrCheck?
Hi Gerd The alternative would be to use test.display.SrtDisplay to generate a different version of our resources/sort/cp1254.txt that matches theirs, or maybe have versions findable by id1/id2 that match. Ticker On Thu, 2021-12-09 at 09:09 +, Gerd Petermann wrote: > Hi devs, > > I think there is a bug in MdrCheck, probably also in other Check > programs. The program doesn't read the SRT file content from the map, > instead it uses the corresponding data from mkgmap. > If the builtin sort order in mkgmap doesn't match the SRT file > content the program will report errors about wrong order or missing > repeat flags etc. > I guess this explains why MdrCheck complains about the Garmin demo > map for Turkey? > > I once started to implement a SrtFileReader but I don't know if that > can be used instead. > > 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
