kürzlich ermittelte ich im autom. Router die Länge einer mir sehr gut bekannten Strecke, die am Fuss von Liedberg, nähe Düsseldorf, von Giesenkirchen Richtung Glehn, verläuft. die Strasse läuft wie gesagt am Fuss. aber sie bekam die Höhenangaben vom Berg bzw. von der Strasse, die von Korschenbroich herkommt, da gibt es in beiden Fällen in der Tat Steigungen. nicht aber auf der betroffenen Strasse… da ich mich von einer Knie-Entzündung erhole, hätte ich diese Strecke sonst wegen der anscheinend zu rapide zunehmenden Steigung (die es gar nicht gibt, zumindest direkt an der Stelle) abgelehnt.
ich frage daher ironisch: wie werden eigentlich Höhenangaben von OSM «beherrscht» ?
(von beherrschen scheint man weit weg? oder?)
wie kann man Abhilfe schaffen?
(ich habe seit kurzem ein kleines Android-Tablett HTC als elektr. Buch für den Garten, und da wir Mitte im Winter sind, ist mir der Umgang damit noch völlig Fremd. sie ist nicht unterwegs internet-fähig, da kein Telefon-Zusatz drin, nur zu Hause über WLAN, aber sie hat einen GPS-Teil. Kann man damit an dem Problem der falschen Höhen arbeiten, und wie macht man das, ohne die anderen in OSM bereits erfassten Werte durcheinander zu bringen?)
OSM hat gar keine flächendeckenden Höhenangaben. Lediglich ein paar Punkte (theoretisch beliebige, aber in der Praxis oft nur einige wenige, Gipfel z.B.) tragen einen Wert für ele.
Viele Router liefern ein Höhenprofil für berechnete Strecken. Die holen sich die Werte aber nicht aus OSM, sondern von anderen Anbietern (SRTM z.B. von der NASA ist recht beliebt).
Liedberg als “Berg” zu bezeichnen ist sicherlich etwas übertrieben - ist ja nicht mehr aus ein “Sandhaufen” (Quarzitkuppe) mit gut 50 Meter über NN. Bezüglich der Steilheit einiger Wege gebe ich dir allerdings recht … das ist für die niederrheinische Tiefebene schon ungewöhnlich. Aber dein Post war ja auch ironisch gemeint …
Aber zu Thema: Höhenangaben sind m.E. für OSM durchaus interessant - z.B. in Form von “Trigonometrischen Referenzpunkten (mit bekannter Höheneinmessung)” oder sonstiger Punkte mit exakt vermessener Höhenangabe (mit Consumer-GPS-Geräten (Garmin etc.) geht das nicht). Wenn dir solche Punkte bekannt sind, solltest du die mappen … ansonsten muß du, wie maxbe schon ausgeführt hat, Höhendaten aus anderen Quellen heranziehen.
Ich verwende (mangels anderer Angaben) durchaus auch schon mal Höhenangaben vom GPS für das ele Tag in OSM. Irgendwann zu Anfang meiner OSM Zeit hat hier mal jemand zu mir gesagt: Lieber ungenaue Angaben als gar keine. Mir ist die Ungenauigkeit von GPS Höhendaten durchaus bewußt, aber gerade zum Beispiel auf Berggipfeln ist die generelle Genauigkeit eines GPS recht gut. Vergleiche ich das mit bekannten Angaben liegen die Abweichungen oft bei unter 5 Metern. Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung. Fazit: Da Höhenangaben meiner Meinung nach vor allem im Gebirge wichtig sind trage ich schon mal die Angaben meines GPS an Punkten die im Gebirge liegen und noch keine Höhe in OSM haben ein, aber nur wenn das GPS nicht gerade offensichtlich ungenau arbeitet (zum Beispiel in Schluchten bzw. generell wenn das GPS eine Ungenauigkeit von mehr als 5 Metern selber anzeigt). Das sind dann nicht nur Gipfel (die meisten haben bereits eine Höhenangabe) sondern auch schon mal Unterkunftshütten oder Wegweiser.
Das ist immer eine Frage des Zwecks. Den Gipfel eines Berges um 5 Meter falsch einzutragen schadet ja nicht. Wenn aber an einem eigentlich vollkommen flachen Weg jeder Punkt mit einer Höhenangabe versehen ist, die ± 5 Meter schwankt, ist das nicht ungenau, sondern einfach falsch.
Das ist nicht das Problem (Abweichungen in Bereich von ein paar Meter) sondern das viele ele Angaben nicht das WGS84 Ellipsoid verwenden. Sprich, es wird eingetragen was gerade auf dem Gerät angezeigt wird, was locker 50m daneben liegen kann.
QED (du hast die falsche Höhe eingetragen)
Simon
PS: ich behaupte nicht, dass die Definition des ele Tags sonderlich praxis nah ist …
Höhen sind leider ein Beispiel dafür, was OSM nicht beherrscht sondern ordentlich versiebt.
Laut Wiki sollen Höhen in WGS84 eingetragen werden, nicht in NN. Laut Historie der Seite war diese Änderung die Idee eines einzelnen Mappers in 2009.
Nachdem aber sonst kein Mensch auf die Idee käme, sowas überhaupt im Wiki nachzuschlagen geschweige denn weiß was er da wie umrechnen müßte, gehe ich davon aus daß die meisten Höhen in NN eingetragen sind. Aber vielleicht mit genug Ausnahmen von Technikfreunden daß man jetzt generell mit den Höhen nicht wirklich was anfangen kann.
Persönlich scheint mir der Ansatz geeigneter, als diese auch noch bei OSM zu pflegen. Das www.opendem.info will ja AFAIK langfristig dahin kommen, dass man dort Höhen editieren kann.
Insbesondere SRTM Rohdaten sind mit Vorsicht zu genießen. Generell wird dort die Gesamthöhe gemessen, also z.B. Wald ab Oberkante Baumwipfel. Grade im Gebirge enthalten sie gravierende Fehler, es können komplette Berge in den Daten fehlen, z.B. unter Gletschern, oder es gibt auch “verfüllte” Täler mit Höhenlinien quer zum tatsächlichen Verlauf [1].
Gemessene Höhen dürfte einen deutlich geringeren Fehler haben als aus SRTM abgelesene Höhenangaben.
Ich habe nie behauptet, dass sie perfekt sind. Aber es ist nun mal derzeit das einzige, was uns flächenmäßig zu Verfügung steht. In meinen Augen sind sie eine gute Grundlage, auf die man aufsetzen und dann manuell per crowdsourcing verfeinern kann. Und wer weiß, vielleicht gibt es ja in den nächsten Jahren auch eine OpenData Spende von Geländeprofilen
So viel ich weiss, gibts durchaus lokale Quellen von hochpräzisen DEMs (z.B: Sächische Schweiz) die im Prinzip freiverfügbar sind. Das Problem ist wirklich eine Platform zu bauen, die einerseits die Verarbeitung von zusätzlichen DEM Quellen erlaubt, anderseits auch Crowdsourced Daten unterstützt.
Wegen der WGS84 Problematik braucht es vermutlich ein gewisses Mass an Heuristik um Messungen mit falscher Referenz entweder auszuschliessen oder entsprechend umzurechnen.
Für brauchbare Höhendaten aus dem GPS brauchst Du (mindestens) einen möglichst niedrig stehenden Satelliten. Dumm ist, dass der sich oft hinterm Horizont versteckt.
Das ist bei der Positionsmessung nicht wirklich anders: auch da sind sind Satelliten mit 90° Anstand gerne gesehen, während drei auf einer Linie nicht wirklich Spaß machen.
Auf einem Berggipfel ist die Wahrscheinkeit groß, einen niedrigstehenden Satelliten zu sehen und damit eine brauchbare Höhe zu bekommen, in einem Tal eher gering.
Das zu wissen hilft natürlich nicht bei der fehlenden Angabe des Höhen-Bezugssystem. Das ist ja sogar zwischen DE und AT verschieden, so dass die Zugspitze in DE und AT unterschiedliche Höhen hat (aber weit unter 1m, also in einem Bereich, der uns nicht interessiert). Wirklich fies finde ich, dass die GPSe auf NN umrechnen, ohne den Fakt an sich geschweige denn das benutzte System anzugeben.
Mir ist bekannt das die Höhen laut Wiki in WGS84 Höhen eingetragen werden sollen und ich kenne auch diesen Umrechner dafür: http://www.bkg.bund.de/DE/Bundesamt/Geodaesie/GeodIS-WA/WApp/GidBer/gidber00__node.html__nnn=true
Aber: Auch wenn ich mich sonst immer genau an das was im Wiki steht halte: In diesem Fall halte ich mich mit Absicht nicht dran. Ich halte dies für völlig Praxisfern! Die meisten Höhenangaben in OSM sind in Normalhöhennull gemacht. Damit aber klar ist das ich auch meine Angaben in Normalhöhennull eintrage schreibe ich immer 2 Höhenangaben rein. Zum Beispiel für die Benediktenwand:
ele=1801
ele:NN=1801
Mit ele:XX kann das Referenzmodel explizit angegeben werden.
Damit wird bei solchen Angaben von mir klar das in ele Normalhöhenull angegeben ist.
Das mache ich so seit dieser Diskussion: http://forum.openstreetmap.org/viewtopic.php?id=18946
Ich glaube, es ist egal, wieviele Werte wir in OSM eintragen, das Problem aus #1 werden wir nicht lösen. Da wir niemals ein flächendeckendes Gitter vermessen können, müssen Router auch weiterhin aus externen Daten interpolieren.
Ich hab mal ein Bildchen gemalt:
Der einzige aus OSM bekannte Wert in der Karte ist unixaskets Benediktenwand mit 1801m.
Um das Höhenprofil des blauen Weges zu berechnen bräuchten wir entweder ganz viele Höhenwerte am Weg, oder wir nehmen eben externe Daten (die ganzen Punkte mit den Zahlen dran sind die Werte aus openDEM).
Die liegen nicht auf dem Weg, sondern rund um die Strecke verstreut. Dafür hat man auch Werte (und damit Höhenlinien, Schummerung…) an Stellen, die niemals ein Mapper betreten wird.
Grüße, Max
PS: Die SRTM-Werte in dieser Gegend sind deutlich zu niedrig. Abweichungen sind ein typischen Problem für bergige Gegenden, weil ein Mess"punkt" auf der Karte entspricht in der wirklichen Welt einem gemittelten Fussballfeld und an manche Stellen sieht der Satellit auch nicht gut hin. Da ich nur linear interpoliere, wird auch kein Fehler wieder rausgerechnet.
SRTM nutze ich - trotz der bekannten Qualitätsprobleme - für die aktuell in Entwicklung befindliche Geländeuntersützung in OSM2World ebenfalls, weil es eben der einzige von der Lizenz her unproblematische globale Höhendatensatz ist. Dieselbe Technologie könnte man aber auch für andere Datenquellen als SRTM einsetzen.
Zusätzlich will ich aber auch Tags in OSM mit einfließen lassen (allerdings nicht ele, die sind derzeit unbrauchbar). Für das Ausgangsproblem würden mir dann z.B. incline-Tags an einer Straße helfen, die durch das grobe Geländemodell vermittelte falsche Annahme zu korrigieren.
Also, ich bin der Meinung dass “bloß” ein editierbares DEM auch nicht reicht, denn dann hat man ja zwei getrennte Datenquellen und das Geländemodell passt sich nicht ohne umständliche manuelle Eingriffe an, wenn z.B. die Straße in OSM verschoben wird.
Für unbebautes Gebiet wäre so ein editierbares DEM natürlich das Mittel der Wahl, zumal die automatisch erzeugten Daten an Bergen etc. oft sogar Messfehler und Datenlücken haben. Dort könnte man dann auch lokale Datenspenden einpflegen. Aus meiner Sicht ist von daher die Kombination aus möglichst gutem freien Raster-DEM und Berücksichtigung von OSM-Daten richtige Lösung.
Anfangen kann man mit dem Sammeln von Tracks mit Höhenangaben. Idealerweise mit Höhen aus barometrischen Höhenmessern. Denn die relative Genauigkeit der Höhendaten ist recht gut, und die absoluten Werte sind (fast) ohne Bedeutung, wenn man das Netz an Festpunkten aufhängt und dazwischen über die Tracks verfeinert.
Um die nötige Ausgleichsrechnung könnte ein Geographieinstitut sich kümmern. Ich kann die Schwierigkeit nicht beurteilen, denke aber, sowas schreit nach Diplom- und/oder Doktorarbeit.
Für die Festpunkte müssten man schlimmstenfalls ein paar Euronen in einen Topf werfen und ein Profi-GPS beschaffen und damit erst einmal die Autobahnen abfahren. Vielleicht bekommt man aber auch Festpunkte spendiert. .oO( oder ein Profi-GPS )
Um an möglichst viele Tracks zu kommen, braucht es Mitstreiter auch außerhalb der OSM-Gemeinde: Radler, Wanderer, Autofahrer. Die sollte man aber über die richtigen Onlime-Magazine erreichen können?
Der Riesengewinn dabei: die präzisen Höhenwerte fallen genau da an, wo sie gebraucht werden, nämlich an Straßen und Wegen, und genau auf den Wegen, die auch befahren werden
“ele:de” ist vermütlich besser, da verschiedene Bezugspegel existieren.
Es ist wichtig, dieses Problem global zu lösen.
Und sollte irgendwann ein Gesamtmodell stehen wird sich ele= nach diesem Modell richten und wir werden kein Problem mit der Bereinigung der Daten haben…
?
