[mkgmap-dev] DEM File Format and mkgmap

Fri Dec 15 19:34:39 GMT 2017

Hi Andreas

I have been able to make it work (tapping on the arrows) on my Oregon 
600 but its very sluggish and at one stage it just freezes.

I think you are right ; there is an issue.

On 15/12/2017 19:30, Andreas Schmidt wrote:
> 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
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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