目標
您通常需要驗證地點的位置。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 取代 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。透過針對假街傳回 UNCONFIRMED_BUT_PLAUSIBLE，API 判定某條街道可能有該名稱可用，但無法與佐證地址資料進行比對。
將 API 結果做為意見回饋，可推論此輸入內容的街道元件 (假街) 是故障的。
透過與 Geocoding API 相同的地址，地理編碼工具就能比對「加州」上的比對結果，如地理編碼工具的螢幕截圖所示，您可以在這裡試用：
然而，結果是整個狀態的地理編碼，減少對輸入中哪些元件可能有錯誤的回應。
拼寫錯誤範例
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, 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))。這個方法會逐漸提高地址存在的信賴水準，但不會百分之百準確。因此需要 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 這兩項部分相符的結果。請注意，如果要求包含拼寫錯誤的地址元件，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 - 區域自訂調整
如果您知道某個國家/地區的地理編碼，可以利用「區域自訂調整」功能取得更準確的結果。舉例來說，假設您是在加拿大進行地理編碼，我們建議為將偏向加拿大的要求加上
®ion=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 | 解決方案工程師
Thomas Anglaret | 解決方案工程師
Sarthak Ganguly | 解決方案工程師