上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
2つの住所間の距離は、ジオコーディングAPIが直接返すものではありません。距離の計算に必要なのは座標だけであり、座標はジオコーディングのエンドポイントに送ったどの住所についてもすでに返ってくるからです。
各住所を個別に、または1回の一括リクエストでまとめてジオコーディングし、それぞれの緯度と経度の組を取得します。
POST /v1/forward
Content-Type: application/json
["221B Baker Street, London", "10 Downing Street, London"]{
"status": "ok",
"results": [
{"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}},
{"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {}}
]
}2組の座標が揃ったら、標準的なハバーサインの公式を適用します。この公式は、緯度と経度の差を地球表面上の直線距離に変換します。ほとんどのプログラミング言語には、短い関数や一般的なライブラリとして、小さく十分にテストされたハバーサインの実装があるため、三角関数の計算を一から書く必要はありません。
distance_km = haversine(51.5237, -0.1585, 51.5033, -0.1276)ハバーサインの公式は緯度と経度をラジアンで受け取ることを前提としていますが、APIレスポンスの座標は常に度で表されています。ラジアン用に書かれた公式に度の値をそのまま入れると、一見もっともらしく見えても、実は大きな倍率で誤った距離が算出されます。先に度をラジアンに変換するか、どの単位を想定しているかが明記されたライブラリ関数を使い、本番環境で信頼する前に、すでにわかっている距離と結果を照らし合わせて確認してください。
同じ計算は、2地点より多い場合にも自然に拡張できます。ルート上のすべての立ち寄り先を1回の一括リクエストでジオコーディングし、連続する座標の各組の間のハバーサイン距離を合計すれば、ルートのおおよその全長が得られます。実際のターンバイターンのルーティングを導入する前でも、配送ルートを手早く見積もるのに役立ちます。
total_km = haversine(a, b) + haversine(b, c) + haversine(c, d)ハバーサインの計算で得られるのは直線距離であり、実際の道路に沿った車や徒歩での移動距離ではありません。近くの場所を並べ替えたり、おおよその近さを見積もったりといったほとんどの用途では、直線距離で十分であり、すでに手元にある座標以外には何も必要ありません。ルーティングに基づく移動距離が特に必要な場合、それはジオコーディングの検索が提供する範囲外の、別の種類の計算です。
日付変更線(180度経線)をはさんで反対側にある2地点や、極に非常に近い2地点では、経度が180からマイナス180へ一周して戻ることを考慮していない単純な距離の公式がつまずくことがあります。一般的な住所間の距離チェックではまれですが、アプリケーションが実際に地球のその部分にまたがる場合は、テストしておく価値があります。
2つの住所のジオコーディングには、別々の呼び出しで送っても1回の一括呼び出しで送っても、2リクエストかかります。両方の座標の組が揃えば、距離の計算自体はすべて自分のコード内で行われ、割り当てに対する追加のコストは一切かかりません。
どちらかの住所を以前にジオコーディングしてキャッシュしてあれば、新たなリクエストが必要なのは新しい住所だけなので、その計算のコストは2リクエストではなく1リクエストに減ります。
まだ座標に変換していない住所でも、距離の計算までジオコーディングのリクエストはわずか1回です。レスポンスの全体構造についてはジオコーディングのドキュメントをご覧ください。