Como obter um perfil de elevação para uma pista de GPS?

Gostaria de obter um perfil de elevação razoavelmente preciso para uma pista gravada com um GPS (que geralmente possui dados de altitude pouco confiáveis ​​e, ocasionalmente, nenhum, dependendo do modelo).

Alguém tem alguma dica sobre a maneira mais fácil de fazer isso. As duas técnicas que estou considerando até agora são:

• Usando a API do Google Elevation

  Essa API é relativamente fácil de usar, mas ainda exige algumas etapas que não são triviais devido às restrições de uso: no máximo 512 amostras retornadas por solicitação e o número de pontos ao longo do caminho também é limitado (pelo tamanho da URL).

  Eu espero que um filtro de simplificação de gpsbabel possa ser inventado para reduzir a faixa a um número adequado de pontos (nenhum ponto neles estando mais próximos do que 100m ou mais devido à resolução dos dados de altitude), mas o problema permanece em como mapear essa faixa simplificada volta ao caminho original, pois os comprimentos serão diferentes.

  Ou, se isso não for adequado para automação, a melhor abordagem pode ser permitir que o usuário selecione os pontos de transecção em um mapa manualmente.

• Fazendo o download dos dados da SRTM (Shuttle Radar Topography Mission) e fazendo a consulta localmente.

  Isso é algo com o qual não tenho experiência; portanto, todas as sugestões sobre como isso é viável são bem-vindas. Qual é o tamanho do conjunto de dados? Qual software GIS é necessário e pode ser script de maneira adequada? Eu preferiria não ter que escrever um algoritmo de amostragem e interpolação, que soa como uma dor . Qual é o desempenho provável de tal abordagem? (Eu preciso que ele seja bem rápido e execute em um servidor VPS com memória limitada ...)

Mais alguns detalhes para esclarecer a resposta de @ MerseyViking ao baixar os dados de http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp :

Existem 72 x 24 blocos, cada um com um arquivo zip de 20mb que é descompactado para um arquivo TIF de 72,1mb e 16 bits (6001x6001 pixels).

Isso é ~ 120 GB, o que é mais do que posso armazenar. Deixá-lo compactado e ignorando os oceanos o reduzirá para talvez 10 GB, o que ainda é um pouco grande demais. O carregamento dos dados sob demanda reduziria drasticamente o espaço de armazenamento necessário, mas o site de origem é lento (eu estava obtendo apenas 10kb / s), tornando isso bastante impraticável.

Para uma solução local, o GRASS pode ser script para fazer isso:

# 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

Eu executei uma versão estendida disso para um dos meus casos de uso e o desempenho do v.drape não foi um problema.

O gpsvisualizer.com fará isso por você. Acredito que esteja usando o GPSBabel e a API do Google em segundo plano.

Parece que você precisa disso como uma solução genérica, ou seja, ter todos os dados de elevação do mundo disponíveis para qualquer pista que você deseja processar, portanto, não deseja armazenar todos os dados do CGIAR localmente; o gpsvisualizer.com mencionado acima (@Llaves) pode ser sua melhor aposta.

Se você não precisa de alta resolução, o conjunto de dados GTOPO (grade de 1 km) é de apenas ~ 300 MB para todo o planeta; caso contrário, os conjuntos de dados ASTER GDEM (30m) e SRTM (90m) estão disponíveis, mas, como você ressalta, muitos dados. (O tamanho dos dados do ASTER pode ser reduzido após o download, removendo os PDFs agrupados, que geralmente são maiores que os dados reais de elevação - o conjunto de dados da África foi reduzido em 40% quando eu fiz isso!).

Em R, você pode extrair o perfil de elevação de qualquer um desses conjuntos de dados rapidamente - embora o carregamento da varredura possa demorar a maior parte do tempo. Isso usa uma pequena função readGPX personalizada e gpsbabel para processar dados 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' agora é uma tabela de pontos GPS com lat / lon, outros dados GPX padrão (velocidade, elevação de gps, etc.) e uma coluna 'profile' que indica a elevação nesse ponto.

É fácil fazer o download dos dados do SRTM para uma determinada área, usei este site no passado. Os arquivos não são enormes e você pode obtê-los como TIFFs georreferenciados. O download do mundo inteiro pode demorar um pouco, mas algumas peças cobrem uma área bastante grande. O problema que você pode ter é com resolução horizontal, que é de cerca de 90 metros para a maior parte do mundo, e o erro vertical pode ser bastante grande, com picos e áreas com dados ausentes.

O conjunto de dados ASTER GDEM é uma pesquisa de resolução mais recente e mais recente com resolução horizontal de ~ 30m, mas a qualidade geralmente é mais baixa que os dados SRTM correspondentes.

Não sei em que resolução estão os dados de elevação do Google, mas não ficaria surpreso se fossem baseados no SRTM; portanto, o uso da API do Google pode fornecer resultados semelhantes aos do processo local.

Seguindo a resposta de @underdark, se este for um sistema simples baseado na Web, GRASS GIS é provavelmente o caminho a percorrer. Eu usei o r.profile para fazer gráficos de intervisibilidade simples com algum sucesso, mas não sei ao certo qual método de interpolação ele usa; pode ser apenas o vizinho mais próximo. Edit : Olhando para o código-fonte , r.profileusa o vizinho mais próximo, para que você possa obter alguns artefatos de subir escadas.

Outra opção pode ser escrever um script Python, usando GDAL e NumPy , o que pode ser um pouco mais trabalhoso, mas seria uma boa solução personalizada.

Primeiro, você deve especificar com que tipo de precisão horizontal / vertical você ficaria satisfeito.

Mas vamos olhar para isso de uma perspectiva prática:

• Cada bloco SRTM3 possui células de 1200x1200 , cada célula é um valor inteiro de dois bytes que representa a elevação em metros. Isso representa cerca de 2,75 MB de dados brutos não compactados.
• Existem 14042 blocos SRTM3. Isso é cca. 38 GB de dados brutos.
• Você realmente precisa cobrir o mundo inteiro? Imagino que não exista muito interesse em exibir o perfil de elevação de uma faixa de GPS no meio do Saara, no Deserto de Gobi ou na Sibéria, por isso não é economicamente viável cobri-lo se você estiver sem dinheiro (BTW: SRTM3 não cobre o mundo inteiro , para que você não precise se preocupar com lugares como a Groenlândia e a Antártica;)).
• Com alguma compactação inteligente e codificação de dados, você pode reduzir drasticamente o tamanho do conjunto de dados. Os valores de elevação são de 0 a 8848, portanto, os dois bits restantes não são usados. Você também pode codificar elevações através da compactação delta para reduzi-la ainda mais. Você também pode abdicar de alguma precisão vertical (para, digamos, 2m, que economiza um bit extra para cada célula.
• Dependendo dos tipos de trilhas de GPS em que isso será usado (caminhada, ciclismo, direção ...), você deve armazenar os dados em blocos menores (digamos 0,25x0,25 graus) como arquivos no disco ou linhas em uma tabela de banco de dados.
• Use um cache de memória inteligente para blocos, para que você não precise recarregar os mais usados.
• Calcular a elevação a partir das células é a parte fácil de todo esse negócio.