目標
您經常需要驗證地點的位置。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 層級。
信義街不存在於美國加州山景城，而 Address Validation API 會在傳回的元件層級詳細資料中反映：
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
在本案例中，要檢查的重要屬性是 confirmationLevel。藉由對假街傳回 UNCONFIRMED_BUT_PLAUSIBLE，API 確定了街道可以擁有該街道名稱，但是無法與支援的地址資料配對。
將 API 結果做為意見回饋，我們可以推斷此輸入的街道元件 (偽造街) 出錯。
使用同一個地址搭配 Geocoding API 時，這個 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, 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 這兩項部分相符的結果。請注意，如果要求包含拼寫錯誤的地址元件，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 | 解決方案工程師