<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi Andreas</p>
    <p>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.</p>
    <p>I think you are right ; there is an issue.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 15/12/2017 19:30, Andreas Schmidt
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:BA9222B8-CD3F-4134-A17D-1655E24253A8@mobileclient.telekom.de">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      <span>Hi Frank,<br>
        <br>
        with ypur great tool I am able to <br>
        <br>
        - have3d - View in basecamp<br>
        - hillshading on Oregon600<br>
        <br>
        Thats really amazing !<br>
        <br>
        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. <br>
        <br>
        Could you make it work on your device?<br>
        <br>
        Andreas <br>
        <br>
        <br>
        <br>
        <br>
        <br>
        <br>
        <br>
        <p id="claim">Gesendet mit der <a
href="http://www.t-online.de/service/redir/emailmobilapp_ios_smartphone_footerlink.htm"
            moz-do-not-send="true">Telekom Mail App</a></p>
        <br>
        <br>
        -----Original-Nachricht-----<br>
        Von: Frank Stinner <a class="moz-txt-link-rfc2396E" href="mailto:frank.stinner@leipzig.de"><frank.stinner@leipzig.de></a><br>
        Betreff: Re: [mkgmap-dev] DEM File Format and mkgmap<br>
        Datum: 08.12.2017, 09:27 Uhr<br>
        An: <a class="moz-txt-link-abbreviated" href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
        Hi,<br>
        <br>
        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.<br>
        <br>
        My description in the pdf is (only) validfor the „TOPO
        Deutschland v3“. Please see the pages 3 and 4. There area few
        "unknown values". <br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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?<br>
        <br>
        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?<br>
        <br>
        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?<br>
        <br>
        I think, a decompiler with the algo frommy pdf is working only
        for this special case:<br>
        0x15 in dem header should be 0 (meter)<br>
        0x25 in dem header should be 1<br>
        0x0 and 0x12 in every zoomlevel should 0<br>
        <br>
        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.<br>
        <br>
        <br>
        Frank</span>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
mkgmap-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a>
<a class="moz-txt-link-freetext" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>