[mkgmap-dev] mkgmap ToDo list

Wed Apr 30 13:04:51 BST 2014

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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20140430/1289d64b/attachment-0001.html>