<font size=2 face="Arial">Hi,</font>
<br>
<br><font size=2 face="Arial">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.</font>
<br>
<br><font size=2 face="Arial">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". </font>
<br>
<br><font size=2 face="Arial">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.</font>
<br>
<br><font size=2 face="Arial">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.</font>
<br>
<br><font size=2 face="Arial">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?</font>
<br>
<br><font size=2 face="Arial">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?</font>
<br>
<br><font size=2 face="Arial">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?</font>
<br>
<br><font size=2 face="Arial">I think, a decompiler with the algo from
my pdf is working only for this special case:</font>
<br><font size=2 face="Arial">0x15 in dem header should be 0 (meter)</font>
<br><font size=2 face="Arial">0x25 in dem header should be 1</font>
<br><font size=2 face="Arial">0x0 and 0x12 in every zoomlevel should 0</font>
<br>
<br><font size=2 face="Arial">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.</font>
<br>
<br>
<br><font size=2 face="Arial">Frank</font>