Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Héberger soi-même Open-Elevation ou utiliser un endpoint géré
La simplicité d'Open-Elevation en tant que projet open source est à double tranchant. Le format de requête et de réponse est vraiment facile à utiliser, un tableau de coordonnées en entrée, un tableau de valeurs d'altitude en mètres en sortie, mais l'exploiter vous-même implique de vous procurer un jeu de données d'altitude, de le charger sur un serveur disposant d'assez d'espace disque pour le contenir, et de garder ce serveur disponible chaque fois que votre application a besoin d'une réponse.
Les jeux de données d'altitude ne sont pas petits. Selon la résolution et la couverture géographique dont un projet a besoin, des données d'altitude auto-hébergées peuvent exiger un stockage conséquent, et des données à plus haute résolution pour une région précise se font au détriment d'une couverture mondiale plus large mais plus grossière. Ce choix, tout comme le provisionnement du serveur et le rythme des mises à jour, est une véritable responsabilité permanente qu'une équipe endosse le jour où elle choisit l'auto-hébergement, et non un coût d'installation ponctuel.
Un endpoint géré supprime cette responsabilité en échange d'une dépendance à l'infrastructure et aux choix de données de quelqu'un d'autre. La recherche d'altitude de My Geocode est un endpoint pleinement fonctionnel qui renvoie l'altitude du sol en mètres pour une coordonnée donnée, à partir de nos propres données d'altitude plutôt que de données que vous devez vous procurer et charger vous-même. La documentation se trouve sur /docs/elevation-lookup/.
La manière honnête de comparer ces deux voies est d'examiner votre utilisation réelle plutôt qu'une préférence générale pour une approche :
- Si les recherches d'altitude sont peu fréquentes, par exemple générées uniquement quand un utilisateur consulte un itinéraire ou un lieu précis, le quota gratuit quotidien d'un endpoint géré couvre probablement la charge, sans aucune infrastructure à maintenir
- Si les recherches d'altitude se font à un volume élevé et régulier dans le cadre d'une fonctionnalité centrale du produit, il vaut la peine de comparer le coût réel par requête selon la tarification d'un endpoint géré au coût amorti du serveur et du stockage d'une instance auto-hébergée
- Si votre cas d'usage exige des données d'altitude à une résolution ou pour une région qu'un jeu de données auto-hébergé optimise spécifiquement, c'est une raison légitime de conserver l'auto-hébergement, quelle que soit la comparaison des coûts
Pour les équipes qui passent d'une instance Open-Elevation auto-hébergée à l'endpoint géré, le principe des requêtes (des coordonnées en entrée, des valeurs d'altitude en sortie) reste le même sur le fond, même si l'authentification change pour une clé envoyée via X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête. Vous disposez de 2 500 requêtes gratuites par jour sans aucune clé, et de 2 500 requêtes gratuites supplémentaires par clé et par jour, comptées par réseau, puis de crédit prépayé à 0,0001 € par requête au-delà, ou d'une clé Unlimited à 50 € par mois, au même tarif que tous les autres endpoints de la plateforme.
Aucune des deux voies n'est universellement la bonne. Un projet personnel qui a besoin de temps en temps de l'altitude de quelques coordonnées par jour est bien servi par la seule offre gratuite d'un endpoint géré. Une équipe ayant des exigences très précises de résolution des données pour une zone géographique restreinte peut trouver que l'auto-hébergement reste le meilleur choix, et c'est une conclusion légitime d'une comparaison menée honnêtement.