Henning Scholland wrote
Hi Gerd, I tried NewZealand also with 1.500.000 and 2.000.000 as max-nodes. Both failed. Germany and the alps were fine with 1.000.000. Turkey same as NewZealand. I tried NewZealand with r202 (cut polygon with osmconvert before) and it works fine with 1.000.000.
So I think there is a problem with larger water-parts and many nodes with your new algorithm.
I tried to reproduce the problem with the data in http://www.aighes.de/data/densities-out.zip, but that seems to be the output of a different area? Or maybe the explanation for the problem is that your merge with osmconvert produces a file with a strange bbox. When I cut planet with your newzealand.poly I have no problems and I get a densities-out.txt that starts with two lines giving "planet" bboxes: -4194304,-8388608,4194304,8388608 -4194304,-8388608,4194304,8388608 In your densities-out.txt I find this -4194304,-8388608,4194304,8388608 2027520,227328,2568191,800768 The 2nd bbox comes from the input file, and it doesn't cover anything near New Zealand. Splitter reports Exact map coverage is (43.505859375,4.8779296875) to (55.10740041732788,17.1826171875) Is it possible that the srtm data doesn't cover planet and osmconvert puts only this smaller bbox into the merged file? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r269-problems-with-osm-data-and-srtm... Sent from the Mkgmap Development mailing list archive at Nabble.com.