Les coureurs qui planifient un parcours se soucient des côtes d'une manière difficile à évaluer à partir d'une simple carte plate, car deux parcours de même distance peuvent donner des sensations complètement différentes selon le dénivelé qu'ils concentrent. Sur le tableau des demandes de fonctionnalités d'une application de course à pied, une demande est restée en tête pendant des mois : afficher le profil d'altitude d'un parcours planifié avant que l'on s'engage à le courir.
La fonction d'itinéraire de l'application produisait déjà une suite de coordonnées décrivant une course planifiée, générée à partir d'un point de départ, d'un point d'arrivée et de la logique de recherche de chemin propre à l'application, le long de vraies rues et de vrais sentiers. Il manquait les données d'altitude pour chaque point de ce parcours. /v1/elevation a directement comblé ce manque : une liste de coordonnées envoyée en une seule requête revenait sous forme d'une liste correspondante de valeurs d'altitude, dans le même ordre, prête à être tracée en fonction de la distance cumulée parcourue par le coureur.
Le graphique obtenu, l'altitude en fonction de la distance, a donné aux coureurs exactement ce que demandait la requête de fonctionnalité : une vue claire de l'emplacement des montées le long d'une course planifiée, de la raideur apparente de chacune par rapport au reste du parcours, et un dénivelé positif total qui est devenu, avec la distance et l'allure estimée, l'un des chiffres principaux affichés pour chaque parcours enregistré dans l'application.
La densité d'échantillonnage comptait ici pour maîtriser les coûts, comme pour une application de vélo confrontée au même problème. Une courte course dans le quartier nécessitait un échantillonnage de l'altitude assez fréquent pour produire un graphique fluide et d'apparence précise, tandis qu'un parcours plus long pouvait utiliser un intervalle d'échantillonnage plus large sans que le graphique obtenu paraisse sensiblement différent à un coureur qui y jetait un coup d'œil. Comme une requête d'altitude groupée compte chaque point comme un élément facturé, l'équipe technique de l'application a réglé l'intervalle d'échantillonnage selon la longueur du parcours, précisément pour éviter de demander bien plus de points que ce dont la résolution visuelle du graphique avait réellement besoin.
L'application a ajouté une autre petite fonctionnalité à partir des mêmes données : un badge « difficulté de montée » sur les parcours enregistrés, calculé à partir du dénivelé positif total rapporté à la distance, qui permet aux coureurs de comparer rapidement deux parcours de longueur similaire sans lire un graphique complet pour chacun. L'esprit est le même que lorsqu'une application de randonnée utilise ce calcul pour la difficulté des sentiers, simplement adapté aux distances plus courtes et aux allures différentes d'une course à pied habituelle plutôt que d'une randonnée.
L'utilisation des parcours enregistrés a augmenté après le lancement de la fonctionnalité, ce que l'équipe de l'application a attribué précisément au fait que les coureurs se sentaient plus confiants pour se lancer sur un parcours inconnu une fois qu'ils pouvaient voir ce qui les attendait réellement en matière de montées, au lieu de ne découvrir la difficulté d'un parcours qu'à mi-chemin lors de leur première sortie.
Les recherches d'altitude s'exécutaient une fois par parcours enregistré plutôt qu'à chaque course, puisque le profil d'altitude d'un parcours ne change pas d'une sortie à l'autre. Le volume total de requêtes restait ainsi proportionnel au nombre de parcours distincts créés par les utilisateurs plutôt qu'à l'utilisation globale de l'application, et tenait confortablement dans le quota quotidien gratuit pour une application comptant un nombre modéré d'utilisateurs actifs.
La documentation de l'endpoint, y compris les limites de points par requête, se trouve sur /docs/elevation-lookup/.