ich bin auf die folgenden Hinweise gestoßen und mir ist nicht ganz wohl dabei, diese einfach mit “Kein OSM-Fehler” zu schliessen. Insbesondere da die Karten ja auf der OSM-Website eingebettet sind.
Mein aktueller Stand ist, dass OpencycleMap und CyclOSM mindestens in dem Gebiet falsche Höhenlinien verzeichnen (1960 statt 520m). Ich hatte schon vermutet, dass die 1960 nicht metrisch sind, aber 1960 Fuß wären z.B. 597 Meter.
Auch liegt das südwestliche Ufer des Obersees (Karte) ca. 1000m höher als das nordöstliche, auch das halte ich für physikalisch ausgeschlossen.
CyclOSM verwendet laut Lizenz-Datei die Konturen und Höhenlinien wie die OpenTopoMap.
OpenTopoMap verwendet laut dieser Seite SRTM-Höhendaten von viewfinderpanoramas.org und VFP verwendet größtenteils die DEMs von ASTER.
OpenCycleMap gibt an, die Höhendaten ebenfalls von ASTER zu beziehen.
Schlussendlich würde ich mir überlegen, welchen Einfluss wir als OSM-Community auf diese Höheninformationen von ASTER haben und ob es uns überhaupt möglich ist, diese zu korrigieren.
Relevant ist auch noch die folgende Information: SRTM, ASTER usw. veröffentlichen in der Regel Raster-Höhendaten mit einer gewissen Auflösung. Beim verbreiteten SRTM3 sind das 3 Bogensekunden, was grob 90 Metern entspricht (am Äquator ist eine Bogenminute genau eine Seemeile, eine Bogensekunde also 1/60nm = 30,9 Meter; je weiter man sich vom Äquator entfernt, desto kürzer wird diese Länge in Ost-West-Richtung).
Du bekommst dabei also die Information “die in diesem 90x90-Meter-Rechteck gemessene Höhe ist X”. Es ist nicht klar, ob das die höchste oder tiefste Stelle in dem Rechteck ist oder irgendwas Zufälliges dazwischen. Oder vielelicht wegen Wolkendecke gar kein Wert. Ferner gibt es viele verschiedene Algorithmen, um aus diesen Messwerten dann Höhenlinien zu berechnen; die sollen ja möglichst ein bisschen hübsch geschwungen aussehen und sich nicht so pixelgrafik-mäßig an den Messkästchen entlanghangeln.
Also kurzgesagt, erstens können verschiedene Höhendatensätze voneinander abweichen, zweitens müssen aber auch Höhenlinien verschiedener Anbieter, die aus den gleichen Höhendaten errechnet werden, nicht gleich sein.
Und drittens können wir bei OSM exakt null daran ändern
Danke euch schonmal für die Rückmeldung/die Erläuterungen.
Ich habe mir jetzt mal testweise die Daten von viewfinderpanoramas in qgis geladen und diese Daten scheinen korrekt zu sein.
Also kann es eigentlich nur am Renderer liegen, oder?
Mir ist noch aufgefallen, dass das betroffene Gebiet relativ genau an der Grenze zweier Tiles von viewfinderpanorama liegt, möglicherweise ist da was beim Zusammenführen schief gelaufen.
€: Achja, nachdem es eigentlich nur am Renderer liegen kann, habe ich es mal an cyclosm weiter gemeldet. Bei OTM habe ich erstmal drauf verzichtet, da das Projekt momentan ohnehin nicht gewartet wird.
OSM stellt keine Höhenlinien zur Verfügung. Für einzelne Nodes gibt es aber durchaus Höhenangaben in OSM, wenn diese zum Beispiel für das Objekt essentiell sind oder On-The-Ground ausgewiesen werden.
Für viele Länder stehen inzwischen sehr genaue LiDAR-Höhendaten frei zur Verfügung. Aus diesen lassen sich entsprechend präzise Höhenlinien ableiten (deutlich besser als SRTM).
Genau das hatte ich ja ganz am Anfang (in der Note) bereits geschrieben, also so weit war ich schon.
Und es geht ja nicht darum, dass die Konturen leicht abweichen, es geht darum, dass vollkommen halluzinierte Höhenlinien auf sehr kurzer horizontaler Distanz mit einer Abwechung zur Realität von >1000 Höhenmetern gerendert werden.
Mein aktueller Stand ist, dass cyclosm etc. die Höhenlinien mit dem Script phyghtmap berechnet. Ich habe es bisher bei mir nicht zum laufen bekommen, aber wenn ich es evtl. über die Feiertage mal zum laufen bekomme will ich mal versuchen, welche Höhenlinien mir hier generiert werden. Unter dem Thread zu phyghtmap hatte ich geschrieben, weil ich gehofft hatte, dass jemand schon mal über dieses oder ähnliche Fehler gestolpert ist und einen Lösungsansatz hat.
Ich glaube das ist nicht dasselbe, zumindest sehe ich dort keine Abweichung von >1000m zwischen den Layern sondern bestenfalls leicht anders interpolierte Höhenlinien.
Mir ist nicht klar zu was das führen soll, da die Höhenlinien in der Regel integraler Bestandteil der Karte sind. Anders ausgedrückt: Die Höhenlinien kannst du vermutlich nicht ändern.
Naja, es würde den Fehler zumindest schonmal eingrenzen.
Wie gesagt, falls das irgendwie missverstanden wurde: Es geht mir nicht um geringfügig anders unterpolierte Linien sondern um einen vierstelligen Höhenunterschied welcher durchaus ernsthafte Folgen für Bergwanderer etc. haben kann.
Danke für die Links, ich seh es mir die Tage mal an.
Es betrifft dasselbe Problem und es sind dieselben OSM-Layer, welche die fehlerhaften Höhenlinien zeigen. Insofern ist es m.E. kein qualitativer, sondern nur ein quantitativer Unterschied.
Dieses Phänomen kenne ich aus meiner Heimatregion aus (für OSM) grauer Vorzeit, sprich wohl vor circa 10 Jahren.
Ich war damals mit einem “Kartenanbieter” in Kontakt und die Ursache war ein Fehler in den SRTM-Daten - bei der NASA haben wir dann nicht weiter nachgefragt - und bei einem späteren Datenupdate war der Fehler dann verschwunden - und ist seither auch nicht mehr aufgetreten.
Wie schon von Anderen geschrieben, von OSM-Seite lässt sich da nicht wirklich was machen, ausser einfach abwarten.
NASA provides elevation data from the Shuttle Radar Topography Mission (SRTM). Files from SRTMv3 can be downloaded from the NASA EarthData website after creating an account. To easily download all the required tiles for the area you want covered, you can use phyghtmap (here downloading for the entire world):
phyghtmap --download-only --srtm=3 --srtm-version=3 --earthexplorer-user=<NASA-USERNAME> --earthexplorer-password=<NASA-PASSWORD> --hgtdir=./dem/hgt -a -180:-85.05112877980659:180:85.05112877980659
