A los corredores que planifican una ruta les importan las cuestas de una forma difícil de valorar solo con un mapa plano, ya que dos rutas de la misma distancia pueden sentirse completamente distintas según cuánto desnivel concentren, y el tablón de solicitudes de funciones de una app de running tuvo durante meses un elemento cerca de lo más alto: mostrar el perfil de elevación de una ruta planificada antes de que alguien se decida a correrla.
La función de rutas de la app ya generaba una secuencia de coordenadas que describía una carrera planificada, obtenida a partir de un punto de inicio, un punto final y la propia lógica de búsqueda de caminos de la app por calles y senderos reales. Lo que faltaba eran los datos de elevación de cada punto de ese recorrido. /v1/elevation cubrió ese hueco directamente: una lista de coordenadas enviada en una sola solicitud volvía como una lista equivalente de valores de elevación, en el mismo orden, lista para representarla frente a la distancia acumulada del corredor a lo largo de la ruta.
El gráfico resultante, elevación frente a distancia, dio a los corredores exactamente lo que pedía la solicitud de función: una visión clara de dónde estaban las subidas a lo largo de una carrera planificada, lo empinada que parecía cada una en comparación con el resto de la ruta y una cifra de desnivel positivo total que se convirtió, junto con la distancia y el ritmo estimado, en uno de los números principales que se muestran para cada ruta guardada en la app.
La densidad de muestreo importaba aquí para controlar el coste, de forma parecida a como una app de ciclismo abordaría el mismo problema. Una carrera corta por el barrio necesitaba muestrear la elevación con bastante frecuencia para producir un gráfico suave y de aspecto preciso, mientras que una ruta más larga podía usar un intervalo de muestreo más amplio sin que el gráfico resultante pareciera notablemente distinto a un corredor que le echara un vistazo, ya que una solicitud masiva de elevación cuenta cada punto como un elemento facturado, y el equipo de ingeniería de la app ajustó el intervalo de muestreo según la longitud de la ruta precisamente para no solicitar muchos más puntos de los que la resolución visual del gráfico resultante necesitaba realmente.
La app añadió una pequeña función más sobre los mismos datos: una insignia de "dificultad de subida" en las rutas guardadas, calculada a partir del desnivel positivo total en relación con la distancia, que daba a los corredores una forma rápida de comparar dos rutas de longitud similar sin leer un gráfico completo para cada una, con un espíritu parecido a cómo una app de senderismo podría usar el mismo cálculo subyacente para la dificultad de los senderos, solo que ajustado a las distancias más cortas y a las distintas expectativas de ritmo de una carrera típica en lugar de una caminata.
La interacción de los usuarios con las rutas guardadas aumentó tras el lanzamiento de la función, algo que el equipo de la app atribuyó específicamente a que los corredores se sentían más seguros al lanzarse a una ruta desconocida una vez que podían ver en qué se estaban metiendo en cuanto a subidas, en lugar de descubrir la dificultad de una ruta a mitad de camino la primera vez que la corrían.
Las consultas de elevación se ejecutaban una vez por ruta guardada y no por carrera, ya que el perfil de elevación de una ruta no cambia de una carrera a otra, lo que mantenía el volumen total de solicitudes proporcional al número de rutas distintas que creaban los usuarios y no al uso total de la app, cómodamente dentro de la cuota diaria gratuita para una app con un número moderado de usuarios activos.
La documentación del endpoint, incluidos los límites de puntos por solicitud, está en /docs/elevation-lookup/.