La distancia por sí sola es una mala forma de valorar lo difícil que es realmente una ruta. Un sendero llano de seis millas junto a la orilla de un río y un sendero de seis millas que sube una montaña aparecían ambos con la misma etiqueta de "moderado, seis millas" en el directorio de una app de guías de senderos, una clasificación que había generado un flujo constante de quejas de senderistas que confiaron en la clasificación de moderado y se encontraron en una subida mucho más dura de lo que habían previsto.
La app ya guardaba cada sendero como una secuencia de coordenadas que trazaba su recorrido, recopiladas a partir de grabaciones GPS enviadas por colaboradores. Lo que le faltaba era la elevación a lo largo de ese recorrido, el dato que realmente distingue un paseo llano de una subida seria con la misma distancia. /v1/elevation recibía la lista completa de coordenadas de un sendero, ya que una solicitud masiva acepta una lista de puntos y devuelve la elevación de cada uno, y la app recibía un valor de elevación para cada punto del recorrido grabado, en el mismo orden en que se enviaron.
A partir de esa lista, calcular el desnivel positivo total, la suma de cada subida a lo largo de la ruta, era una operación aritmética sencilla que resolvía el propio backend de la app. El desnivel total, combinado con la distancia, producía una señal de dificultad mucho más útil que la distancia sola: un sendero con mucho desnivel en poca distancia se clasificaba como empinado y difícil por corto que pareciera sobre el papel, mientras que un sendero largo y llano se clasificaba como más fácil a pesar de su longitud, lo que se ajustaba mucho mejor a lo que los senderistas viven sobre el terreno que el antiguo sistema basado solo en la distancia.
La app reconstruyó su clasificación de dificultad en torno a esta cifra combinada y recalculó retroactivamente todos los senderos que ya había en su directorio, un trabajo por lotes puntual sobre toda la biblioteca de senderos. Ese lote fue la solicitud más grande que la app envió nunca, y como una solicitud masiva de elevación cuenta cada punto como un elemento facturado, y no cada sendero, el tamaño exacto del trabajo dependía de cuántos puntos de coordenadas existían en toda la biblioteca y no del número de senderos, algo que el equipo tuvo en cuenta al estimar el coste de antemano en lugar de llevarse la sorpresa después.
Además de la clasificación de dificultad principal, los mismos datos de elevación permitieron a la app mostrar un gráfico de perfil de subida en la página de cada sendero, parecido al que mostraría una app de ciclismo, para que el senderista viera exactamente dónde estaban los tramos empinados a lo largo de la ruta en lugar de conocer solo una etiqueta de dificultad global. Los senderistas que querían prepararse para un tramo duro concreto, y no solo saber que un sendero era difícil en general, encontraron el gráfico más útil que la etiqueta por sí sola.
Después del lote inicial, las consultas de elevación continuas dependían de los nuevos senderos enviados, un volumen mucho más pequeño y estable que el del proyecto puntual de recálculo, cómodamente dentro de la cuota diaria gratuita para el ritmo habitual de nuevos envíos de colaboradores de la app.
Un sistema de clasificación es tan bueno como los datos que tiene debajo, y la elevación resultó ser el dato que le había faltado desde el principio a la clasificación de dificultad de la app. La documentación del endpoint, incluidos los límites de puntos por solicitud, está en /docs/elevation-lookup/.