Comment obtenir un profil d'altitude pour une piste GPS?

J'aimerais obtenir un profil d'altitude raisonnablement précis pour une trace enregistrée avec un GPS (qui a souvent des données d'altitude très peu fiables et parfois aucune du tout, selon le modèle).

Quelqu'un at-il des conseils sur la façon la plus simple de le faire? Les deux techniques que j'envisage jusqu'à présent sont:

• Utilisation de l' API Google Elevation

  Cette API est relativement facile à utiliser, mais nécessite toujours quelques étapes qui ne sont pas triviales en raison de ses restrictions d'utilisation: max 512 échantillons retournés par demande, et le nombre de points le long du chemin est également limité (par la longueur de l'URL).

  Je m'attends à ce qu'un filtre gpsbabel simplify puisse être concocté pour réduire la piste à un nombre approprié de points (aucun point en eux étant à moins de 100m environ en raison de la résolution des données d'altitude), mais le problème reste de savoir comment cartographier cette piste simplifiée revient sur le chemin d'origine, car les longueurs seront différentes.

  Ou, si cela ne convient pas à l'automatisation, la meilleure approche peut être de laisser l'utilisateur sélectionner manuellement les points de transect sur une carte.

• Téléchargement des données de la mission de topographie radar Shuttle (SRTM) et exécution de la requête localement.

  C'est une chose avec laquelle je n'ai aucune expérience, donc toute suggestion sur la faisabilité de ceci est la bienvenue. Quelle est la taille de l'ensemble de données? Quel logiciel SIG est requis et peut-il être scénarisé de manière appropriée? Je préférerais ne pas avoir à écrire un algorithme d'échantillonnage et d'interpolation, qui sonne comme une douleur . Quelle est la performance probable d'une telle approche? (J'ai besoin qu'il soit assez rapide et s'exécute sur un serveur Web VPS à mémoire limitée ...)

Quelques détails supplémentaires pour étoffer la réponse de @ MerseyViking concernant le téléchargement des données depuis http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Il y a 72 x 24 tuiles, chacune d'environ un fichier zip de 20 Mo qui se décompresse en un fichier TIF de 72,1 Mo 16 bits (6001x6001 pixels).

C'est ~ 120 Go, ce qui est plus que ce que je peux stocker. Le laisser compressé et ignorer les océans le réduira peut-être à 10 Go, ce qui est encore un peu trop grand. Le chargement des données à la demande réduirait considérablement l'espace de stockage nécessaire, mais le site source est lent (je n'obtenais que 10 Ko / s), ce qui est assez peu pratique.

Pour une solution locale, GRASS peut être scripté pour ce faire:

# 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

J'ai exécuté une version étendue de cela pour l'un de mes cas d'utilisation et les performances de v.drape ne posaient aucun problème.

gpsvisualizer.com le fera pour vous. Je pense qu'il utilise GPSBabel et l'API Google en arrière-plan.

Il semble que vous en ayez besoin en tant que solution générique, c'est-à-dire en ayant à votre disposition toutes les données d'élévation du monde pour toute piste que vous souhaitez traiter, donc ne pas vouloir stocker toutes les données CGIAR localement; le gpsvisualizer.com mentionné ci-dessus (@Llaves) peut être votre meilleur pari.

Si vous n'avez pas besoin d'une haute résolution, l' ensemble de données GTOPO (grille de 1 km) ne représente que ~ 300 Mo pour la planète entière; sinon, les jeux de données ASTER GDEM (30 m) et SRTM (90 m) d'origine sont disponibles mais, comme vous le signalez, beaucoup de données. (La taille des données ASTER peut être réduite après le téléchargement en supprimant les fichiers PDF groupés qui sont souvent plus grands que les données d'élévation réelles - l'ensemble de données Afrique a été réduit de 40% lorsque j'ai fait cela!).

Dans R, vous pouvez extraire le profil d'élévation de n'importe lequel de ces ensembles de données assez rapidement, bien que le chargement du raster puisse prendre la majorité du temps. Cela utilise une petite fonction readGPX personnalisée et gpsbabel pour traiter les données 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' est maintenant un tableau de points GPS avec lat / lon, d'autres données GPX standard (vitesse, altitude gps, etc.), et une colonne 'profile' qui indique l'altitude à ce point.

Les données SRTM sont faciles à télécharger pour une zone donnée, j'ai utilisé ce site dans le passé. Les fichiers ne sont pas énormes et vous pouvez les obtenir sous forme de fichiers TIFF géoréférencés. Le téléchargement du monde entier peut prendre un certain temps, mais quelques tuiles couvrent une assez grande surface. Le problème que vous pourriez avoir concerne la résolution horizontale, qui est d'environ 90 mètres pour la plupart du monde, et l'erreur verticale peut être assez importante, avec des pointes et des zones de données manquantes.

Le jeu de données ASTER GDEM est un levé plus récent et à plus haute résolution à une résolution horizontale de ~ 30 m, mais la qualité est souvent inférieure aux données SRTM correspondantes.

Je ne sais pas à quelle résolution se trouvent les données d'élévation de Google, mais je ne serais pas surpris si elles étaient basées sur SRTM, donc l'utilisation de l'API Google peut vous donner des résultats similaires à l'utilisation d'un processus local.

Dans la continuité de la réponse de @underdark, s'il s'agit d'un simple système basé sur le Web, GRASS GIS est probablement la voie à suivre. J'ai utilisé r.profile pour faire des tracés d'intervisibilité simples avec un certain succès mais je ne sais pas quelle méthode d'interpolation il utilise; ce pourrait être juste le plus proche voisin. Edit : En regardant le code source , r.profileutilise le plus proche voisin, donc vous pourriez obtenir des artefacts de marche d'escalier.

Une autre option pourrait être d'écrire un script Python, en utilisant GDAL et NumPy , ce qui peut être un peu plus de travail, mais ferait une belle solution personnalisée.

Vous devez d'abord spécifier le type de précision horizontale / verticale dont vous seriez satisfait.

Mais regardons cela d'un point de vue pratique:

• Chaque tuile SRTM3 a des cellules de 1200 x 1200 , chaque cellule est une valeur entière de deux octets représentant l'élévation en mètres. Cela représente environ 2,75 Mo de données brutes non compressées.
• Il y a 14042 tuiles SRTM3. C'est ça. 38 Go de données brutes.
• Avez-vous vraiment besoin de couvrir le monde entier? J'imagine qu'il n'y a pas grand intérêt à afficher le profil d'altitude d'une piste GPS au milieu du Sahara, du désert de Gobi ou de la Sibérie, il n'est donc pas économiquement faisable pour vous de le couvrir si vous êtes à court d'argent (BTW: SRTM3 ne couvre pas le monde entier , vous n'avez donc pas à vous soucier d'endroits comme le Groenland et l'Antarctique;)).
• Avec une compression et un encodage de données intelligents, vous pouvez réduire considérablement la taille de l'ensemble de données. Les valeurs d'élévation sont comprises entre 0 et 8848, les deux bits restants ne sont donc pas utilisés. Vous pouvez également coder les élévations via la compression delta pour la réduire encore plus. Vous pouvez également renoncer à une partie de la précision verticale (jusqu'à, disons, 2 m, ce qui vous permet d'économiser un bit supplémentaire pour chaque cellule).
• Selon les types de traces GPS utilisées (marche, vélo, conduite ...), vous devez stocker les données dans des tuiles plus petites (par exemple 0,25x0,25 degrés) sous forme de fichiers sur le disque ou de lignes dans une table de base de données.
• Utilisez un cache mémoire intelligent pour les tuiles afin que vous n'ayez pas besoin de recharger celles souvent utilisées.
• Le calcul de l'élévation à partir des cellules est la partie la plus simple de toute cette entreprise.