imagico, das mit der konvergierenden Richtung könnte was werden. Ein paar Tests sehen jedenfalls ganz gut aus. Der Brenner hat nach 50m eine annehmbare Richtung (+-10° halte ich für “gut”). Das Problemkind Ettaler Sattel konvergiert erst ab 130m dorthin, wo man ihn haben will. Wär mal ne Forschungsaufgabe, vermutlich eine langwierige … ;)

x-Achse: Radius in Meter, y-Achse: Richtung in Grad)

Davor, dass diese Richtungen zur Qualitätskontrolle genutzt werden, oder womöglich gar in die Datenbank geschrieben werden, hab ich ein bisschen Angst. Wenn man die Richtung und Lage und die Höhenlinen vergleicht, findet man schnell Fehler. Ob das Fehler im Höhenmodell sind oder in OSM weiss man aber nicht, es lässt sich auch nicht aus den Daten ableiten. Als Hinweis “da vielleicht stimmt was nicht, frag nen Ortskundigen” wäre es natürlich schon geeignet.

“gute Daten”: Wir sind ja auf recht freie Höhendaten angewiesen, wegen odbl und derivative database und so, wirklich gute Daten gibts da nicht wirklich.

Mein erster pessimistischer Schnellschuss: Höhenlinien in einzelnen Gebieten löschen wird der Datenbank nicht viel bringen…

So eine Höhenlinie ist ja ein sehr langes Gebilde und kreuzt viele unterschiedliche Gebiete. Die 500-Meter-Linie vor meiner Haustüre ist in meiner Gegend im Flachland und die 510m-Linie ist vielleicht nützlich. Die gleiche Linie läuft aber auch durch das hügelige Inn- und Donautal, umkreist irgendwo die Alpen und taucht in der Lombardei wieder auf, wo die 510m-Linie verzichtbar wäre.

Würde man die dazugehörige 510m-Linie zerstückeln, hätte man statt einer grossen Linie viele kleine Stücke in der Datenbank. Das könnte ein bisschen Platz bei den Linien selbst sparen, dafür wächst der Index. Ich glaube nicht, dass sich der Aufwand lohnt.

Ich hab das mal für ein kleineres Gebiet gemacht und die Seen zu den Flusssystemen dazugeschlagen. Viele graue Stellen lassen wieder füllen, wenn man auch Flüsse berücksichtigt, die das Seeufer schneiden.