¿Cómo obtener un perfil de elevación para una pista gps?

Me gustaría obtener un perfil de elevación razonablemente preciso para una pista grabada con un GPS (que a menudo tiene datos de altitud muy poco confiables y ocasionalmente ninguno, según el modelo).

¿Alguien tiene alguna pista sobre la forma más fácil de hacer esto? Las dos técnicas que estoy considerando hasta ahora son:

• Usando la API de Google Elevation

  Esta API es relativamente fácil de usar, pero aún requiere algunos pasos que no son triviales debido a sus restricciones de uso: máximo 512 muestras devueltas por solicitud, y el número de puntos a lo largo de la ruta también está limitado (por la longitud de la URL).

  Espero que se pueda inventar un filtro de simplificación gpsbabel para reducir la pista a un número adecuado de puntos (no hay punto en que estén más cerca de 100 metros aproximadamente debido a la resolución de los datos de altitud), pero el problema sigue siendo cómo mapear Esta pista simplificada vuelve a la ruta original, ya que las longitudes serán diferentes.

  O, si esto no es adecuado para la automatización, el mejor enfoque puede ser permitir que el usuario seleccione los puntos de transección en un mapa manualmente.

• Descargando los datos de Shuttle Radar Topography Mission (SRTM) y haciendo la consulta localmente.

  Esto es algo con lo que no tengo experiencia, por lo que cualquier sugerencia sobre la factibilidad de esto es bienvenida. ¿Qué tan grande es el conjunto de datos? ¿Qué software SIG se requiere? ¿Se puede crear una secuencia de comandos adecuada? Prefiero no tener que escribir un algoritmo de muestreo e interpolación, que suena como un dolor . ¿Cuál es el rendimiento probable de tal enfoque? (Necesito que sea bastante rápido y se ejecute en un servidor web VPS con memoria limitada ...)

Algunos detalles adicionales para completar la respuesta de @ MerseyViking al volver a descargar los datos de http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Hay 72 x 24 mosaicos, cada uno sobre un archivo zip de 20mb que se descomprime en un archivo TIF de 72.1mb 16bit (6001x6001 píxeles).

Eso es ~ 120 gb, que es más de lo que puedo almacenar. Dejarlo comprimido e ignorar los océanos lo reducirá a unos 10 gb, que todavía es un poco demasiado grande. Cargar los datos a pedido reduciría drásticamente el espacio de almacenamiento necesario, pero el sitio de origen es lento (solo obtenía 10 kb / s), lo que hace que sea poco práctico.

Para una solución local, GRASS puede ser programado para hacer esto:

# 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

Ejecuté una versión extendida de esto para uno de mis casos de uso y el rendimiento de v.drape no fue un problema en absoluto.

gpsvisualizer.com lo hará por usted. Creo que está usando GPSBabel y Google API en segundo plano.

Parece que necesita esto como una solución genérica, es decir, tener todos los datos de elevación del mundo disponibles para cualquier pista que desee procesar, por lo tanto, no desea almacenar todos los datos de CGIAR localmente; El gpsvisualizer.com mencionado anteriormente (@Llaves) puede ser su mejor apuesta.

Si no necesita alta resolución, el conjunto de datos GTOPO (cuadrícula de 1 km) es solo ~ 300 MB para todo el planeta; de lo contrario, los conjuntos de datos ASTER GDEM (30m) y SRTM originales (90m) están disponibles pero, como usted señala, hay muchos datos. (El tamaño de los datos de ASTER se puede reducir después de la descarga eliminando los PDF incluidos que a menudo son más grandes que los datos de elevación reales; ¡el conjunto de datos de África se redujo en un 40% cuando hice esto!).

En R puede extraer el perfil de elevación de cualquiera de estos conjuntos de datos con bastante rapidez, aunque la carga del ráster puede llevar la mayor parte del tiempo. Utiliza una pequeña función readGPX personalizada y gpsbabel para procesar datos 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' ahora es una tabla de puntos GPS con lat / lon, otros datos GPX estándar (velocidad, elevación gps, etc.) y una columna de 'perfil' que indica la elevación en ese punto.

Los datos de SRTM son fáciles de descargar para un área determinada, he usado este sitio en el pasado. Los archivos no son enormes y puede obtenerlos como TIFF georreferenciados. La descarga de todo el mundo puede llevar un tiempo, pero un par de mosaicos cubren un área bastante grande. El problema que puede tener es con la resolución horizontal, que es de aproximadamente 90 metros para la mayor parte del mundo, y el error vertical puede ser bastante grande, con picos y áreas de datos faltantes.

El conjunto de datos ASTER GDEM es una encuesta más reciente y de mayor resolución con una resolución horizontal de ~ 30 m, pero la calidad suele ser inferior a los datos SRTM correspondientes.

No sé en qué resolución están los datos de elevación de Google, pero no me sorprendería si se basara en SRTM, por lo que usar la API de Google puede brindarle resultados similares a los de un proceso local.

Siguiendo la respuesta de @underdark, si se trata de un sistema simple basado en la web, GRASS GIS es probablemente el camino a seguir. He usado r.profile para hacer trazados simples de intervisibilidad con cierto éxito, pero no estoy seguro de qué método de interpolación utiliza; posiblemente sea el vecino más cercano. Editar : al mirar el código fuente , r.profilese usa el vecino más cercano, por lo que puede obtener algunos artefactos para subir escaleras.

Otra opción podría ser escribir un script de Python, usando GDAL y NumPy , que puede ser un poco más trabajo, pero sería una buena solución personalizada.

Primero debe especificar con qué tipo de precisión horizontal / vertical estaría satisfecho.

Pero veamos esto desde una perspectiva práctica:

• Cada mosaico SRTM3 tiene celdas de 1200x1200 , cada celda es un valor entero de dos bytes que representa la elevación en metros. Eso es alrededor de 2.75 MB de datos sin comprimir sin procesar.
• Hay 14042 fichas SRTM3. Eso es cca. 38 GB de datos en bruto.
• ¿Realmente necesitas cubrir todo el mundo? Me imagino que no hay mucho interés por mostrar el perfil de elevación de una pista GPS en el medio del Sahara, el desierto de Gobi o Siberia, por lo que no es económicamente factible que lo cubras si tienes poco dinero (BTW: SRTM3 no cubre todo el mundo , por lo que no necesita preocuparse por lugares como Groenlandia y la Antártida;)).
• Con un poco de compresión inteligente y codificación de datos, podría reducir drásticamente el tamaño del conjunto de datos. Los valores de elevación son de 0 a 8848, por lo que no se utilizan los dos bits restantes. También puede codificar elevaciones a través de la compresión delta para reducirla aún más. También puede renunciar a parte de la precisión vertical (por ejemplo, 2 m, que luego le ahorra un bit extra por cada celda.
• Dependiendo de qué tipo de pistas GPS se usará para esto (caminar, andar en bicicleta, conducir ...), debe almacenar los datos en mosaicos más pequeños (digamos 0.25x0.25 grados) como archivos en el disco o filas en una tabla de base de datos.
• Use un poco de memoria caché inteligente para los mosaicos, por lo que no necesita volver a cargar los que se usan con frecuencia.
• Calcular la elevación desde las celdas es la parte fácil de todo este negocio.