La distance seule est un mauvais moyen d'évaluer la difficulté réelle d'une randonnée. Un sentier plat de six miles le long d'une rivière et un sentier de six miles qui gravit une montagne apparaissaient tous deux sous la même étiquette « modéré, six miles » dans l'annuaire d'une application de guide de randonnée, une classification qui avait suscité un flux régulier de plaintes de randonneurs qui s'étaient fiés à la mention « modéré » et s'étaient retrouvés dans une ascension bien plus difficile que celle à laquelle ils s'étaient préparés.
L'application stockait déjà chaque sentier sous forme d'une suite de coordonnées retraçant son parcours, issues d'enregistrements GPS envoyés par des contributeurs. Il lui manquait l'altitude le long de ce parcours, la donnée qui distingue réellement une promenade à plat d'une vraie ascension sur la même distance. /v1/elevation prenait la liste complète des coordonnées d'un sentier, puisqu'une requête groupée accepte une liste de points et renvoie l'altitude de chacun, et l'application recevait une valeur d'altitude pour chaque point du parcours enregistré, dans l'ordre même où ils avaient été envoyés.
À partir de cette liste, calculer le dénivelé positif total, c'est-à-dire la somme de toutes les montées le long du parcours, relevait d'une simple arithmétique que le backend de l'application effectuait lui-même. Le dénivelé positif total, combiné à la distance, produisait un indicateur de difficulté bien plus utile que la distance seule : un sentier avec un fort dénivelé sur une courte distance était classé raide et difficile, quelle que soit sa longueur apparente sur le papier, tandis qu'un long sentier plat était classé plus facile malgré sa longueur, ce qui correspondait bien mieux à ce que vivent réellement les randonneurs sur le terrain que l'ancien système fondé uniquement sur la distance.
L'application a reconstruit sa cotation de difficulté autour de cet indicateur combiné et a recalculé rétroactivement chaque sentier déjà présent dans son annuaire, un traitement par lot ponctuel sur toute la bibliothèque de sentiers. Ce lot a été la plus grosse requête que l'application ait jamais envoyée, et comme une requête d'altitude groupée compte chaque point, et non chaque sentier, comme un élément facturé, la taille exacte du traitement dépendait du nombre de points de coordonnées présents dans toute la bibliothèque plutôt que du nombre de sentiers. L'équipe en a tenu compte en estimant le coût à l'avance, au lieu d'être surprise après coup.
Au-delà de la cotation de difficulté principale, les mêmes données d'altitude ont permis à l'application d'afficher un graphique de profil de montée sur chaque page de sentier, comparable à ce que pourrait afficher une application de vélo, afin qu'un randonneur voie exactement où se trouvent les passages raides le long du parcours au lieu de ne connaître qu'une étiquette de difficulté globale. Les randonneurs qui voulaient se préparer à un passage difficile précis, plutôt que de savoir seulement qu'un sentier était difficile dans l'ensemble, trouvaient le graphique plus utile que l'étiquette seule.
Après le lot initial, les recherches d'altitude étaient liées aux nouveaux sentiers proposés, un volume bien plus faible et plus régulier que le projet de recalcul ponctuel, et qui tenait confortablement dans le quota quotidien gratuit au rythme habituel des nouvelles contributions à l'application.
Un système de cotation ne vaut que par les données sur lesquelles il repose, et l'altitude s'est révélée être la donnée manquante dont la cotation de difficulté de l'application avait besoin depuis le début. La documentation de l'endpoint, y compris les limites de points par requête, se trouve sur /docs/elevation-lookup/.