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.
Eine Zeitzonenintegration der Google Maps Platform ablösen
Eine Zeitzonenabfrage bekommt in den Architekturnotizen eines Projekts selten einen eigenen Eintrag. Meist läuft sie in einem Konto der Google Maps Platform mit, das für Geokodierung oder Kartenanzeige eingerichtet wurde, und wird überall dort aufgerufen, wo ein Zeitstempel für eine bestimmte Koordinate in Ortszeit umgerechnet werden muss. Genau diese Bündelung macht es etwas umständlich, sie allein umzuziehen: Konto, Abrechnung und Schlüssel werden mit Funktionen geteilt, die Sie vielleicht nicht gleichzeitig migrieren.
Die Zeitzonen-API von Google nimmt einen Standort und einen Zeitstempel entgegen und liefert eine timeZoneId, einen timeZoneName sowie Offset-Werte in Sekunden, sowohl für die Standardzeit als auch für eine etwaige Sommerzeitanpassung. Es ist eine kleine, klar definierte Antwort, was sie zu einem sinnvollen ersten Kandidaten macht, um sie aus einem größeren Google-Konto herauszulösen, bevor Sie die Geokodierung oder etwas Aufwendigeres angehen.
My Geocode betreibt Zeitzonenabfragen als unabhängigen, voll funktionsfähigen Endpunkt und nicht als Schicht, die das spezifische Format von Google nachbildet, denn dies ist eine der Abfragen, bei denen sich eine echte, funktionierende Antwort direkt beschreiben lässt. Eine Anfrage für eine Koordinate liefert die Zeitzonenkennung und die Offset-Informationen, die nötig sind, um einen UTC-Zeitstempel in Ortszeit umzurechnen. Details finden Sie unter /docs/timezone-lookup/.
Da es sich um einen eigenständigen Endpunkt und nicht um einen gleichwertigen Kompatibilitäts-Host handelt, müssen Sie beim Abschied von der Zeitzonen-API von Google die konkreten Feldnamen anpassen, die Ihr Code liest. Das ist normalerweise eine kleine, überschaubare Änderung, da Zeitzonendaten von Natur aus wenig umfangreich sind: eine Kennung, ein Offset, vielleicht ein Sommerzeit-Flag. Das ist deutlich weniger Arbeit als die Migration einer vollständigen Geokodierungsintegration mit dem Parsing der Adresskomponenten.
Praktische Schritte für genau diesen Umstieg:
- Isolieren Sie jede Aufrufstelle, die derzeit den Zeitzonen-Endpunkt von Google anspricht, da er selbst in einer größeren Codebasis oft nur aus einer oder zwei Hilfsfunktionen aufgerufen wird
- Testen Sie mit Koordinaten in Regionen mit ungewöhnlichen Zeitzonenregeln, etwa Orten mit Halbstunden-Offsets oder Gebieten ohne Sommerzeit, da naive Umrechnungen gerade an diesen Randfällen oft scheitern
- Stellen Sie die Authentifizierung auf einen Schlüssel um, der als
X-API-Key, perAuthorization: Bearer, HTTP Basic Auth oder als Query-Parameter gesendet wird, je nachdem, was am natürlichsten zu Ihrem bestehenden Anfragecode passt
Die Preise sind hier dieselben wie bei jedem anderen Endpunkt: 2.500 kostenlose Anfragen pro Tag ohne Schlüssel, 2.500 weitere kostenlos pro Schlüssel und Tag, gezählt pro Netzwerk, danach Prepaid-Guthaben zu 0,0001 € pro Anfrage oder ein Unlimited-Schlüssel zu 50 € pro Monat. Wenn die Nutzung der Google Maps Platform in Ihrem Konto hauptsächlich aus Zeitzonenaufrufen mit gelegentlicher Geokodierung bestand, kann der Umzug allein des Zeitzonenteils deutlich verringern, was noch an das ursprüngliche Konto gebunden bleibt, und der Rest der Migration kann in eigenem Tempo folgen.