ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
Google Maps Platformのタイムゾーン連携から移行する
タイムゾーン検索が、プロジェクトのアーキテクチャのメモで独立した項目になることはめったにありません。たいていはジオコーディングや地図表示のために用意されたGoogle Maps Platformのアカウントの中に同居しており、ある座標についてタイムスタンプを現地時刻に変換する必要がある場所から呼び出されます。このまとめ方こそが、タイムゾーンだけを移すことを少し面倒にしています。アカウント、請求、キーのすべてが、同時には移行しないかもしれない機能と共有されているからです。
GoogleのタイムゾーンAPIは、位置とタイムスタンプを受け取り、timeZoneId、timeZoneName、そして標準時と夏時間の調整それぞれについて秒単位のオフセット値を返します。小さく明確に定義されたレスポンスなので、ジオコーディングやより込み入った作業に取り組む前に、大きなGoogleアカウントから最初に切り離す候補として妥当です。
My Geocodeはタイムゾーン検索を、Google特有の形式に形を合わせるレイヤーではなく、独立して完全に動作するエンドポイントとして提供しています。これは実際に動作するレスポンスを直接説明できる検索の1つだからです。座標をリクエストすると、UTCのタイムスタンプを現地時刻に変換するのに必要なタイムゾーンの識別子とオフセット情報が返されます。詳細は/docs/timezone-lookup/にあります。
これは同じ形を再現する互換ホストではなく単独のエンドポイントなので、GoogleのタイムゾーンAPIから移行するには、コードが読み取る特定のフィールド名を調整する必要があります。タイムゾーンのデータはもともと識別子、オフセット、場合によっては夏時間のフラグ程度と小さいため、通常は小さく限定された変更で済みます。住所構成要素のパース処理を伴うジオコーディング連携全体の移行と比べると、作業量はかなり少なくなります。
この移行のための実践的な手順です。
- 現在Googleのタイムゾーンエンドポイントを呼び出しているすべての呼び出し箇所を洗い出します。大きなコードベースでも、1つか2つのユーティリティ関数からしか呼び出されていないことがよくあります
- 30分単位のオフセットを採用している場所や夏時間のない地域など、特殊なタイムゾーンの規則を持つ地域の座標でテストします。単純な変換が壊れやすいのは、こうしたエッジケースだからです
- 認証を、
X-API-Key、Authorization: Bearer、HTTP Basic認証、クエリパラメータのうち、既存のリクエストコードに最も自然に合う方法でキーを送る形に更新します
ここでの料金は他のすべてのエンドポイントと同じです。キーなしで1日あたり2,500リクエストが無料、さらにキーごとにネットワーク単位でカウントされる1日あたり2,500リクエストが無料で、その後は1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキーとなります。アカウントでのGoogle Maps Platformの利用が主にタイムゾーンの呼び出しで、ジオコーディングはときどきという場合は、タイムゾーンの部分だけを移すことで元のアカウントに残る範囲を大きく減らせ、残りの移行は自分のペースで進められます。