logo separator

[mkgmap-dev] DEM format Questions

From Gerd Petermann gpetermann_muenchen at hotmail.com on Sun Nov 19 18:54:31 GMT 2017

Hi Frank,

I still work on the code to decode the bitstream. I still have problems to understand how the decoder knows what Method the encoder used for wrapping and encoding the value.
I would expect that all threshold values that are used to determine the used method(s) are easily calculated without table lookups or complex functions. Something like

for (...)
 int val = decodeValFromBitstream(...);
numVals ++;
 sum1 += Math.abs(val);
sum2 += ...
ddiff = ...
vdiff = ...
if (....) hunit *= 2;
method = ...
prevVal = val;
The method decodeValFromBitstream(...) would only use the values calculated in the loop. Do you think it is possible to calculate all the threhold values
in an iterative manner?
In the pdf you write that Garmin doesn't use a predictive method to compress the data, but my current understanding is that the variable hunit value
is a kind of prediction. 


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Mittwoch, 15. November 2017 15:08:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] DEM format Questions

Hi Frank,

some years ago I worked for a company which (still) produces software that - besides others - analyses mainframe data structures, e.g. the data stored by different schedulers which are
used to plan jobs. These schedulers allow to say e.g. "my job should be executed every 2nd work day" or
"my job should run on the 10th work day before christmas" or "my job should run every third day of the week if that is not a free day, in case it is a free day use the next work day" (and a lot of much more complex rules and dependencies between jobs)
A colleque wrote a software that displayed a calendar with the days on which a job will run. This software worked fine in most cases, but from time to time one customer found a special case
where it did not. More and more if -then -else cases were added and finally the colleque gave up. Next time when an error was found I was the one who was told to fix the code, and after several days I found two nested loops which were coded the wrong way (inner loop should have been outer). This allowed to remove lots of the complex code.
Your findings on the DEM data structure reminds me on this, e.g. Garmin may use a different way to calculate the normalized data.
Anyhow, I just try to explain why I did not publish any patch until now.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Frank Stinner <frank.stinner at leipzig.de>
Gesendet: Mittwoch, 15. November 2017 13:22:41
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] DEM format Questions

Hi Gerd,

at first the good news. In the meantime i have build maps for Czech Republik, Germany, Austria, Switzerland and Italy, ever with 6 zoomlevels. I don't found an error. Of course, this is no evidence for the algorithm.

And yes, there are a few mysterious things. I'm sure, what ever the garmin programmers done, they have found a very good compression for this special case. They don't waste a bit. But perhaps they think also to confuse all the snoopy guys on the world. Perhaps they say: hey let us take a special case, if the compression is not worse.

I have no idea for the 158. I belief, we can see this as parameter. Perhaps garmin have found with trial and error, that 158 give smallest DEM's for a lot of areas on earth. Then it is more a "statistical" reason.

By the way, the worst thing in my opinion is the rule for "Längencodierung". It is rather a "descriptiv" solution. Perhaps behind this is a more "mathematical theory", but i don't found it.

mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list