目標
您經常需要驗證地點的位置。Google 地圖平台中提供多種服務，可協助您處理此用途。本文件可協助您選擇兩種主要位置驗證服務：Address Validation API 和 Geocoding API。
Address Validation API 是 Google 地圖平台提供的服務，可協助客戶驗證地址是否正確。
使用 Geocoding API 進行地理編碼，就是將地址轉換為地理座標的過程，您可以使用這些座標在地圖上放置標記或位置。
如要概略瞭解地址驗證和地理編碼 API 的差異，請參閱這篇文章。
何時應選擇地址驗證功能，何時應選擇 Geocoding API
關於上述流程圖的注意事項：
- 使用者互動用途是指使用者與結果互動時。
- Places Autocomplete 是 JavaScript API，因此適合與使用者介面整合。
- 您可能會發現現有地址有資料品質問題。因此，即使您只需要地理編碼，建議您透過 Address Validation API 執行這些位置，以便修正資料集。
在許多情況下，您可能會根據上述決策樹狀圖，選擇使用某項產品而非另一項。但在其他情況下，您可能需要同時使用這兩種產品才能達成目標。
在下列情況下，您可以選擇使用 Address Validation API 而非 Geocoding API：
- 很可能會產生可疑資料，或是取得錯誤地址會對後續作業造成負面影響。這是因為 Address Validation API 會提供更多意見回饋，說明輸入內容為何未獲得高精確度結果。
- 您需要修正使用者輸入內容 (例如拼寫錯誤或缺少欄位)，這樣才能提高輸出結果的準確度。
- 與 Geocoding API 相比，目標區域會從 Address Validation API 傳回更多中繼資料，例如建築物類型分類 (住宅或商業)。
您可能會在下列情況下，選擇使用地理編碼而非地址驗證 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 結果做為回饋，可以推斷這個輸入內容的街道元件 (Fake St) 有誤。
使用相同的地址與 Geocoding API，可以比對「California」，如地理編碼工具的螢幕截圖所示，您可以在此試試：
不過，結果是整個州的座標，且只提供少量意見回饋，指出輸入內容的哪些元件可能有誤。
拼寫錯誤示例
76 Buckingamm 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, US
除了單位號碼 (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 傳回部分相符項目。請注意，如果要求包含拼寫錯誤的地址元件，Geocoding API 可能會建議使用其他地址。以這種方式觸發的建議不會標示為部分相符。
合成地址
Geocoding API 可能會傳回「合成」地址的位置，但這些位置並未在 Google 資料庫中顯示為精確位置。
在這種情況下，回應物件通常會包含長型地點 ID，以及下列屬性：geometry.location_type=APPROXIMATE。
如果在回應中看到這些指標，請考慮將輸入的地址標示為無效，然後嘗試透過其他方式重新驗證。
注意：這是另一個使用 Address Validation API 的範例，如果地址不存在，您會收到直接的意見回饋。
瞭解 Address Validation API 回應
我們已提供詳細說明文件，說明如何解讀 Address Validation API 的回應，因此這裡不會進一步說明。
最佳做法
指定地理區域
在呼叫地址驗證或地理編碼 API 時，最佳做法是盡量限制搜尋該地址所在的區域。這兩個 API 以兩種方式實作這項功能：
Geocoding API - Region Biasing
如果您知道地理編碼會位於特定國家/地區，請使用區域偏好設定，以便取得更精確的結果。舉例來說，如果您在加拿大進行地理編碼，建議您在要求中加入
®ion=ca，以便偏向加拿大。請注意，區域偏好設定只會偏好該區域的結果。但仍可取得該區域以外的搜尋結果。Address Validation API - Region Code
同樣地，如果在要求中使用
regionCode欄位傳遞 ISO2 代碼，Address Validation API 就會產生更準確的結果。
儲存地點 ID
如要儲存 Google 地圖平台提供的位置資訊，以便日後提出要求，您可以將地點 ID 儲存在資料庫中，做為位置的屬性。每個 placeID 只需提出一次尋找地點要求。您也可以在使用者要求交易詳細資料時搜尋地點 ID。
為確保您隨時都能取得最新資訊，請每 12 個月使用含有 place_id 參數的 Place Details 要求重新整理地點 ID。
注意：請務必參閱地理編碼的最佳做法指南。
結論
本文將說明地址驗證 API 和地理編碼 API 之間的主要差異。總結來說，請在下列情況下考慮使用 Address Validation API：
- 必須提供正確的郵寄地址，尤其是為了確保可送達性。
- 輸入資料的品質已知不佳。Address Validation API 會更寬容輸入錯誤，並醒目標示無法驗證的地址元件，以及修正輸入資料。
- 地址需要更多資訊，例如住宅或商業地址 (僅適用於特定地區)。
後續步驟
下載「透過可靠的地址改善結帳、運送和營運」 白皮書，並觀看「透過地址驗證功能改善結帳、運送和營運」 網路研討會。
建議參閱以下文章：
貢獻者
本文由 Google 維護。以下是原始作者。
主要作者：
Henrik Valve | 解決方案工程師
Thomas Anglaret | 解決方案工程師
Sarthak Ganguly | 解決方案工程師