Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.
Hi Ticker,
yes, with your theory I found errors in my code. Here's the corrected version
// depth 3, prefix 0x07
addHuffmanNode("111", 'A');
// depth 4, prefix 0x09
addHuffmanNode("0111", '\0'); // 0x00
addHuffmanNode("1000", ' '); //0x20
addHuffmanNode("1001", 'E');
addHuffmanNode("1010", 'N');
addHuffmanNode("1011", 'O');
addHuffmanNode("1100", 'I');
addHuffmanNode("1101", 'R');
// depth 5, prefix 0x0b
addHuffmanNode("00101", 'C');
addHuffmanNode("00110", 'S');
addHuffmanNode("00111", 'D');
addHuffmanNode("01000", 'T');
addHuffmanNode("01001", 'M');
addHuffmanNode("01010", 'V');
addHuffmanNode("01011", 'J');
addHuffmanNode("01100", 'K');
addHuffmanNode("01101", 'L');
// depth 6
addHuffmanNode("000101", 'G');
addHuffmanNode("000110", 'Z');
addHuffmanNode("000111", 'U');
addHuffmanNode("001000", 'P');
addHuffmanNode("001001", 'B');
// depth 7
addHuffmanNode("110", 'H');
addHuffmanNode("111", '1');
addHuffmanNode("0001000", '2');
addHuffmanNode("0001001", '.');
// depth 8
addHuffmanNode("0011", '5');
addHuffmanNode("0100", '6');
addHuffmanNode("0101", '-');
addHuffmanNode("0110", '7');
addHuffmanNode("0111", '3');
addHuffmanNode("1000", '8');
addHuffmanNode("1001", '9');
addHuffmanNode("1010", '0');
addHuffmanNode("1011", '4');
// depth 9
addHuffmanNode("00010", 'F');
addHuffmanNode("00011",',');
addHuffmanNode("00100", '(');
addHuffmanNode("00101", ')');
// depth 10
addHuffmanNode("11", '*');
// depth 11
addHuffmanNode("011", 'Y');
addHuffmanNode("100", '"');
addHuffmanNode("101", (char) 0x06); //
non-print4
// depth 12
addHuffmanNode("0011", 'W');
addHuffmanNode("0100", 'X');
addHuffmanNode("0101", (char) 0x05);
//non-print some shield code
// depth 13
addHuffmanNode("00100", '&');
addHuffmanNode("00101", (char) 0x1f);
//non-print2
// depth 14
addHuffmanNode("11", 'Q');
addHuffmanNode("000100", 'Š');
addHuffmanNode("000101", '\''); //
mdr16 says 0x8a
addHuffmanNode("000110", 'Ë');
addHuffmanNode("000111", '/');
// depth 15
addHuffmanNode("100", 'Æ');
addHuffmanNode("101", 'È');
// depth 16
addHuffmanNode("0101", (char)
0x04); // non-print3
addHuffmanNode("0110", '!');
addHuffmanNode("0111", (char)
0x9e); //Ž
// depth 17
addHuffmanNode("00110",'+');
addHuffmanNode("00111", '–'); //
different to minus mdr16: 0x96
addHuffmanNode("01000", 'Á'); //Á
Re: [mkgmap-dev] Problem using profiles with OSM based maps
Hi Carlos, I really don't know. maybe this thread helps? https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/025927.html Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Montag, 20. Dezember 2021 10:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Problem using profiles with OSM based maps Thanks Gerd for the hint, I didn't know about --custom option. But according to mkgmap help, it is for marine maps, maybe using it as default could break more than fix? El 20/12/21 a las 10:18, Gerd Petermann escribió: > Hi Carlos, > > I don't understand all of this but the mentioned change from 17 (0x11) to 23 > (0x17) is > done when the --custom option is given. > > Gerd > > > > Von: mkgmap-dev im Auftrag von > Carlos Dávila > Gesendet: Montag, 20. Dezember 2021 09:55 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Problem using profiles with OSM based maps > > An user of my maps has reported the following problem when using OSM > based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable > different sets of maps associated to each profile. When he has several > OSM based maps in the SD card (not only mines, also from other sources, > witch I guess are also built with mkgmap), switching between profiles > automatically enables all OSM maps, even if they were previously > disabled in a given profile. It seems to be related to some parameters > in the TRE subfile, as reported in this thread: > https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571&sid=6e0edd3239fb36f34c4b5d8df4f9f036 > > > ___ > 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] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.
Hi Ticker,
OK, I see. It seems to work out for most of the delta values.
Deltas are 6,9,6,4,3,2,5,2,3,3,1,4,9,4
I'll try to find out if I can modify the tree so that it matches all numbers.
Probably sometimes I found too short codes.
Good finding!
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Montag, 20. Dezember 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn]Commit r572: MDR16 is
somekindof codebook.
Hi Gerd
Are you OK with the idea of the letters at any level being to the
right. Then the letters at this level take decreasing values. When
exhausted, the next lower slot will be the start of the next level, so
subtract 1 to find it and append '1' to the bit-string to get the
starting position for the next level.
in the test map there is, say:
02cf | 19 | 11 | struct level: 17
02d0 | 1a | 15 50 00 00 | struct for 17
02d4 | 1e | 10 | struct level: 16
02d5 | 1f | 19 80 00 00 | struct for 16
02d9 | 23 | 0f | struct level: 15
02da | 24 | 1c c0 00 00 | struct for 15
The differences between the first byte after the level indicator ie 15,
19 & 1c) give 4 and 3, which are the number of letters at level 17 and
level 16
Ticker
On Mon, 2021-12-20 at 09:18 +, Gerd Petermann wrote:
> Hi Ticker,
> please explain. What counters do you see? What do they mean?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Montag, 20. Dezember 2021 09:49
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16
> is somekindof codebook.
>
> Hi Gerd
>
> The tree is arranged so that letters at any level always have the
> highest values, ie come in from the right, and there are no gaps so no
> need for bit-flags. All it needs is the count of letters at each level
> to determine the tree.
>
> For levels 7 to 18 this is consistent and the count can be determined
> from the first byte in the "struct for {level}".
>
> Levels 19 and 20 are slightly out, but I think you found some
> strangeness here, including something indicate using Mdr3x data.
>
> Level 6 count might be mixed into the following
>
> I haven't been able to work out levels 1-5 yet, but somewhere would
> hope to find counts 0,0,1,7,9 maybe cumulative, maybe backwards, maybe
> without the first 2 values, maybe starting from the cumulative level 6
> value.
>
> Ticker
>
>
> On Sun, 2021-12-19 at 21:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > my thought for the struct bytes was that the 1-bits might represent
> > the position of leafs, but
> > the bit counts don't match.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Sonntag, 19. Dezember 2021 10:12
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572:
> > MDR16 is somekindof codebook.
> >
> > Hi Gerd
> >
> > It looks like the order of the letter patterns approaches canonical
> > Huffman (but not quite as far as I can see). With this, only the
> > number
> > of codes of each length is required to form the tree.
> >
> > The "struct for {level}" looks like 2 numbers. Both increasing as
> > levels go from 20 to 6. The first, a single byte from #00 to #3d -
> > this
> > could be give the accumulated lengths at each level (but I didn't get
> > it to match). The second, variable length, from #06 to #180c00
> > and
> > I've no idea what it could mean.
> >
> > Levels 1 - 5 seem to be handled differently. with the repeat * 4,
> > repeat * 2, no repeat and the padding.
> >
> > Ticker
> >
> >
> > ___
> > 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
___
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] Problem using profiles with OSM based maps
Thanks Gerd for the hint, I didn't know about --custom option. But according to mkgmap help, it is for marine maps, maybe using it as default could break more than fix? El 20/12/21 a las 10:18, Gerd Petermann escribió: Hi Carlos, I don't understand all of this but the mentioned change from 17 (0x11) to 23 (0x17) is done when the --custom option is given. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Montag, 20. Dezember 2021 09:55 An: Development list for mkgmap Betreff: [mkgmap-dev] Problem using profiles with OSM based maps An user of my maps has reported the following problem when using OSM based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable different sets of maps associated to each profile. When he has several OSM based maps in the SD card (not only mines, also from other sources, witch I guess are also built with mkgmap), switching between profiles automatically enables all OSM maps, even if they were previously disabled in a given profile. It seems to be related to some parameters in the TRE subfile, as reported in this thread: https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571&sid=6e0edd3239fb36f34c4b5d8df4f9f036 ___ 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] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.
Hi Gerd
Are you OK with the idea of the letters at any level being to the
right. Then the letters at this level take decreasing values. When
exhausted, the next lower slot will be the start of the next level, so
subtract 1 to find it and append '1' to the bit-string to get the
starting position for the next level.
in the test map there is, say:
02cf | 19 | 11 | struct level: 17
02d0 | 1a | 15 50 00 00 | struct for 17
02d4 | 1e | 10 | struct level: 16
02d5 | 1f | 19 80 00 00 | struct for 16
02d9 | 23 | 0f | struct level: 15
02da | 24 | 1c c0 00 00 | struct for 15
The differences between the first byte after the level indicator ie 15,
19 & 1c) give 4 and 3, which are the number of letters at level 17 and
level 16
Ticker
On Mon, 2021-12-20 at 09:18 +, Gerd Petermann wrote:
> Hi Ticker,
> please explain. What counters do you see? What do they mean?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Montag, 20. Dezember 2021 09:49
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16
> is some kind of codebook.
>
> Hi Gerd
>
> The tree is arranged so that letters at any level always have the
> highest values, ie come in from the right, and there are no gaps so no
> need for bit-flags. All it needs is the count of letters at each level
> to determine the tree.
>
> For levels 7 to 18 this is consistent and the count can be determined
> from the first byte in the "struct for {level}".
>
> Levels 19 and 20 are slightly out, but I think you found some
> strangeness here, including something indicate using Mdr3x data.
>
> Level 6 count might be mixed into the following
>
> I haven't been able to work out levels 1-5 yet, but somewhere would
> hope to find counts 0,0,1,7,9 maybe cumulative, maybe backwards, maybe
> without the first 2 values, maybe starting from the cumulative level 6
> value.
>
> Ticker
>
>
> On Sun, 2021-12-19 at 21:12 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > my thought for the struct bytes was that the 1-bits might represent
> > the position of leafs, but
> > the bit counts don't match.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Sonntag, 19. Dezember 2021 10:12
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572:
> > MDR16 is some kind of codebook.
> >
> > Hi Gerd
> >
> > It looks like the order of the letter patterns approaches canonical
> > Huffman (but not quite as far as I can see). With this, only the
> > number
> > of codes of each length is required to form the tree.
> >
> > The "struct for {level}" looks like 2 numbers. Both increasing as
> > levels go from 20 to 6. The first, a single byte from #00 to #3d -
> > this
> > could be give the accumulated lengths at each level (but I didn't get
> > it to match). The second, variable length, from #06 to #180c00
> > and
> > I've no idea what it could mean.
> >
> > Levels 1 - 5 seem to be handled differently. with the repeat * 4,
> > repeat * 2, no repeat and the padding.
> >
> > Ticker
> >
> >
> > ___
> > 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.
Hi Ticker,
please explain. What counters do you see? What do they mean?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Montag, 20. Dezember 2021 09:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn]Commit r572: MDR16 is
somekindof codebook.
Hi Gerd
The tree is arranged so that letters at any level always have the
highest values, ie come in from the right, and there are no gaps so no
need for bit-flags. All it needs is the count of letters at each level
to determine the tree.
For levels 7 to 18 this is consistent and the count can be determined
from the first byte in the "struct for {level}".
Levels 19 and 20 are slightly out, but I think you found some
strangeness here, including something indicate using Mdr3x data.
Level 6 count might be mixed into the following
I haven't been able to work out levels 1-5 yet, but somewhere would
hope to find counts 0,0,1,7,9 maybe cumulative, maybe backwards, maybe
without the first 2 values, maybe starting from the cumulative level 6
value.
Ticker
On Sun, 2021-12-19 at 21:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> my thought for the struct bytes was that the 1-bits might represent
> the position of leafs, but
> the bit counts don't match.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Sonntag, 19. Dezember 2021 10:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572:
> MDR16 is somekindof codebook.
>
> Hi Gerd
>
> It looks like the order of the letter patterns approaches canonical
> Huffman (but not quite as far as I can see). With this, only the
> number
> of codes of each length is required to form the tree.
>
> The "struct for {level}" looks like 2 numbers. Both increasing as
> levels go from 20 to 6. The first, a single byte from #00 to #3d -
> this
> could be give the accumulated lengths at each level (but I didn't get
> it to match). The second, variable length, from #06 to #180c00
> and
> I've no idea what it could mean.
>
> Levels 1 - 5 seem to be handled differently. with the repeat * 4,
> repeat * 2, no repeat and the padding.
>
> Ticker
>
>
> ___
> 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] Problem using profiles with OSM based maps
Hi Carlos, I don't understand all of this but the mentioned change from 17 (0x11) to 23 (0x17) is done when the --custom option is given. Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Montag, 20. Dezember 2021 09:55 An: Development list for mkgmap Betreff: [mkgmap-dev] Problem using profiles with OSM based maps An user of my maps has reported the following problem when using OSM based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable different sets of maps associated to each profile. When he has several OSM based maps in the SD card (not only mines, also from other sources, witch I guess are also built with mkgmap), switching between profiles automatically enables all OSM maps, even if they were previously disabled in a given profile. It seems to be related to some parameters in the TRE subfile, as reported in this thread: https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571&sid=6e0edd3239fb36f34c4b5d8df4f9f036 ___ 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] Problem using profiles with OSM based maps
An user of my maps has reported the following problem when using OSM based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable different sets of maps associated to each profile. When he has several OSM based maps in the SD card (not only mines, also from other sources, witch I guess are also built with mkgmap), switching between profiles automatically enables all OSM maps, even if they were previously disabled in a given profile. It seems to be related to some parameters in the TRE subfile, as reported in this thread: https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571&sid=6e0edd3239fb36f34c4b5d8df4f9f036 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.
Hi Gerd
The tree is arranged so that letters at any level always have the
highest values, ie come in from the right, and there are no gaps so no
need for bit-flags. All it needs is the count of letters at each level
to determine the tree.
For levels 7 to 18 this is consistent and the count can be determined
from the first byte in the "struct for {level}".
Levels 19 and 20 are slightly out, but I think you found some
strangeness here, including something indicate using Mdr3x data.
Level 6 count might be mixed into the following
I haven't been able to work out levels 1-5 yet, but somewhere would
hope to find counts 0,0,1,7,9 maybe cumulative, maybe backwards, maybe
without the first 2 values, maybe starting from the cumulative level 6
value.
Ticker
On Sun, 2021-12-19 at 21:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> my thought for the struct bytes was that the 1-bits might represent
> the position of leafs, but
> the bit counts don't match.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Sonntag, 19. Dezember 2021 10:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r572:
> MDR16 is some kind of codebook.
>
> Hi Gerd
>
> It looks like the order of the letter patterns approaches canonical
> Huffman (but not quite as far as I can see). With this, only the
> number
> of codes of each length is required to form the tree.
>
> The "struct for {level}" looks like 2 numbers. Both increasing as
> levels go from 20 to 6. The first, a single byte from #00 to #3d -
> this
> could be give the accumulated lengths at each level (but I didn't get
> it to match). The second, variable length, from #06 to #180c00
> and
> I've no idea what it could mean.
>
> Levels 1 - 5 seem to be handled differently. with the repeat * 4,
> repeat * 2, no repeat and the padding.
>
> Ticker
>
>
> ___
> 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
