logo separator

[mkgmap-dev] splitter-r269 - problems with osm-data and srtm-data

From GerdP gpetermann_muenchen at hotmail.com on Sun Dec 23 08:28:18 GMT 2012

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-data-tp5741485p5741556.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.


More information about the mkgmap-dev mailing list