目標
您經常需要驗證地點的位置。Google 地圖平台中提供多種服務，可協助您處理此用途。本文可協助您選擇兩項主要位置驗證服務：Address Validation API 和 Geocoding API。
Address Validation API 是 Google 地圖平台提供的服務，可協助客戶驗證地址是否正確。
使用 Geocoding API 地理編碼是將地址轉換成地理座標的程序，讓標記能夠在地圖上或地圖位置放置標記。
如需 Address Validation 和 Geocoding API 之間的差異，請參閱本文。
選擇 Address Validation 與 Geocoding API 的時機
關於上述流程圖的注意事項：
- 使用者互動用途是指使用者與結果互動時。
- Places Autocomplete 是 JavaScript API，因此適合與使用者介面整合。
- 你可能會發現現有地址有資料品質問題。因此，即使您只需要地理編碼，建議您透過 Address Validation API 執行這些位置，以便修正資料集。
在許多情況下，您可能會根據上述決策樹狀圖，選擇使用某項產品而非另一項。但在其他情況下，您可能需要同時使用這兩項產品才能達成目標。
在下列情況下，您可以選擇使用 Address Validation API 取代 Geocoding API：
- 資料很可能有問題，或是地址不正確會對下游帶來負面影響。這是因為 Address Validation API 可提供更多意見回饋，說明為何輸入內容未收到高精確度結果。
- 您需要修正使用者輸入內容 (例如拼寫錯誤或缺漏的欄位)，提高生成準確結果的機率。
- 與 Geocoding API 相比，目標區域會從 Address Validation API 傳回更多中繼資料，例如建築物類型分類 (住宅或商業)。
您可能會在下列情況下，選擇使用 Geocoding API 而非 Address Validation API：
- 您的主要目標是擷取地址的位置資訊，因此個別地址的精確度可能不太重要。
- 例如從大量資料產生熱視圖。
- 您需要全球解決方案，而 Address Validation API 並非適用於所有目標區域。
以下列舉幾個例子，說明 Address Validation API 功能與 Geocoding API 的差異。
無效地址範例
1 Fake St, Mountain View, CA 94043, USA
Address Validation API 會將這項輸入內容拆解為個別地址元件 (街道、城市、州等)。你也可以透過這個方式提供精細的意見回饋，瞭解為何地址有效，無法細分至 PREMISE 層級。
Fake St 不在加州山景市，因此 Address Validation API 會在傳回的元件層級詳細資料中反映這項資訊：
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
在本案例中，要檢查的重要屬性是 confirmationLevel。針對 Fake St 傳回 UNCONFIRMED_BUT_PLAUSIBLE 後，API 判斷街道名稱可以是這個字串，但無法與支援的地址資料比對。
將 API 結果做為意見回饋，可推斷此輸入的街道元件 (偽造街) 發生錯誤。
使用 Geocoding API 搭配相同的地址，即可在「California」上進行比對，如地理編碼工具的螢幕截圖所示，您可以在此試用：
不過，結果是整個州的座標，而且只會提供最少的意見回饋，指出輸入內容的哪些元件可能有誤。
拼字錯誤範例
76 Buckingam Palace Road, Londn, SW1W 9TQ, GB
上述地址包含幾個拼寫錯誤，一個包含街道名稱和縣市。
地址驗證和地理編碼 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 回應中是否設定了任何參數 (例如 types、partial_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_type 為 ROOFTOP 或 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 這兩項部分相符的結果。請注意，如果要求包含拼寫錯誤的地址元件，地理編碼 API 可能就會建議使用替代地址。透過這種方式觸發的建議，不會標示為部分相符。
綜合地址
Geocoding API 可能會傳回「合成」地址的位置資訊，但這些位置資訊並非 Google 資料庫中精確的位置。
在這種情況下，回應物件通常會包含長的 Place ID，以及以下屬性：geometry.location_type=APPROXIMATE。
如果您在回應中看到這些指標，請考慮將輸入的地址標示為無效，然後嘗試透過其他方式重新驗證。
注意：這是另一個使用 Address Validation API 的例子，如果地址不存在，您就會收到直接的意見回饋。
瞭解 Address Validation API 回應
我們已提供詳細說明文件，說明如何解讀 Address Validation API 的回應，因此我們不會在此進一步說明。
最佳做法
指定地理位置
呼叫 Address Validation API 或 Geocoding API 時，建議您盡量限制搜尋該地址的地理區域。這兩個 API 實作這項功能的方式有兩種：
Geocoding API - 區域偏差
如果您知道哪些地理編碼會在特定國家/地區內進行，您可以使用區域自訂調整功能獲得更準確的結果。舉例來說，如果您在加拿大進行地理編碼，建議您在要求中加入
®ion=ca，以便偏向加拿大。請注意，區域自訂調整功能只會優先顯示該區域的結果。但仍可顯示該區域以外的搜尋結果。Address Validation API - 區域代碼
同樣地，如果在要求中使用
regionCode欄位傳遞 ISO2 代碼，Address Validation API 會產生更準確的結果。
儲存地點 ID
如要儲存 Google 地圖平台的地點資訊，以便用於日後的要求，您可以將地點 ID 當成地點屬性，無限期儲存於資料庫中。每個 placeID 只需發出一次 Find Place 要求。此外，您也可以在每次使用者要求交易明細時搜尋地點 ID。
為確保您隨時都能取得最新資訊，請使用 place_id 參數搭配 Place Details 要求，每 12 個月重新整理一次地點 ID。
注意：請務必參閱地理編碼的最佳做法指南。
結論
本文件說明地址驗證 API 和地理編碼 API 之間的主要差異。總結來說，您可以在下列情況下使用 Address Validation API：
- 必須提供正確的郵寄地址，尤其是為了確保可送達性。
- 輸入資料的品質已知不佳。Address Validation API 會更寬容輸入錯誤，並會醒目顯示無法驗證的地址元件，以及修正輸入資料。
- 地址必須提供更多資訊，例如住宅或商業 (適用於特定地區)。
後續步驟
下載「透過可靠的地址改善結帳、運送和營運」 白皮書，並觀看「透過地址驗證功能改善結帳、運送和營運」 網路研討會。
建議參閱以下文章：
貢獻者
本文由 Google 維護。以下是原始作者。
主要作者：
Henrik Valve | 解決方案工程師
Thomas Anglaret | 解決方案工程師
Sarthak Ganguly | 解決方案工程師