[mkgmap-dev] DEM File Format and mkgmap

Sat Dec 16 12:15:56 GMT 2017

If you are having problems with dem not showing for 1 level then it may 
be due to you  not using

--usedummydata=true

I find this is essential else indeed it produces dem files which have no 
effect at all !

I also have

--lastcolstd --overwrite=true

On 16/12/2017 12:04, andreas.schmidt.hetschbach at t-online.de wrote:
>
> …I´m not too sure how this works at all 😊.
>
> But what is (if there is one at all) the relation of the number of 
> dlon-parameters and the so called Levels? I´ve found out that with 
> only one dlon-parameter even the hiillshadung doens´t work. So I 
> choosed the same numbers of Parameters as there are Levels in Options-file
>
> Options-file:
>
> levels = 0:24, 1:23, 2:22, 3:21, 4:20, 5:19
>
> overview-levels = 6:17,7:14
>
> BuildDEMFile.exe:
>
>         C:\Garmin\bin\BuildDEMFile.exe -O -d %%i\%%i.DEM 
> --hgtpath=%hgtpath% --tre=%%i\%%i.TRE --dlon=0.00027761 --dlon=0.00049 
> --dlon=0.00075 --dlon=0.00106 --dlon=0.0017 --dlon=0.0025
>
> Is this correct?
>
> 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: *Samstag, 16. Dezember 2017 12:35
> *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
>
> 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
>
>
>
> _______________________________________________
> 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/43f0f717/attachment-0001.html>