Wie bekomme ich ein Höhenprofil für eine GPS-Strecke?

Ich möchte ein einigermaßen genaues Höhenprofil für eine mit einem GPS aufgezeichnete Strecke erhalten (die häufig sehr unzuverlässige Höhendaten enthält und gelegentlich, je nach Modell, überhaupt keine).

Hat jemand irgendwelche Hinweise auf den einfachsten Weg, dies zu tun. Die beiden Techniken, die ich bisher in Betracht ziehe, sind:

• Verwenden der Google Elevation-API

  Diese API ist relativ einfach zu verwenden, erfordert jedoch einige Schritte, die aufgrund der Nutzungsbeschränkungen nicht trivial sind: Es werden maximal 512 Beispiele pro Anforderung zurückgegeben, und die Anzahl der Punkte entlang des Pfads ist ebenfalls begrenzt (durch die URL-Länge).

  Ich gehe davon aus, dass ein gpsbabel simplify-Filter zusammengestellt werden kann, um die Spur auf eine geeignete Anzahl von Punkten zu reduzieren (kein Punkt in ihnen ist näher als etwa 100 m zusammen, da die Höhendaten aufgelöst sind), aber dann bleibt das Problem der Kartenerstellung bestehen Diese vereinfachte Spur führt zurück auf den ursprünglichen Pfad, da die Längen unterschiedlich sein werden.

  Wenn dies nicht für die Automatisierung geeignet ist, empfiehlt es sich, die Schnittpunkte auf einer Karte manuell auszuwählen.

• Herunterladen der SRTM-Daten (Shuttle Radar Topography Mission) und lokale Abfrage.

  Dies ist etwas, mit dem ich keine Erfahrung habe, daher sind Vorschläge, wie dies machbar ist, willkommen. Wie groß ist der Datensatz? Welche GIS-Software wird benötigt und kann in geeigneter Weise gescriptet werden? Ich würde es vorziehen, keinen Abtast- und Interpolationsalgorithmus zu schreiben, der sich nach Schmerz anhört . Was ist die wahrscheinliche Leistung eines solchen Ansatzes? (Ich brauche es, um ziemlich schnell zu sein und auf einem speicherbegrenzten VPS-Webserver zu laufen ...)

Einige weitere Details zur Ausarbeitung der Antwort von @ MerseyViking beim Herunterladen der Daten von http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Es gibt 72 x 24 Kacheln mit jeweils etwa 20 MB ZIP-Datei, die in eine 72,1 MB 16-Bit-TIF-Datei (6001 x 6001 Pixel) dekomprimiert wird.

Das sind ~ 120 GB, mehr als ich speichern kann. Wenn Sie es komprimiert lassen und die Ozeane ignorieren, wird es möglicherweise auf 10 GB reduziert, was immer noch ein bisschen zu groß ist. Das Laden der Daten bei Bedarf würde den benötigten Speicherplatz drastisch reduzieren, aber die Quellwebsite ist langsam (ich habe nur 10 KBit / s erhalten), was dies ziemlich unpraktisch macht.

Für eine lokale Lösung kann GRASS folgendermaßen skriptiert werden:

# extract raster values at our points
# use cubic convolution for interpolation between DEM locations
v.drape in=my_pts out=pts_srtm_elev type=point rast=srtm_dem method=cubic

Ich habe eine erweiterte Version für einen meiner Anwendungsfälle ausgeführt, und die Leistung von v.drape war überhaupt kein Problem.

gpsvisualizer.com erledigt das für Sie. Ich glaube, es verwendet GPSBabel und Google API im Hintergrund.

Es hört sich so an, als ob Sie dies als generische Lösung benötigen, dh Sie haben alle Höhendaten der Welt für jede Spur zur Verfügung, die Sie verarbeiten möchten, und möchten daher nicht alle CGIAR-Daten lokal speichern. Das oben erwähnte gpsvisualizer.com (@Llaves) ist möglicherweise die beste Wahl.

Wenn Sie keine hohe Auflösung benötigen, beträgt der GTOPO-Datensatz (1 km-Raster) nur ~ 300 MB für den gesamten Planeten. Andernfalls stehen die Datensätze ASTER GDEM (30 m) und Original SRTM (90 m) zur Verfügung, Sie weisen jedoch darauf hin, dass viele Daten vorhanden sind. (Die Größe der ASTER-Daten kann nach dem Download reduziert werden, indem die gebündelten PDF-Dateien entfernt werden, die häufig größer als die tatsächlichen Höhendaten sind - der Afrika-Datensatz wurde dabei um 40% reduziert!).

In R können Sie das Höhenprofil relativ schnell aus einem dieser Datasets extrahieren. Das Laden des Rasters kann jedoch die meiste Zeit in Anspruch nehmen. Dies verwendet eine kleine benutzerdefinierte readGPX-Funktion und gpsbabel, um GPX-Daten zu verarbeiten:

#Load elevation model and process track:
dem <- raster("E020N40.DEM")
track <- readGPXt("trackfile.gpx")
coordinates(track) <- ~Longitude+Latitude
proj4string(track) <- "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
#Overlay (extract) the elevation data for the track points:
track$profile <- extract(dem, track)
track <- as.data.frame(track)

'track' ist jetzt eine Tabelle mit GPS-Punkten mit Lat / Lon, anderen Standard-GPX-Daten (Geschwindigkeit, GPS-Höhe usw.) und einer 'profile'-Spalte, die die Höhe an diesem Punkt angibt.

SRTM-Daten können für einen bestimmten Bereich einfach heruntergeladen werden. Ich habe diese Site in der Vergangenheit verwendet. Die Dateien sind nicht riesig und können als georeferenzierte TIFFs abgerufen werden. Das Herunterladen der ganzen Welt kann eine Weile dauern, aber ein paar Kacheln bedecken einen ziemlich großen Bereich. Das Problem, das Sie möglicherweise haben, ist die horizontale Auflösung, die für den größten Teil der Welt etwa 90 Meter beträgt, und der vertikale Fehler kann mit Spitzen und Bereichen mit fehlenden Daten recht groß sein.

Der ASTER GDEM-Datensatz ist eine neuere Vermessung mit höherer Auflösung und einer horizontalen Auflösung von ca. 30 m, die Qualität ist jedoch häufig geringer als die entsprechenden SRTM-Daten.

Ich weiß nicht, mit welcher Auflösung die Google-Höhendaten vorliegen, wäre aber nicht überrascht, wenn sie auf SRTM basieren. Daher kann die Verwendung der Google-API zu ähnlichen Ergebnissen führen wie die Verwendung eines lokalen Prozesses.

Nach der Antwort von @underdark ist GRASS GIS wahrscheinlich der richtige Weg, wenn dies ein einfaches webbasiertes System sein soll . Ich habe r.profile verwendet, um einfache Intervisibility-Diagramme mit einigem Erfolg zu erstellen , bin mir jedoch nicht sicher, welche Interpolationsmethode verwendet wird. es könnte möglicherweise nur der nächste Nachbar sein. Bearbeiten : Wenn Sie sich den Quellcode ansehen , r.profilewird der nächste Nachbar verwendet, sodass Sie möglicherweise einige Treppenstufen-Artefakte erhalten.

Eine andere Möglichkeit könnte darin bestehen, ein Python-Skript mit GDAL und NumPy zu schreiben , was zwar etwas aufwändiger ist, aber eine schöne, benutzerdefinierte Lösung darstellt.

Als erstes sollten Sie angeben, mit welcher horizontalen / vertikalen Genauigkeit Sie zufrieden wären.

Aber schauen wir uns das aus praktischer Sicht an:

• Jede SRTM3-Kachel hat 1200x1200 Zellen . Jede Zelle ist eine 2-Byte-Ganzzahl, die die Höhe in Metern darstellt. Das sind ungefähr 2,75 MB unkomprimierte Rohdaten.
• Es gibt 14042 SRTM3-Kacheln. Das ist cca. 38 GB Rohdaten.
• Müssen Sie wirklich die ganze Welt abdecken? Ich stelle mir vor, dass die Anzeige des Höhenprofils eines GPS-Tracks in der Mitte der Sahara, in der Wüste Gobi oder in Sibirien nicht sehr interessant ist. Daher ist es wirtschaftlich nicht machbar, dass Sie das Profil abdecken, wenn Sie in Geldnot sind ( Übrigens : SRTM3 deckt nicht ab die ganze Welt , Sie brauchen also nicht zu befürchten Orten wie Grönland und der Antarktis;)).
• Mit etwas cleverer Komprimierung und Datencodierung können Sie die Datenmenge drastisch reduzieren. Die Höhenwerte reichen von 0 bis 8848, sodass die beiden verbleibenden Bits nicht verwendet werden. Sie können auch Erhöhungen durch die Delta-Komprimierung codieren, um sie noch weiter zu reduzieren. Sie können auch einen Teil der vertikalen Genauigkeit (z. B. 2 m) aufgeben, wodurch Sie ein zusätzliches Bit für jede Zelle sparen.
• Abhängig davon, für welche Arten von GPS-Tracks diese verwendet werden (Gehen, Radfahren, Fahren ...), sollten Sie die Daten in kleineren Kacheln (z. B. 0,25 x 0,25 Grad) als Dateien auf der Festplatte oder in Zeilen in einer Datenbanktabelle speichern.
• Verwenden Sie einen cleveren Speicher-Cache für Kacheln, damit Sie häufig verwendete Kacheln nicht neu laden müssen.
• Das Berechnen der Höhe aus Zellen ist der einfache Teil dieses gesamten Geschäfts.