Hi Minko, okay, your options look strange, but I cannot reproduce a run time problem here. Do you see this for all tiles? Maybe you have a tile with special boundaries. Please post the input file that takes so long. What is your value for JRE option -Xmx ?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von lig fietser <ligfiet...@hotmail.com> Gesendet: Samstag, 6. Januar 2018 14:30:04 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] r4033: new dem options are now documented Gerd, I don't know why but mkgmap >v4025 does not work for my maps anymore. It is doing hours to compile one tile! My (experimental) DEM settings are dem-dists=3312,3312,3312,6628,9942 overview-dem-dist=16560 Map levels: levels = 0:24, 1:23, 2:22, 3:20, 4:18 overview-levels = 5:17, 6:15, 7:14 v4025 compiles ok, I updated my OFM Alps, Benelux and Germany recently. ________________________________ Van: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> namens Gerd Petermann <gpetermann_muenc...@hotmail.com> Verzonden: zaterdag 6 januari 2018 03:09:39 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: [mkgmap-dev] r4033: new dem options are now documented Hi all, see http://www.mkgmap.org.uk/doc/options I've added them in a chapter headed "Hill Shading (DEM) options" This also means that you no longer need the --x- prefix when using r4033 or newer. Please suggest improvements, esp. if you have found rules to determine "good" dem-dists values. If possible I'd like to do the calculations in mkgmap instead of asking each user to find out what is good. Maybe option --dem should be changed to --dem-source before merging to trunk? I think these are the other open problems now (no particular order): -- determine optimal block-size to avoid MapFailedExeption with large DEM files, if that is too complex we'll change the default from 512 to 2048. -- find possible encoding error for low resolutions, esp. in overview maps. Frank Stinner tries to find a solution for this :-) -- Problems with java heap when creating large or highly detailed maps: Zipped files require more heap memory because the current implementation has to keep a copy of the unzipped content while unzipped files are kept in MappedByteBuffers which don't require java heap. On the other hand they maybe cause other problems as those reported by Carlos: http://gis.19327.n8.nabble.com/mkgmap-r4025-implements-x-dem-poly-option-tp5909038p5909257.html One work around would be to keep the unzipped data in temporary files (more I/O), another solution might be to further change the algorithm so that it doesn't require full random access to all(!) hgt files "touched" by the overview map. I've already tried to change that with r4027 so that only some rows are required, but that code is not very elegant. I hope I find a better solution for this. @Frank: I think BuildDEMFile also has this problem, right? -- The code needs further clean up , javadoc and unit tests. Thanks for the good feedback so far, I think this will be another big improvement if merged into trunk. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev