[mkgmap-dev] DEM Resolution and size savings

Sat Mar 31 13:25:22 BST 2018

Hi Felix,

the size of DEM doesn't change, you can easily see that when you split the files with gmt -s or use the --gmapi option.
The other question is how Mapsource / Basecamp or the device decides how to use DEM data. I am sure Mapsource and Basecamp use
different levels, for rendering as well as for the elevation profile, but I also don't see a need to have multiple DEM levels in
PC installations. On my Oregon the basemap has DEM and that seems to be good enough for rendering, for the elevation profile it seems
that the resolution is too poor.

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 14:17:59
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] DEM Resolution and size savings

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<mailto: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<tel: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<tel: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<mailto: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<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: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.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com<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><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>>>
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.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 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 lists.mkgmap.org.uk<mailto:mkgmap-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><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: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.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 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 at hotmail.com<mailto:gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at 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 lists.mkgmap.org.uk<mailto:mkgmap-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><mailto:mkgmap-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<mailto:mkgmap-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>><mailto:mkgmap-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<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: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:extremecarver at gmail.com<mailto:extremecarver 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: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<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<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<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: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<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: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>
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