Corredores que planejam uma rota se importam com as subidas de um jeito difícil de avaliar apenas com um mapa plano, já que duas rotas com a mesma distância podem parecer completamente diferentes dependendo de quanta subida está concentrada nelas, e o quadro de pedidos de recursos de um aplicativo de corrida teve um item perto do topo durante meses: mostrar o perfil de altitude de uma rota planejada antes que alguém se comprometa a corrê-la.
O recurso de rotas do aplicativo já produzia uma sequência de coordenadas descrevendo uma corrida planejada, gerada a partir de um ponto de partida, um ponto de chegada e a própria lógica de busca de caminhos do aplicativo por ruas e trilhas reais. O que faltava eram os dados de altitude de cada ponto ao longo desse percurso. O /v1/elevation preencheu essa lacuna diretamente: uma lista de coordenadas enviada em uma única requisição voltava como uma lista correspondente de valores de altitude, na mesma ordem, pronta para ser plotada em relação à distância acumulada do corredor ao longo da rota.
O gráfico resultante, altitude em relação à distância, deu aos corredores exatamente o que o pedido de recurso vinha solicitando: uma visão clara de onde ficavam as subidas ao longo de uma corrida planejada, o quão íngreme cada uma parecia em relação ao resto da rota e um número de ganho total de altitude que se tornou, junto com a distância e o ritmo estimado, um dos números principais exibidos para cada rota salva no aplicativo.
A densidade de amostragem era importante para controlar o custo aqui, de forma semelhante à maneira como um aplicativo de ciclismo abordaria o mesmo problema. Uma corrida curta pelo bairro precisava de altitude amostrada com bastante frequência para produzir um gráfico suave e de aparência precisa, enquanto uma rota mais longa podia usar um intervalo de amostragem maior sem que o gráfico resultante parecesse visivelmente diferente para um corredor que olhasse rapidamente para ele, já que uma requisição de altitude em lote conta cada ponto como um item cobrado, e a equipe de engenharia do aplicativo ajustou o intervalo de amostragem de acordo com o comprimento da rota justamente para evitar solicitar muito mais pontos do que a resolução visual do gráfico resultante realmente exigia.
O aplicativo acrescentou mais um pequeno recurso com base nos mesmos dados: um selo de "dificuldade de subida" nas rotas salvas, calculado a partir do ganho total de altitude em relação à distância, dando aos corredores uma forma rápida de comparar duas rotas de comprimento semelhante sem ler um gráfico completo de cada uma, com um espírito parecido com a forma como um aplicativo de trilhas poderia usar o mesmo cálculo subjacente para a dificuldade das trilhas, só que ajustado para as distâncias mais curtas e as diferentes expectativas de ritmo de uma corrida típica, e não de uma caminhada.
O engajamento dos usuários com as rotas salvas aumentou depois do lançamento do recurso, o que a equipe do aplicativo atribuiu especificamente ao fato de os corredores se sentirem mais confiantes para se comprometer com uma rota desconhecida quando podiam ver o que realmente iam enfrentar em termos de subidas, em vez de descobrir a dificuldade de uma rota só no meio da primeira vez que a corriam.
As consultas de altitude eram feitas uma vez por rota salva, e não por corrida, já que o perfil de altitude de uma rota não muda entre uma corrida e outra, mantendo o volume total de requisições proporcional ao número de rotas distintas criadas pelos usuários, e não ao uso total do aplicativo, confortavelmente dentro da cota diária gratuita para um aplicativo com um número moderado de usuários ativos.
A documentação do endpoint, incluindo os limites de pontos por requisição, está em /docs/elevation-lookup/.