A distância sozinha é uma forma ruim de avaliar o quão difícil uma trilha realmente é. Uma trilha plana de seis milhas à beira de um rio e uma trilha de seis milhas que sobe uma montanha apareciam com o mesmo rótulo de "moderada, seis milhas" no diretório de um aplicativo de guia de trilhas, uma classificação que gerava um fluxo constante de reclamações de trilheiros que confiaram na classificação moderada e se viram em uma subida muito mais difícil do que aquela para a qual tinham se preparado.
O aplicativo já armazenava cada trilha como uma sequência de coordenadas que traçava o seu percurso, coletadas a partir de gravações de GPS enviadas por colaboradores. O que faltava era a altitude ao longo desse percurso, o dado que realmente diferencia uma caminhada plana de uma subida séria com a mesma distância. O /v1/elevation recebia a lista completa de coordenadas de uma trilha, já que uma requisição em lote aceita uma lista de pontos e retorna a altitude de cada um, e o aplicativo recebia de volta um valor de altitude para cada ponto ao longo do percurso gravado, ainda na mesma ordem em que foram enviados.
A partir dessa lista, calcular o ganho total de altitude, a soma de cada variação para cima ao longo da rota, era uma aritmética simples que o próprio backend do aplicativo fazia. O ganho total, combinado com a distância, produzia um indicador de dificuldade realmente mais útil do que a distância sozinha: uma trilha com muito ganho em uma distância curta era classificada como íngreme e difícil, por mais curta que parecesse no papel, enquanto uma trilha longa e plana era classificada como mais fácil apesar do comprimento, correspondendo muito mais ao que os trilheiros realmente vivem no terreno do que o antigo sistema baseado apenas na distância.
O aplicativo reconstruiu a sua classificação de dificuldade em torno desse número combinado e recalculou retroativamente todas as trilhas que já estavam no diretório, um processamento em lote pontual sobre toda a biblioteca de trilhas. Esse lote foi a maior requisição que o aplicativo já enviou e, como uma requisição de altitude em lote conta cada ponto como um item cobrado, e não cada trilha, o tamanho exato do trabalho dependia de quantos pontos de coordenadas existiam em toda a biblioteca, e não do número de trilhas, algo que a equipe levou em conta ao estimar o custo com antecedência, em vez de ser surpreendida depois.
Além da classificação de dificuldade principal, os mesmos dados de altitude permitiram que o aplicativo mostrasse um gráfico de perfil de subida em cada página de trilha, parecido com o que um aplicativo de ciclismo poderia mostrar, deixando o trilheiro ver exatamente onde ficavam os trechos íngremes ao longo da rota, em vez de conhecer apenas um rótulo de dificuldade agregado. Trilheiros que queriam se preparar para um trecho difícil específico, e não apenas saber que uma trilha era difícil no geral, acharam o gráfico mais útil do que o rótulo sozinho.
As consultas de altitude contínuas após o lote inicial eram geradas pelo envio de novas trilhas, um volume muito menor e mais estável do que o do projeto pontual de recálculo, confortavelmente dentro da cota diária gratuita para o ritmo típico de novos envios dos colaboradores do aplicativo.
Um sistema de classificação é tão bom quanto os dados por trás dele, e a altitude acabou sendo o dado que faltava desde o início para a classificação de dificuldade do aplicativo. A documentação do endpoint, incluindo os limites de pontos por requisição, está em /docs/elevation-lookup/.