[mkgmap-dev] DEM File Format and mkgmap

Fri Dec 8 09:02:53 GMT 2017

Hi Frank,

strange. I think most of my Garmin demo maps have elevation in feet, and yes, I agree that the higher numbers should require changes in the algo.
I use the maps from the links posted here:
http://gis.19327.n8.nabble.com/Routing-tp5793031p5793224.html

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Frank Stinner <frank.stinner at leipzig.de>
Gesendet: Freitag, 8. Dezember 2017 09:26:57
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap

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