Les cyclistes qui préparent un itinéraire s'intéressent à un chiffre plus qu'à tout autre : le dénivelé à grimper. Soixante kilomètres de plat et soixante kilomètres vallonnés sont deux sorties complètement différentes, et une application de cyclisme conçue pour la planification d'itinéraires devait pouvoir montrer cette différence avant qu'un cycliste ne s'engage, pas une fois qu'il en est à la troisième côte et qu'il le regrette.
L'application disposait déjà des itinéraires sous forme de suites de coordonnées, générées par son propre moteur de calcul d'itinéraire à partir d'un point de départ et d'un point d'arrivée. Ce qui lui manquait, c'était l'altitude en chacun de ces points. /v1/elevation a réglé le problème directement : on lui envoie une liste de coordonnées, un seul point ou une longue suite le long d'un itinéraire, et il renvoie l'altitude du sol pour chacune. Un itinéraire de deux cents points revenait sous forme de deux cents valeurs d'altitude, toujours dans l'ordre d'envoi, prêtes à être tracées en profil en fonction de la distance parcourue.
Cette liste, tracée en fonction de la distance cumulée, constitue le graphique de dénivelé que les cyclistes veulent vraiment voir : où sont les côtes, à quel point l'approche paraît raide par rapport aux points voisins et où se trouvent les portions plates. L'application s'en servait pour calculer le dénivelé positif total d'un itinéraire, un chiffre unique qui s'est avéré plus important que la distance totale pour les cyclistes qui décidaient de tenter ou non un itinéraire.
Comme un itinéraire pouvait compter de quelques dizaines à quelques centaines de points selon sa longueur, et comme une requête d'altitude groupée compte chaque point comme un élément facturé, l'application ajustait le nombre de points échantillonnés par itinéraire au lieu de demander l'altitude à la résolution la plus fine possible pour chaque sortie. Un itinéraire peu accidenté échantillonné tous les quelques centaines de mètres produisait un profil tout aussi utile qu'un échantillonnage tous les dix mètres, pour une fraction du volume de requêtes, et la différence était invisible pour un cycliste qui regardait le graphique obtenu.
L'application permettait aussi au cycliste de vérifier un point à la demande, en touchant n'importe quel endroit de la carte pour voir l'altitude à cet endroit précis, ce qui utilisait le même endpoint avec une requête d'un seul point au lieu d'un itinéraire complet. Le cas d'un point unique et le cas par lot passent par le même appel, ce qui gardait le code de l'application simple : une seule fonction qui accepte une liste de coordonnées et renvoie la liste d'altitudes correspondante, utilisée aussi bien pour un simple toucher que pour la planification d'un itinéraire complet.
Le trafic dépendait du nombre d'itinéraires planifiés par les cyclistes plutôt que du nombre de sorties effectuées, puisque le profil d'un itinéraire enregistré n'avait besoin d'être calculé qu'une fois. Pour une application dotée d'une base d'utilisateurs active mais pas gigantesque, les recherches d'altitude restaient ainsi largement dans le quota gratuit quotidien, le crédit prépayé constituant l'étape suivante naturelle si une nouvelle fonctionnalité populaire provoquait un pic de planification d'itinéraires.
L'altitude est l'un des rares endpoints pour lesquels un exemple concret est facile à donner : une sortie en bord de mer affichera des valeurs d'altitude proches du niveau de la mer pour ses premiers points, puis des valeurs croissantes à mesure que l'itinéraire monte vers l'intérieur des terres, un graphique qui parle à un cycliste au premier coup d'œil. Les détails sur le format des requêtes et les limites de points se trouvent sur /docs/elevation-lookup/.