[mkgmap-dev] DEM File Format and mkgmap

Mon Dec 18 15:37:36 GMT 2017

I have generated Italy map with DEM. Hillshading is correctly displayed, 
but 3D option is disabled in BaseCamp.
BuildDEMFile command for map tiles was:
for i in 551${FID}* ; do wine ../../../../dist/BuildDEMFile.exe -O 
--usedummydata=true -d ${i}/${i}.DEM --hgtpath=../../../../DEM/hgt/ 
--tre=${i}/${i}.TRE --dlon=0.00027761 --dlon=0.00049 --dlon=0.00075 
--dlon=0.00106 --dlon=0.0017; done
And for overview map:
BuildDEMFile.exe -O --usedummydata=true -d $ABR-1${FID}/551${FID}000.DEM 
--hgtpath=../../../../DEM/hgt/ --tre=$ABR-1${FID}/551${FID}000.TRE 
--dlon=0.005
My options file contains the following levels:
levels = 0:24, 1:22, 2:21, 3:20, 4:18
overview-levels = 5:17, 6:16, 7:15, 8:14, 9:12
Any idea why 3D doesn't work in BaseCamp?

El 16/12/17 a las 14:05, andreas.schmidt.hetschbach at t-online.de escribió:
>
> Thx for the hints, but the Problem was I myself. The 3d-view is only 
> avaiable for the actual Position, i.e. you must have a dem-capable map 
> installed for the actual position – this works now for me too.
>
> 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 13:15
> *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
>
> 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