目標
您經常需要驗證地點的位置。Google 地圖平台提供多項服務，可協助您處理這個用途。本文將協助您選擇兩種主要的位置驗證服務：Address Validation API 和 Geocoding API。
Address Validation API 是 Google 地圖平台提供的服務，可協助客戶驗證地址是否正確。
地理編碼是指使用 Geocoding API 將地址轉換為地理座標的程序，可用於在地圖上放置標記或在地圖上定位。
如要大致瞭解 Address Validation API 和 Geocoding API 的差異，請參閱這篇文章。
何時該選擇 Address Validation API，而非 Geocoding API
上述流程圖注意事項：
- 使用者互動是指使用者在場並與結果互動。
- Place 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，地址驗證 API 會在傳回的元件層級詳細資料中反映這點：
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
在本例中，要檢查的重要屬性是 confirmationLevel。API 針對「Fake St」傳回 UNCONFIRMED_BUT_PLAUSIBLE，表示街道可能會有這個名稱，但無法與支援的地址資料比對。
根據 API 結果做為意見回饋，可以推斷這個輸入內容的街道元件 (Fake St) 有誤。
使用 Geocoding API 查詢相同地址時，系統會比對出「加州」，如地理編碼工具的螢幕截圖所示 (您可以在這裡試用)：
不過，結果是整個州的地理編碼，且幾乎不會提供有關輸入內容中可能發生錯誤的元件。
拼寫錯誤範例
76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB
上述地址有幾個拼字錯誤，一個是街道名稱，另一個是所在地。
地址驗證和 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
這個地址正確無誤，但建築物內沒有 123 號室。
Address Validation API 可驗證地址 (111 8th Ave)，並提供房地產的一些中繼資料，包括該房地產為商業用途PREMISE
場所：
"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 的回應，因此這裡不會進一步說明。
最佳做法
指定地理區域
呼叫 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 和 Geocoding API 的主要差異。總而言之，在下列情況下，建議使用 Address Validation API：
- 請務必提供正確的郵寄地址，確保郵件能順利送達。
- 輸入資料的品質不佳。地址驗證 API 對輸入錯誤的容錯程度較高，會醒目顯示無法驗證的地址元件，並修正輸入資料。
- 地址需要更多資訊，例如住宅地址或商業地址 (僅適用於特定地區)。
後續步驟
下載「提供可靠的地址，改善結帳、送貨和營運流程 」白皮書，並觀看「提供可靠的地址，改善結帳、送貨和營運流程 」網路研討會。
建議閱讀：
貢獻者
本文由 Google 維護。以下是這篇文章的原始撰稿人。
主要作者：
Henrik Valve | 解決方案工程師
Thomas Anglaret | 解決方案工程師
Sarthak Ganguly | 解決方案工程師