20.07.2024, 09:55
Hans, das ist ja gerade der Sinn des Threads: Höhendaten werden immer hochauflösender und auf GPS/Baro ist kein Verlass. (Kenne das Thema in-und-auswendig.)
Sonny gibt auf seiner Seite ja die Referenzquellen an. Für die BRD und Frankreich (RGE-ALTI) sind das z.T. Daten mit 1m - 10m Auflösung, die er allerdings aus Kompatibilitätsgründen in SRTM1 konvertiert. Er hat genau einen Link auf Österreich mit einer 0.5°-Auflösung (HGT 7200^2) , die allerdings in RC nicht funktioniert, wie #2 zeigt.
Ich könnte selbst HGTs < SRTM1 aus GeoTIffs erzeugen und würde die dann in RC verwenden, wenn er "aufgebohrt" würde.
NB: HGT gefällt mir auch deshalb nicht, weil sie Integer-Werte enthält, was eine weitere Fehlerquelle ist. Eine kerzengerade flache Strecke hat dann halt vielleicht die Höhenpunkte 114-115-115-114-114, obwohl alle 114.3 hoch sind. Deshalb gibt es die höherauflösenden DEM-Daten inzwischen meist mit FLOAT-Werten.
OT: Habe übrigens diverse Tests gemacht mit Aufzeichnung einer hügeligen Strecke parallel mit 1. Locus, 2. Samsung SmartWatch, 3. selbstgestrickter App, die direkt den Android-GSP-Sensor abfragt, 4. Bike-Computer Sigma ROX 10, welcher Baro und GPS kombiniert.
Die SmartWatch gibt wirklich Müll aus. Fehler liegt im Schnitt bei 12m. Locus hat eigene Korrekturalgorithmen implementiert und hat nur ca. 4 m Fehler. Die eigene App kommt auf durchschnittl. 8 m Fehler, der ROX ist aber auf 2 m genau (!).
Also alle vier schlechter, als interpoliertes SRTM1.
Sonny gibt auf seiner Seite ja die Referenzquellen an. Für die BRD und Frankreich (RGE-ALTI) sind das z.T. Daten mit 1m - 10m Auflösung, die er allerdings aus Kompatibilitätsgründen in SRTM1 konvertiert. Er hat genau einen Link auf Österreich mit einer 0.5°-Auflösung (HGT 7200^2) , die allerdings in RC nicht funktioniert, wie #2 zeigt.
Ich könnte selbst HGTs < SRTM1 aus GeoTIffs erzeugen und würde die dann in RC verwenden, wenn er "aufgebohrt" würde.
NB: HGT gefällt mir auch deshalb nicht, weil sie Integer-Werte enthält, was eine weitere Fehlerquelle ist. Eine kerzengerade flache Strecke hat dann halt vielleicht die Höhenpunkte 114-115-115-114-114, obwohl alle 114.3 hoch sind. Deshalb gibt es die höherauflösenden DEM-Daten inzwischen meist mit FLOAT-Werten.
OT: Habe übrigens diverse Tests gemacht mit Aufzeichnung einer hügeligen Strecke parallel mit 1. Locus, 2. Samsung SmartWatch, 3. selbstgestrickter App, die direkt den Android-GSP-Sensor abfragt, 4. Bike-Computer Sigma ROX 10, welcher Baro und GPS kombiniert.
Die SmartWatch gibt wirklich Müll aus. Fehler liegt im Schnitt bei 12m. Locus hat eigene Korrekturalgorithmen implementiert und hat nur ca. 4 m Fehler. Die eigene App kommt auf durchschnittl. 8 m Fehler, der ROX ist aber auf 2 m genau (!).
Also alle vier schlechter, als interpoliertes SRTM1.