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.
(23.03.2022, 10:59)SaschaT Wrote: @routeconverter: Wäre es denkbar eine Interpolation der Höhendaten einzubauen?
Anfragen hatte ich dazu schon ein paar – nur nie jemand, der die Mathematik oder Java dazu erklärt hat.
(23.03.2022, 10:59)SaschaT Wrote: 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.
Hier in getElevationFor ist das Berechnen der Höhe – da wird schon innerhalb einer Kachel interpoliert:
(23.03.2022, 10:59)SaschaT Wrote: Falls also zufällig Mal Zeit dafür wäre...
Das ist nie
Ich versuche seit November, eine neue Website auf einem neuen Server hochzuziehen... im Moment bin ich näher dran, den Server wieder abzugeben und irgendwann gibt es die Seite halt nicht mehr.
warum wählst du dann in den Optionen statt der SRTM3-Daten nicht eine der drei Quellen mit 1"-Höhendaten?
Huch, das hatte ich noch gar nicht realisiert. Asche über mein Haupt! Steht auf Automatic, und ich sah im Hintergrund scheinbar immer nur die Ferrantis runterladen.
Allerdings sind alle, außer dem ferrante3-Verzeichnis auch leer. Automatic scheint nicht ganz so automatisch zu laufen?
(25.03.2022, 13:43)SaschaT Wrote: Automatic scheint nicht ganz so automatisch zu laufen?
Die SRTM1 Dateien decken m.W. nicht annähernd so viel Fläche ab. Das kann ich verifizieren, wenn Du mir ein paar Koordinaten schickst – als GPX, oder so?
(23.03.2022, 12:33)routeconverter Wrote: ...Anfragen hatte ich dazu schon ein paar – nur nie jemand, der die Mathematik oder Java dazu erklärt hat.
Naja, mathematisch gibt es die unterschiedlichsten Methoden. Ich lade hier als Beispiel mal einen Screenshot aus Excel hoch, der meine Vorgehensweise dokumentiert.
Dargestellt ist das HGT-Grid, ein grüner Track, der darüber läuft, und ein Punkt P darauf, zu dem das Höhendatum ermittelt werden soll. Blau sind die Höhenwerte.
Ich nehme nach Berechnung der Zelle, in der der Punkt liegt, die 8 angrenzenden Zellen. Von denen errechne ich lat/lon-Werte - da, wo die schwarzen Punkte liegen.
Die Strecken D1-D8 sind der Abstand der Koordinate von P zu diesen angrenzenden Punkten.
Diese Strecken setze ich als Gewichtungsfaktoren f1-f9, wobei die Ausdehnung einer Zelle dCell (1°/1200) ins Verhältnis gesetzt wird. Läge P genau auf dem schwarzen Punkt von H(3|3), so käme für f5 auch genau 1,0 raus. Bei entfernteren Punkten entsprechend weniger, als 1,0.
Mit diesen Gewichtungsfaktoren multipliziere ich die einzelnen Höhendaten, summiere diese und teile das Ganze durch die Summe der Faktoren. Heraus kommt eine gewichtete Höhe.
Die Gewichtung kann man steuern, indem die Faktoren potenziert werden. Mit f^1 ist es linear, mit f = f^2 eben quadratisch. Ich nehme als Exponent bisher 1,5; hängt vom Gelände ab, wie sehr die umliegenden Punkte berücksichtigt werden sollten. (Bei höheren Rauschen wohl eher 2, bei glattem Gelände eher 1,0 oder gar weniger).
Ich hoffe, das ist verständlich.
(25.03.2022, 13:43)SaschaT Wrote: Automatic scheint nicht ganz so automatisch zu laufen?
Die SRTM1 Dateien decken m.W. nicht annähernd so viel Fläche ab. Das kann ich verifizieren, wenn Du mir ein paar Koordinaten schickst – als GPX, oder so?
Angehängt.
Der Screenshot vom Höhenprofil zeigt aus den (real nicht exisierenden) Wellen (ist ein kontinuierlicher Pass, aber in einer Schlucht), noch ein anderes Problem: Tunnel. Das ist der violett hervorgehobene Bereich.
Statt der reelen 300 Höhenmeter zeigt RC so 520 Meter.
25.03.2022, 14:56 (This post was last modified: 25.03.2022, 14:58 by nordlicht.)
(25.03.2022, 13:57)routeconverter Wrote: Die SRTM1 Dateien decken m.W. nicht annähernd so viel Fläche ab.
SRTM1-Daten gibt es seit 2015 in dem Streifen von 56°S bis 60°N (darüberhinaus hat keine Erfassung stattgefunden) rund um den Globus vom USGS über deren EarthExplorer, Jonathan de Ferranti bietet 1"-Daten für Mittel- und Nordeuropa (also auch nördlich von 60°N) und einige Gebirge an. Europa sollte also flächendeckend verfügbar sein.
Ob Sonnys Daten für Europa vollständig sind, weiß ich nicht.
Steht auf 
