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.
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.
Edit: Update der Anzahl
Du solltest zusätzliche Tags “ele” anlegen, ansonsten haben nicht alle was davon.
Gruß Klaus
Hallo Chris,
Sehr schön.
http://wiki.openstreetmap.org/wiki/Key:ele:NHN so und nur so wird ein Schuh draus. Was noch schön wäre, ist ein Verweis im Wiki auf den entsprechenden EPGS-Code: 5783. Da in Deutschland nur relativ wenige verschiedene Höhensysteme auftreten (können), sollte mann diese auch gleich mit tabellarisch nennen.
Sven
1+
(auch für nur einmal “müssten”)
Weltweit zu denken finde ich nicht nur bei OSM wichtig.
So schreibt man keine Standards. “Wäre schön, wenn ihr die IP-Adresse als 128 Bit auslegt”. Meine Güte, das Internet würde zusammenbrechen, wenn jeder das auslegt wie er will. Die OSM-Karte ist zwar nicht so elementar, aber wenn ein Deutscher in Irland 50 Meter weiter als erwartet zum Gipfel klettern muss ist das auch nicht gut für den Blutdruck 
Man kann sich den Murks auch schönreden. Es wäre schön, wenn OSM sich etwas am Anspruch der topografischen Karte orientiert, wo man sich auch auf ein einheitliches korrektes Koordinatensystem verlassen kann.
Wir schreiben keine Standards. Wir wenden sie an und die verwendeten Tags und Werte müssen ausreichend und nachvollziehbar dokumentiert werden und bereits etablierte Standards sollten so gut es geht ver- und angewendet werden.
Siehe auch Vorschläge und Umsetzungen zu den Höhenangaben: hier, hier und hier.
Sven
Doch, projektinterne Standards. Die Straßentypen sind auch OSM-intern durchstandardisiert. So ist garantiert, dass aus einer Autobahn in der Datenbank eine Autobahn in der Karte wird. In den Anfängen waren die Straßenkategorien nicht so ganz klar definiert, was an länderspezifischen Unterschieden lag. OSM hat seinen Ursprung halt in England. OSM kann aber international nur funktionieren, wenn man sich auf Standards einigt. Der Betrachter ist zwar meist auf ein Land fixiert, aber die Software (Renderer, Smartphone-Apps, Routingapps) muss exakt wissen wie die Daten zu interpretieren sind. Es wäre doch schade, wenn eine OSM-App nur in Deutschland funktioniert und in England wieder eine Neue installiert werden muss.
Nahmd,
Das Wiki enthält keine Standards. Das Wiki enthält freundliche Empfehlungen.
OSM gibt es schon ein paar Jahre. Und ist noch nicht zusammengebrochen. Es wächst und gedeiht.
(Hervorhebung durch mich)
Wer sagt’s denn? Du bist auf dem richtigen Weg.
Wäre schön™, wenn Du so weitermachst.
Gruß Wolf
BTW: es wäre auch schön, wenn die Bearbeiter nur korrekte Tags und Values verwenden würden, dann bräuchte Oli-Wan nicht den Aufwand in den Aufräum-Robot zu stecken. Es wäre auch schön, wenn die API Konsistenzkriterien durchsetzen würden, z.B. nodelose oder minderbenodete Ways zurückweisen und defekte “type=multipolygon” Relationen ablehnen. Es wäre auch schön, wenn mehr Hausnummern erfasst würden, das würde hausnummerngenaues Routing erlauben. Wäre auch schön, wenn mehr lanes erfasst würde, das würde OSM-Navisoftware das “rechts halten, dann links halten” erlauben.