Quienes planifican una ruta en bicicleta se fijan en un dato por encima de todos: cuánto hay que subir. Sesenta kilómetros llanos y sesenta kilómetros con colinas son salidas completamente distintas, y una app de ciclismo pensada para planificar rutas necesitaba una forma de mostrar esa diferencia antes de que alguien se comprometiera con una salida, no cuando ya llevaba tres cuestas y se estaba arrepintiendo.
La app ya tenía las rutas como una secuencia de coordenadas, generada por su propio motor de rutas a partir de un punto de inicio y uno final. Lo que le faltaba era la elevación en cada uno de esos puntos. /v1/elevation lo resolvía directamente: le envías una lista de coordenadas, ya sea un solo punto o una secuencia larga a lo largo de una ruta, y devuelve la elevación del terreno de cada una. Una ruta con doscientos puntos a lo largo de su recorrido volvía como doscientos valores de elevación, en el mismo orden en que se enviaron, listos para trazarse como un perfil frente a la distancia recorrida.
Esa lista, representada frente a la distancia acumulada, es el gráfico de desnivel que los ciclistas realmente quieren ver: dónde están las subidas, lo empinada que parece la aproximación en comparación con los puntos vecinos y dónde quedan los tramos llanos. La app la usaba para calcular el desnivel positivo total de una ruta, un único dato que resultó importar más que la distancia total a los ciclistas que decidían si intentar una ruta.
Como una ruta podía tener desde unas pocas decenas hasta unos cientos de puntos según su longitud, y como una solicitud de elevación masiva cuenta cada punto como un elemento facturado, la app ajustó cuántos puntos muestreaba por ruta en lugar de solicitar la elevación con la máxima resolución posible para cada salida. Una ruta suave muestreada cada pocos cientos de metros producía un perfil tan útil como una muestreada cada diez metros, con una fracción del volumen de solicitudes, y la diferencia era invisible para un ciclista que mirara el gráfico resultante.
La app también permitía a un ciclista consultar un solo punto cuando quisiera, tocando cualquier lugar del mapa para ver la elevación en ese punto exacto, lo que usaba el mismo endpoint con una solicitud de un solo punto en lugar de una ruta completa. Tanto el caso de un punto como el de lotes pasan por la misma llamada, lo que mantenía sencillo el código de la app: una función que acepta una lista de coordenadas y devuelve la lista correspondiente de elevaciones, usada tanto para un toque rápido como para planificar una ruta completa.
El tráfico crecía con el número de rutas que planificaban los ciclistas y no con el de salidas que realmente hacían, ya que el perfil de una ruta guardada solo había que calcularlo una vez. En una app con una base de usuarios activa pero no enorme, eso mantenía las consultas de elevación muy por debajo de la cuota gratuita diaria, con el crédito prepago como siguiente paso natural si una nueva función popular provocaba un pico en la planificación de rutas.
La elevación es uno de los pocos endpoints en los que es fácil dar un ejemplo real: una ruta costera mostrará valores de elevación cercanos al nivel del mar en sus primeros puntos y valores crecientes a medida que la ruta sube hacia el interior, un gráfico que un ciclista entiende de un vistazo. Los detalles sobre el formato de las solicitudes y los límites de puntos están en /docs/elevation-lookup/.