API v2からv3に移植するコードがあります。古いコードでは、xmlに戻ってきた精度フィールドがありました(名前はわかりませんが、それは一種の信頼レベルを表していました)。新しいAPIでは、そのようなフィールドはありません。v3 GoogleマップジオコーディングAPIに精度を表すフィールドがありますか?
「Oregon、USA」を検索フィールドに入力すると、5つの一致が得られます。最初の2つは「オレゴン、米国」と「オレゴン、オハイオ、米国」です。どちらも "partial_match" = falseです。これは正しくないと思われますが、部分的に見えますが、そうではありません。さらに、彼らはどちらも同じ "location_type"(APPROXIMATE)を返しています。実際、すべてのマッチは部分的ではなく、同じ場所タイプを持つように表示されています。
私の質問は、結果セットのフィールドは、結果の正確さにある種の信頼を伝えていますか?私のサンプルでは、実際には1つの結果が他のどのものよりもずっと正確であるようです - 入力文字列が返されるQuickAddressフィールドと正確に一致するように。
非常に賢い。それを考えなかっただろうか。私は私たちの "非屋上"のアドレスでいくつかのテストを行い、巨大な範囲を見つけました。屋上、通り(ブロックまたはZIP + 4)、ZIP + 2、ZIPの4つの内訳があります。 Googleの非屋上ロケーションタイプのそれぞれについて、私は時にはAPPROXIMATEがZIP + 4(都市部では屋上にかなり近い)とRANGE_INTERPOLATEDがZIPに近いように終わるので、精度をさらに分析するロジックを作成しました。巨大。 –
私が気づいたもう一つの事は、時にはGoogleがROOFTOPにちょうど通りの住所を与えるが、suite/unit/apt/whateverを追加する... lat/lonが同じままであっても、APPROXIMATEに切り替えるようにしたことである。これはあなたの考えが便利な場所です。サブユニットを追加している間は、他の回はちょうど通りの番地APPROXIMATEになり、ROOFTOPに切り替わります。私は最初のもの、すなわちより多くのデータ、より少ない「信頼」を見ました。私は最初にサブユニットなしで試してみると、ROOFTOPでサブユニットを試そうとするロジックを構築することを考えています。まだROOFTOPでない場合は、境界ボックスを比較し、小さいものを使用してください。 –
@AndrewSありがとう、私は私がインターネットのこの特定のコーナーで唯一の人だったように感じていた - 私は思い出したようにGoogleグループで答えは得られなかった... – jcollum