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.
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Frank Stinner <frank.stin...@leipzig.de> Gesendet: Mittwoch, 15. November 2017 13:22:41 An: mkgmap-dev@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. Frank _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
