Wie haltet ihr es mit Höhenangaben ?

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

Nahmd,

:smiley: :laughing: :sunglasses:

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. :sunglasses:

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.

Aber genau das vermurkst die OSM-Karte.

Die ele= Werte werden auf die Karte als Berghöhen geschrieben. Das muss einheitlich sein. Der Zustand jetzt ist doch unhaltbar. Da konfiguriert man auf Gebrauchshöhen und hat in Irland doch wieder ellipsoide Höhen.

Das muss klar definiert werden, entweder als “Gebrauchshöhe”, also lokale Höhe, ellipsoide WGS84-Höhe oder geoide WGS84-Höhe.
Wenn sich alle daran halten kann man auch Karten danach zeichnen.

Was meinst du was ich von meiner topografischen Karte halten würde, wenn man sich auf die Höhenangaben da nicht mehr verlassen könnte.

Nun, was ist zu machen? Vermutlich macht es am meisten Sinn, die ele-Höhe wie im Wiki angedeutet als
WGS84-Geoid-Höhe zu definieren. Das passt zum NMEA-Standard und wäre eine weltweit durchsetzbare Definition
und würde Konsistenz im Datenbestand ermöglichen. Auch sonst ist OSM bei den 2D-Koordinaten im WGS84-Modell
festgelegt und nicht in den länderspezifischen Systemen (Gauß-Krüger, Lambert, ED50, etc.).

Ich vermute zum DHHN92 ist der Unterschied so klein (< 1m), dass wir ihn mit OSM-typischer Genauigkeit
vernachlässigen könnten. Lediglich die Iren müssten dann von ellipsoider zu geoider Höhe konvertieren.

Moins,

”Muss”, “sollte”, ”verlangen”, “geht nicht” … hey! Das ist schlecht für den Blutdruck!
Mach daraus ein “kann”, “wäre schön, wenn”, “kann man bitten”, “wäre schön, wenn nicht”, und Du lebst gesünder.

Bitte akzeptiere einfach, dass “ele” ein Feld ähnlich wie “name” ist und nichts mit irgendwelchen Elliposioden, Geoiden oder was auch immer zu tun. Oder vielleicht auch irgendwie schon. Oder doch nicht? Sind wir nicht alle ein bisschen?

Du vergeudest an dieser Stelle Deine Energie und schadest Deiner Gesundheit. Und das ist doof! Denn ich geh davon aus, dass Du sehr kompetent bist, wir brauchen kompetente Mitstreiter, und deshalb hoffe ich (ganz egoistisch), dass Du uns länger erhalten bleibst!

Gruß Wolf

In meiner Gemeinde gibt’s mittlerweile über 300 ele:NHN Knoten.

Jetzt müsste mir zur Kontrolle und Visualisierung nur noch jemand eine Karte bauen,
welche das Straßennetz anzeigt, wobei die Segmente je nach Steigung
gefärbt sind. :sunglasses:

Edit: Update der Anzahl

Du solltest zusätzliche Tags “ele” anlegen, ansonsten haben nicht alle was davon.

Gruß Klaus