位置データは正常系だけでなくエッジケースでもテストする
よく地図化された市の中心部の住所からは、システムが農村部のルート、係争中の国境、極地付近のクエリをどう扱うかについてほとんど何もわかりません。難しいケースを意図的にテストしてください。
nullや信頼度の低い結果をどう扱っているか
質問に答えるシステムには、確実に答えられない質問だと認めるよりも、常に何かを返したいという現実的な誘惑があります。位置データの場合、その誘惑に負けることは明確に有害です。もっともらしく見えても間違っている答えは、データが確信を持った答えを裏付けていないと正直に認めることよりも、それが使われる判断に対して一般にはるかに大きな損害を与えるからです。
はっきり言葉にしてしまえば、その理由は単純です。null の結果、あるいは明示的に低い信頼度が付いた結果であれば、よく設計されたアプリケーションはそれを検出し、意図的に処理できます。ユーザーに確認を求める、より広い範囲のデフォルトを適用する、レコードに手動確認のフラグを付ける、といったフォールバックが可能です。一方、ほかの確信度の高い結果とまったく同じ見た目で作られた推測は、実際には弱い一致や曖昧な一致だったことを示すシグナルが何もないため、検出することも特別に処理することもまったくできません。外から見ると本当に確かな回答と区別がつかず、どこか下流で実際に目に見える問題を引き起こすまで気づかれないからです。しかもその問題は、本当の原因までさかのぼって突き止めるのが難しいことがよくあります。
だからこそ、曖昧なクエリや解決できないクエリに対しては、結果をまったく返さないか、実際の不確かさを confidence スコアに正直かつ明確に反映した結果を返すべきです。ジオコーダーが複数のもっともらしい候補から黙って1つを選び、曖昧さのない一致と同じような確かさで提示するべきではありません。同じ原則は精度にも当てはまります。より具体的に見える結果を常に返せという圧力があっても、結果はデータが実際に裏付ける以上に細かい精度レベルを主張すべきではありません。推測で house と報告するより、正直に city と報告するほうがよい結果です。
この種のデータを使って開発する方にとって実践的な意味は、null の結果や低信頼度の結果を、後付けの特別な処理を必要とするまれな例外ケースとしてではなく、レスポンスの中でごく普通に起こる日常的な一部として本当に想定し、適切に処理するようにアプリケーションを設計することです。信頼度が高く完全に解決された結果に対する正常系しか用意されておらず、それ以外について何も考慮された動作がないフォームは、データが確信を持って解決できないクエリにいずれ必ず出会ったとき、わかりにくい形で壊れます。そしてそうしたクエリは、たいていの初期設計が想定しているよりも頻繁に発生します。
すべての結果で precision と confidence の両方を確認し、どちらかがご自身のユースケースで実際に必要なしきい値を下回ったときの、意図的でよく考えられたフォールバック動作を用意しておくこと。これが、難しいケースで穏やかに品質を落とすアプリケーションと、きれいで曖昧さのない回答以外を想定するように設計されていなかったために不正確なデータを静かに広めてしまうアプリケーションとの違いです。