目標
您經常需要驗證地點的位置。Google 地圖平台中提供多種服務，可協助您處理此用途。本文可協助您選擇兩項主要位置驗證服務：Address Validation API 和 Geocoding API。
Address Validation API 是 Google 地圖平台提供的服務，可協助客戶驗證地址是否正確。
使用 Geocoding API 進行地理編碼，是指將地址轉換為地理座標的程序，您可以使用這些座標在地圖上放置標記或定位。
如要概略瞭解地址驗證 API 和 Geocoding API 的差異，請參閱這篇文章。
何時應選擇 Address Validation API 或 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 結果做為意見回饋，可以推斷這個輸入內容的街道元件 (Fake St) 有誤。
使用 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, 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 傳回 ROOFTOP 或 RANGE_INTERPOLATED 的 location_type，不一定表示地址存在。同樣地，如果 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 | 解決方案工程師