Wie haltet ihr es mit Höhenangaben ?

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

Ach so. Nee, wir müssten uns schon die Werte bei amerikanischen Behörden im 15-Minuten-Raster für umsonst holen oder bei unserem Staat im 1-Minuten-Raster kaufen :wink:

Max, von 45.96m über dem Ellipsoid (kostenlos) oder 46.5m (kostenpflichtig) grüßend

Was habt ihr immer mit “Meinungen”?
Es geht hier um Definitionen.

http://en.wikipedia.org/wiki/World_Geodetic_System

“Presently WGS 84 uses the EGM96 (Earth Gravitational Model 1996) geoid, revised in 2004. This geoid defines the nominal sea level surface by means of a spherical harmonics series of degree 360 (which provides about 100 km horizontal resolution).[7] The deviations of the EGM96 geoid from the WGS 84 reference ellipsoid range from about −105 m to about +85 m.[8] EGM96 differs from the original WGS 84 geoid, referred to as EGM84.”

WGS84 definiert also sehr wohl die Korrektur zu einem Geoiden.
Es gibt also WGS84-Geoidhöhen und WGS84-Ellipsoidhöhen.
Nur ist das noch nicht die exakte Höhe nach DHHN92.

So ganz habe ich aber noch nicht raus, ob der Unterschied WGS84-Geoidhöhe zu DHHN92-Höhe wirklich für OSM praktisch von Bedeutung ist, also <1m.

Ich bin kein Geodät. Haben wir uns richtig verstanden? Das WGS84-Geoid ist doch an
das Schwerefeld der Erde angeglichen und damit “quasi” über Meeresspiegel,
anders als der WGS84-Ellipsoid. Ist dann trotzdem der Unterschied noch so groß?

“Geoidundulation” ist doch der Unterschied Geoidhöhe zu Ellipsoidhöhe und nicht
der Unterschied zwischen verschiedenen Geoidmodellen.

So in etwas meinte ich das mit “hilfsweise in Ausnahmefällen”.

Gruß Klaus

Offensichtlich ist nicht jeder unserer Meinung, wie weit die Definition verbindlich ist. Selbst Hersteller von Navigationsgeräten scheinen unterschiedlicher Ansicht zu sein, welche Teile der Definition auch in ihren Geräten berücksichtigt werden sollen.

Ist es überhaupt sinnvoll, überhall Höhen zu mappen? Vollständigkeit wird die Karte so ohnehin nicht bekommen und zuverlässig scheint es auch nicht zu sein. Interessant ist es bei Bergen, damit es auf der Karte erscheint. Fürs Fahrrad-Routing, Höhenlinien und hillshading muss man externe Höhendaten heranziehen. OSM-eigene Höhen wären dafür nur tauglich wenn sie eine gewisse Vollständigkeit haben. Dafür ist OSM gar nicht ausgelegt, denn dafür müssten alle Koordinaten in 3D gespeichert werden, nicht nur einzelne ele-Tags.

Geoidkorrektur kostet halt. Daran erkennt man Hersteller die jeden Cent einsparen wollen.
Garmin macht es in der Regel, Android-Handies oft nicht.

Ich weiss. Die Nachlässigkeit gibt’s nicht nur bei OSM, sondern auch bei bekannten Herstellern.
Das ist aber keinen Grund, solche Bugs als Normalzustand zu akzeptieren.
Man muss eben immer wieder betonen, Datenformate korrekt zu definieren.
Bei NMEA-Chips gibt es machmal die Möglichkeit, die Korrektur ein/auszuschalten.
Der NMEA-Standard ist aber eindeutig, dass Höhe eine WGS84-Geoidhöhe ist.
Als 2. Stufe gibt es dann noch eine Korrekturmöglichkeit in der Software, die NMEA-Daten
verarbeitet. Aber der muss man dann auch wieder sagen, wenn der Chipset falsch liefert.

Nein, Die Angaben auf Schildern sind oft ungenauer. Ich habe an verschiedenen Berggipfeln die Höhe per GPS gemessen. Es hängt zum Teil auch vom GPS Gerät ab, manche sind genauer manche nicht. Gute Erfahrungen habe ich mit den Garmin eTrex (10/20) gemacht deren Höhenmessung recht genau ist. Dabei habe ich auf Berggipfeln meist weniger als 3 Meter Abweichung von dem was topografische Karten sagen. Auf Berggipfeln ist der Empfang auch meist recht gut. Anders sieht es natürlich an anderen Punkten aus, die zum Beispiel in Schluchten liegen. Da ist der Empfang zu schlecht.

In der Soierngruppe im Karwendel gibt es eine ganze Reihe von Höhenangaben auf Schildern. Bei diesen habe ich eine deutliche Ungenauigkeit (festgestellt durch mehrfache Messung mit verschiedenen Geräten und zwar barometrisch und GPS) festgestellt, die über die Ungenauigkeit meines GPS definitiv hinaus geht. Manchmal ist also die Angabe des GPS besser, als die die auf einem Schild steht.

Gruß
unixasket

Dann hatte ich das falsch aufgefaßt. Dann korrigiere ich mich auf: Der irische Ansatz, nur umgekehrt mit ele für die Otto-Normaluser-Höhe.

bye, Nop

Nahmd,

Relevanzdiskussion, ick hör Dir trappsen.

Gruß Wolf

Ich hab’s mal hierhin umgeleitet

http://www.sapos.de/pdf/5symposium/145-163_westendorff.pdf
"Satellitengeometrie und -bahnfehler:
Naturbedingt können bei der Positionsbestimmung am Erdboden Satelliten nur oberhalb
des Antennenstandpunktes beobachtet werden. Diese Tatsache führt zu einer gegenüber
den Lagekomponenten um mindestens Faktor 2 schlechteren Höhengenauigkeit (Santerre
1991). "

Das ist eigentlich die beste geometrische Erklärung für die mangelnde Höhengenauigkeit. Eine Halbebene wird abgeschattet und darum sind die Sat-Emitter senkrecht dazu weniger räumlich verteilt. Im Extremfall, wenn die Emitter ganz in einer Ebene liegen würden hätte man die schlechtmöglichste Höhenbestimmung, also im Prinzip gar keine mehr. Das ist so als wenn alle Sats in einer Linie stehen würden, wo dann auch 2 Dimensionen verloren gehen. Damit könnte dann bestenfalls noch ein Winkel bestimmt werden, aber keine Ortung mehr.

Du beschreibst es eigentlich schon völlig richtig. Ein Mappen ist nur für bestimmte Stellen/Objekte sinnvoll, bei denen die punktuelle, absolute Höhe eine Rolle spielt (Berge, Pässe, Ortschaften, Meßpunkte…).

Für Routing usw. braucht man einen flächigen Verlauf und oft nur die Höhenunterschiede, dafür sind gemappte Höhen nutzlos.

bye, Nop

OK, weil für die z-Komponente nur 180° zur Verfügung stehen, für x und y aber 360°, ist die statistische Verteilung für die horizontalen Werte günstiger, d.h. die Satelliten stehen öfter in günstiger Position. Das gibt aber nur einen Faktor von etwa 2, die Höhenschwankungen, die ich beobachtet habe, waren aber deutlich größer. Theoretisch sollten die Höhen viel langsamer variieren als die Horizontalen (Kunstflug und Raketenstarts mal ausgenommen), das habe ich bisher aber nur bei einem barometrisch unterstützten Gerät (Garmin Oregon) gesehen, bei den anderen gab es in der Ebene schön glatte Tracks, während die Höhe deutlich zappelt. Tracks auf Abwegen sahen oft für sich gar nicht schlecht aus, nur die Höhenwerte wanderten unmotiviert nach oben oder unten aus.

Ja, subjektiv fand ich auch bisher alles relativ ungenau in der Höhe, schlimmer als Faktor 2. Aber ich hatte das nie systematisch untersucht. Ich hatte auch viele verschiedene Geräte benutzt, GPS-Mäuse, externe GPS-Logger, Pocket PC (SIRF-2), Auto-Navi (SIRF-3), Android (gpsOne) … Die haben eben alle ihre Eigenheiten. Ich vermute oft wenn man über die GPS-Höhe meckert liegt es auch am falschen Höhenmodell. Dazu kommen noch die verschiedenen Einstellmöglichkeiten zur Geoid-Korrektur, sowohl im Chipset (per serielles Kommando) als auch in der App. Bei diesem Chaos hab ich nun überhaupt keinen Überblick mehr wo im Einzelnen die möglichen Fehlerquellen liegen. Im Zweifel in den Alpen habe ich mich einfach auf die Papierkarte verlassen. In den Bergen ist Multipath ohnehin ein KO-Kriterium für die GPS-Ortung. Auf dem Gipfel sollte es bei wunderbarer Satelliten-Sicht wieder genau sein. Mit kleinen Kindern gibt’s aber normalerweise keine Gipfelkletterei.

Du hattest mal vermutet dass in der Höhe weniger gemittelt wird. Bisher hatte ich keine Hinweise, dass die Höhe da irgendwie anders behandelt werden soll. Rechnerisch arbeitet man erstmal in kartesischen ECEF-Koordinaten (erdmittenzentriert), wo die Höhe sowieso keine bestimmte Achse hat. Eine echte Mittelung gibt es auch nicht, sondern die zuverlässigere Kalman-Filterung. Was nur passieren kann: wenn es nur 3 Sats gibt reicht es nicht für eine 3D-Ortung. Dann ist aber eine 2D-Ortung möglich. Ich weiss nicht, was der Chip dann mit der Höhe macht (leeres NMEA-Feld? Geoid-Höhe als Default?).

Interessant an moderneren Chips ist wohl, dass neben GPS auch Glonass-Satelliten empfangen werden. Mit der höheren Sat-Zahl sollte dann auch die Höhenmessung besser funktionieren. Die Russen haben ihre Sat-Orbits 10° höher inkliniert als GPS, gut für die Genauigkeit in höheren Breitengraden.

Mein billiges Samsung mit gpsOne-Chip von Qualcomm hat eine Geoid-Höhe im entsprechenden
NMEA-Datenfeld (mit “NMEA Recorder” App gesichtet).

Ich habe nur nicht herausbekommen, ob dieses NMEA direkt vom GPS-Chip gpsOne ausgelesen wird,
so wie bei den SIRFs über einen seriellen Port, oder ob es andere Schnittstellen gibt und NMEA
lediglich vom Android-Betriebssystem in der API simuliert wird.

Merkwürdig fand ich das GPGGA-Feld zur geoid separation, dass nicht die erwarteten 47m zeigt,
sondern 100m, als ob das die Höhe über Ellipsoid wäre.

Die Apps gehen auch unterschiedlich heran. Die App “GPS Test” zeigt mir die Höhe über Geoid,
nach NMEA-Standard, “GPS Status” ca. 50 m mehr. Orux wieder die NMEA-Höhe und OsmAnd
wieder einen zu hohen Wert. Aber was das alles ist, welche Systeme, darüber gibt es nichts
in den Datenblättern.

Es wäre schön, wenn sich die Chipsätze, Hersteller und App-Programmierer einfach
mal stur an Definitionen halten würden. Dann hätten wir das Chaos nicht.
Netzwolf mag das ja alles lustig finden, als “Dookratie”. Aber mich nervt das total.
Den Ingenieuren und Programierern dürfte es zumutbar sein, vor der Arbeit einmal
die Definitionen der Datenfelder zu checken. NMEA ist da sehr eindeutig, als Höhe über WGS84-Geoid.
Alles andere könnte man umrechnen, wenn die Datengrundlage konsistent ist.

Ich finde diese Diskussion auch lustig, sowas passiert, wenn sich Fachleute über die echte Welt unterhalten.

Für 95% der Mapper und 99.9% der Bevölkerung sieht eine Höhenangabe so aus:

ältere Leser werden vielleicht so etwas vor Augen haben:

Da steht kein Höhenbezugssystem, da ist auch keine Stellschraube am Barometer für WGS/NHN/MüA/NN. Die Leute kennen das gar nicht und die tragen das auch nicht ein (Irland hat das ja auch nicht durch mappen, sondern einen Import bekommen). Die nehmen einfach die 510 aus dem Höhenmesser oder die 1808 vom Schild und tragen das bei ele ein. Zum Glück lesen sie vorher nicht das Wiki und lassen sich verwirren :wink:

Grüße, Max