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

Tue Dec 28 09:03:29 GMT 2021

Hi Ticker,

new patch seems to work with my 5 maps.
reg. bytes 0..2 and 30/31 etc:

The Adria Topo map has 30/31 and 32/33, the other 4 maps with MDR 16 don't have that.
Info for some demo maps in gmapsupp format(they don't have 15/16)
TransAlpin (2009) has 32/33, but not 30/31
TransAlpin (2012) has 30/31 and 32/33
Winter Activity Map  has 30/31 and 32/33

2 (always 0x15 in my maps) may really be a bit flag and the 5 would be the table size.
When I change it to 0x16 MapSource crashes, with 0x14 I see partly wrong strings.

I found some code in GPXSee https://github.com/tumic0/GPXSee
which handles huffman tables. I didn't try it yet but the program seems to be able to display
GMP format, so maybe it'll help to understand that format. It didn't help me to understand the
MDR16 so far and I don't think that exactly the same structure is used.

Will keep on playing with those bytes to find out more...
Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 28. Dezember 2021 01:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn]  Commit  r572:   MDR16   is      some    kind    of codebook.

Hi Gerd

So, in the first byte of each prefix table entry, the bottom bit =1
means push 0-n bits back, =0 means need to get extra bits to decode. In
both cases the value is >>1 and biased in a strange way. In most cases
variable numbers of bits will be needed, but the minimum is known.
Value of 0 means might need to get bits up to the max encoding length.

Have you come up with a meaning for the second byte of the prefixes
where it isn't a direct character.

I see what you mean about byte 4.

I don't follow what you mean about byte 6 and the length of the last
block.

Other static info that omight be encoded in bytes 0, 1 & 2 could be:
1/ version/subversion
2/ initial bits to read, giving size of prefix table (all 5 so far)
3/ includes refs to mdr29/30 &| 30/31. Which of your test maps have
these sections?

Ticker

On Sun, 2021-12-26 at 19:39 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> a few more patterns:
> byte 4 seems to relate to the highest stat value in the rows with
> even stat values.
> I see e.g 0x0f  and 0x1c or 0x0a and 0x1b. The formula: byte at 4 =
> highest /2 + 1
>
> byte 6 (x) is related to the number of bytes (y) in the last block.
> (x = y * 2+ 1)
> I see e.g. 0x6b (107) and 53 bytes or 0x6d (109) with 54 bytes or
> 0x5d (93) and 46 bytes.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <gpetermann_muenchen at hotmail.com>
> Gesendet: Donnerstag, 23. Dezember 2021 20:53
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev]       [mkgmap-svn]    Commit  r572:
> MDR16   is      some    kind    of      codebook.
>
> Hi Ticker,
>
> reg. "stat": my rule is a bit different but the result is the same:
> for all odd values:
> depth = usedBits = stat >> 1;
>
> val is the 2nd byte.
> for even stat values and rows where stat == val << 1 the decoder
> has to read  exactly 1 more bit to decide which character was
> encoded.
> I've not yet understood how the stat or the val field can be used to
> find the correct entry
> in the byte array with the characters.
>
> So, maybe the stat value should be shifted to the right to make some
> sense.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 23. Dezember 2021 15:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev]       [mkgmap-svn]    Commit  r572:
> MDR16   is      some    kind    of      codebook.
>
> Hi Gerd
>
> Maybe the "is always 8" is the character width.
>
> I think I understand parts of it.
>
> Read 5 bits and look up, giving 2 bytes.
> if first 3/5/6/9/b the final char in the second byte and return (b-
> first)/2 to the bit stream. Otherwise the combination somehow
> indicate
> a minimum number of more bits to read and where to start searching.
> maybe the 'struct for level' 1 or 2 bytes is a bit flag of which
> levels
> to look in. I notice (in topo_fr) it is normally a single or adjacent
> bits except for 0xa, but there are no chars at level 19
>
> prefix 0 doesn't quite follow the rules
>
> Ticker

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdr-experimental-table_v1b.patch
Type: application/octet-stream
Size: 29224 bytes
Desc: mdr-experimental-table_v1b.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211228/dd4a7a23/attachment-0001.obj>