Come ottenere un profilo altimetrico per una traccia GPS?

Vorrei ottenere un profilo altimetrico ragionevolmente accurato per una traccia registrata con un GPS (che spesso ha dati di altitudine molto inaffidabili e occasionalmente nessuno, a seconda del modello).

Qualcuno ha qualche suggerimento sul modo più semplice per farlo. Le due tecniche che sto prendendo in considerazione finora sono:

• Usando il dell'API di elevazione di Google

  Questa API è relativamente facile da usare, ma richiede ancora alcuni passaggi che non sono banali a causa delle sue restrizioni di utilizzo: massimo 512 campioni restituiti per richiesta e il numero di punti lungo il percorso è limitato (dalla lunghezza dell'URL).

  Mi aspetto che un gpsbabel semplifichi il filtro per ridurre la traccia a un numero adeguato di punti (nessun punto è più vicino di 100m circa a causa della risoluzione dei dati di altitudine), ma rimane il problema di come mappare questa traccia semplificata ritorna sul percorso originale, poiché le lunghezze differiranno.

  Oppure, se questo non è adatto per l'automazione, l'approccio migliore potrebbe essere quello di consentire all'utente di selezionare manualmente i punti di transetto su una mappa.

• Scaricare i dati della missione di radar Radar Topography (SRTM) ed eseguire la query localmente.

  Questo è qualcosa con cui non ho esperienza, quindi qualsiasi suggerimento su quanto sia fattibile è il benvenuto. Quanto è grande il set di dati? Quale software GIS è richiesto e può essere copiato in modo adeguato? Preferirei non dover scrivere un algoritmo di campionamento e interpolazione, che suona come un dolore . Qual è la probabile prestazione di un tale approccio? (Ho bisogno che sia abbastanza veloce ed eseguito su un server web VPS con memoria limitata ...)

Alcuni ulteriori dettagli per arricchire la risposta di @ MerseyViking riguardo il download dei dati da http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Ci sono 72 x 24 tessere, ognuna circa un file zip da 20 MB che si decomprime in un file TIF a 16 bit da 72,1 MB (6001x6001 pixel).

Questo è ~ 120 GB, che è più di quello che posso memorizzare. Lasciandolo compresso e ignorando gli oceani lo ridurrà a forse 10 GB, che è ancora un po 'troppo grande. Caricare i dati su richiesta ridurrebbe drasticamente lo spazio di archiviazione necessario, ma il sito di origine è lento (stavo ottenendo solo 10kb / s) rendendolo piuttosto poco pratico.

Per una soluzione locale, GRASS può essere programmato per fare questo:

# 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

Ho eseguito una versione estesa di questo per uno dei miei casi d'uso e le prestazioni di v.drape non sono state affatto un problema.

gpsvisualizer.com farà questo per te. Credo che stia utilizzando GPSBabel e l'API di Google in background.

Sembra che tu abbia bisogno di questo come soluzione generica, vale a dire avere tutti i dati di elevazione del mondo disponibili per qualsiasi traccia che desideri elaborare, quindi non voler archiviare tutti i dati CGIAR localmente; gpsvisualizer.com sopra menzionato (@Llaves) potrebbe essere la soluzione migliore.

Se non hai bisogno di alta risoluzione, il set di dati GTOPO (griglia da 1 km) è solo ~ 300 MB per l'intero pianeta; in caso contrario, sono disponibili i set di dati ASTER GDEM (30m) e SRTM originali (90m) ma, come sottolineato, molti dati. (La dimensione dei dati ASTER può essere ridotta dopo il download rimuovendo i PDF raggruppati che sono spesso più grandi dei dati di elevazione effettivi - il set di dati Africa è stato ridotto del 40% quando l'ho fatto!).

In R è possibile estrarre il profilo di elevazione da uno qualsiasi di questi set di dati abbastanza rapidamente, anche se il caricamento del raster può richiedere la maggior parte del tempo. Questo utilizza una piccola funzione readGPX personalizzata e gpsbabel per elaborare i dati GPX:

#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' è ora una tabella di punti GPS con lat / lon, altri dati GPX standard (velocità, elevazione gps, ecc.) e una colonna 'profilo' che indica l'elevazione in quel punto.

I dati SRTM sono facili da scaricare per una determinata area, ho usato questo sito in passato. I file non sono enormi e puoi ottenerli come TIFF georeferenziati. Il download di tutto il mondo potrebbe richiedere del tempo, ma un paio di tessere coprono un'area piuttosto ampia. Il problema che potresti avere è con la risoluzione orizzontale, che è di circa 90 metri per la maggior parte del mondo, e l'errore verticale può essere piuttosto grande, con punte e aree di dati mancanti.

Il set di dati ASTER GDEM è un rilevamento più recente, con una risoluzione più elevata a una risoluzione orizzontale di ~ 30 m, ma la qualità è spesso inferiore ai corrispondenti dati SRTM.

Non so a quale risoluzione si trovino i dati di elevazione di Google, ma non sarei sorpreso se fosse basato su SRTM, quindi l'utilizzo dell'API di Google potrebbe darti risultati simili all'utilizzo di un processo locale.

In seguito alla risposta di @underdark, se si tratta di un semplice sistema basato sul web, GRASS GIS è probabilmente la strada da percorrere. Ho usato r.profile per fare semplici grafici di intervisibilità con un certo successo, ma non sono sicuro del metodo di interpolazione che utilizza; potrebbe essere il vicino più vicino. modificare : guardando il codice sorgente , r.profileusa il vicino più vicino, quindi potresti ottenere alcuni manufatti per scalare le scale.

Un'altra opzione potrebbe essere quella di scrivere uno script Python, usando GDAL e NumPy , che potrebbe essere un po 'più di lavoro, ma renderebbe una bella soluzione personalizzata.

Innanzitutto è necessario specificare il tipo di precisione orizzontale / verticale di cui si sarebbe soddisfatti.

Ma vediamo questo da una prospettiva pratica:

• Ogni riquadro SRTM3 ha celle 1200x1200 , ogni cella ha un valore intero a due byte che rappresenta l'elevazione in metri. Sono circa 2,75 MB di dati grezzi non compressi.
• Ci sono 14042 tessere SRTM3. Questo è cca. 38 GB di dati non elaborati.
• Hai davvero bisogno di coprire tutto il mondo? Immagino che non ci sia molto interesse per la visualizzazione del profilo altimetrico di una traccia GPS nel mezzo del Sahara, del deserto del Gobi o della Siberia, quindi non è economicamente fattibile coprirlo se si è a corto di liquidità (BTW: SRTM3 non copre tutto il mondo , quindi non devi preoccuparti di luoghi come la Groenlandia e l'Antartide;)).
• Con una compressione e una codifica dei dati intelligenti è possibile ridurre drasticamente le dimensioni del set di dati. I valori di elevazione sono compresi tra 0 e 8848, quindi i due bit rimanenti non vengono utilizzati. È inoltre possibile codificare elevazioni attraverso la compressione delta per ridurla ulteriormente. Potresti anche rinunciare a una parte della precisione verticale (ad esempio, 2 m, che ti consente di risparmiare un ulteriore bit per ogni cella.
• A seconda del tipo di traccia GPS che verrà utilizzato (a piedi, in bicicletta, in auto ...), è necessario archiviare i dati in riquadri più piccoli (ad esempio 0,25x0,25 gradi) come file sul disco o righe in una tabella del database.
• Usa una cache di memoria intelligente per i riquadri in modo da non dover ricaricare quelli usati di frequente.
• Calcolare l'elevazione dalle celle è la parte facile di tutta questa attività.