logo separator

[mkgmap-dev] DEM File Format and mkgmap

From Andreas Schmidt andreas.schmidt.hetschbach at t-online.de on Fri Dec 15 19:30:12 GMT 2017

Hi Frank,

with ypur great tool I am able to

- have3d - View in basecamp
- hillshading on Oregon600

Thats really amazing !

In Oregon there is also a menu item „3D“. Even if the map Shows Up 
hillshading,, this function doesnt work. Oregon complains that the map does 
Not have enough hight information.

Could you make it work on your device?

Andreas








Gesendet mit der Telekom Mail App
<http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm>



-----Original-Nachricht-----
Von: Frank Stinner <frank.stinner at leipzig.de>
Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap
Datum: 08.12.2017, 09:27 Uhr
An: mkgmap-dev at lists.mkgmap.org.uk
Hi,

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

My description in the pdf is (only) validfor the „TOPO Deutschland v3“. 
Please see the pages 3 and 4. There area few "unknown values".

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

Unknown is also the byte on position 0x25in the dem header. In the „TOPO 
Deutschland v3“ there we have 0x1 buti have also seen in other maps 0x0.

Interesting is also the word in 0x12 in evereyzoomlevel definition (see 
page 26 in the pdf). In the „TOPO Deutschlandv3“ thats all 0. But i have 
also found 0x100, 0x200, 0x400. Perhaps akind of multiplier for heights?

Very important is the bytes 0x0 (and 0x1)in everey zoomlevel definition. In 
the „TOPO Deutschland v3“ 0x0 is ever0. 0x1 seems to be a number as "link" 
to a maplevel. But i don'treally understand the sense ot that. We can have 
6 maplevels and we cansay 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 onewith 1 on 0x0. Perhaps 0x0 is for different and 
optimized output on pcand gps?

I think, a decompiler with the algo frommy 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 valuesin 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 fromfoot 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/20171215/b1a2b3d8/attachment.html>


More information about the mkgmap-dev mailing list