Messages

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.

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!

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.

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.

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

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

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?

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