Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Open-Elevation selbst hosten oder einen verwalteten Endpunkt nutzen
Die Einfachheit von Open-Elevation als Open-Source-Projekt hat zwei Seiten. Das Anfrage- und Antwortformat ist wirklich leicht zu handhaben, ein Array von Koordinaten hinein, ein Array von Höhenwerten in Metern heraus, doch es selbst zu betreiben bedeutet, einen Höhendatensatz zu beschaffen, ihn auf einen Server mit genug Speicherplatz zu laden und diesen Server verfügbar zu halten, wann immer Ihre Anwendung eine Antwort braucht.
Höhendatensätze sind nicht klein. Je nach Auflösung und geografischer Abdeckung, die ein Projekt benötigt, können selbst gehostete Höhendaten erheblichen Speicherplatz erfordern, und höher aufgelöste Daten für eine bestimmte Region stehen im Zielkonflikt mit einer breiteren, aber gröberen globalen Abdeckung. Diese Entscheidung ist, zusammen mit der Serverbereitstellung und dem Aktualisierungsrhythmus, eine echte, dauerhafte Verantwortung, die ein Team an dem Tag übernimmt, an dem es sich für das Selbsthosting entscheidet, und keine einmaligen Einrichtungskosten.
Ein verwalteter Endpunkt nimmt Ihnen diese Verantwortung ab, im Tausch dafür, dass Sie von der Infrastruktur und den Datensatzentscheidungen eines anderen abhängen. Die Höhenabfrage von My Geocode ist ein voll funktionsfähiger Endpunkt, der für eine gegebene Koordinate die Geländehöhe in Metern zurückgibt, auf Basis unserer eigenen Höhendaten statt eines Datensatzes, den Sie selbst beschaffen und laden. Die Dokumentation finden Sie unter /docs/elevation-lookup/.
Ehrlich vergleichen lassen sich diese beiden Wege, indem Sie Ihr tatsächliches Nutzungsmuster betrachten statt einer allgemeinen Vorliebe für einen Ansatz:
- Wenn Höhenabfragen selten sind, etwa nur dann, wenn ein Nutzer eine bestimmte Route oder einen bestimmten Ort ansieht, deckt das kostenlose Tageskontingent eines verwalteten Endpunkts die Last wahrscheinlich ab, ganz ohne zu wartende Infrastruktur
- Wenn Höhenabfragen als Teil einer zentralen Produktfunktion in hohem, stetigem Volumen anfallen, lohnt es sich, die tatsächlichen Kosten pro Anfrage nach den Preisen eines verwalteten Endpunkts mit den amortisierten Kosten für Server und Speicher einer selbst gehosteten Instanz zu vergleichen
- Wenn Ihr Anwendungsfall Höhendaten in einer Auflösung oder für eine Region benötigt, für die ein selbst gewählter Datensatz gezielt optimiert ist, ist das unabhängig vom Kostenvergleich ein legitimer Grund, beim Selbsthosting zu bleiben
Für Teams, die von einer selbst gehosteten Open-Elevation-Instanz auf den verwalteten Endpunkt wechseln, bleibt das Anfragemuster (Koordinaten hinein, Höhenwerte heraus) im Prinzip gleich, allerdings erfolgt die Authentifizierung nun über einen Schlüssel, der als X-API-Key, Authorization: Bearer, per HTTP Basic Auth oder als Query-Parameter gesendet wird. Es gibt 2.500 kostenlose Anfragen pro Tag ganz ohne Schlüssel und 2.500 weitere kostenlose Anfragen pro Schlüssel und Tag, gezählt pro Netzwerk, darüber hinaus Prepaid-Guthaben zu 0,0001 € pro Anfrage oder einen Unlimited-Schlüssel für 50 € pro Monat, zum selben Preis wie jeder andere Endpunkt der Plattform.
Keiner der beiden Wege ist grundsätzlich der richtige. Ein Nebenprojekt, das gelegentlich Höhenwerte für eine Handvoll Koordinaten pro Tag benötigt, ist allein mit dem kostenlosen Kontingent eines verwalteten Endpunkts gut bedient. Ein Team mit sehr spezifischen Anforderungen an die Datenauflösung für ein eng begrenztes geografisches Gebiet stellt womöglich fest, dass das Selbsthosting weiterhin besser passt, und auch das ist ein legitimes Ergebnis, wenn man diesen Vergleich ehrlich durchführt.