Messages

Ich konnte eine Lösung für die Erzeugung von zusätzlichen Zwischenpunkten finden:

gpsbabel -t -i gpx -f WestruperHeide-Rennberg-20km.gpx -x interpolate,distance=10m -o gpx -F Interpoliert-WestruperHeide-Rennberg-20km.gpx

In einem zweiten Schritt werden dann noch die Höhendaten für alle Punkte ermittelt. Die sich ergebenden Höhenmeter liegen sehr nahe an den Daten des aufgezeichneten Tracks.

BTW: Im gpsbabel-Kommando werden alle 10 Meter Zwischenpunkte gesetzt. Dies entspricht grob der Aufzeichnungshäufigkeit im Track.

Um die Frage zu beantworten, nein, denn der Track existiert wie eben erstellt.

Was meinst du damit? Der Track wurde aus der Planung abgeleitet und nicht etwa aufgezeichnet.

Das grundsätzliche Problem mit (via Locus-Map) geplanten Strecken und deren Höhendaten haben wir damit herausgearbeitet.

Beispiel:
Eine Strecke von A nach B ist 1200 Meter lang und (in den OSM-Daten) gerade.
Die Punkte A und B liegen auf der gleichen Höhe.
Dazwischen liegt eine Anhöhe von 60 Meter.
Die Höhendaten von 60 Meter tauchen dann in den geplanten Höhendaten nicht auf.

Wenn der Locus-Map-Classic-Routenplaner keine Zwischenpunkte setzen kann, wäre eine nachgelagerte Software von Interesse. Also eine Anwendung die Zwischenpunkte auf Geraden einfügen kann. Ist jemandem hier so etwas bekannt?

Woher stammen denn die Daten?

DGM1: Genauer und besser geht es nicht.

Am besten zeichnest Du das Teilstück mit Locus mal auf, und vergleichst dann die Resultate der ermittelten/berechneten Höhenmeter.

Für den gesamten Track ergibt sich schon ein deutlicher Unterschied in den Höhenmeter:
Planung: 197.78 m
Aufzeichnung: 315.43 m

Ob die Begrenzung der Distanz auf 50m zum Setzen eines Trackpunktes viel bringt, ist m.M.n. fraglich.

Ja, ein kürzer Abstand zwischen zwei Punkten bringt eine Menge.

Frage: Ist es möglich den Abstand der Zwischenpunkte in einem geplanten Track zu definieren?

Im angehängten Beispiel sieht man einen geplanten Track. Der Abstand zwischen den beiden markierten Punkten beträgt 1135 Meter. Ich hätte aber gerne einen Abstand von (zum Beispiel) nur 50 Metern zwischen zwei Punkten.

Durch die zusätzlichen Punkte ließen sich die zu erwartenden Höhenmeter viel genauer bestimmen.

Ja, das ist ja mein Reden 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.

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

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

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.

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)

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?

Was genau ist die Intention des Vorhabens?
Genaue Höhendaten für einen geplanten oder durchgeführten Track?
Genaue dynamische Höhenwerte für die Planung oder im Verlauf der Tour?

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.

Die freizeitkarte-osm.de sollte, analog zu OSM, alle Wanderrouten beinhalten. Die Anzeige der Routen muss über einen zusätzlichen Layer aktiviert werden. Das Knotenpunktnetzwerk ist übrigens auch enthalten.