Le profil d'altitude d'un sentier de randonnée ou d'un trajet en voiture se résume rarement à une seule coordonnée. Il s'agit de dizaines, parfois de centaines de points le long d'un parcours, chacun nécessitant une valeur d'altitude pour construire un graphique de dénivelé ou estimer l'effort en chemin. Ce mode d'utilisation, de nombreuses coordonnées au service d'un même itinéraire continu, est précisément ce que nous avons optimisé lors d'une récente révision de /v1/elevation.
Le format de requête et de réponse de l'endpoint n'a pas changé, et tout ce qui est documenté sur /docs/elevation-lookup/ s'applique toujours exactement tel qu'écrit. Ce qui a changé, c'est l'efficacité avec laquelle un grand lot de coordonnées le long d'un itinéraire est traité en interne, afin de réduire le temps nécessaire pour obtenir le profil d'altitude d'un long parcours plutôt que d'un seul point isolé.
Comme une requête groupée compte chaque coordonnée comme un élément, exactement comme toujours, cette amélioration concerne la vitesse, pas la tarification ni le comportement des quotas. Un itinéraire de deux cents points compte toujours pour deux cents requêtes sur le quota applicable, qu'il s'agisse du quota quotidien gratuit, du crédit prépayé à 0,0001 € par requête ou de la couverture d'un forfait Unlimited. Ce qui change, c'est le temps que met la réponse à revenir, ce qui compte directement pour tout ce qui construit un profil d'itinéraire de manière interactive plutôt qu'en tâche de fond.
Cette même amélioration profite à notre hôte compatible Open-Elevation sur /compatibility/open-elevation/, puisqu'il s'appuie sur le même endpoint d'altitude sous-jacent. Tout ce qui envoie déjà des lots de la longueur d'un itinéraire via cet hôte bénéficie d'un traitement plus rapide sans aucune modification côté intégration.
Les applications d'itinéraires et de randonnée sont généralement celles où ce type d'amélioration se ressent le plus directement, car un profil d'altitude qui met sensiblement plus de temps à charger que l'itinéraire lui-même crée un décalage visible pour l'utilisateur qui attend devant sa carte. Une réponse plus rapide pour ces lots plus longs, en forme d'itinéraire, comble cet écart.
Si votre application demande l'altitude d'itinéraires composés de nombreuses coordonnées, que ce soit pour la randonnée, le vélo ou la voiture, vous devriez constater une amélioration discrète de la rapidité avec laquelle un profil complet revient, sans rien d'autre à changer dans l'intégration. La documentation complète de l'endpoint reste disponible sur /docs/elevation-lookup/.