Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Un profil d'altitude n'est qu'une liste de points auxquels est associée une hauteur, tracée en fonction de la distance parcourue le long de l'itinéraire. L'endpoint d'altitude vous fournit cette hauteur pour autant de points que vous lui envoyez, en un seul appel.
Transmettez une série de paires latitude et longitude avec le paramètre points, séparées par des barres verticales, chaque paire étant séparée par une virgule.
GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210},
{"lat": 45.8475, "lon": 6.8750, "elevation_m": 1390}
]
}Chaque élément de results correspond au point que vous avez envoyé à la même position. Associez elevation_m à la distance cumulée entre points consécutifs, que vous calculez vous-même à partir des coordonnées, et vous obtenez les valeurs x et y d'un graphique de profil sans aucune autre recherche.
Si vous préférez envoyer un tableau structuré plutôt que le paramètre points séparé par des barres verticales, envoyez en POST un tableau JSON d'objets de coordonnées à /v1/elevation, de la même manière que les autres endpoints acceptent les corps de requête groupés.
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]Dans les deux cas, le coût est le même, une requête par point : choisissez donc la forme la plus simple à construire à partir de la structure de données dont vous disposez déjà, une chaîne de requête construite à partir d'un tableau ou un tableau JSON construit de la même façon.
Un itinéraire comportant une centaine de points GPS espacés de quelques mètres n'a pas besoin de l'altitude de chacun d'eux pour tracer un profil lisible. Échantillonner un point sur vingt ou sur cinquante le long d'un long itinéraire, ou rééchantillonner à intervalles de distance réguliers, garde le graphique fluide tout en réduisant le nombre de requêtes, puisque chaque point du paramètre points compte comme une requête.
Considérer elevation_m comme exact au centimètre près, c'est demander aux données plus que ce dont un profil d'altitude a besoin. La valeur est assez précise pour tracer un profil fluide et lisible et pour calculer un dénivelé positif total cohérent, mais deux points distants d'un mètre sur un terrain plat peuvent renvoyer des valeurs légèrement différentes qui ne disent rien du terrain réel. Concevez votre graphique et vos calculs de dénivelé pour tolérer ce type de petit bruit plutôt que de traiter chaque fluctuation comme une véritable caractéristique de l'itinéraire.
Un point situé au-dessus d'une étendue d'eau ou dans une zone disposant de peu de données d'altitude peut renvoyer une valeur basse ou plate plutôt qu'une erreur. Si votre itinéraire comprend une traversée en ferry ou un tronçon en terrain isolé, vérifiez la cohérence des portions inhabituellement plates de votre profil en les comparant à la carte elle-même plutôt que de supposer que le nombre décrit toujours la terre ferme.
Un profil de cent points représente cent requêtes, largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé ou disponibles depuis une même adresse sans clé. Un outil de planification d'itinéraires servant de nombreux utilisateurs par jour doit tout de même surveiller ses en-têtes de quota, car les profils d'altitude des itinéraires populaires s'additionnent plus vite que des recherches uniques.
Les données d'altitude transforment une carte plate en un outil autour duquel un randonneur ou un cycliste peut vraiment planifier. La liste complète des paramètres figure sur la page de documentation de la recherche d'altitude.