[mkgmap-dev] DEM File Format and mkgmap

Fri Dec 8 08:26:57 GMT 2017

Hi,

i must confess, i have never tried to decompile a garmin dem map. I have 
only playing with bit-patterns and then looking for the result in 
mapsource. But i'm sure, that we have different algorithms or one 
algorithm with different special cases.

My description in the pdf is (only) valid for the ?TOPO Deutschland v3?. 
Please see the pages 3 and 4. There are a few "unknown values". 

For example see "Codierungstyp" (coding type) for a 64x64 tile. I found in 
different garmin maps values from 0 to 6. 0 is the standard. It seems to 
be, that the coding type have no influence of the algorithm, but i'm not 
sure. Presumable is this type only important for different interpretations 
of the height values. BuildDEMFile use type 1 for areas with "unknown 
height". This is in this case the interpretation for height=maxvalue.

Unknown is also the byte on position 0x25 in the dem header. In the ?TOPO 
Deutschland v3? there we have 0x1 but i have also seen in other maps 0x0.

Interesting is also the word in 0x12 in everey zoomlevel definition (see 
page 26 in the pdf). In the ?TOPO Deutschland v3? thats all 0. But i have 
also found 0x100, 0x200, 0x400. Perhaps a kind of multiplier for heights?

Very important is the bytes 0x0 (and 0x1) in everey zoomlevel definition. 
In the ?TOPO Deutschland v3? 0x0 is ever 0. 0x1 seems to be a number as 
"link" to a maplevel. But i don't really understand the sense ot that. We 
can have 6 maplevels and we can say the maplevel 2 and 4 are without 
dem's?

In a little demo map from garmin i have see "twins" of zoomlevelnumbers, 
one with value 0 on 0x0 and one with 1 on 0x0. Perhaps 0x0 is for 
different and optimized output on pc and gps?

I think, a decompiler with the algo from my pdf is working only for this 
special case:
0x15 in dem header should be 0 (meter)
0x25 in dem header should be 1
0x0 and 0x12 in every zoomlevel should 0

By the way, have anybody see a dem with values in foot? The values in such 
a dem should be greater then for a dem in meter. Have anybody height 
values with a precision of foot? The conversion from foot to meter would 
be a first compression step. If garmin really use "foot", then a 
different/better compression algo make sense.

Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20171208/a8e1ad6f/attachment.html>