ガイド

ループを書かずに座標のリストを逆ジオコーディングする

緯度と経度のペアのテーブルがあり、1行ごとにAPIを1回呼び出すスクリプトを使っているなら、検索そのものではなく、往復通信にコストを払っていることになります。逆ジオコーディングのエンドポイントは、ジオコーディングのエンドポイントと同じように一括のPOST本文を受け付け、1回の呼び出しですべてのペアを処理します。

座標のペアを送信する

地点ごとに1回のGETリクエストを送る代わりに、座標オブジェクトの配列を/v1/reverseに送信します。各項目は、送信された順序でそれぞれの住所を返します。

POST /v1/reverse
Content-Type: application/json

[{"lat": 48.8584, "lon": 2.2945}, {"lat": 40.6892, "lon": -74.0445}]
{
  "status": "ok",
  "results": [
    {"formatted": "Champ de Mars, Paris, France", "lat": 48.8584, "lon": 2.2945, "type": "address", "precision": "street", "confidence": 0.9, "place_id": "gh789", "components": {}},
    {"formatted": "Liberty Island, New York, NY", "lat": 40.6892, "lon": -74.0445, "type": "address", "precision": "street", "confidence": 0.88, "place_id": "jk012", "components": {}}
  ]
}

ループより優れている理由

座標ごとに1回のHTTPリクエストを送るループは、行ごとに接続のオーバーヘッドが加わり、1日の割り当ての状況も把握しにくくなります。1つのレスポンスではなく、何百もの個別のレスポンスでヘッダーが流れていくのを見ることになるからです。1回の一括呼び出しでも項目ごとに1リクエストが課金されるため、割り当てに対する総コストは同じですが、読み取る割り当てヘッダーは1組だけで、エラーを捕捉する場所も1か所で済みます。

レスポンスの読み取り

配列内の各結果は、同じ位置で送信した座標に対応しています。開けた水域や地図化されていない広い地域など、近くに住所がない場所にある地点では、エラーではなく、信頼度スコアが低くなるか精度の値が粗くなると考えてください。そのため、整形済みの住所を顧客向けの用途に使う前に、両方のフィールドを確認してください。

2つ目の例:タイムゾーンデータとの組み合わせ

座標のリストの住所を取得した後によく行われるのが、それぞれの地点の現在時刻を調べることです。結果をもう一度ループ処理するのではなく、同じ座標のリストを/v1/timezoneに別の一括リクエストとして渡します。そうすると、/v1/reverseからの住所と/v1/timezoneからのタイムゾーン識別子という、どちらも元の行の順序に並んだ2つの配列が得られ、コストはエンドポイントごとに地点1つにつき1リクエストです。

避けるべき間違い

送信する前に、テーブル内のすべての座標が有効だと思い込まないでください。-90から90の範囲外の緯度や、-180から180の範囲外の経度は、スプレッドシートで列が入れ替わったときに意外なほど頻繁に発生しますが、妥当な結果を返せなくてもリクエストとしてカウントされます。成功するはずのない検索に費用を払うのではなく、バッチを送信する前に自分のコードで範囲を確認してください。

バッチのサイズを決める

データベースのテーブル全体を1回のリクエストで送る必要はありません。座標を、自分のスクリプトのメモリとタイムアウトの制限に合ったサイズのバッチにまとめ、各バッチが1日あたりの無料割り当てやクレジット残高に対して何リクエストを使うかを把握してください。各レスポンスのX-Quota-UsedヘッダーとX-Quota-Free-Remainingヘッダーで、次のバッチを送る前に現在の状況を正確に確認できます。

この方法でリスト全体を逆ジオコーディングすれば、以前は時間のかかるループだったものが、バッチごとに1回のリクエストになり、APIが行う項目ごとの処理はどちらの場合も同じです。リクエストとレスポンスの詳細は逆ジオコーディングのドキュメントに記載されています。