Höhenmesser mit Smartphone-Integration

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.

kreuzschnabel · 2020-05-03T10:42:15.000Z

streckenkundler:

Meiner Meinung nach sind Höhenangaben ohne Angabe des Höhensystems nicht, oder kaum zu gebrauchen.

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

–ks

SimonPoole · 2020-05-03T10:50:27.000Z

kreuzschnabel:

streckenkundler:

Meiner Meinung nach sind Höhenangaben ohne Angabe des Höhensystems nicht, oder kaum zu gebrauchen.

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.

Auch der Meinung, die Höhensysteme unterscheiden sich nur wenig.

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.

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.

…

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

Siehe oben (GPS Höhe wird massiv anders sein als die aus Höhenlinien).