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 fichier GPX enregistré avec un téléphone ou un GPS basique contient souvent des valeurs d'altitude totalement absentes ou nettement inexactes, car les mesures d'altitude des GPS grand public sont généralement bien moins fiables que la latitude et la longitude qu'ils enregistrent.
Analysez les points de trace du fichier GPX en n'en extrayant que la latitude et la longitude, et écartez les valeurs d'altitude existantes que vous comptez remplacer.
<trkpt lat="45.8326" lon="6.8652"><ele>1050</ele></trkpt>Envoyez les coordonnées extraites à /v1/elevation, soit via le paramètre points pour un petit fichier, soit via un tableau en POST groupé pour un fichier plus volumineux.
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210}
]
}Tous les usages ne nécessitent pas de traiter une trace complète. Avant de publier la description d'une randonnée, un seul appel confirme l'altitude au point de départ du sentier.
GET /v1/elevation?lat=45.8326&lon=6.8652La réponse a la même structure avec une seule entrée, ce qui est utile pour vérifier ponctuellement une altitude de départ ou d'arrivée citée dans des notes de randonnée sans avoir à toucher au fichier GPX complet.
Les résultats reviennent dans le même ordre que les coordonnées envoyées : réécrivez donc elevation_m dans la balise ele de chaque point de trace en vous fondant sur la position, en remplaçant la valeur enregistrée à l'origine par la valeur recherchée.
<trkpt lat="45.8326" lon="6.8652"><ele>1035</ele></trkpt>Ne mélangez pas le format du paramètre de requête points et un corps POST groupé au sein d'une même tâche sans rester cohérent dans la manière de rattacher les résultats aux points de trace. Le paramètre points et le tableau JSON renvoient tous deux les résultats dans l'ordre fourni, mais récupérer les coordonnées d'un point via un paramètre de requête et celles des autres via un POST groupé, puis fusionner les deux ensembles de réponses par supposition plutôt que par une correspondance explicite des coordonnées, est un moyen facile d'introduire un décalage d'un élément dans le fichier réécrit.
Un fichier GPX peut contenir des milliers de points de trace enregistrés à intervalles rapprochés. Les enrichir tous représente une requête par point, ce qui s'accumule vite sur une longue trace. Sous-échantillonner à un intervalle plus large avant la recherche d'altitude, puis interpoler entre les valeurs obtenues pour les points intermédiaires, est une façon raisonnable de réduire le nombre de requêtes tout en produisant un profil d'apparence précise.
Une trace qui longe une côte ou traverse un delta de basse altitude peut légitimement renvoyer une valeur elevation_m égale ou proche de zéro, voire parfois un petit nombre négatif pour des terres situées sous le niveau de la mer. Ni l'un ni l'autre n'est une erreur. Considérez une valeur proche de zéro comme une mesure réelle plausible pour ce terrain plutôt que de l'écarter comme une donnée erronée.
Chaque point enrichi correspond à une requête. Une trace de randonnée modeste de quelques centaines de points, sous-échantillonnée à partir d'un enregistrement brut bien plus volumineux, reste largement dans les 2 500 requêtes gratuites par jour incluses avec chaque clé.
Nettoyer ainsi les données d'altitude transforme une trace approximative enregistrée au téléphone en un fichier qui mérite d'être partagé ou analysé. La documentation de la recherche d'altitude décrit à la fois le paramètre points et le format des requêtes groupées.