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