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 
Grüße, Max
Nahmd,
Gruß Wolf
Tja, das ist eben die Informationsgesellschaft. Wenn alles vernetzt wird muss man Standards harmonisieren. Sonst kommt so ein Murks raus, dass OSM entweder in Irland oder in Deutschland falsche Werte anzeigt. Wie die armen Mapper das vor Ort eintragen ist natürlich ein anderes Problem. Da sollten auch die Editoren Unterstützung liefern, dass man dort sein “Eingabesystem” konfigurieren kann. Muss ja gar nicht der Aufwand sein, dass für jede Angabe nach dem System gefragt wird, sondern per Default nach dem Motto “ich pinne nur von Schildern ab” oder “ich lese von meinem Gerät ab”. Aber selbst da sollte sich der Mapper klar sein welche Höhen sein Gerät genau anzeigt. Sonst würde man Äpfel mit Birnen vergleichen. Ein bisschen Mitdenken kann man auch vom Mapper verlangen. Dass wir bei Eingabe und bei der Kartenansicht “Gebrauchshöhen” also DHHN92 anzeigen ist ja wohl Konsens von allen. Darum verstehe ich deinen Einwand nicht. Aber Informationssysteme brauchen eben klare Standards. Es geht nicht, dass die Iren einen anderen Standard als Deutsche für die gleiche Datenbank und das gleiche Datenfeld benutzen.
p.s. was haben die Bugs in den Geräten mit den OSM-Mappern zu tun?
Da wird seit Jahren im Umgang mit dem NMEA-Standard geschlampt. Ich will auch ohne OSM meine Höhe mit der Topo-Karte vergleichen können.
Das bisher einzig verlässliche ist die amtliche Topo-Karte, weil die Vermessungsingenieure streng ein Höhenmodell konsequent umgesetzt haben.
Lustig, nach 2 Posts habt ihr schon ein System durcheinandergebracht.
Meine Frage war nach dem Unterschied von WGS84 Höhe über Geoid zur DHHN92-Höhe. Das sind keine 45m.
WGS84 definiert zwei verschiedene Höhen, einmal die Höhe über WGS84/EGM96 Geoid und einmal Höhe über WGS84-Referenzellipsoid (GRS 80-Nachfolger). NMEA aus den GPS-Geräten liefert erstere. Ob Garmins daraus nochmal ein DHHN92 approximieren weiss ich nicht. Manche Consumer-Geräte liefern auch letzteren Wert, wobei das aber dem Standard widerspricht. Darum hat GPS-Software oft noch eine Korrektureinstellung als Workaround gegen diesen Fehler.
Bald ist ja Weihnachten:
Den Deutsches Kombiniertes Quasigeoid 2011 gibt’s im Online Shop für schlappe 750 Euros.
Moin,
ich würde mich eher mal von dem Gedanken lösen, jemals “definierte” Werte in ele=* vorzufinden.
Max hat die Ursache dafür völlig korrekt beschrieben - das bleibt bei PI*Auge.
Für definierte Werte gibt es die ele:xyz=*
Denn wenn sich “die Mapper” schon so technische Gedanken machen (müssen), kann man das auch gleich im Tag festhalten.
Dann kann wenigstens jeder “sein” Bezugssystem mit angeben - und alle können etwas damit anfangen.
Vor allem: Der Wert wird nicht gleich wieder vom nächsten “Feld-Wald-Wiesen-Mapper” (*) korrigiert!
“Auf dem Schild vor Ort steht doch was Anderes!” - was weiß der “Feld-Wald-Wiesen-Mapper” schon, auf welchem Standard die Angabe beruht.
Gruß
Georg
(*) Ist jetzt absolut nicht abwertend gemeint - bezüglich Höhenangaben würde auch ich selbst alles in ele verwursten, was ich so vor Ort finde.