'Glättung' von Höhendaten und Aktualisierung von SRTM-Daten

[clausin]

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:
You cannot view this attachment.
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:
You cannot view this attachment.
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

[Joska]

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?

[clausin]

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

[Joska]

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?

Aus eigener Erfahrung, die Erfolgsquote steigt, wenn die auch jenseits des deutschen Forums fragst UND  auch mal im Locus Helpdesk schreibst.

[fzk]

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.

[clausin]

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

[fzk]

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?

[WRPSoft]

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.

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) 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
Ich bin jedenfalls bei dem Versuch, das zu automatisieren, mehrmals gescheitert (also bei meinen Versuchen geht es gänzlich ohne manuelles Eingreifen leider nicht)

You cannot view this attachment.

[fzk]

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)

[Tapio]

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?

Oh ja!

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?

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.

[clausin]

@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 

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

[clausin]

Connection aborted: Welche Eingabedaten führten zur Fehlermeldung? Und mit welchem Client ist das aufgetreten?

Ich verwende Python:

Code Select Expand

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) ausgeführt. Auch hier ziemlich oft der Fehler 'Error: read ECONNRESET' und gelegentlich eine Antwort.

[fzk]

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.

[fzk]

('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.

[clausin]

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.

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.