Guten Tag zusammen,
ich habe zwei Fragen zu Verarbeitung der Höhendaten in LM:
1) Wenn man bei einer aufgenommenen Strecke die Höhendaten aktualisiert, dann zittert die Höhenlinie im Diagramm immer etwas um um die Trendlinie, so wie in dem Beispiel:
Höhenprofil_Schwankungen.jpg
Das lässt sich wohl bei dem Höhendaten im 90x90 Raster nicht vermeiden, wenn es links und rechts steil hoch und runter geht. Und bei SRTM ist es wegen der schlechteren Qualität dann auch noch schlimmer als bei Lidar, siehe Frage 2.
Nun werden, soweit ich das analysiert habe, die kleinen Schwankungen bei den Höhenmetern Bergauf und Bergab mitgezählt, was die Werte systematisch überhöht.
Um den Effekt abzuschätzen, habe ich mit die DGM1-Daten (1m-Raster) des Ortes besorgt und mit Python ein Skript geschrieben, was die Höhendaten auf der Basis aktualisiert. Damit sieht das Höhenprofil schon viel eher aus wie die Strecke und passt auch sehr gut zu den Höhenlinien in den openandromaps-Karten:
Höhenprofil_DGM1.jpg
Im ersten Bild waren die Höhenmeter jeweils ca. 125m hoch und runter, im zweiten 95m. Also eine erschreckende Überschätzung. Auf dem Gerät sind wohl die SRTM-Daten als Höhendaten hinterlegt. Ich habe auf einem zweiten Geräte ebenfalls die Höhen aktualisieren lassen, dann kamen jeweils 111m raus. Auf dem Geräte sind wohl neuere Höhendaten auf Basis der LIDAR-Messungen heruntergeladen.
Und nun die Frage: Gibt es in LM die Möglichkeit, für die Höhenangaben einen Glättungsmechanismus einzubauen, der optional die Schwankungen rausglättet? Den gleichen Wunsch hätte ich auch für die Geschwindigkeitsangaben im Graphen. Die sind meiner Meinung auch zu volatil, weil die Genauigkeit der GPS-Sensoren zu gering ist.
2) Wie schon geschrieben, habe ich bei der Analyse festgestellt, dass auf den Geräten nicht die gleichen Höhendaten heruntergeladen wurden. Soweit ich verstanden habe, wurden irgendwann die SRTM-Daten durch Lidar-Daten ersetzt, das eine Geräte hatte die Daten vorher gezogen (irgendwann 2023), das andere danach. Nun habe ich geschaut, ob es in der Anwendung irgendwo eine Information über die Daten gibt (ich verwende die Karten von openandromaps). Und ob es eine Möglichkeit gibt, die Höhendaten aus der Anwendung zu aktualisieren. Ich könnte per USB-Kabel mir vom PC den Speicherordner der SRTM-Daten öffnen und die alten Dateien löschen, dann werden die hoffentlich neu geladen. Das kann ich mir aber nicht für Nutzer vorstellen, die technisch weniger versiert sind.
Vielen Dank schon mal für die Informationen!
Claus
Wenn ich es richtig verstanden und den Menschen richtig interpretiert habe, der die Lidar-Daten zur Verfügung stellt, nutzt Locus zur Zeit automatisch dieser höher auflösenden Lidar-Daten noch nicht. Unterscheiden kann man sie, was anderes habe ich noch nicht gefunden, an der Größe der Kacheln, "alte" DTM-Daten meist unter 5 MB pro Kachel, "neue" Lidar-Daten über 20 MB pro Kachel, teilweise sogar über 100 MB. Letztere muss man händisch von Sonnys Seite ( https://sonny.4lima.de/ )herunterladen. Dabei kann man die Daten eines Landes komplett markieren, komplett herunterladen und in einen Rutsch komplett entpacken und anschließend komplett in den STRM-Ordner von Locus kopieren. (Ich habe es jahrelang einzeln gemacht ;) )
Eine Rückfrage: Du hast die exportieren gpx-Daten mit den Python-Script geklättet und dann wieder zurück kopiert? Es läuft kein Script auf den Phone?
Ich habe die hgt-Dateien (Alt und neu) verglichen (von Locus automatisch heruntergeladen). Sie sind gleich groß (2.8 MB), also die gleiche Auflösung (3", 1200 Punkte pro Grad). Locus zeigt bei den neueren Höhendaten bei dynamischer Höhe (die nach meinem Verständnis aus den hgt-Dateien erzeugt wird) bei Höhenlinien in der Karte (die von openandromaps berechnet wurden) ziemlich genau die richtige Höhe an, daher mein Verdacht, dass da detaillierte Daten heruntergeladen werden. Da scheint der Interpolations-Algorithmus in LM gute Arbeit zu leisten.
Die von mir verwendeten Daten für die Aktualisierung der Höhen sind DGM1 vom Hessischen Amt für Geoinformationen (https://www.gds.hessen.de/INTERSHOP/web/WFS/HLBG-Geodaten-Site/de_DE/-/EUR/ViewDownloadcenter-Start?path=3D-Daten/Digitales%20Gel%C3%A4ndemodell%20(DGM1) (https://www.gds.hessen.de/INTERSHOP/web/WFS/HLBG-Geodaten-Site/de_DE/-/EUR/ViewDownloadcenter-Start?path=3D-Daten/Digitales%20Gel%C3%A4ndemodell%20(DGM1)).
Das DGM1-Modell hat eine Rasterweite von 1m! Eine Kachel umfasst einen Quadratkilometer und hat schon 2 - 3 MB. Allein die nähere Umgebung (ca. 10 - 15 km) meines Heimatorts belegen 1.3 GB. Das will ich gar nicht auf dem Handy haben, abgesehen davon, dass ich nicht wüsste, wie man Python auf Android zum Laufen bekommt. Und wenn eine neue Region benötigt wird, muss man jede einzelne Gemeinde herunterladen und auspacken (kommt Dir sicher bekannt vor :D )
Also Antwort auf die Frage: ja, die Verarbeitung findet auf einem PC statt. Exportieren und importieren muss ich von Hand, der Sync passiert automatisch. Wobei mein Hauptpziel die Analyse der Dateien auf dem PC ist, das Zurückspielen habe ich nur mal gemacht, um mit das Ergebnis in Locus anzuzeigen.
Zu meinen Fragen: Lohnt es sich die auf Englisch nochmal im allgemeines Forum zu stellen, oder lesen die Hersteller von Locus und andere nicht deutschsprachige Nutzer dank Übersetzungstools sowieso alles?
Quote from: clausin on June 10, 2025, 21:57:30Zu meinen Fragen: Lohnt es sich die auf Englisch nochmal im allgemeines Forum zu stellen, oder lesen die Hersteller von Locus und andere nicht deutschsprachige Nutzer dank Übersetzungstools sowieso alles?
Aus eigener Erfahrung, die Erfolgsquote steigt, wenn die auch jenseits des deutschen Forums fragst UND auch mal im Locus Helpdesk schreibst.
Hier kannst du die aufgezeichneten GPS-Höhendaten in deinem Track durch hochgenaue DGM1-Daten ersetzen (Dienste -> GPX-Datei): https://hoehendaten.de/index.html
PS: Ich wäre an einer Diskussion deiner Ergebnisse / Erkennissen interessiert, weil es in Kürze dort auch einen Dienst zur Auswertung von GPX-Höhendaten geben soll.
@fzk Danke für den Link, den kannte ich nocht nicht.
Und dabei habe ich vor dem Schreiben meines Skripts schon nach so was gesucht. Entweder war ich mit dem falschen Suchbegriffen unterwegs, oder die Seite ist zu neu. Aber ich habe dabei auch einiges gelernt. Der Weg ist das Ziel (gilt hier auch im übertragenen Sinn).
Ich habe mal für eine gpx-Datei dort Höhen berechnen lassen. Da kommt schon fast genau das gleiche raus wie bei der Verarbeitung der geotif-Dateien direkt. 'Fast genau' beudeutet dabei, dass der Dienst ganz viele Nachkommastallen produziert, die auf die Anzahl der Nachkommastellen der geotif-Datei gerundet das gleiche ergeben. Bei der Genauigkeit der Daten würde eine Nachkommastelle ausreichen. Ist meine persönliche Meinung (und Lehrmeinung in der Physik).
Was nicht funktioniert ist der API-Aufruf für einen einzelnen Punkt. Wenn man die auf der Seite angegebenen Daten (ID und Koordinaten) verwendet, kommt eine Response mit der Höhe, wenn man andere Koordinaten angibt, kommt eine Fehlermeldung:
('Connection aborted.', ConnectionResetError(10054, 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen', None, 10054, None))
Seltsam. Aber stört mich jetzt nicht, weil ich die Koordinaten meiner Strecken, die ich derzeit anschaue schon habe. Und andere, die ich gerne auschauen möchte, liegen in den Alpen und nicht im Bereich der Seite :( .
Was meinst Du mit Diskussion über Erkenntnisse / Ergebnisse? Das was ich oben schon kommentiert habe? Da bin ich gerne dabei, wenn es weitere Fragen gibt.
Der Dienst "GPX-Datei" (auf der Webseite hoehendaten.de) kann verwendet werden:
- um die genauen Höhenangaben für einen geplanten Track zu ermitteln,
oder entsprechend
- um die genauen Höhenangaben für einen aufgezeichneten Track zu ermitteln.
Was auf der Webseite noch fehlt, ist ein Dienst "Track-Analyse" der die genauen Höhenangaben im GPX-Track statisch auswertet. Also zum Angaben wie "Höhenmeter bergauf" oder "Höhenmeter bergab" ermittelt.
Die "Track-Analyse" müßte eine Reihe von Randbedingungen und/oder Benutzerparameter zur Glättung der Daten berücksichtigen. Welche genau, darum ginge es mir im Rahmen einer Diskussion. Das Diskussionsergebnis soll dann in die konkrete Implementierung einfließen.
Anzahl Nachkommastellen: Die API liefert die Höhenwerte exakt so zurück, wie sie von den Landesvermessungsämtern bereitgestellt werden. Das erklärt die vielen Nachkommastellen (z.B. 327.13800048828125 m) bei einem Höhenwert. Das suggeriert eine Scheingenauigkeit, für die Weiterverarbeitung sollte der Wert auf 2 Nachkommastellen gerundet werden (z.B. 327.14 m). Auf der "Karte" wird das auch genauso gemacht.
Connection aborted: Welche Eingabedaten führten zur Fehlermeldung? Und mit welchem Client ist das aufgetreten?
Quote from: fzk on June 15, 2025, 07:03:34Was auf der Webseite noch fehlt, ist ein Dienst "Track-Analyse" der die genauen Höhenangaben im GPX-Track statisch auswertet. Also zum Angaben wie "Höhenmeter bergauf" oder "Höhenmeter bergab" ermittelt.
Die "Track-Analyse" müßte eine Reihe von Randbedingungen und/oder Benutzerparameter zur Glättung der Daten berücksichtigen. Welche genau, darum ginge es mir im Rahmen einer Diskussion. Das Diskussionsergebnis soll dann in die konkrete Implementierung einfließen.
Das ist eigentlich ein guter Ansatz. Leider öffnet man damit bei GPS-Daten, die ja doch sehr unterschiedlicher Natur sein können, mitunter die Büchse der Pandora. Im schlimmsten Fall kommt man nicht umhin, an den Faktoren immer wieder manuell Hand anzulegen.
In meiner App (https://forum.locusmap.eu/index.php?topic=9063.msg78707#msg78707 (https://forum.locusmap.eu/index.php?topic=9063.msg78707#msg78707)) kann man einen Glättungs- und einen Hysteresefaktor in
Echtzeit variabel zuweisen.
Auf diese Weise kann man die Auswirkungen dieser beiden Faktoren sehr gut einsehen.
Bei sehr feinauflösenden Höhendaten (barometerbasierte Messung oder eben sehr fein auflösende SRTM-Daten) hat die Glättung m.E. weit weniger Einluss. Da wirkt sich vor allem ein Hysteresefaktor aus, sofern man diesen nutzt, um kleinere Erhebungen zu egalisieren (was bei Barometerbasierten Daten m.M. sinnvoll ist -> ich habe meine Wurzeln in der Bike-Computer Ecke).
Was ich sagen will, eine Verbesserung der Track-Analyse in Locus Map wäre sicherlich schön, wenn Menion das aber in trockene Tücher packen will, also diese Randbedingungen und/oder Benutzerparameter zur Glättung der Daten automatisieren will, dann wird es wirklich schwierig. Gerade dann, wenn man konform mit diversen Webdiensten (Komoot, etc.) gehen will, die ja alle ihre eigenen Höhenmeter-Wahrheiten offenbaren 8)
Ich bin jedenfalls bei dem Versuch, das zu automatisieren, mehrmals gescheitert (also bei meinen Versuchen geht es gänzlich ohne manuelles Eingreifen leider nicht) :-[
2025-06-15_100331.gif
Beim Aspekt "Glättung" sehe ich folgende Sachverhalte:
Die DGM1-Höhendaten sind extrem genau, was aber dazu führt, dass ein unebener, horizontal verlaufender Naturweg plötzlich Steigung und/oder Gefälle aufgrund der Unebenheiten aufweist. Glättung?
Läuft bei Pausen die Trackaufzeichnung weiter, führt dies oft zu mehr oder weniger ausgeprägten Punktwolken. Diese Punktwolken führen zu Steigung und/oder Gefälle obwohl keine Bewegung erfolgte. Glättung?
Vielleicht hilft ein Beispiel. Der Track sollte so um die 250 Meter Steigung und Gefälle aufweisen:
Höhenmeter-Auswertung basierend auf ungenauen Höhendaten via GPS-Signal:
Uphill: 672.4 m (weighted moving average)
Downhill: 676.5 m (weighted moving average)
Uphill: 1183.7 m (unfiltered)
Downhill: 1187.8 m (unfiltered)
Höhenmeter-Auswertung basierend auf hochgenauen DGM1-Höhendaten:
Uphill: 245.7 m (weighted moving average)
Downhill: 248.0 m (weighted moving average)
Uphill: 277.4 m (unfiltered)
Downhill: 279.7 m (unfiltered)
Quote from: fzk on June 15, 2025, 11:23:33Die DGM1-Höhendaten sind extrem genau, was aber dazu führt, dass ein unebener, horizontal verlaufender Naturweg plötzlich Steigung und/oder Gefälle aufgrund der Unebenheiten aufweist. Glättung?
Oh ja!
QuoteLäuft bei Pausen die Trackaufzeichnung weiter, führt dies oft zu mehr oder weniger ausgeprägten Punktwolken. Diese Punktwolken führen zu Steigung und/oder Gefälle obwohl keine Bewegung erfolgte. Glättung?
Oh nein! Punktwolken (schönes Wort) a) gar nicht erst entstehen lassen bzw. b) nachträglich entfernen.
Also: Pausenerkennung. Nicht so ganz trivial wie man zunächst denkt. zu a) Menion hat dazu ja was getan aber IIRC verlässt er sich da auf irgendeine Android-API die mitteilt, ob Bewegung stattfindet. zu b) Nacharbeiten, da ist LM traditionell schwach.
Punktwolken nehme ich nach einer Tour meist manuell raus, einfach mit dem Editor in LM.
@WRPSoft: Ich habe Deinen Blogeintrag zum dem Thema gelesen. Ein hervorragender Artikel zu den Problemen mit der Höhenberechnung. Und ich zweifle nochmals an meinen Fähigkeiten, ordentlich zu einem Thema zu recherchieren. Auch die Seite hatte ich nicht gefunden :'(
Quote from: WRPSoft on June 15, 2025, 10:19:07Was ich sagen will, eine Verbesserung der Track-Analyse in Locus Map wäre sicherlich schön, wenn Menion das aber in trockene Tücher packen will, also diese Randbedingungen und/oder Benutzerparameter zur Glättung der Daten automatisieren will, dann wird es wirklich schwierig. Gerade dann, wenn man konform mit diversen Webdiensten (Komoot, etc.) gehen will, die ja alle ihre eigenen Höhenmeter-Wahrheiten offenbaren 8)
Ich bin jedenfalls bei dem Versuch, das zu automatisieren, mehrmals gescheitert (also bei meinen Versuchen geht es gänzlich ohne manuelles Eingreifen leider nicht) :-[
Das ist sicher richtig. Die Frage ist, welchen Aufwand man betreiben muss, um aus offensichtlich falschen Werten einigermaßen vernünftige Werte zu machen. Da sollte Menion schon ein Interesse haben, insbesondere wenn das mit anderen Apps verglichen wird. Aus Aufnahmeprofil und Quelle für die Höhenangaben sollte man man schon mal in die richtige Richtung kommen. Absolute Genauigkeit erwarte ich nicht. Und ich ging davon aus (und sehe mich durch Deinen Blog-Eintrag bestätigt), dass die Algorithmen zu dem Thema bekannt sind. fsk hat mit seinem Service vielleicht die Möglichkeit viele verschiedene GPX-Dateien zu sammeln und auszuwerten (sofern es das in seinen Nutzungbedingungen darstellt, habe ich jetzt nicht geschaut). Vielleicht kommt er dann auch zur Erkenntnis, dass es die eine Methoden mit wenigen Parametern nicht gibt.
Quote from: fzk on June 15, 2025, 07:03:34Connection aborted: Welche Eingabedaten führten zur Fehlermeldung? Und mit welchem Client ist das aufgetreten?
Ich verwende Python:
import requests
import json
data = """{
"Type": "PointRequest",
"ID": "Langenberg (Rothaargebirge, höchster Berg in NRW)",
"Attributes": {
"Longitude": 8.558333,
"Latitude": 51.276389
}
}"""
header = {"Content-Type": "application/json",
"Accept": "application/json" }
url = "https://api.hoehendaten.de:14444/v1/point"
response = requests.post(url, data, headers=header)
responsedata = json.loads(response.content)
print(responsedata['Attributes']['TileIndex'], responsedata['Attributes']['Elevation'])
Ich habe das noch ein paar Mal ausgeführt, und es war tatsächlich Zufall, dass es immer mit den Beispiel-Koordinaten funktioniert hat. Der Fehler tritt tatsächlich bei 3 - 4 Aufrufen 2 - 3 Mal auf. Also ziemlich häufig, aber zufällig.
Ich habe den Aufruf auch mehrmals mit Postman (https://www.postman.com (https://www.postman.com)) ausgeführt. Auch hier ziemlich oft der Fehler 'Error: read ECONNRESET' und gelegentlich eine Antwort.
Abstrakt betrachtet möchte man mit Track-Statistiken drei Dinge erreichen:
- Vor der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
- Nach der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
- Während der Tour: Wieviel Strecke und wieviele Höhenmeter kommen noch?
Die Statistiken vor und nach der Tour macht man am besten auf Basis von DGM/DEM-Daten. Die Schwierigkeit während der Tour ist die Berechnung der Höhenmeter. Hier sind GNSS-Daten (Satellit) ungeeignet, weil sie zu ungenau und zu stark verrauscht sind. Der Vergleich von "GNSS-Höhendaten mit DGM/DEM-Höhendaten" entspricht einem Vergleich von "Äpfeln mit Birnen". Um während der Tour eine vernünftige Aussage zur Frage "Wieviele Höhenmeter kommen noch?" treffen zu können, sollte man richtigerweise dieselbe Basis verwenden wie für die Planung.
Anders ausgedrückt: Der Nutzen von GNSS-Höhendaten ist sehr gering. Am besten man verzichtet darauf. Die Höhenmeter während der Tour müssen auf anderem Wege ermittelt werden.
Quote from: clausin on June 14, 2025, 23:15:28('Connection aborted.', ConnectionResetError(10054, 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen', None, 10054, None))
Der Service schließt mit jeder Response die Verbindung. Möglicherweise versuchst du in deinem Client mehrere Requests über dieselbe Verbindung durchzuführen. Das würde zumindest zur Fehlermeldung 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen' passen.
Quote from: fzk on June 15, 2025, 21:59:43Der Service schließt mit jeder Response die Verbindung. Möglicherweise versuchst du in deinem Client mehrere Requests über dieselbe Verbindung durchzuführen. Das würde zumindest zur Fehlermeldung 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen' passen.
Guter Hinweis. Ich muss mal schauen, wie Python die Connection handhabt. Standard-Einstellung scheint keep-alive zu sein. Das mach ich heut aber nicht mehr.
Quote from: fzk on June 15, 2025, 11:23:33Beim Aspekt "Glättung" sehe ich folgende Sachverhalte:
Die DGM1-Höhendaten sind extrem genau, was aber dazu führt, dass ein unebener, horizontal verlaufender Naturweg plötzlich Steigung und/oder Gefälle aufgrund der Unebenheiten aufweist. Glättung?
Die DGM1-Daten sind natürlich extrem genau (vergleichbar mit einer barometerbasierten Messung bei stabilem Wetter). In Kombination mit vielen GPS-
Fehlern (schlechte Empfangsbedingungen oder 'schlechten' GPS-Chipsätze, die es leider immer noch gibt), sind sie aber nicht mehr so extrem genau, sondern nur noch feinauflösend.
Und bei sehr fein auflösenden Daten hat eine Glättung in der Regel weniger Auswirkung, zumal man die Glättung dann sehr fein
runterregeln muss (bei DGM1-Daten operiert man dann ja im cm Bereich, analog zu Barometerbasierten Messungen, die heutztage auch im cm Bereich die Höhe
messen).
Quote from: fzk on June 15, 2025, 11:23:33Läuft bei Pausen die Trackaufzeichnung weiter, führt dies oft zu mehr oder weniger ausgeprägten Punktwolken. Diese Punktwolken führen zu Steigung und/oder Gefälle obwohl keine Bewegung erfolgte. Glättung?
Also kommt man leider nicht umhin, die (GPS)-Daten vorher - vor der Höhenwertzuweisung bzw.
Höhenwertreparatur - aufzubereiten. Da gibt es mehrere Möglichkeiten, Tapio hat das ja beschrieben. In Echtzeit stelle ich mir das sehr schwierig vor; nachträglich durchaus machbar, wobei aber die Frage bleibt, wie weit man das
automatisieren kann.
Quote from: fzk on June 15, 2025, 11:23:33Vielleicht hilft ein Beispiel. Der Track sollte so um die 250 Meter Steigung und Gefälle aufweisen:
Höhenmeter-Auswertung basierend auf ungenauen Höhendaten via GPS-Signal:
Uphill: 672.4 m (weighted moving average)
Downhill: 676.5 m (weighted moving average)
Uphill: 1183.7 m (unfiltered)
Downhill: 1187.8 m (unfiltered)
Höhenmeter-Auswertung basierend auf hochgenauen DGM1-Höhendaten:
Uphill: 245.7 m (weighted moving average)
Downhill: 248.0 m (weighted moving average)
Uphill: 277.4 m (unfiltered)
Downhill: 279.7 m (unfiltered)
An deinem Beispiel sieht man recht gut, dass die Glättung vor allem bei verrauschten Daten große Auswirkungen hat, bei den fein abgestuften DGM1-Daten aber weniger.
Ich habe - wie gesagt - auch recht viel mit solchen Daten experimentiert, spätestens dann, wenn man stark unterschiedliche Touren aufbereiten/
normalisieren will, kamen dann aber wieder größere Abweichungen zustande.
Z.B. Rennradtouren vers. MTB-Touren vers. Wandertouren, kurze Touren vers. langen Touren, stark verrauschte Daten vers. eher genauen Daten (auch oder vor allem, was die GPS-Daten betrifft), lange Anstiege gegenüber Achterbahntouren (z.B. Wandern in Weinbergen), verwendete Aufzeichnungsintervalle (da bietet Locus Map ja sehr viele Einstellungsmöglichkeiten), etc.
Ich konnte das mit einer Universalformel leider nicht einfangen. Wenn man z.B. einen Ötztaler Radmarathon alleine mit der Glättung der Höhendaten berechnen will, dann kommen m.E. immer deutlich zu viele Auf- und Abstiegsmeter heraus, sodass ich bei dieser Art Tour um eine zusätzliche Hysterese nicht umhingekommen bin.
Das mögen jetzt Sonderfälle sein, aber Locus Map muss das ja quasi alles eintüten und erschwerend kommt hinzu, dass Locus Map mit vielen Arten von Android Phones zusammenarbeiten muss und daher eine sehr große Bandbreite, was die Zuverlässigkeit der Aufzeichnungen betrifft, aufschlagen dürften).
Nicht gänzlich unmöglich, aber ich glaube, das ist schon eine sehr, sehr großen Baustelle, wenn man das alles auf dem Phone berechnen will. Wahrscheinich viele Stellschrauben, die man konfigurieren muss, um diese unterschiedlichen Ausgangsdaten handeln zu können.
PS: Das ist jetzt alles sehr subjektiv, da ich mich selbst sehr viel mit Radaufzeichnungen beschäftigt habe. Man hangelt sich ja immer von einer bestimmten Ausgangslage zur nächsten und versucht im nächsten Schritt, eine allgemeingültige Variante zu finden.
Quote from: clausin on June 15, 2025, 20:57:22@WRPSoft: Ich habe Deinen Blogeintrag zum dem Thema gelesen. Ein hervorragender Artikel zu den Problemen mit der Höhenberechnung. Und ich zweifle nochmals an meinen Fähigkeiten, ordentlich zu einem Thema zu recherchieren. Auch die Seite hatte ich nicht gefunden :'(
Freut mich zu hören, danke für die netten Worte. Wobei ich natürlich sehr subjektiv an das Thema herangehe, weil meine Wurzeln wie gesagt im Bikecomputer- und Wanderuhren-Bereich liegen. Die erste Generation dieser Geräte konnte noch keine GPS-Daten protokollieren, das waren rein barometerbasierte Höhenmesser und da war die Hysterese quasi die einzige Stellschraube. Glätten musste man dabei nicht viel, da die Höhenmess-Chips schon recht früh im cm-Bereich auflösen konnten und dieses feine Grundrauschen konnte/kann man mit der Hysterese sehr gut egalisieren.
Heutzutage sieht das natürlich etwas anders aus, aber zumindest die Echtzeitberechnungen auf den Geräten selbst, laufen m.E. immer noch ähnlich ab (man hangelt sich von Datenpunkt zu Datenpunkt und operiert mit den Deltas).
Quote from: clausin on June 15, 2025, 20:57:22Das ist sicher richtig. Die Frage ist, welchen Aufwand man betreiben muss, um aus offensichtlich falschen Werten einigermaßen vernünftige Werte zu machen. Da sollte Menion schon ein Interesse haben, insbesondere wenn das mit anderen Apps verglichen wird. Aus Aufnahmeprofil und Quelle für die Höhenangaben sollte man man schon mal in die richtige Richtung kommen. Absolute Genauigkeit erwarte ich nicht. Und ich ging davon aus (und sehe mich durch Deinen Blog-Eintrag bestätigt), dass die Algorithmen zu dem Thema bekannt sind. fsk hat mit seinem Service vielleicht die Möglichkeit viele verschiedene GPX-Dateien zu sammeln und auszuwerten (sofern es das in seinen Nutzungbedingungen darstellt, habe ich jetzt nicht geschaut). Vielleicht kommt er dann auch zur Erkenntnis, dass es die eine Methoden mit wenigen Parametern nicht gibt.
Ich glaube, Interesse wird bei Menion schon vorhanden sein, aber er muss halt gegen eine sehr große Bandbreite an Geräten und Daten ankämpfen und das macht's nicht gerade einfacher ;) Wir haben hier drei
aktuelle Mittelklasse-Smartphones in Verwendung, eines davon protokolliert leider sehr grausliche GPS-Koordinaten. Da macht dann sogar eine nachträgliche Korrektur der Höhendaten nur bedingt Sinn, weil man eigentlich vorher die GPS-Ausreißerkoordinaten korrigieren/filtern müsste.
Auch das könnte man natürlich irgendwie angehen, die einfachste Variante wäre ein Glätten der GPS-Koordianten mittels Douglas-Peucker-Filter, wobei das aber auch keine Universalwaffe ist und ich nicht weiß, ob Locus Map die GPS-Daten im Hintergrund bereits etwas aufbereitet.
Wie gesagt, recht anspruchsvoll, könnte man wahrscheinlich eine Doktorarbeit draus machen 8)
@WRPSoft: Der Nutzen von ungenauen, stark verrauschten GNSS-Höhendaten ist sehr gering. Da hilft auch Glätten wenig. Am besten man verzichtet auf GNSS-Höhendaten. Die Höhendaten während einer Tour müssen also auf anderem Wege ermittelt werden (z.B. via DEM/DGM). Vor und nach der Tour ermittelt man die Höhendaten ja ohnehin schon via DEM/DGM.
Quote from: fzk on June 15, 2025, 21:55:46Abstrakt betrachtet möchte man mit Track-Statistiken drei Dinge erreichen:
- Vor der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
- Nach der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
- Während der Tour: Wieviel Strecke und wieviele Höhenmeter kommen noch?
Die Statistiken vor und nach der Tour macht man am besten auf Basis von DGM/DEM-Daten. Die Schwierigkeit während der Tour ist die Berechnung der Höhenmeter. Hier sind GNSS-Daten (Satellit) ungeeignet, weil sie zu ungenau und zu stark verrauscht sind. Der Vergleich von "GNSS-Höhendaten mit DGM/DEM-Höhendaten" entspricht einem Vergleich von "Äpfeln mit Birnen". Um während der Tour eine vernünftige Aussage zur Frage "Wieviele Höhenmeter kommen noch?" treffen zu können, sollte man richtigerweise dieselbe Basis verwenden wie für die Planung.
Anders ausgedrückt: Der Nutzen von GNSS-Höhendaten ist sehr gering. Am besten man verzichtet darauf. Die Höhenmeter während der Tour müssen auf anderem Wege ermittelt werden.
Daan bleibt zur Echtzeitberechnung aber nicht mehr viel, was man aufgreifen könnte:
- Barometerbasierte Höhenmessung wäre eine Möglichkeit, allemal besser als reine GPS-Höhenwerte.
- Oder die Höhenwerte bereits zur Echtzeit durch DEM-Daten ersetzen. Ist dann die Frage, wie hochauflösend die DEM-Daten sind, ob man diese lokal auf dem Gerät speichert oder diese jeweils per Internetverbindung pro Datenpunkt (ggfs. nur alle X Datenpunkte abfragen und die Zwischenwerte interpolieren) zuweist.
Das Thema ist sicherlich noch nicht ausgereizt, aber gerade die Echtzeitberechnung wird noch den ein oder anderen Stolperstein zu Tage befördern. Bin gespannt, wie sich das zukünftig entwickelt.
Quote from: fzk on June 16, 2025, 08:54:05@WRPSoft: Der Nutzen von ungenauen, stark verrauschten GNSS-Höhendaten ist sehr gering. Da hilft auch Glätten wenig. Am besten man verzichtet auf GNSS-Höhendaten. Die Höhendaten während einer Tour müssen also auf anderem Wege ermittelt werden (z.B. via DEM/DGM). Vor und nach der Tour ermittelt man die Höhendaten ja ohnehin schon via DEM/DGM.
Ja, das ist ja mein Reden 8) Eine Frage ist halt, wie bzw. ob man das zur Echtzeit eintüten kann.
Quote from: WRPSoft on June 16, 2025, 09:04:01Ja, das ist ja mein Reden 8) Eine Frage ist halt, wie bzw. ob man das zur Echtzeit eintüten kann.
Die Höhendaten während der Tour sollten aus derselben Quelle stammen, die auch die Grundlage für die Statistik der geplanten Tour war. Also z.B. dasselbe DEM/DGM. Nur so können die aktuellen Daten während der Tour mit den geplanten Tourdaten verglichen werden.
Fazit: Keine GNSS-Höhendaten in den Track schreiben. Stattdessen die Höhendaten aus einem DEM/DGM (offline oder online) ermitteln und in den Track schreiben.
Quote from: fzk on June 15, 2025, 21:59:43Der Service schließt mit jeder Response die Verbindung. Möglicherweise versuchst du in deinem Client mehrere Requests über dieselbe Verbindung durchzuführen. Das würde zumindest zur Fehlermeldung 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen' passen.
Das war es wohl. Auch wenn man requests nach Anleitung mit Session nutzt und nach jedem Aufruf die Connection schließt, kommt alle paar Aufrufe der Fehler. Wenn man die Basis-Lib urllib3 verwendet, tritt der Fehler nicht mehr auf.
Damit kann ich nun auch Tracks überarbeiten, die nicht in der näheren Umgebung liegen. Vielen Dank!