[mkgmap-dev] DEM File Format and mkgmap

Sat Dec 16 11:35:55 GMT 2017

Interestingly I don't get the error message.

I click on 3d View (available on oregons but not GPS64)

then get this

http://files.mkgmap.org.uk/download/373/oregon6003dview.jpg

On 16/12/2017 10:12, andreas.schmidt.hetschbach at t-online.de wrote:
>
> HI,
>
> not sure if we meant the same thing:
>
> Map displayed with hillshading (Looks ok):
>
>   * http://files.mkgmap.org.uk/download/370/2017-12-16_10-57-56_194.jpeg
>
> Menu item 3d-view
>
>   * http://files.mkgmap.org.uk/download/371/2017-12-16_10-58-44_277.jpeg
>
> Error
>
>   * http://files.mkgmap.org.uk/download/372/2017-12-16_10-58-56_743.jpeg
>
> Regards
>
> Andreas
>
> Gesendet von Mail <https://go.microsoft.com/fwlink/?LinkId=550986> für 
> Windows 10
>
> *Von: *osm at pinns <mailto:osm at pinns.co.uk>
> *Gesendet: *Freitag, 15. Dezember 2017 20:34
> *An: *mkgmap-dev at lists.mkgmap.org.uk 
> <mailto:mkgmap-dev at lists.mkgmap.org.uk>
> *Betreff: *Re: [mkgmap-dev] DEM File Format and mkgmap
>
> 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
>
>
>
> _______________________________________________
> 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/20171216/5118b576/attachment.html>