[mkgmap-dev] Error splitting SRTM data

Thu Sep 22 23:43:18 BST 2011

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