You apparently do manually over a long timespan what my script essentially does on each map update run. Attached is my script (build.php), it will not run it but it might give you an example of how I implemented this. The interesting bits are the two functions render() and subsplit(). They call each other recursively until an image has been rendered successfully within the specified size limit or that subsplitting any further is not possible. Please excuse the sloppy code :p On 30/04/2014 13:47, Felix Hartmann wrote:
On 30.04.2014 13:36, Lambertus wrote:
To get a better optimum in file size, using the process I described earlier, you could start off with a huge --max-nodes setting and then 'search' for the highest --max-nodes that works for each specific area.
Well that's basically what I do. I have for all areas a rather high max-nodes, and If I see it crashes on a tile, the next week I decrease it. However in reality I should also increase it sometimes - but that would be even more work. Some nice interaction between mkgmap calling splitter in order to keep track of crashing tiles due to too high max-nodes would be great. I cannot run multiple mkgmap.jar threads, as my server only has 12GB of RAM - and that works out to exactly running a single mkgmap.jar instance using max-jobs=8 --- plus multithreading the nsis.exe in the background as nsis packing is super slow... (damn, when will they ever update nsis to lzma2 and a rather recent .7z version - also getting rid of 2GB limit).. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev