Xây dựng khả năng xác thực vị trí bằng cách sử dụng Nền tảng Google Maps

Mục tiêu

Bạn thường có nhu cầu xác thực vị trí của một địa điểm. Nền tảng Google Maps có một số dịch vụ có thể giúp bạn trong trường hợp sử dụng này. Tài liệu này giúp bạn chọn giữa hai dịch vụ xác thực vị trí chính là Address Validation API và Geocoding API.

Address Validation API là một sản phẩm của Nền tảng Google Maps, giúp khách hàng xác thực xem một địa chỉ có chính xác hay không.

Mã hoá địa lý bằng Geocoding API là quy trình chuyển đổi địa chỉ thành toạ độ địa lý. Bạn có thể dùng toạ độ này để đặt điểm đánh dấu trên bản đồ hoặc một vị trí trên bản đồ.

Bạn có thể xem thông tin tổng quan về những điểm khác biệt giữa API Xác thực địa chỉ và API Mã hoá địa lý tại đây.

Dùng thử ngay: Truy cập vào Google Cloud Console rồi bật Address Validation API và Places API.

Thời điểm nên chọn Address Validation API so với Geocoding API

Lưu ý về sơ đồ quy trình ở trên:

• Trường hợp sử dụng tương tác của người dùng là khi người dùng có mặt để tương tác với kết quả.
• Tính năng tự động hoàn thành địa điểm là một API JavaScript, nên phù hợp để tích hợp với Giao diện người dùng.
• Bạn có thể biết về các vấn đề về chất lượng dữ liệu trong địa chỉ hiện có. Vì vậy, mặc dù bạn chỉ muốn mã địa lý, nhưng bạn nên chạy những vị trí đó thông qua Address Validation API để sửa bộ dữ liệu.

Có nhiều trường hợp bạn có thể chọn sử dụng một sản phẩm thay vì sản phẩm khác dựa trên cây quyết định ở trên. Nhưng trong những trường hợp khác, bạn có thể cần sử dụng cả hai sản phẩm để đạt được mục tiêu của mình.

Bạn có thể chọn sử dụng Address Validation API thay vì Geocoding API khi:

• Khả năng cao là dữ liệu có vấn đề hoặc trường hợp nhận được địa chỉ không chính xác sẽ gây ảnh hưởng tiêu cực đến các bước tiếp theo. Điều này là do Address Validation API cung cấp thêm thông tin phản hồi về lý do khiến một dữ liệu đầu vào không nhận được kết quả có độ chính xác cao.
• Bạn cần phải chỉnh sửa thông tin đầu vào của người dùng (ví dụ: lỗi chính tả hoặc thiếu trường), điều này làm tăng khả năng nhận được kết quả chính xác ở đầu ra.
• Khu vực mục tiêu của bạn trả về nhiều siêu dữ liệu hơn từ Address Validation API so với Geocoding API, chẳng hạn như phân loại loại toà nhà là khu dân cư so với khu thương mại.

Bạn có thể chọn sử dụng dịch vụ Mã hoá địa lý thay vì API Xác thực địa chỉ khi:

• Mục tiêu chính của bạn là truy xuất vị trí của một địa chỉ và độ chính xác của từng địa chỉ có thể không quan trọng.
  • Ví dụ: để tạo bản đồ nhiệt từ một tập dữ liệu lớn.
• Bạn cần một giải pháp toàn cầu và Address Validation API không có ở tất cả các khu vực mục tiêu.

Sau đây là một số ví dụ minh hoạ các chức năng của Address Validation API so với Geocoding API.

Ví dụ về địa chỉ không hợp lệ

1 Fake St, Mountain View, CA 94043, Hoa Kỳ

Address Validation API chia dữ liệu đầu vào này thành các thành phần địa chỉ riêng lẻ (đường phố, thành phố, tiểu bang, v.v.). Bạn cũng có thể nhận được ý kiến phản hồi chi tiết về lý do địa chỉ không hợp lệ ở cấp PREMISE.

Fake St không tồn tại ở Mountain View, California và Address Validation API phản ánh điều đó trong thông tin chi tiết về cấp độ thành phần được trả về:

{
  "componentName": {
    "text": "Fake St",
    "languageCode": "en"
   },
   "componentType": "route",
   "confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
 }

Thuộc tính quan trọng cần kiểm tra trong trường hợp này là confirmationLevel. Bằng cách trả về UNCONFIRMED_BUT_PLAUSIBLE đối với Fake St, API đã xác định rằng một đường phố có thể có tên như vậy, nhưng không thể khớp với dữ liệu địa chỉ hỗ trợ.

Dựa vào kết quả API làm thông tin phản hồi, bạn có thể suy luận rằng thành phần đường phố của dữ liệu đầu vào này (Fake St) có lỗi.

Khi sử dụng cùng một địa chỉ với Geocoding API, API này có thể so khớp với "California" như bạn thấy trong ảnh chụp màn hình của công cụ mã hoá địa lý mà bạn có thể dùng thử tại đây:

Tuy nhiên, kết quả là mã địa lý của toàn bộ tiểu bang, với thông tin phản hồi tối thiểu về những thành phần có thể bị lỗi trên dữ liệu đầu vào.

Ví dụ về lỗi chính tả

76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB

Địa chỉ trên có một vài lỗi chính tả, một lỗi ở tên đường và một lỗi ở địa điểm.

Cả API Xác thực địa chỉ và API Mã hoá địa lý đều có thể sửa những lỗi này và đạt được kết quả là 76 Buckingham Palace Road, London, SW1W 9TQ. Tuy nhiên, Address Validation API có thể cung cấp thêm thông tin về quy trình này.

Hãy xem một trong những thành phần địa chỉ bị viết sai chính tả khi nhập:

{
  "componentName": {
    "text": "Buckingham Palace Road",
    "languageCode": "en"
        },
        "componentType": "route",
        "confirmationLevel": "CONFIRMED",
        "spellCorrected": true
     }
}

Address Validation API trả về một cờ để cho biết rằng trường này đã được điều chỉnh. Bạn có thể triển khai logic nghiệp vụ dựa trên cờ này để kiểm tra kỹ thông tin chỉnh sửa với nhà cung cấp dữ liệu, chẳng hạn như khách hàng trong quy trình thanh toán của trang thương mại điện tử.

Ví dụ về lỗi chính tả và thiếu dữ liệu

Bollschestraße 86, 12587, Đức

Địa chỉ nêu trên có lỗi chính tả trong tên đường và thiếu thành phố (địa phương) Berlin.

Address Validation API có thể khắc phục cả hai lỗi này và trả về một mã địa lý cấp PREMISE, cũng như một địa chỉ đã được xác minh ở cấp PREMISE:

Bölschestraße 86, 12587 Berlin, DE

Trong trường hợp này, Geocoding API không thể khắc phục thành công các lỗi đầu vào và trả về kết quả là ZERO_RESULTS.

Ví dụ về siêu dữ liệu bổ sung cho địa chỉ

111 8th Avenue Ste 123, New York, NY 10011-5201, Hoa Kỳ

Địa chỉ này chính xác, ngoại trừ số căn hộ (Ste 123) không tồn tại trong toà nhà.

Address Validation API có thể xác thực địa chỉ thành PREMISE (111 8th Ave) và cung cấp một số siêu dữ liệu về tài sản, bao gồm cả việc tài sản đó là tài sản thương mại

premises:

"business": true

Ngoài ra, giá trị dpvConfirmation được trả về trong uspsData trong phản hồi là S:

"dpvConfirmation": "S"

Giá trị dpvConfirmation là S cho biết địa chỉ được xác thực ở cấp PREMISE, nhưng số căn hộ được cung cấp trong dữ liệu đầu vào không được liên kết với địa chỉ đó.

Geocoding API không thể cung cấp thông tin này.

Tìm hiểu phản hồi của Geocoding API

Tổng quan

Nếu bạn sử dụng Geocoding API, kết quả mã hoá địa lý sẽ chứa nhiều thông tin trong phản hồi mà bạn có thể dùng để tìm hiểu thông tin chi tiết về địa chỉ được cung cấp.

Cách thức hoạt động của Geocoding API là phân giải các thành phần địa chỉ theo một hệ thống phân cấp.

Ví dụ: 123 Example Street, Chicago, 60007, USA phân giải theo thứ tự sau:

/ Example Street/ Chicago/ 60007/ USA sẽ được đánh giá theo thứ tự đó. Trong trường hợp này, kết quả trùng khớp đầu tiên là Chicago và cụ thể hơn là mã bưu chính 60007. Do đó, hàm này sẽ trả về Place_id sau đây cho Mã bưu chính đó:

ChIJwRKzf8ixD4gRHiXqucwr_HQ

API Địa lý mã hoá chứa thông tin sau trong phản hồi:

        "partial_match": true,
           "place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
           "types": [
               "postal_code"
           ]

Geocoding API có thể xác nhận loại địa điểm mà địa chỉ này thuộc về. Bạn có thể xem danh sách types địa chỉ do Geocoding API trả về tại đây.

Nếu không có thành phần nào của đầu vào được phân giải, API sẽ trả về:

{
   "results": [],
   "status": "ZERO_RESULTS"
}

Khi bạn đưa ra yêu cầu chỉ có địa chỉ đường phố mà không có số nhà, kết quả sẽ có dạng:

"types": [
  "route"
]

Điều này có nghĩa là Geocoding API không tìm thấy hoặc không khớp được số nhà.

Lưu ý: Để biết một địa chỉ có tồn tại hay không, hãy kiểm tra xem có tham số nào (chẳng hạn như types, partial_match, results, status)) được đặt trong phản hồi của Geocoding API hay không. Điều này sẽ dần tăng mức độ tin cậy rằng một địa chỉ có thể tồn tại, nhưng sẽ không chính xác 100%. Đó là lý do chúng tôi cần Address Validation API.

Bạn có thể sử dụng các kỹ thuật nêu trên để tăng độ tin cậy về độ chính xác của địa chỉ chỉ từ một phản hồi của Geocoding API. Tuy nhiên, không giống như kết quả của Address Validation API, Geocoding API sẽ không trả về thông tin phản hồi chính xác để xác định độ chính xác của kết quả.

Loại vị trí

Để hiểu rõ phần này, bạn cần hiểu các loại vị trí có thể được trả về từ phản hồi của API Địa lý:

• ROOFTOP cho biết kết quả trả về là một mã địa lý chính xác mà chúng tôi có thông tin vị trí chính xác đến từng địa chỉ đường phố.
• RANGE_INTERPOLATED cho biết kết quả trả về phản ánh một giá trị ước chừng (thường là trên đường) được suy đoán giữa hai điểm chính xác (chẳng hạn như giao lộ). Kết quả được nội suy thường được trả về khi không có mã địa lý trên nóc nhà cho một địa chỉ đường phố.
• GEOMETRIC_CENTER cho biết kết quả được trả về là tâm hình học của một kết quả, chẳng hạn như đường nhiều đoạn (ví dụ: đường phố) hoặc đa giác (khu vực).
• APPROXIMATE cho biết kết quả trả về không thuộc trường hợp nào ở trên.

Nếu Geocoding API trả về location_type là ROOFTOP hoặc RANGE_INTERPOLATED, thì điều đó không nhất thiết có nghĩa là địa chỉ đó tồn tại. Tương tự, nếu Geocoding API trả về với cờ partial_match được đặt thành true, thì đó vẫn có thể là kết quả phù hợp với bạn.

Loại kết quả trùng khớp giả này là một vấn đề rất khó giải quyết bằng Geocoding API. Ít nhất, bạn có thể cân nhắc triển khai một số quy trình xác thực cơ bản sau xử lý đối với quốc gia và địa phương của yêu cầu / phản hồi. Tốt hơn nữa, hãy so sánh địa chỉ đường phố thực tế để tìm lỗi chính tả và/hoặc địa chỉ chưa đầy đủ.

Lưu ý: Nếu quyết định sử dụng Geocoding API, bạn nên thường xuyên kiểm tra chất lượng dữ liệu giữa yêu cầu ban đầu và phản hồi của Geocoding API.

Trùng khớp một phần và trùng khớp sai

Nếu một địa chỉ là kết quả khớp một phần, tức là Geocoding API không thể xác định chính xác địa chỉ, thì phản hồi sẽ chứa:

"partial_match": true,
"types": [
           "locality",
           "political"
         ]

Điều quan trọng hơn cả các loại vị trí nêu trên là bạn cần cân nhắc thời điểm partial_match = true trong phản hồi. partial_match cho biết Geocoding API không trả về kết quả khớp chính xác cho yêu cầu ban đầu, mặc dù API này có thể khớp một phần của địa chỉ được yêu cầu.

Bạn nên xem xét yêu cầu ban đầu về địa chỉ chưa đầy đủ. Kết quả trùng khớp một phần thường xảy ra đối với những địa chỉ đường không tồn tại trong địa điểm được chỉ định trong yêu cầu. Kết quả trùng khớp một phần cũng có thể được trả về khi một yêu cầu trùng khớp với từ 2 vị trí trở lên ở cùng một địa phương.

Ví dụ: "21 Henr St, Bristol, UK" trả về kết quả khớp một phần cho cả Henry Street và Henrietta Street. Xin lưu ý rằng nếu một yêu cầu có chứa một thành phần địa chỉ bị sai chính tả, thì Geocoding API có thể đề xuất một địa chỉ thay thế. Những đề xuất được kích hoạt theo cách này sẽ không được đánh dấu là trùng khớp một phần.

Địa chỉ ảo

Geocoding API có thể trả về vị trí cho các địa chỉ "giả tạo" không tồn tại dưới dạng vị trí chính xác trong cơ sở dữ liệu của Google.

Trong những trường hợp như vậy, đối tượng phản hồi thường chứa một Place ID dài và thuộc tính sau: geometry.location_type=APPROXIMATE.

Nếu bạn gặp phải những chỉ báo này trong phản hồi, vui lòng cân nhắc đánh dấu địa chỉ đầu vào là không hợp lệ và thử xác thực lại bằng một phương tiện khác.

Lưu ý: Đây là một ví dụ khác cho thấy bạn sẽ nhận được ý kiến phản hồi trực tiếp nếu một địa chỉ không tồn tại khi sử dụng Address Validation API.

Tìm hiểu về phản hồi của Address Validation API

Đã có tài liệu chi tiết về cách hiểu các phản hồi từ Address Validation API, vì vậy, chúng ta sẽ không đi sâu vào chi tiết ở đây.

• Bạn có thể xem thông tin tổng quan về đối tượng phản hồi tại đây.
• Bản minh hoạ minh hoạ các thành phần khác nhau của phản hồi có tại đây
• Trong Tài liệu Xác thực địa chỉ cho quy trình thanh toán, có phần mô tả chi tiết về cách phân biệt địa chỉ phù hợp và địa chỉ không phù hợp.

Các phương pháp hay nhất

Chỉ định vị trí địa lý

Khi thực hiện lệnh gọi đến API Xác thực địa chỉ hoặc API Mã hoá địa lý, bạn nên cố gắng giới hạn phạm vi địa lý để tìm kiếm địa chỉ đó. Hai API này triển khai việc này theo hai cách khác nhau:

• Geocoding API – Region Biasing

  Nếu biết mã địa lý sẽ nằm trong một quốc gia nhất định, bạn sẽ nhận được kết quả tốt hơn nhiều bằng cách sử dụng tính năng Thiên vị theo khu vực. Ví dụ: nếu đang mã hoá địa lý ở Canada, bạn nên thêm &region=ca vào các yêu cầu để ưu tiên Canada. Xin lưu ý rằng tính năng Ưu tiên theo khu vực chỉ ưu tiên kết quả trong khu vực đó. Bạn vẫn có thể nhận được kết quả bên ngoài khu vực này.

• Address Validation API – Mã khu vực

  Tương tự, Address Validation API sẽ mang lại kết quả chính xác hơn nếu mã ISO2 được truyền trong yêu cầu, bằng cách sử dụng trường regionCode.

Lưu trữ mã địa điểm

Để lưu trữ thông tin từ Google Maps Platform về vị trí cho các yêu cầu trong tương lai, bạn có thể lưu trữ mã địa điểm vô thời hạn trong cơ sở dữ liệu của mình dưới dạng một thuộc tính của vị trí. Bạn chỉ cần thực hiện yêu cầu Tìm địa điểm một lần cho mỗi placeID. Bạn cũng có thể tìm kiếm mã địa điểm mỗi khi người dùng yêu cầu thông tin chi tiết về giao dịch.

Để đảm bảo bạn luôn có thông tin mới nhất, hãy làm mới mã địa điểm sau mỗi 12 tháng bằng cách sử dụng yêu cầu Chi tiết về địa điểm có tham số place_id.

Lưu ý: Vui lòng nhớ xem kỹ hướng dẫn về các phương pháp hay nhất để sử dụng tính năng Mã hoá địa lý.

Kết luận

Tài liệu này mô tả những điểm khác biệt chính giữa API Xác thực địa chỉ và API Mã hoá địa lý. Tóm lại, hãy cân nhắc sử dụng Address Validation API khi:

• Bạn phải cung cấp địa chỉ gửi thư chính xác, đặc biệt là để đảm bảo khả năng gửi thư.
• Dữ liệu đầu vào được biết là có chất lượng kém. Address Validation API có khả năng bỏ qua lỗi nhập liệu, sẽ làm nổi bật các thành phần địa chỉ không xác minh được và sửa dữ liệu đầu vào.
• Bạn cần cung cấp thêm thông tin cho địa chỉ, chẳng hạn như Địa chỉ nhà riêng so với Địa chỉ thương mại (chỉ có ở một số khu vực).

Các bước tiếp theo

Tải Cải thiện quy trình thanh toán, giao hàng và hoạt động bằng địa chỉ đáng tin cậy Sách trắng và xem Cải thiện quy trình thanh toán, giao hàng và hoạt động bằng tính năng Xác thực địa chỉ Hội thảo trực tuyến.

Tài liệu đọc thêm được đề xuất:

• Xác thực địa chỉ cho quy trình thanh toán của thương mại điện tử
• Tài liệu về tính năng Tự động hoàn thành địa điểm
• Tài liệu về Address Validation API
• Báo cáo của Nền tảng Google Maps

Người đóng góp

Google duy trì bài viết này. Những người đóng góp sau đây là tác giả ban đầu của bài viết này.

Tác giả chính:

Henrik Valve | Kỹ sư giải pháp

Thomas Anglaret | Kỹ sư giải pháp

Sarthak Ganguly | Kỹ sư giải pháp