Monitore o uso da sua chave antes de atingir um limite
Acompanhar seus cabeçalhos de cota ao longo do caminho mostra quando um limite está se aproximando, bem antes de uma requisição ser realmente rejeitada.
Um arquivo GPX gravado por um celular ou por um GPS básico muitas vezes tem valores de altitude totalmente ausentes ou visivelmente imprecisos, já que as leituras de altitude do GPS de consumo costumam ser bem menos confiáveis do que a latitude e a longitude que ele registra.
Analise os pontos de trilha do arquivo GPX, extraindo apenas a latitude e a longitude de cada um, e descarte os valores de altitude existentes que você pretende substituir.
<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>Envie as coordenadas extraídas para /v1/elevation, pelo parâmetro points no caso de um arquivo menor ou por um array em POST em lote no caso de um maior.
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
]
}Nem todo uso exige processar uma trilha inteira. Antes de publicar a descrição de uma caminhada, uma única chamada confirma a altitude no próprio início da trilha.
GET /v1/elevation?lat=45.8326&lon=6.8652Isso retorna a mesma estrutura de resultado com uma única entrada, útil para conferir pontualmente um valor de altitude inicial ou final citado em notas de trilha sem precisar mexer no arquivo GPX completo.
Os resultados voltam na mesma ordem das coordenadas enviadas, então grave elevation_m de volta na tag ele de cada ponto de trilha correspondendo pela posição, substituindo o valor originalmente gravado pelo valor consultado.
<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>Não misture o formato do parâmetro de consulta points e um corpo POST em lote em um mesmo trabalho sem ser consistente na forma de associar os resultados aos pontos de trilha. O parâmetro points e o array JSON retornam resultados na ordem informada, mas buscar as coordenadas de um ponto por parâmetro de consulta e o restante por POST em lote, e depois juntar os dois conjuntos de respostas por suposição em vez de por correspondência explícita de coordenadas, é uma forma fácil de introduzir um erro de deslocamento por um no arquivo gravado.
Um arquivo GPX pode ter milhares de pontos de trilha gravados em intervalos curtos. Enriquecer cada um deles é uma requisição por ponto, o que se acumula em uma trilha longa. Reduzir a amostragem para um intervalo maior antes da consulta de altitude e depois interpolar entre os valores consultados para os pontos intermediários é uma forma razoável de reduzir o número de requisições e ainda produzir um perfil com aparência precisa.
Uma trilha que desce ao longo de um litoral ou atravessa um delta de baixa altitude pode legitimamente retornar um valor de elevation_m igual ou próximo de zero, ou ocasionalmente um pequeno número negativo para terras abaixo do nível do mar. Nenhum dos dois é um erro. Trate um valor próximo de zero como uma leitura real plausível para aquele terreno, em vez de descartá-lo como um dado ruim.
Cada ponto enriquecido é uma requisição. Uma trilha de caminhada modesta com algumas centenas de pontos, reamostrada a partir de uma gravação bruta muito maior, fica bem dentro das 2.500 requisições gratuitas por dia incluídas em cada chave.
Limpar os dados de altitude dessa forma transforma uma trilha instável gravada pelo celular em algo que vale a pena compartilhar ou analisar. A documentação da consulta de altitude descreve tanto o parâmetro points quanto o formato de requisição em lote.