On Thu, 22 Sep 2011 16:28:17 +0200, Thorsten Kukuk wrote:

On Mon, Sep 19, Michael Prinzing wrote:

...

srtm2osm has a parameter -corrxy to shift the contour lines. Without this parameters they are not aligned with the real heights. Is phyghtmap handling this correct?

The official version: I cannot see any code adjusting the alignment of the contour lines. For the area where I'm living, it looks perfect even without.

Without correction, contour lines created with srtm2osm are shifted about 50m to the south and also about 50m to the west. You will need some adequate terrain to see it, but take a look at http://www.wanderreitkarte.de/index.php?lon=9.8361&lat=48.6375&zoom=17 There is a gap in the forest to the west. It should match the contour lines, but it doesn't. There is a white way with red border that should follow the contour lines, but it also doesn't.

...

Since none of the two methods is producing valid data in osm 0.6 format, we need a better solution anyway.

Until now I haven't found any tool which has problems with the generated 0.6 osm format.

The limit of 2000 nodes per way is pretty new, it did not exist in osm 0.5. Since probably nobody will build such a limit intentionally into an existing tool, /today/ there might be few or even no tools really relying on this. But this may change in the future. osmosis for example crashes if I am trying to sort a file containing ways with much more than 2000 nodes. This may have another cause, but it is what I would expect more and more often in the future.

I think "fixing" phyghtmap should be pretty simple.

Then I would do it. If there is a limit introduced with a new version of the API, it should be respected wherever possible, IMHO. Michael