will try it, please update the help file too! I think if you use --keep-complete, then you should not specify --overlap at all, right? Because on 256 I got crahes while using --keep-complete --overlap=0... which is however exactly what is recommended in the help file. I don't think there is any need for overlap if --keep-complete is used, or could there be reasons? Also I think most people will want --keep-complete by default, except if overlap is >0 could you further specify this please? I cannot see how to enable it (which I would expect if it is really experimental and not only new and needs to be tested). - correct handling of holes in polygon (experimental) On 14.12.2012 12:01, GerdP wrote:
Hi all,
I've committed r257. Changes since r254: - fixed memory leaks (appeared when more than max-areas tiles were processed). Now it shoud really require less memory if you lower the max-areas value so that multiple read passes are done (of course run time increases) - write areas.poly only if no split-file was given - don't write unneeded coordinates to areas.poly (filter points lying on a straight line) - correct handling of holes in polygon (experimental) - report number of "areas per pass" in problem-list-generator - increased allowed max-areas (now 4096) - increased default max-areas (now 512)
If I don't get problem reports, this version will be merged to trunk next monday.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r257-tp5740402.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org