Höhenmesser mit Smartphone-Integration

dieterdreist · 2020-04-29T23:38:35.000Z

kreuzschnabel:

Dann fehlt mir auch ein wenig das Vertrauen in diese Methode, und ich kann gleich GPS-Höhen hernehmen

naja, bei der GPS Höhe sind zig Meter eine erwartbare Ungenauigkeit, die barometrischen Höhenmesser behaupten sub-meter (relative) Genauigkeit

kreuzschnabel · 2020-04-30T06:57:37.000Z

dieterdreist:

bei der GPS Höhe sind zig Meter eine erwartbare Ungenauigkeit

Meine GPS-Höhen liegen normalerweise so ± 10 m neben den in der Topographischen Karte angegebenen¹. Hängt natürlich von der Empfangsqualität ab, mitten im Wald ist die Abweichung größer.

dieterdreist:

die barometrischen Höhenmesser behaupten sub-meter (relative) Genauigkeit

Relative Genauigkeit glaube ich gern, aber die relative Höhe nützt dir nicht viel. Absolute sub-metergenaue Messung geht nur, wenn ein hochwertiger Sensor drin ist (dessen Messwert sich z.B. nicht mit der Temperatur ändert) und das Gerät auf 0,05 hPa genau auf den aktuellen lokalen meteorologischen Druck eingestellt ist. 1 hPa Druckdifferenz entspricht hier unten rund 8 m Höhendifferenz. Das METAR des nächsten Flughafens liefert i.d.R. nur einen auf volle hPa gerundeten Wert, der sich darüber hinaus auf die ICAO-Standardatmosphäre bezieht und nicht auf die tatsächliche, die (abhängig von der Luftfeuchte) einen anderen Druckgradienten aufweisen kann.

Du kannst natürlich versuchen, eine unbekannte Höhe rein relativ zu messen, indem du den Höhenmesser an einem Punkt mit bekannter Höhe auf diese einstellst und dann auf den unbekannten Berg steigst. Das ist bei konstantem met. Druck beliebig genau, aber in den zwei Stunden, bis du auf Berg x stehst, kann sich der meteorologische Druck auch schon so weit ändern², dass du wieder 10 oder 20 Meter daneben liegst.

Exakte barometrische Höhenmessung geht, ist aber alles andere als trivial, selbst mit präzisen Messmitteln.

–ks

¹ Gerade mal am gestrigen Track nachgesehen: Diese Kreuzung ist laut TK25 425 m hoch. Mein Track zeigt beim Abmarsch 427 m, bei Ankunft 413 m. Gemittelt ist das doch gar nicht schlecht
² Meine nächstgelegene Messstation mit Luftdruck für die zurückliegenden 24 Stunden. Seit 2 Uhr kontinuierlich um 3 hPa gefallen. Das ist vollkommen normal.

kreuzschnabel · 2020-04-30T07:28:06.000Z

Entschuldigt, falls ich mich bei dem Thema etwas echauffiere, aber wenn ich mir nur mal diese beiden Nodes anschaue:

https://www.openstreetmap.org/node/2413308
https://www.openstreetmap.org/node/663752

… und die Autobahn dort kenne, die garantiert keine 42 Meter Höhenunterschied zwischen den Richtungsfahrbahnen aufweist, dann ärgert mich einfach so ein komplett unbrauchbarer Müll in der Datenbank

–ks

Bernhard_W · 2020-04-30T08:01:42.000Z

Dann aber bitte den Wert von 2413308 nehmen, der ist schließlich auf 1 nm genau angegeben. (1/500 der Wellenlänge des sichtbaren Lichts)

seichter · 2020-04-30T08:13:29.000Z

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 ;).

Bernhard_W · 2020-04-30T11:56:53.000Z

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.

Bernhard

Edit: Tippfehler korrigiert

Bernhard_Hiller · 2020-04-30T17:43:12.000Z

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.

kreuzschnabel · 2020-04-30T17:47:51.000Z

Bernhard Hiller:

@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

–ks

shammat · 2020-04-30T17:57:27.000Z

Bernhard Hiller:

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.

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).

openDEM · 2020-05-01T16:02:33.000Z

Hier gibt es mehr Infos zum Thema:
https://opendem.info/gps_barometer.html
Es ist leider nicht so einfach vernünftige Ergebnisse zu erhalten.

toc-rox · 2020-05-02T04:42:38.000Z

Bernhard Hiller:

Smartphones verfügen zwar meistens über GPS, aber fast nie über einen barometrischen Höhenmesser.

Der Aussage schließe ich mich nicht an, da sehr viele Samsung-Geräte (und etliche andere (Top-) Smartphones) ein Barometer enthalten.

Hier sieht man mal was ein Smartphone-Sensor (Gerätelage nicht verändert) so misst (Messzeitraum circa eine Stunde):

hav5B4L.png1920×1080 43 KB

Bernhard_Hiller · 2020-05-02T16:12:31.000Z

shammat:

bei der Höhenmessung angeben wie stark die Werte geglättet werden

Das wird schwierig, enn ich sowohl durch recht flaches Land als auch durchs Hügelland radle: im flachen Bereich wird dann arg viel weggemacht.

toc-rox:

da sehr viele Samsung-Geräte (und etliche andere (Top-) Smartphones) ein Barometer enthalten

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.

geow · 2020-05-02T17:16:09.000Z

kreuzschnabel:

Ich hatte mal ein LG G6 mit eingebautem Baro-Sensor. AFAIR konnte OsmAnd nicht mal den verwenden.

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.

Ich habe mal für OsmAnd eine Ergänzung angeregt: https://github.com/osmandapp/OsmAnd-ios/issues/673

Edit: GitHub-link

SimonPoole · 2020-05-03T06:30:53.000Z

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).

toc-rox · 2020-05-03T07:20:07.000Z

Bernhard Hiller:

Werde mir aber erst in etlichen Jahren ein anderes Gerät zulegen, muß dann halt mal schauen, wie ich mit den Defiziten zurecht komme.

Verstehe ich nicht so richtig. Was für Defizite meinst du?

dieterdreist · 2020-05-03T07:53:27.000Z

SimonPoole:

und das ist auch nicht das erste Mal wo das diskutiert wird).
Offline

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

SimonPoole · 2020-05-03T08:47:29.000Z

dieterdreist:

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

Du hast den Punkt nicht verstanden.

PS: dein Proposal ist auch noch falsch, EGM96 bestimmt ein Geoid also ~MSL und nicht das Ellipsoid, siehe auch https://en.wikipedia.org/wiki/Earth_Gravitational_Model

kreuzschnabel · 2020-05-03T09:28:02.000Z

dieterdreist:

Wenigstens ist es seit einigen Jahren explizit festgelegt, dass ele die WGS84 Höhe beschreiben soll.

Dann korrigiere doch gleich mal den kompletten Schwarzwald um 50 Meter nach oben. Das wird Freude bei den -städtern auslösen, wenn der Kniebis über 1000 m liegt
https://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel#Ellipsoidische_H%C3%B6he_(GPS)

–ks

dieterdreist · 2020-05-03T10:13:02.000Z

SimonPoole:

Du hast den Punkt nicht verstanden.
PS: dein Proposal ist auch noch falsch, EGM96 bestimmt ein Geoid also ~MSL und nicht das Ellipsoid, siehe auch https://en.wikipedia.org/wiki/Earth_Gravitational_Model

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

streckenkundler · 2020-05-03T10:13:51.000Z

dieterdreist:

Wenigstens ist es seit einigen Jahren explizit festgelegt, dass ele die WGS84 Höhe beschreiben soll.

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.

Aktuelle brandenburger Geodaten dürfen mittlerweile vollständig im DHHN2016 (EPSG-Code 7837) vorliegen.

Sven

PS: auf der Wiki-Seite zu ele sollte der epsg-Code mit erfasst werden.