23.03.2022, 10:59
Ich verwende RC noch immer zur Radtourenplanung. Gerne auch in bergigem Gelände. 
Während das grafische Höhenprofil eine gute Abschätzung einer Tour liefert, sind die aufsummierten Aufstiege oft erstmal desillusionierend; sprich: zu hoch!
Route ich etwa einen Pass hoch, so kommt es zu einer Steigungssumme, die bis zu 20% über dem tatsächlichen Wert liegt. Sieht man auch an der Gefällesumme, die eigentlich bei einem kontinuierlichen Weg nach oben 0 sein sollte.
Das Problem ist mir klar. Bei 90m-DEM-Abständen springt eine Koordinate des Tracks mal eine Reihe/Zeile im Höhen-Grid hoch, mal runter, wenn der Berg steil ist. Das lässt sich mit SRTM3 nicht genauer machen.
@routeconverter: Wäre es denkbar eine Interpolation der Höhendaten einzubauen?
Ich programmiere selbst einige GIS-Sachen mit MAPWinGis und GDAL. Mit GDALWarp bzw. den entspr. API-Methoden kann man gut ein Höhen-Grid hochskalieren und, wie in Bildbearbeitungen, dabei Algos, wie bilinear, kubisch, spline, etc., angeben. Mit CUBIC oder Lanzos bekomme ich die besten Ergebniss, wobei Lanczos oft etwas überschwingt.
Skaliiere ich eine HGT auf etwa das Vierfache und verwende das dann zur Berechnung des Höhenprofils eines Tracks, so ist der Fehler der Höhensumme nur ca. 3%.
Aber so genau wollte ich das auch gar nicht implementiert haben. GDAL muss nicht in den RC inkludiert werden. Es würde mir reichen, wenn eine Koordinate aus den umliegenden 8 Punkten linear interpoliert würde. Also je nach Abstand der gefragten Koordinate zu den Lat/Lon-Werten der Column/Row-Punkte im Höhen-Grid deren Höhenwerte unterschiedlich gewichtet als Durchschnitt summieren. Ich habe das selbst gerade getestet; ergibt auf jeden Fall bessere Ergebnisse, als HGT pur.
Falls also zufällig Mal Zeit dafür wäre... bin leider kein Java-Programmierer - sonst würde ich mich selbst dran machen.
Grüße!
Sascha
Während das grafische Höhenprofil eine gute Abschätzung einer Tour liefert, sind die aufsummierten Aufstiege oft erstmal desillusionierend; sprich: zu hoch!
Route ich etwa einen Pass hoch, so kommt es zu einer Steigungssumme, die bis zu 20% über dem tatsächlichen Wert liegt. Sieht man auch an der Gefällesumme, die eigentlich bei einem kontinuierlichen Weg nach oben 0 sein sollte.
Das Problem ist mir klar. Bei 90m-DEM-Abständen springt eine Koordinate des Tracks mal eine Reihe/Zeile im Höhen-Grid hoch, mal runter, wenn der Berg steil ist. Das lässt sich mit SRTM3 nicht genauer machen.
@routeconverter: Wäre es denkbar eine Interpolation der Höhendaten einzubauen?
Ich programmiere selbst einige GIS-Sachen mit MAPWinGis und GDAL. Mit GDALWarp bzw. den entspr. API-Methoden kann man gut ein Höhen-Grid hochskalieren und, wie in Bildbearbeitungen, dabei Algos, wie bilinear, kubisch, spline, etc., angeben. Mit CUBIC oder Lanzos bekomme ich die besten Ergebniss, wobei Lanczos oft etwas überschwingt.
Skaliiere ich eine HGT auf etwa das Vierfache und verwende das dann zur Berechnung des Höhenprofils eines Tracks, so ist der Fehler der Höhensumme nur ca. 3%.
Aber so genau wollte ich das auch gar nicht implementiert haben. GDAL muss nicht in den RC inkludiert werden. Es würde mir reichen, wenn eine Koordinate aus den umliegenden 8 Punkten linear interpoliert würde. Also je nach Abstand der gefragten Koordinate zu den Lat/Lon-Werten der Column/Row-Punkte im Höhen-Grid deren Höhenwerte unterschiedlich gewichtet als Durchschnitt summieren. Ich habe das selbst gerade getestet; ergibt auf jeden Fall bessere Ergebnisse, als HGT pur.
Falls also zufällig Mal Zeit dafür wäre... bin leider kein Java-Programmierer - sonst würde ich mich selbst dran machen.
Grüße!
Sascha
Steht auf 
