上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
自由入力の住所欄には、さまざまな書式の癖が集まります。余分な空白、不統一な大文字と小文字、表記ゆれのある略語、そしてどこかから貼り付けられた紛れ込んだ文字などです。どれもジオコーディングのリクエストを必ず壊すわけではありませんが、先に整えておくと一致の品質が向上する傾向があります。
先頭と末尾の空白を取り除き、連続する空白を1つにまとめます。制御文字や、明らかに住所に含まれるべきでない紛れ込んだ記号を取り除きます。実際の住所の内容には手を加えないでください。フォワードエンドポイントは自由入力のテキストをパースするように設計されており、通り、市区町村、郵便番号のフィールドに自分で分ける必要はありません。
GET /v1/forward?q=221b baker st, london&limit=1エンドポイントは固定のテンプレートではなく現実の住所テキストを扱うように作られているため、このような緩い書式の入力でも一般的には解決できます。ただし、入力文字列を整えておくほうが、本当に乱雑なデータで、あいまいな一致や信頼度の低い一致になる可能性を減らせます。
「Street」を「St」、「Avenue」を「Ave」とするような一般的な略語を使ったクエリは、送信前に展開する必要はありません。
GET /v1/forward?q=500 5th Ave, New York&limit=1リクエストを送る前にすべての略語を自分で展開するのは、結果をほとんど変えない余分な作業です。エンドポイントは通常の住所テキストのパースの一環として、標準的な略語をすでに処理しているからです。問題になったことのない略語を書き換えるのではなく、貼り付けられた改行や文字コードの崩れなど、本当に壊れた入力に整える作業を集中させてください。
登録済みの請求先住所やサイトが対象とする地域などから、住所がどの国にあるべきかがすでにわかっている場合は、countriesパラメータでそれを渡すと、世界の別の場所にある似た名前の地名とのあいまいな一致を減らせます。
GET /v1/forward?q=Springfield Main Street&countries=US&limit=3見慣れないものを何でも取り除いて住所を整えすぎると、ジオコーダーが実際に必要としていた情報まで消してしまうことがあります。部屋番号やアパートの番号、階数の表示、通りの住所に付いた建物名は、住所の他の部分と見た目が違っていても、ノイズではなく意味のある内容です。整える作業は空白、文字コード、明らかに紛れ込んだ文字に限定し、住所の一部である可能性があるものには手を加えないでください。
正規化は誤った一致を減らしますが、完全になくすわけではありません。リクエストが成功したからといって返された結果が自動的に正しいと想定せず、必ず結果のconfidenceフィールドを確認してください。
送信前に入力文字列を整えても、検索にかかるリクエスト数は変わらず、住所1件につき1リクエストのままです。変わるのは、送った1回のリクエストが役に立つ結果を返す可能性です。そうでなければ、修正した2回目の試行が必要になり、2回分のリクエストがかかります。
最初に正規化を正しく行えば、無駄な検索が減り、下流のデータもきれいになります。countriesやlimitを含む、サポートされているパラメータの一覧はジオコーディングのドキュメントをご覧ください。