Wie haltet ihr es mit Höhenangaben ?

Dito.
Wobei ich es noch steigere: Ich betrachte mangels Standard JEDE Höhenangabe in der Datenbank als wahrscheinlich falsch. Denn selbst wenn sie nach irgendeinem der hier schon beschriebenen Referenzsystemen eingetragen zu sein scheint, so halte ich es für SEHR wahrscheinlich, dass der Mapper vor Ort lediglich das Tagging von einem anderen Node übernommen und nur den Wert angepasst hat, ohne sich der grundsätzlichen Problematik auch nur annähernd bewusst gewesen zu sein.

Mir begegnen beim Wandern mit den OSM Karten Ungenauigkeiten von 30 Metern hinsichtlich Nord, Ost, Süd und West - da kann ich auch mit einer Ungenauigkeit bei der Höhenangabe leben :wink:

Bezüglich der Höhenangaben wird es m.E. nicht gelingen ein OSM-einheitliches Schema zu etablieren. Dies schon deshalb nicht, weil die verschiedenen Höhenangaben historisch gewachsen sind und sehr unterschiedliche Bezugsgrößen haben (WGS84, Amsterdamer Pegel, Triester Pegel, …). Wichtig erscheint mir in diesem Zusammenhang die Erfassung des Bezugssystems. Hiermit wäre dann eine Umrechnung in die gewünschte Zielgröße möglich …

Gruß Klaus

Aufgrund dieses Vorschlages hole ich diese Diskussion einfach mal hoch, da es sich um die aktuellste der drei Vorschläge handelt.
Dann einigt euch mal weiter…

Edit: korrekter link

Für die Höhenangaben aus dem NRW-Atlas werde ich ab sofort wohl ele:NHN eintragen.

Somit ist die einzig relevante Frage ob der Wert der in ele steht geoid-korrigiert ist oder nicht (Abweichung 30-50m).

Ich trage alle Höhenangaben in m über NN ein, so wie sie auf irgendwelchen Schildern zu finden sind.

Ich rendere alle Höhenangaben auf der RWK unverändert als m über NN und es gab keine einzige Beschwerde.

Zur Lösung des Dilemmas schlage ich vor:

  • ele enthält faktisch meist die ortsübliche Angabe aus den für Mapper vor Ort offenkundigen Quellen, also sollte es auch wieder so beschrieben werden
  • eine Angabe gemäß einem bestimmten Bezugssystem sollte ein entsprechendes Tag benutzen z.B. ele:wgs84. Das irische Beispiel finde ich sehr gut gelöst. Damit haben die Experten exakte Angaben und der Normalmapper muß nichts umrechnen
  • das Wiki sollte entsprechend korrigiert werden

bye, Nop

Ja, ich denke das steht außer Frage. Man braucht verlässliche Datengrundlagen.

Die Umrechnung ist aber relativ kompliziert. Es wäre für das System von Vorteil, wenn bei der Eingabe
die Software gleich in ein Einheitssystem konvertiert und sowohl den Eingabewert als auch
den standardisierten Wert speichert. Also wenn jemand N.N.-Angaben macht, dass dazu
automatisch ein WGS84-Eintrag generiert wird.

Dann könnte man so eine Datenbankabfrage machen wie “gib mir alle Berge über 3000m NN”.
Das wäre schwieriger, wenn die Datenfelder nicht vereinheitlicht wären.

Was zunächst zu klären wäre: welches WGS84 überhaupt?
Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

Die verschiedenen nationalen System unterscheiden sich historisch seit der Preußenzeit
100 Jahre lang lediglich um ein paar cm.

Volle Zustimmung, bis auf

In Irland steht ele für “WGS84 über dem Ellipsoid”, die Werte über dem Meer sind in “ele:local” und “ele:tm75” versteckt. Wer “ele” eintragen will, muss umrechnen, wobei mir einer erklären müsste, wie er das machen soll…

Mal ne Statistik gefällig? In meiner Gegend sieht es so aus:

156777 Nodes haben ein ele-Tag
208 haben ein “ele:NN”. Dort ist ele=ele:NN. Einer davon hat kein ele.
75 haben ein “ele:wgs84”. Fast sämtliche ele:wgs84 sind ohne Geoidkorrektur, bis auf einen. Ein weiterer liegt völlig daneben mit der Umrechnung.
16 haben ein “ele:local” allerdings haben alle diese Nodes kein ele
ele:nhn kommt gar nicht vor.

Über die 156777 Nodes ohne weitere spezielle Höhenangaben kann ich natürlich nichts sagen, allerdings sind mir auch noch nirgends falsche Höhen aufgefallen. Die 100% Übereinstimmung von ele und ele:NN ist aber schon deutlich…

Grüße, Max

PS: Einige Höhenangaben könnten in dem Bereich fehlen. Ich werfe alles aus meiner Datenbank, was ich nicht irgendwie als Zahl interpretieren kann, schliesslich muss ich mit dem Wert rechnen können.

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Wir könnten dann ruhig an der einheitlichen Definition von ele= als WGS84-Geoidhöhe
festhalten, ohne dass die bisherhigen N.N.-Einträge grob falsch wären.
Das würde quasi die deutschen ele-Angaben retten. Nur die Iren müssten dann alles ändern.

Da noch nicht viele ele-Tags überhaupt in OSM stecken - ist eben fast alles in 2D-Koordinaten -
sollte man nicht danach gehen wer was ändern muss, sondern was langfristig gesehen das
Sinnvollste ist.

Als Beispiel: in NMEA steht auch die WGS84-Geoidhöhe, wobei die Geoid-zu-Elleipsoid-Differenz
als Datenfeld gleich mitgeliefert wird. So lässt sich dann auch gut umrechnen.
Aber wie sollte man die unkorrigierte WGS84-Ellipsoidhöhe taggen? ele:wgs84= ?
Dann müsste aber ziemlich deutlich gesagt werden, dass das keine WGS84-Geoidhöhe ist.

Reicht völlig, solange man keine Brücken bauen will… http://de.wikipedia.org/wiki/Hochrheinbr%C3%BCcke

Ja.

Und vielleicht noch ein paar andere Regionen mit eigener Auffassung, was ele ist. Das ist ja nicht das deutsche Wiki für das deutsche OSM. In anderen Gegenden müsste man erst nachsehen und das diskutieren. Deshalb bleibt sowas ja auch so lange stehen. “Wir hier” können uns ja einigen. Aber wer sagts den Iren und fragt in Südamerika und Asien nach?

Der Normalfall ist nicht der Mapper mit GPS, sondern der Mapper vor einem Schild. Noch seltener sind GPS-Besitzer, die auch noch sagen können, ob das was sie am Gerät sehen aufs Geoid oder aufs Ellipsoid bezogen ist. Nur wenige werden überhaupt die Frage verstehen.

Ja. Die Idee, dass die Korrektur Teil der WGS84-Definition ist, ist hier ja recht deutlich eine Minderheitenmeinung.

Grüße, Max

Das ist auch gut so, denn die mit einem Consumer-GPS-Gerät gemessenen Höhenangaben sollten m.E. nicht (vielleicht hilfsweise in Ausnahmefällen) in OSM eingetragen werden. Sie sind zu ungenau … da bringt auch die Angabe des Bezugssystem nichts.

Gruß Klaus

Überlegen wir mal. Die Verarbeiter (gemeint ist Software) von Geodaten arbeiten mit EPSG-Codes. Mit diesem EPSG-Code ist ein System, sei es ein geographisches der ein projiziertes System der XY-Richtung oder ein vertikales der Z-Richtung definiert und mit den relevanten Berechnungsparameter hinterlegt.

Das hatte ich hier schon mal geschrieben.

Wie Wolf schon richtig schrieb:

Man muß Aufpassen.

eine DHHN92- Höhe könnte z.B. so aussehen:

ele:epsg:5783=311 Also Höhe nach EPSG-Code 5783 (gleich DHHN92; gleich NHN) beträgt 311 Meter.

Im Wiki steht dann, daß EPSG 5783 das DHHN92 ist und NHN…

Feddich.

Sven

Aus der INSPIRE-Spezifikation für Elevation:

Das genannte EVRS wird beim BKG beschrieben: http://www.bkg.bund.de/geodIS/EVRS/EN/Home/homepage__node.html__nnn=true .

Es gibt also mindestens europäische Höhenstandards, an die wir uns hängen sollten. Das doofe ist, das ich die Standards da nicht wirklich verstehe…es bräuchte also eineN GeodätIn, derdie sich damit auskennt und uns da erhellen könnte.

Nein! Die Geoidundulation beträgt in Deutschland zwischen +34 und +51 Meter.
Quelle mit Visualisierung: http://www.bezreg-koeln.nrw.de/brk_internet/presse/publikationen/geobasis/faltblatt_geobasis_normalhoehen.pdf (Seite 2)

Ähhhh. “Korrigieren” heisst ja auch nicht, dass wir eine Konstante addieren, sondern dass wir eben diese 34 bis 51 Meter addieren… Oder was meinst Du mit “Nein!”

Die Umrechnung Gebrauchshöhe (DHHN92, …) in ellipsoidische Höhen (WGS84) ist einfach. Man nimmt die eine Höhe und addiert/subtrahiert einen Korrekturwert. Diesen Korrekturwert erhält man aus Tabellen die z.B. für ein 10x10 km-Raster die Korrekturwerte enthalten. Für alle Punkte dazwischen kannst man interpolieren.

Für ingenieurgeodätische Zwecke (Millimetergenauigkeit) reichen meistens (d.h. außerhalb von Berg- und Tagebaugegenden) 1 km-Raster aus.

Ich hatte den Eindruck, dass openzzz gemeint hat, die Differenz DHHN92 zu WGS84 sei <1 m.

Nahmd,

Allen Unkenrufen zum Trotz: bei niedrigem Horizont ist die per GPS gemessene Höhe überraschend gut.

Unterwegs zeichne ich barometrisch auf und normalisiere die Höhenwerte im Track daheim anhand der Punkte mit (woher auch immer) bekannten Höhen und dazwischen angenommenen linearen Verlauf des Basisluftdrucks.

Die damit gewonnen Werte haben vielleicht ±10m Fehler, meist deutlich darunter.

Und natürlich trage ich diese Werte ein. Woher sollen die Werte denn sonst kommen? Nicht jeder weglose Übergang und nicht jede Wegweisertafel enthält eine Höhenangabe. Und wenn, dann das ist die Höhe auch gerne einer Karte entnommen und hat dann Höhenliniengenauigkeit (±20m).

BTW: ich hab auch schon versucht, den im “Basislager” konstanter Höhe kontinuierlich aufgezeichneten Luftdruck zur Korrektur zu verwenden, das führt aber zu keinem besseren Ergebnis. Bei langsamer Luftdruckänderung tun sich beide Methoden nichts, und plötzliche Luftdruckänderungen bei Wetterkapriolen geschehen in der Referenzstation zu einem anderen Zeitpunkt als draußen.

Dann hatte ich die Idee, die barometrischen Höhen aus dem Track mit den SRTM-Daten zusammenführen, um den Einfluss des Luftdruckes herauszurechnen. Kalman für Arme. Bin ich aber schon bei den Vorüberlegungen gescheitert. :frowning:

(Das wäre was für die Vermessungs-Profis: wenn man die hunderttausende hochgeladenen Tracks mit den Höhendaten von SRTM oder ASTER ausgleichte, hätte man ein feineres Höhenmodell mit Stützstellen entlang der begangenen und befahrenen Wege. Das was die Router brauchen.)

Gruß Wolf