Ich gehe mal zurück zur ursprünglichen Frage:
Barometrische Unterstützung ist gut dafür geeignet, den Höhenverlauf eines Tracks vernünftig darzustellen.
Höhenmessungen mit einem Consumer-GPS-Gerät egal auf welche Art sind nicht dafür geeignet, absolute Höhen in Meter-Genauigkeit für OSM-nodes zu erstellen.
Das sollte man auseinander halten.
Wenn man so eine Angabe z.B. als Anhaltspunkt für einen Gebirgspass machen möchte, gehört die Quelle (source=GPS oder source=DEM) dazu.
Bei Punkt 2413308 wäre es eher source=calculator output in double precision ;).
Mein altes Smartphone Samsung Galaxy S3 (I-9300) enthält einen Drucksensor (LPS331AP von STMicroeletronics).
Barometer- und Höhenmesser-Apps zeigen eine Schwankung von ca. 1 m (niederfrequentes Rauschen). Damit kann man ziemlich gut die Höhendifferenz zwischen zwei Punkten bestimmen, die man innerhalb kurzer Zeit erreichen kann (Gebäude, Hügel, Damm, …)
Wie kreuzschnabel bereits geschrieben hat, ändert sich der Luftdruck ständig. Über einen größeren Zeitabstand wird die Messung ziemlich ungenau.
OsmAnd hat diesen Sensor vermutlich noch nie benutzt. Ich kenne dazu auch keinen Menüpunkt.
Um die Vor- und Nachteile barometrischer Höhenmessung ging es mir nicht - mein im Zerfallen begriffenes Garmin Oregon besitzt einen barometrischen Höhenmesser. Ich bin viel mit dem Rad unterwegs, durchaus im hügelligen Land, und da ist der aufsummierte Bruttoanstieg einer Tagestour ungefährt so interessant wie die Tageskilometer.
Immerhin entnehme ich der Diskussion hier, daß es solche Teile nicht als Smartphone-integrierbare Zusatzteile gibt, und viele Äpps nicht mal mit Höhenmesser, die bereits im Gerät eingebaut sind, zurecht kommen. Schade.
@ks: du kennst sicherlich den Weg von Matinsthal an der B260 hinauf nach Wambach, dann links ab bis zur “Paßhöhe” hinter Bärstadt: das geht - mit einer kleinen Ausnahme innerhalb Schlangenbads (als Radfahrer ziehe ich das der B260 vor) “streng monoton” bergauf. Laut GPS-Höhe ist das ne Berg- und Talbahn.
Hast gewonnen das ist aber gerade zwischen Schlangenbad und Wambach ein so schmales Tal, dass GPS denkbar schlechte Voraussetzungen hat, während der Luftdruck in voller Güte vorliegt. Unfairer Vergleich
Ich verwende LocusMap als Ersatz für mein altes Oregon.
Dort kann man bei der Höhenmessung angeben wie stark die Werte geglättet werden sollen.
Ich habe bei den ersten Bergtouren mit LocusMap sowohl mein Smartphone als auch das Oregon dabei gehabt und beide mitlaufen lassen. Mit der Einstellung “Sehr starker Filter” bei der Glättung, kamen dann am Ende im Prinzip die gleichen Höhenmeter bei beiden Geräten raus (+/- 50hm).
Das wird schwierig, enn ich sowohl durch recht flaches Land als auch durchs Hügelland radle: im flachen Bereich wird dann arg viel weggemacht.
Dann habe ich wohl daneben gegriffen. Werde mir aber erst in etlichen Jahren ein anderes Gerät zulegen, muß dann halt mal schauen, wie ich mit den Defiziten zurecht komme.
Ob und wie die Daten der Drucksonde mit den GPS-Höhendaten verheiratet und per API bereitgestellt werden, habe ich heute mal mit einem iPhone SE (2020) und OsmAnd und Mapout getestet. Als Vergleich dienten zwei jeweils etwa 5 Minuten bei mittelprächtigen Bedingungen stationär aufgezeichnete Tracks.
Ergebnis laut gpx-Daten: Die Spreizung der Höhenwerte lag bei OsmAnd bei rd. 7 m, bei Mapout bei 1 m.
Daher vermute ich, dass iOS sowohl die GPS-Rohdaten (genutzt von OsmAnd) als auch die per Barometer kalibrierten und geglätteten Höhendaten (von Mapout verwendet) zur Verfügung stellt.
Also rein praktisch ist das grösste Problem bei den Höhenangaben in OSM, dass fleissig NN/MSL Daten (sprich, dass was man an Schildern etc abliest) mit Höhe über dem WGS84 Ellipisoid vermischt werden, siehe auch https://wiki.openstreetmap.org/wiki/Altitude
M.a.W. man kann all die anderen Überlegungen in die Tonne treten solange das nicht gelöst ist (und das ist auch nicht das erste Mal wo das diskutiert wird).
Wenigstens ist es seit einigen Jahren explizit festgelegt, dass ele die WGS84 Höhe beschreiben soll.
Wer einfach Höhen von Schildern abschreiben will ohne sich über den Bezug Gedanken zu machen, kann ele:regional verwenden. https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional
danke für den Hinweis, das war auch der Grund weshalb das noch im draft modus war, ich war mir da nicht ganz sicher welche der Angaben passt. Ist aber für das Proposal auch nicht wichtig.
Ich dachte Dein Punkt wäre gewesen, dass in “ele” alle möglichen Bezugshöhen verwendet werden/wurden. Daher halte ich es für zielführend, wenn man durch einen expliziten tag die Möglichkeit schafft, das einzutragen was man ohne weiteres Wissen und Umrechnung vor Ort vorfindet. Dadurch wird auch die Aufmerksamkeit der Leute erhöht, dass es diese Unterschiede überhaupt gibt. Vielleicht sollte man zusätzlich noch ele:wgs84 einführen. Sieh mal an, das machen schon ein paar: https://taginfo.openstreetmap.org/keys/ele%3Awgs84
Meiner Meinung nach sind Höhenangaben ohne Angabe des Höhensystems nicht, oder kaum zu gebrauchen. Es ist nicht sichergestellt und kann nicht sichergestellt werden ob das Höhensystem, welches verwendet werden soll, vom Erfasser auch verwendet worden ist.
Einzig die zusätzliche Angabe des Höhenbezugsystems macht die erfasste Höhenangabe einigermaßen verläßlich.
Unser Wiki im Key ele ist hier übrigens nicht mehr aktuell. Neben den älteren Systemen DHHN12, SNN76, und DHHN92 ist oder wird mittlerweile DHHN2016 eingeführt. Die Unterschiede zu DHHN92 mögen zwar marginal sein, ob es aber überal so ist, kann ich nicht sagen.
Für Geodäten ist das sicher zutreffend. Aber ist für normale Kartennutzer die Angabe „Die Wasserkuppe ist 950 m hoch“ wirklich ohne Angabe des Bezugssystems (fast) komplett unbrauchbar? Es geht hier doch um eine allgemein nutzbare Karte. Es geht nicht darum, ein professionell verwendbares Höhennetz abzubilden. Der Nutzer will die Größenordnung der Bergeshöhe wissen und, wenn er auf der Wasserkuppe steht, um wieviel ungefähr der Heidelstein niedriger ist – alles darüber hinaus ist nice-to-have.
Höhen im ele=* werden nach dem jeweiligen offziellen Höhenbezugssystem angegeben. In Schland also Normalhöhennull (NHN). Das sind „die“ amtlichen Höhen, die sich auch in Nachschlagewerken finden. Das ältere NN und das aktuelle NHN unterscheiden sich nur um Zentimeter; ich halte es für unsinnig, in OSM hier eine Unterscheidung erforderlich zu machen, die niemand wirklich braucht.
Wer explizit ein Bezugssystem angeben will, kann ele:nhn oder so was setzen.
Als Nutzer ist mir für einen noch unbekannten Berggipfel eine per GPS ermittelte oder aus Höhenlinien geschätzte Höhe in der Karte weitaus lieber als gar keine Angabe, auch wenn sie mehrere Meter danebenliegt. Echt! Ich als Präzisionsfetischist, wenn’s um Straßengeometrien geht
Auch der Meinung, die Höhensysteme unterscheiden sich nur wenig.
Eben nicht. ele ist als die Höhe über dem WGS84 Elipisoid definiert (sprich die “GPS Höhe”), dass ist in unseren Landen gut 50m Differenz zu NN/MSL/was auch immer, und das ist tatsächlich relevant.
Es -wäre- sinnvoll gewesen, ele als was halt darauf steht zu definieren (da für unsere Zwecke die NN/MSL Unterschiede nicht wirklich eine Rolle spielen), und für gemessene Werte einen anderen Tag zu verwenden, hat man aber nicht gemacht.
Siehe oben (GPS Höhe wird massiv anders sein als die aus Höhenlinien).
In 2013 wurde die ele Seite geändert um auf EGM86 zu verweisen, was natürlich nichts besser macht.
Nur um die Verwirrung zu vervollständigen: es ist zwar nicht ganz klar vom Standard her, aber alles was ich gesehen habe deutet darauf hin, dass Höhendaten in GPX Tracks auch die Höhe über den Ellipsoid beinhalten. Dies im Gegensatz zu NMEA 0183, dass “MSL” angibt plus die Korrektur zum Ellipsoid.
das ist aber gerade zwischen Schlangenbad und Wambach ein so schmales Tal, dass GPS denkbar schlechte Voraussetzungen hat, während der Luftdruck in voller Güte vorliegt. Unfairer Vergleich 
