[mkgmap-dev] DEM Resolution and size savings

Sat Mar 31 13:17:59 BST 2018

oh yeah - another reason why I was sure DEM is somehow related to
resolution is the total size increase of adding DEM to a map with
resolution 0:24 is much bigger than adding it to 0:23, dem-dists=3312 being
used in both cases. It really does not seem to be independent of resolution.

On 31 March 2018 at 14:13, Felix Hartmann <extremecarver at gmail.com> wrote:

> Hi Gerd,
> Hmm, maybe I'm misled somewhere because I so far created only maps
> consisting of contourlines and DEM but no other map data. If I create that
> map with resolution 0=24 it is pretty exactly twice the size compared to
> 0=23 - so I assumed that the size that the DEM occupies also depends
> whether or not the map has 0:24 or 0:23. The visual quality is nearly
> identical - and THERE is a difference in the quality of the DEM if I go to
> 0:22 - similar to dropping down the DEM exaggeration in Basecamp a couple
> of percent. As having 20m contorulines in level 22 is too much, I right now
> need resolution 23 anyhow (except if I start to really put DEM into another
> empty layer - meaning my map would consist of 3 layers (map data,
> contourlines, DEM) instead of 2 layers (map data, Contourlines/DEM as one
> layer). Furthermore e.g. using --dem-dists=3312,13248,
> 26512,53024,106048,212096,424192 the intermediary dem dists values have
> no real use anyhow. Basecamp will only use 3312, and the values in the
> middle are not useful on GPS device. So basically creating a -dem-dists
> that is like dem-dists=3312,-,-, 53024,106048,212096,424192 would be
> better but right now that is not possible. However if the DEM is a really
> empty level the I could just create one layer with resolution 22 and
> dem-dists 3312 (or whatever if you say it is not connected) and then
> another layer with resolution 20,19,18 and dem-dists= 106048,212096,424192
> to save space and get rid of the not needed to be shown intermdiary DEM
> levels.
>
> On 31 March 2018 at 13:58, Gerd Petermann <gpetermann_muenchen at hotmail.com
> > wrote:
>
>> Hi Felix,
>>
>> sorry, I still don't understand what you try to point out.
>> I don't see any connection between the resolutions used in RGN and the
>> resolutions used in DEM.
>> DEM data is more or less stand alone. The other files like RGN, LBL, NET
>> and NOD all contain pointers
>> into other files, DEM doesn't, and there is no pointer from those files
>> into DEM.
>> Only some flags in tdb and the boundaries from TRE must match.
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
>> Felix Hartmann <extremecarver at gmail.com>
>> Gesendet: Samstag, 31. März 2018 13:47:21
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] DEM Resolution and size savings
>>
>> yes I know - that's why my recommendation is to put the DEM into an empty
>> layer.... (empty meaning no map data).
>> I have not tried out yet if it is possible to create a DEM only
>> gmapsupp.img for the device - that maybe is even only resolution
>> 0=20,1=19,2=18 or resolution 0:21,1=20,2=18 to see if that would work in
>> combination. Meaning you have the map with empty DEM layer at resolution 23
>> only. Then you have a gmapsupp on your device with dem in resolution 21-18
>> or 20-18 which gives shading on device when zoomed out far. If you activate
>> the DEM gmapsupp you have shading on device when zoomed out, if not you
>> don't have any shading plus it stays optional.
>>
>> Empty DEM layer works actually with Mapsource too (unlike contourlines
>> layer which often has problems working in Mapsource while working fine in
>> Basecamp).
>>
>>
>> Still maybe mkgmap could be build the DEM in such a way that resolution
>> 24 has no DEM, but resolution 23 has DEM so you do not need the different
>> layers (though they save time on map updates but confuse users sending maps
>> with Mapinstall/Mapsource sometimes).
>>
>> On 31 March 2018 at 13:38, Gerd Petermann <gpetermann_muenchen at hotmail.c
>> om<mailto:gpetermann_muenchen at hotmail.com>> wrote:
>> Hi Felix,
>>
>> please note that mkgmap doesn't create proper NOD data when level 0 is
>> not at res 24. I don't remember the details,
>> but I think routing at tile boundaries is one problem.
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
>> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
>> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
>> Gesendet: Samstag, 31. März 2018 13:28:00
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] DEM Resolution and size savings
>>
>> Observation based on Austria:
>> Well if I create a map with DEM layer with resolution=0=24,1=23,2=22,3=21,4=20,5=19,6=18
>> and set dem-dists=6624  the resulting quality will be pretty low.
>> If I create that map instead with resolution=0=23,1=22,2:21.... and
>> dem-dists=3312 - the filesize will be similar or actually smaller, the
>> level of detail/quality of the DEM however much higher. Compared to the
>> much bigger (in MB/filesize) option of  0=24,1=23,2=22... and
>> dem-dists=3312 there is virtually no visual difference in Basecamp.
>> Even with dem-dists=1656 there is no visual difference if you create the
>> DEM layer starting with resolution 0=24 or 0=23. For dem-dists=3312 there
>> is really no reason to go higher than resolution 23. Even resolution 22
>> would be fine. For dem-dists=1656 resolution 0=23 is good enough.
>>
>> So actually if mkgmap could somehow make use of this to optimize  the
>> quality/size ratio of DEM layer that would be pretty good.
>> Even though dem-dists=1652 looks pretty neat in Basecamp - I'm not sure
>> if it is not sometimes creating detail that is not there. For sure if you
>> create a route and look at the altitude profile the overall climb/descent
>> will be overstated - but that's of course also due to ways usually
>> following more the possibility of lowest climb/descent vs shortest
>> distance. In general the resolution of both OSM and DEM I guess is then not
>> good enough and climb/descent will be overestimated a bit.
>>
>> For Viewfinderpanormas 1" DEM files - the DEM produced with resolution
>> 0=23 and dem-dists=3312 seems to be a good compromise if size is not a big
>> factor. If size is a factor resolution 0=22 and dem-dists=3312 will be the
>> optimum. For best visual quality resolution 0=23 and dem-dists=1656 will be
>> best (though I'm not sure if we go for fake accuracy here. Resolution 0=24
>> and dem-dists=1562 is really not worth it. It maybe however that the 1"DEM
>> is not up to actually improving quality for dem-dists=1656 in the Alps so
>> best quality default would actually be resolution 0=23 dem-dists=3312 and
>> best quality/size 0=22 and dem-dists=3312.
>>
>> On 31 March 2018 at 13:00, Gerd Petermann <gpetermann_muenchen at hotmail.c
>> om<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann
>> _muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>> wrote:
>> Hi Felix,
>>
>> Sorry, I don't understand how you connect resolution and DEM. Can you
>> explain this more detailed?
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
>> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at list
>> s.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im
>> Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto:
>> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
>> extremecarver at gmail.com>>>
>> Gesendet: Samstag, 31. März 2018 12:33:44
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] DEM Resolution and size savings
>>
>> Yes I know there are still improvements to be done. It was just a
>> suggestion because the result is much better than saving space/data by
>> decreasing the dem-dist value. Even resolution 22 as highest value is still
>> pretty good - but with 22 on 3312 you start to see some very small changes
>> already. Still way better than 6624 at resolution 24.
>> Actually with resolution 22 it just looks a little bit flatter but level
>> of detail still seems to be the same (similar to decreasing the elevation
>> exageration by 20% in Basecamp). Only at resolution 21 you really start to
>> miss detail (in general it seems to me that the DEM detail is not that good
>> in Basecamp - but that also applies to original garmin maps).
>>
>> Maybe to save size (because right now DEM at resolution 24 can get quite
>> huge) - there could be an option to have the DEM always saved like this -
>> so same as 3312 on resolution 22 but at 24....
>>
>> On 31 March 2018 at 08:40, Gerd Petermann <gpetermann_muenchen at hotmail.c
>> om<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann
>> _muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>><mailto:
>> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
>> ><mailto:gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen@
>> hotmail.com>>>> wrote:
>> Hi Felix,
>>
>> yes, the DEM format is not yet fully understood. I assume what you have
>> is a map that uses a shrink factor <> 1.
>> The shrink factor is used like this:
>> The height deltas are devided by this value before encoding and
>> multiplied when extracting. The effect is that the deltas
>> are smaller and therefore the size is also smaller, but of course you
>> also lose a bit of information, because only the integer
>> part is stored.
>> The problem is that Garmin also uses slightly different rules for the
>> encoder, and we did not yet find out all details.
>> Frank Stinners program BuildDEMFile allows to use this but sometimes
>> produces invalid data.
>> The tool DemDisplay shows my current knowledge.
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
>> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces at list
>> s.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
>> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mk
>> gmap-dev-bounces at lists.mkgmap.org.uk><mailto:mkgmap-dev-
>> bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>>>>
>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto:
>> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
>> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
>> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:extremecar
>> ver at gmail.com>>>>
>> Gesendet: Freitag, 30. März 2018 23:07:10
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] DEM Resolution and size savings
>>
>> Hi everyone,
>>
>> I noticed that the DEM layer if created for resolution 23 only (with a
>> map that has not 24 resolution) will only be half the size of the DEM in
>> resolution 24 (dem-dist=3312) - however in Basecamp/Mapsource the detail is
>> virtually identical - I cannot see any difference in quality.
>>
>>
>> So I think there must be some way to still save a lot of data/space - but
>> it's not by going for dem-dits=6624 - that will result in much worse DEM
>> detail.
>>
>> (I still really haven't found a good solution for DEM on GPS devices
>> though. Need more time trying out different values and possibilities. Right
>> now I think best is probably a separate transparent but except for DEM
>> empty DEM only gmapsupp.img).
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
>> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkg
>> map-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
>> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.
>> mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
>> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:mkg
>> map-dev at lists.mkgmap.org.uk>>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180331/85ac036f/attachment-0001.html>