Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Gerd Petermann
Hi Ticker, do you have a link for me? None of the methods to store the tree that I found would produce such a data structure. This is what I found so far: https://web.stanford.edu/class/archive/cs/cs106b/cs106b.1208/assignments/assign6/warmup

Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Ticker Berkin
Hi Gerd This could just be the way the tree has been flattened, with the data for longest sequences at the end, just happening to be byte aligned and without intervening bit markers to represent the tree because they have occurred already. regarding the 00s, maybe this a an escape

Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Gerd Petermann
Hii Ticker, reg. MDR16: When I print the encoded characters which require 8 or more bits in the order of the Huffman tree they build a sequence which appears at the end of MDR 16 (last 60 bytes or so). Those chars which are encoded with fewer bits are still a mistery to me. Gerd

Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Gerd Petermann
Hi Ticker, it's almost impossible to guess when there is only one entry in MDR 30/31 and only one occurence of the code "". I used '#' in my debug code to mark an "unknown" char. A possible meaning could be that 30/31 are common prefixes and 32/33 are common suffixes in

Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Ticker Berkin
Hi Gerd Do you think there might be some form of escape sequence that is followed by a ref to the clear road names in Mdr 30..33. I noticed when looking at MapInstall manipulated Mdr that the '#' sort got changed. Ticker On Wed, 2021-12-15 at 11:13 +, Gerd Petermann wrote: > Hi Ticker, > >

Re: [mkgmap-dev] [mkgmap-svn] Commit r572: MDR16 is some kind of codebook.

2021-12-15 Thread Gerd Petermann
Hi Ticker, this is what I have so far. The non-printable characters 0x01..0x04 are probably not correct. Note the special case with the last sequence. It only occurs once in the index and may as well be an error in the data. My code doesn't detect any unknown codes, so I think MDR16 must somehow

Re: [mkgmap-dev] Format6Encoder/Decoder

2021-12-15 Thread Gerd Petermann
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 im Auftrag von Ticker Berkin Gesendet: Mittwoch, 15. Dezember

Re: [mkgmap-dev] Format6Encoder/Decoder

2021-12-15 Thread Ticker Berkin
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