habe gerade eine Radtour über Korsika hinter mir - geplant natürlich mit dem RC/BRouter.
Was wieder einmal das leidige Höhenproblem zutage förderte: Es gab Tracks(an der Westküste), für die RC etwa 1800 hm Anstieg angab, der sich durch Löschen von Zwischenpositionen auch nur auf ca. 1500 senken ließ, obwohl es reell (Aufzeichnung in Locus App) nur 950 hm waren...
Für Korsika gibt es aber ein 5m-DEM-Grid (!): https://geoservices.ign.fr/rgealti#telechargement5m . Habe die ASC-Dateien mit GlobalMapper in ein GeoTIFF verwandelt (2.5 Gb). Wenn ich in GlobalMapper damit für den GPX-Track ein Path Profile erstelle, dann kommen immerhin nur noch 1100 hm raus. (Die 150 hm zuviel rühren hauptsächlich von Brücken und einen Tunnel her.)
Mit besser aufgelösten DEMs kann man also die Höhenprofilberechnung deutlich verbessern. (Und solche Datenquellen gibt es weltweit immer mehr. Hier in Berlin etwa mit 2m-Auflösung - leider wieder ASC-Dateien, die man mit GM oder QGIS konvertieren muss.)
Lange Rede, kurzer Sinn: Wie hoch schätzt du die Möglichkeit ein in RC irgendwann zusätzlich GeoTIFFs als Datenquellen zu integrieren, die man manuell in ein separates Verzeichnis ablegen würde? Könnte auf WGS84-konforme TIFFs beschränkt sein, um nicht noch eine Extra-Library für die Projektionsberechnungen/-konvertierungen zu benötigen.
Kann man ElevationTile.java so modifizieren, dass auch höher auflösende HGT-File verwendet werden können? (Sonny hat ja inzwischen auch welche mit 0.5° Aufösung.)
Also z.B. zu
Code:
private static final int SRTM1_INTERVALS = 3600;
zusätzlich sowas wie
Code:
private static final int SRTM05_INTERVALS = 7200;
inkl. Änderungen an getIntervalCount().
Wie schon Mal erwähnt bin ich kein Java-Programmierer und blicke deshalb nicht so recht durch, wie der ElevationService funktioniert und wo warum welches Verzeichnis bei Automatic verwendet wird.
Thanks!
deiner Locus-Aufzeichnung und auch jeder anderen Aufzeichnung mit einem Consumer-Gerät würde ich keine 5 m weit trauen und sie schon gar nicht als Referenz nehmen. Equipment mit für diese Zwecke hinreichender Genauigkeit kostet im 5-stelligen Bereich und ist nicht fahrradkompatibel. Ich zeichne schon lange keine Höhenwerte mehr auf und hole mir die Daten aus einem Höhenmodell, wenn ich sie denn tatsächlich mal brauche, früher DeFerranti, heute Sonny.
Bevor du weiter Gedanken an ein mit Consumermitteln* nicht lösbares Problem verschwendest, lies dir mal diesen Artikel durch. Der nächste Schritt wäre dann Recherchen zur systematischen Ungenauigkeit von GPS-Höhenwerten und den verschiedenen Glättungsverfahren.
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.
(19.07.2024, 13:10)SaschaT Wrote: Wie schon Mal erwähnt bin ich kein Java-Programmierer und blicke deshalb nicht so recht durch, wie der ElevationService funktioniert und wo warum welches Verzeichnis bei Automatic verwendet wird.
Thanks!
Dafür dient der AutomaticElevationService, der hat einen ElevationServicePriorityComparator, der die Priorität beim Automatic-Modus festlegt.
Ich hoste derzeit Sonny Dateien von Dezember 2019 für 3" und 1", die müsste ich dem Readme nach mal aktualisieren
Quote:v2 (2021-04-09): Integrated latest LiDAR data
Da könnte ich auch die 0,5" Dateien kopieren und den Automatismus erweitern, diese Dateien zu verwenden, wenn sie vorhanden sind. Also Prio 0.
Bitte probiert mal die neueste Vorabversion aus: die unterstützt mit Sonny 0.5" eine neue Datenquelle. Die wird bei Automatic automatisch verwendet, wenn die Daten vorhanden sind. Dafür kann man die Daten von https://static.routeconverter.com/sonny/dtm-0.5s/ herunterladen und in $HOME/.routeconverter/sonny05 kopieren
Oder man wählt statt Automatic als Datenquelle Sonny 0.5" und RouteConverter lädt die Daten herunter – allerdings nur für die abgedeckten Bereiche.
Läuft perfekt mit der Vorabversion!
Um den Vorteil zu demonstrieren:
Habe eine 8km-Strecke in den österreichischen Alpen geroutet, die ich selbst schon gefahren bin und deshalb weiß, dass es beim Anstieg (durch ein enges Tal) praktisch keine Stellen mit Gefälle gibt.
Ergebnisse:
Code:
Methode | Summe Steigung | Summe Gefälle
SRTM3 532 m 115 m
Sonny1 456 m 39 m
Sonny05 440 m 25 m
reell ca. 420 m 3 m
Das neue Feature ist also ein erheblicher Gewinn bei der Höhenberechnung. Thanks!
(Jetzt muss Sonny nur noch Frankreichs RGEALTI-Daten in 0.5" konvertieren. ;-)
Bei mir ist das etwas kompliziert und braucht Klimmzüge, weil weder GlobalMapper, noch GDAL größere HGTs, als 3601 ^2 unterstützen.)
29.07.2024, 07:18 (This post was last modified: 30.08.2024, 15:20 by SaschaT.)
Nur zur Info nebenbei: Habe ein feature request bei GDAL durchgesetzt, dass demnächst auch die 7201er-Auflösung vom STRMHGT driver unterstützt wird. Mit dem gdalwarp Tool sollte dann auch die Konvertierung beliebiger Datenquellen (GeoTIFFs etc.) ins HGT-Format auf einfache Weise möglich sein.
PS: Infolge eines weiteren Bugs in GDAL v 3.9.2 verschiebt sich das Release mit dem neuen Feature auf v 3.10.0, welches erst am 4.11. erscheint.
30.09.2024, 12:30 (This post was last modified: 10.10.2024, 07:30 by SaschaT.)
...Auf GDAL wollte ich nicht warten, und so habe ich inzwischen mit GlobalMapper (und etwas Hilfe von Sonny) ganz Italien in die neue Auflösung konvertiert.
Gibt's im 7z-Format gepackt unter http://www.moss-soft.de/public/srtm05/
(Entpacken dann unter .routeconverter\sonny05 - sind dann ca. 8Gb)
Ist erstmal BETA!
Aber hier zur Demonstration ein Track (Anhang) an der Küste bei Cinque Terre, den ich selbst schon abgefahren bin und deshalb die (Steil-)Hänge entlang der Route kenne.
In RC geladen ergeben sich folgende Steigungen / Gefälle:
NASA SRTM3 - 1876m / 1686m
Sonny DTM1 - 1152m / 965m
Sonny05 - 1132m / 945m
Viel bringt SRTM05 also nicht im Vergleich zu DTM1 - die Datenquelle Tinitaly basiert ja auch nicht auf LIDAR, aber immerhin...
Bei Frankreich (RGEALTI/LIDAR), an das ich mich gerade heranmache, wird es dann interessanter.
---------------------------------------
PS: Habe nebenbei noch einen Screenshot aus Google Earth für den Track angehängt (Track-Positionen 1345 ff). Da kann man sehen, dass auch die beste SRTM-Auflösung halt nichts nützt, wenn die Route durch Tunnel (links) und über Brücken (rechts anschließend) führt. Selbst Google verlegt die Brücke ins Tal. Das macht zusammen fast 200 hm aus.
