使用 Google 地圖平台建立位置驗證功能

目標

您經常需要驗證地點的位置。Google 地圖平台中有幾項服務可協助你使用這個用途。 本文件會協助您選擇兩種主要的位置驗證服務:Address Validation API 和 Geocoding API。

Address Validation API 是 Google 地圖平台提供的一項服務,可協助消費者確認地址是否正確。

使用 Geocoding API 地理編碼是將地址轉換成地理座標的程序,讓標記能夠在地圖上或地圖位置放置標記。

如需 Address Validation 和 Geocoding API 之間的差異,請參閱本文

選擇 Address Validation 與 Geocoding API 的時機

Address-Validation-vs-Geocoding

上述流程圖的注意事項:

  • 使用者互動用途是指使用者需要與結果互動。
  • Places Autocomplete 是 JavaScript API,因此適合與使用者介面整合。
  • 您可能注意到現有地址的資料品質問題,不過,如果您只是想進行地理編碼,我們仍建議透過 Address Validation API 執行這些位置,以便修正資料集。

您可以根據上方的決策樹狀圖,選擇要採用哪一項產品。不過在另一個情況下,您可能還是需要同時使用這兩項產品才能達成目標。

在下列情況下,您可以選擇使用 Address Validation API 取代 Geocoding API:

  • 資料很可能有問題,或是地址不正確會對下游帶來負面影響。這是因為 Address Validation API 可提供更多意見回饋,說明為何輸入內容未收到高精確度結果。
  • 您需要修正使用者輸入內容 (例如拼寫錯誤或缺漏的欄位),提高生成準確結果的機率。
  • 與 Geocoding API 相比,您的目標區域從 Address Validation API 傳回更多中繼資料,例如將建築物類型分類為住宅、商業用途。

在下列情況下,您可以選擇使用 Geocoding 而非 Address Validation API:

  • 您的主要目標是擷取地址的所在位置,個別地址的正確性並不重要。
    • 例如從大量資料產生熱視圖。
  • 您需要全域解決方案,但 Address Validation API 僅適用於部分目標區域。

以下列舉幾個例子,說明 Address Validation API 功能與 Geocoding API 的差異。

地址無效範例

1 Fake St, Mountain View, CA 94043, USA

Address Validation API 可將此輸入內容分成個別地址元件 (街道、城市、州/省等)。你也可以透過這個方式提供精細的意見回饋,瞭解為何地址有效,無法細分至 PREMISE 層級。

信義街不存在於美國加州山景城,而 Address Validation API 會在傳回的元件層級詳細資料中反映:

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

在本案例中,要檢查的重要屬性是 confirmationLevel。藉由對假街傳回 UNCONFIRMED_BUT_PLAUSIBLE,API 確定了街道可以擁有該街道名稱,但是無法與支援的地址資料配對。

將 API 結果做為意見回饋,我們可以推斷此輸入的街道元件 (偽造街) 出錯。

使用同一個地址搭配 Geocoding API 時,這個 API 就能比對「加州」。正如地理編碼工具的螢幕截圖所示,您可以在這裡試用。

alt_text

不過,這個結果是對整個狀態進行地理編碼,並且盡量減少輸入中哪些元件可能有錯誤的回應。

拼字錯誤範例

76 Buckingamm Palace Road、Londn、SW1W 9TQ、GB

上述地址包含幾個拼寫錯誤,一個包含街道名稱和縣市。

Address Validation 和 Geocoding API 都能夠更正這些錯誤,並達到 76 Buckingham Palace Road, London, SW1W 9TQ 結果。不過,Address Validation API 可提供這項程序的詳細資訊。

請查看輸入時拼字錯誤的地址元件

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Address Validation API 會傳回標記,指出欄位已套用修正。您可以將商業邏輯導入此標記,向資料供應商 (例如電子商務結帳中的客戶) 再次檢查修正結果。

遺漏資料和拼字錯誤範例

Bollschestraße 86, 12587, DE

上述地址的街道名稱有拼字錯誤,而且缺少柏林的城市 (縣市)。

Address Validation API 可以修正這兩種錯誤,並傳回 PREMISE 層級的地理編碼,以及已驗證至 PREMISE 層級的地址:

Bölschestraße 86, 12587 Berlin, DE

在此情況下,Geocoding API 無法成功克服輸入錯誤,因此會傳回 ZERO_RESULTS 的結果。

其他地址中繼資料範例

111 8th Avenue Ste 123, New York, NY 10011-5201, USA

這個地址正確,但建築物內沒有門牌號碼 (Ste 123)。

Address Validation API 可以驗證 PREMISE 的地址 (111 8th Ave),並提供屬性的部分中繼資料,包括其為商業資訊

地端部署:

"business": true

此外,在回應中,uspsData 部分傳回的 dpvConfirmation 值為 S

"dpvConfirmation": "S"

如果 dpvConfirmation 值為 S,表示地址已通過 PREMISE 層級驗證,但輸入中提供的單位號碼與該地址沒有關聯。

Geocoding API 無法提供這項資訊。

瞭解 Geocoding API 回應

總覽

如果使用 Geocoding API,地理編碼結果會在回應中包含多個線索,可用於瞭解所提供地址的詳細資訊。

Geocoding API 的運作方式是透過解析階層中的地址元件。

**例如,123 Example Street, Chicago, 60007, USA 會按照下列順序解析:

/ Example Street/ Chicago/ 60007/ USA 」將依此順序評估。在本例中,第一個相符項目是芝加哥,具體來說是 60007 郵遞區號。因此,它會傳回該郵遞區號的以下 Place_id:

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Geocode API 會在回應中包含以下資訊:

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Geocoding API 可以確認這個地址所屬的地點類型。您可以在這裡找到 Geocoding API 傳回的地址 types 清單。

如果輸入的所有元件均未得到解析,API 會傳回:

{
   "results": [],
   "status": "ZERO_RESULTS"
}

如果在發出要求時只加入街道地址,但沒有門牌號碼,則會傳回以下結果:

"types": [
  "route"
]

這表示 Geocoding API 找不到或與街道號碼相符。

注意:如要知道地址是否存在,請檢查「Geocoding API 回應」中是否有參數 (例如 typespartial_match, results, status))。這樣會逐漸提高地址可能存在的信賴度,但無法達到 100% 的正確性。因此,我們需要 Address Validation API。

您可以使用上述技巧,單靠 Geocoding API 回應,提高地址準確性的信心。但是與 Address Validation API 結果不同的是,Geocoding API 不會傳回確切的意見回饋判斷結果準確性。

位置類型

如要正確解讀這個部分,您必須瞭解 Geocoding API 回應可能傳回的不同位置類型

  • ROOFTOP 表示傳回結果是精確的地理編碼,因為結果中位置資訊的精確範圍已縮小至街道地址。
  • RANGE_INTERPOLATED 表示傳回的結果反映的是插入在兩個精確點之間 (例如十字路口) 的約略位置 (通常是在道路上)。如果 Geocoder 無法取得街道地址的精確定點地理編碼,就會傳回插入的結果。
  • GEOMETRIC_CENTER 表示傳回的結果是結果的幾何中心,包括折線 (例如街道) 和多邊形 (區域)。
  • APPROXIMATE 表示傳回的結果不是上述內容。

如果 Geocoding API 傳回 location_typeROOFTOP RANGE_INTERPOLATED,不一定代表地址存在。同樣地,如果 Geocoding API 傳回 partial_match 旗標設為 true,則可能仍是正確的結果。

這類誤判比對是使用 Geocoding API 解決的一大問題。您至少可以考慮針對要求/回應的國家/地區和當地,執行一些基本的後處理驗證。更棒的是,您可以比對實際街道地址,看看是否有錯別字和/或不完整的地址。

注意:如果您決定使用 Geocoding API,建議您定期檢查初始要求與 Geocoding API 回應之間的資料品質檢查。

部分比對和錯誤比對

如果地址部分符合,表示 Geocoding API 無法確切識別地址,則回應會包含:

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

更重要的是,在回應中將 partial_match = true 納入考量時,請將此納入考量。partial_match 表示 Geocoding API 沒有傳回與原始要求完全相符的結果,但可以比對部分要求的地址。

建議您檢查原始要求,確認地址不完整。出現部分相符結果的最常見原因,是系統在要求中指定的縣市內找不到街道地址。如果要求比對同一個縣市內的兩個或更多地點,也可能會傳回部分相符的結果。

例如「21 Henr St, Bristol, UK」會傳回 Henry Street 和 Henrietta Street 兩者部分相符的結果。請注意,如果要求包含拼寫錯誤的地址元件,Geocoding API 可能會建議其他的地址。以這種方式觸發的建議不會標示為部分相符。

合成地址

Geocoding API 可能會傳回「合成」的位置不是 Google 資料庫的精確位置位置。

在這種情況下,回應物件通常會包含較長的地點 ID,以及下列屬性:geometry.location_type=APPROXIMATE

如果你在回應中看到這些指標,請考慮將輸入地址標示為無效,然後嘗試使用其他方式重新驗證。

注意:這是另一個使用 Address Validation API 的例子,如果地址不存在,您就會收到直接的意見回饋。

瞭解 Address Validation API 回應

目前已有很棒的說明文件,說明如何理解 Address Validation API 回應,因此不會進一步詳細說明。

  • 請參閱這裡,瞭解回應物件的總覽。
  • 如需瞭解回應不同元件的示範,請前往這裡
  • 結帳文件的地址驗證》詳細說明瞭如何區分良好地址與錯誤地址。

最佳做法

指定地理位置

呼叫 Address Validation 或 Geocoding API 時,建議您限制搜尋該地址的地理區域。這兩個 API 會以兩種不同的方式實作此模式:

  • Geocoding API - 區域自訂調整

    如果您知道哪些地理編碼會在特定國家/地區內進行,您可以使用區域自訂調整功能獲得更準確的結果。舉例來說,如果您在加拿大進行地理編碼,建議您在要求中加上 &region=ca,以便針對加拿大提出偏誤。請注意,區域自訂調整隻會「優先」該區域的結果。你仍可取得所在地區以外的結果。

  • Address Validation API - 區域代碼

    以類似的方式,如果您使用 regionCode 欄位在要求中傳遞 ISO2 代碼,Address Validation API 可以產生更準確的結果。

儲存地點 ID

如要儲存 Google 地圖平台上的位置資訊,用於日後的要求,您可以將地點 ID 當成地點屬性,無限期儲存於資料庫中。每個 placeID 只須提出一次 Find Place 要求。此外,您也可以在每次使用者要求交易明細時搜尋地點 ID。

為確保您隨時都能取得最新資訊,請使用 place_id 參數搭配 Place Details 要求,每 12 個月重新整理一次地點 ID

注意:請務必詳閱地理編碼的最佳做法指南

結論

本文件說明 Address Validation 和 Geocoding API 的核心差異。總結來說,您可以在下列情況下使用 Address Validation API:

  • 請務必提供正確的郵寄地址,尤其是方便遞送。
  • 目前已知輸入資料品質不佳。Address Validation API 更能避免輸入錯誤,並醒目顯示無法驗證的地址元件,並修正輸入資料。
  • 地址 (例如住宅或商業) 需要更多資訊 (僅適用於特定地區)。

後續步驟

下載透過可靠地址提升結帳、交付和營運表現 白皮書,並參閱運用地址驗證改善結帳、交付和營運表現 網路研討會。

建議延伸閱讀:

貢獻者

本文由 Google 負責維護。下列提供者原本可以撰寫您的簽名。

主要作者:

Henrik Valve |解決方案工程師

湯瑪斯安格拉特 |解決方案工程師

Sarthak Ganguly |解決方案工程師