Hi Felix, fine :-) And yes, I meant max-nodes may have to be decreased, not increased. Sorry for the typo. Reg. speed: That's unexpected. It should not take much time to find the better split, (a few seconds) and typically safe some time to have fewer tiles. I'll check that tomorrow. Gerd Felix Hartmann-2 wrote
Seems to be much better now. I don't think I can increase the max-nodes value though, but for most maps the new algo creates less tiles for the same max-nodes value (e.g. Austria from 43 down to 35 for me, with the smallest tile now around 5MB instead of 2.8, and the biggest 12MB instead of 11MB, for Asia I simultaneously increased max-nodes from 800k to 900k- so I'm down from 624 tiles to 493.... and size from 970KB-16MB to now ). So it still seems to depend on the country, but it's already a lot better... It's a bit slower (about 10% more time)
On 06.05.2014 13:56, Gerd Petermann wrote:
Hi all,
I've applied num-tiles-v1.patch and improved the split algo, see http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html
It is now less likely that splitter creates tiles with a low number of nodes, it is more likely that all tiles have nearly the same number of nodes, and typically you will see fewer tiles. Maybe this also means that you can increase the max-nodes value.
I hope this also reduces the need for complex interactions between spltter and mkgmap.
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r325-improved-split-algo-and-new-opt... Sent from the Mkgmap Development mailing list archive at Nabble.com.