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ần xác thực vị trí của một địa điểm. Có một số dịch vụ trong Nền tảng Google Maps có thể giúp bạn xử lý 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 – API Xác thực địa chỉ và API Mã hoá địa lý.

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 API Mã hoá địa lý là quá trình chuyển đổi địa chỉ thành toạ độ địa lý. Bạn có thể sử 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 Địa chỉ (Geocoding API) tại đây.

Thử ngay: Truy cập Google Cloud Console và bật Address Validation API (API Xác thực địa chỉ) và Places API (API Địa điểm).

Trường hợp nên chọn API Xác thực địa chỉ thay vì API Mã hoá địa lý

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 đề cập đến thời điểm người dùng hiện diện để tương tác với kết quả.
• Places Autocomplete là một API javascript, vì vậy, rất phù hợp để tích hợp với Giao diện người dùng.
• Bạn có thể nhận thấy 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 các vị trí đó thông qua API Xác thực địa chỉ để sửa các tập dữ liệu.

Có nhiều trường hợp mà 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. Tuy nhiên, trong một số trường hợp khác, bạn có thể sử dụng cả hai sản phẩm để đạt được mục tiêu.

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

• Có nhiều khả năng dữ liệu sẽ bị nghi ngờ hoặc việc nhận được địa chỉ không chính xác sẽ ảnh hưởng tiêu cực đến quy trình tiếp theo. Lý do là Address Validation API cung cấp thêm phản hồi về lý do 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 sửa lỗi dữ liệu đầ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 kết quả đầu ra chính xác.
• Khu vực mục tiêu của bạn trả về nhiều siêu dữ liệu hơn từ API Xác thực địa chỉ so với API Địa chỉ. Ví dụ: phân loại loại hình xây dựng là nhà ở hay thương mại.

Bạn có thể chọn sử dụng API 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ó ở một số khu vực mục tiêu.

Sau đây là một số ví dụ minh hoạ khả năng của API Xác thực địa chỉ so với API Địa chỉ.

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

1 Fake St, Mountain View, CA 94043, USA

Address Validation API (API Xác thực địa chỉ) sẽ chia nhỏ dữ liệu đầu vào này thành các thành phần địa chỉ riêng lẻ (tên đường, thành phố, tiểu bang, v.v.). API này cũng có thể đưa ra ý 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 (API Xác thực địa chỉ) phản ánh điều đó trên thông tin chi tiết 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 cho Fake St, API đã xác định rằng một con đường có thể có tên đó, nhưng không thể so khớp với dữ liệu địa chỉ hỗ trợ.

Khi sử dụng kết quả API làm phản hồi, có thể suy ra rằng thành phần đường phố của dữ liệu đầu vào này (Fake St) là lỗi.

Khi sử dụng cùng một địa chỉ với API Mã hoá địa lý, 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ột mã địa lý của toàn bộ trạng thái, với phản hồi tối thiểu về thành phần nào trên dữ liệu đầu vào có thể bị lỗi.

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 trong tên đường và một lỗi trong địa phương.

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

Hãy xem một trong các thành phần địa chỉ bị 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 đã được sửa. Bạn có thể triển khai logic kinh doanh dựa trên cờ này để kiểm tra lại nội dung sửa đổi 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 thương mại điện tử.

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

Bollschestraße 86, 12587, DE

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

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

Bölschestraße 86, 12587 Berlin, DE

Trong trường hợp này, API Mã hoá địa lý 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 địa chỉ bổ sung

111 8th Avenue Ste 123, New York, NY 10011-5201, US

Đị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ỉ cho 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 đó là một tài sản thương mại

cơ sở:

"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ố đơn vị được cung cấp trong dữ liệu đầu vào không liên kết với địa chỉ đó.

API Địa chỉ được mã hoá địa lý không thể cung cấp thông tin này.

Tìm hiểu về phản hồi của API Mã hoá địa lý

Tổng quan

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

Cách hoạt động của API Địa chỉ là phân giải các thành phần địa chỉ theo hệ 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ự đó. Kết quả trùng khớp đầu tiên trong trường hợp này 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 Mã địa lý chứa các 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 địa chỉ này thuộc loại địa điểm nào. Bạn có thể xem danh sách địa chỉ types do API Địa chỉ được mã hoá trả về tại đây.

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

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

Nếu bạn chỉ đưa ra địa chỉ đường phố mà không có số nhà, thì hệ thống sẽ trả về kết quả ở dạng:

"types": [
  "route"
]

Điều này có nghĩa là API Địa chỉ được mã hoá địa lý không tìm thấy hoặc không khớp với 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 API Địa chỉ được mã hoá địa lý 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 làm cho địa chỉ đó chính xác 100%. Đó là lý do chúng ta cần Address Validation API.

Bạn có thể sử dụng các kỹ thuật ở trên để tăng độ tin cậy về độ chính xác của địa chỉ chỉ bằng một phản hồi của API Mã hoá địa lý. Tuy nhiên, không giống như kết quả của API Xác thực địa chỉ, API Địa chỉ sẽ không trả về 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 rõ các loại vị trí có thể được trả về từ phản hồi của API Địa chỉ được mã hoá đị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 giá trị gần đúng (thường là trên một con đường) được nội suy giữa hai điểm chính xác (chẳng hạn như các giao lộ). Kết quả nội suy thường được trả về khi không có mã địa lý trên mái nhà cho một địa chỉ đường phố.
• GEOMETRIC_CENTER cho biết kết quả trả về là tâm hình học của một kết quả, chẳng hạn như đường đa tuyến (ví dụ: đường phố) hoặc đa giác (khu vực).
• APPROXIMATE (GẦN GIÁ TRỊ THỰC) cho biết kết quả trả về không thuộc trường hợp nào ở trên.

Nếu một API Mã hoá địa lý trả về location_type của 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 một API Mã hoá địa lý 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 rất khó giải quyết bằng API Địa chỉ. Í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 khi xử lý đối với quốc gia và vị trí 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 hoàn chỉnh.

Lưu ý: Nếu quyết định sử dụng API Mã hoá địa lý, 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 API Mã hoá địa lý.

Khớp một phần và khớp sai

Nếu một địa chỉ khớp một phần, tức là API Địa chỉ được mã hoá địa lý 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"
         ]

Quan trọng hơn cả các loại vị trí ở 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 rằng API Địa chỉ được mã hoá địa lý không trả về kết quả khớp chính xác cho yêu cầu ban đầu, mặc dù có thể khớp một phần của địa chỉ được yêu cầu.

Bạn nên kiểm tra 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 phố không tồn tại trong địa phương đượ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 khớp với hai hoặc nhiều vị trí trong 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ó thành phần địa chỉ bị sai chính tả, thì API Địa chỉ được mã hoá địa lý có thể đề xuất một địa chỉ thay thế. Nội dung đề xuất được kích hoạt theo cách này sẽ không được đánh dấu là khớp một phần.

Địa chỉ tổng hợp

API Địa chỉ được mã hoá địa lý có thể trả về vị trí cho các địa chỉ "tổng hợp" 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 Mã địa điểm dài và thuộc tính sau: geometry.location_type=APPROXIMATE.

Nếu bạn gặp các 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à cố gắng xác thực lại địa chỉ đó bằng một phương thức khác.

Lưu ý: Đây là một ví dụ khác về việc sử dụng API Xác thực địa chỉ để nhận phản hồi trực tiếp nếu địa chỉ không tồn tại.

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

Chúng tôi đã có tài liệu rất hữu ích về cách hiểu các phản hồi từ Address Validation API, vì vậy, chúng tôi sẽ không đi sâu vào chi tiết tại đâ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ạ các thành phần của phản hồi tại đây
• Trong tài liệu Xác thực địa chỉ để thanh toán, có nội dung mô tả chi tiết về cách phân biệt địa chỉ hợp lệ và không hợp lệ.

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 Địa chỉ mã hoá địa lý, tốt nhất 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 – Khu vực thiên vị

  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 bạn đ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 Lệch 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 đó.

• Address Validation API – Mã khu vực

  Tương tự, API Xác thực địa chỉ sẽ tạo ra kết quả chính xác hơn nếu mã ISO2 được truyền trong yêu cầu, sử dụng trường regionCode.

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

Để lưu trữ thông tin về vị trí từ Google Maps Platform 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 dưới dạng thuộc tính của vị trí. Bạn chỉ cần tạo một 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 mỗi 12 tháng bằng cách sử dụng yêu cầu Thông tin chi tiết về địa điểm với tham số place_id.

Lưu ý: Ngoài ra, hãy nhớ tham khảo hướng dẫn về các phương pháp hay nhất để Địa chỉ mã hoá.

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 Địa chỉ. Tóm lại, hãy cân nhắc sử dụng API Xác thực địa chỉ khi:

• Bạn phải cung cấp địa chỉ gửi thư chính xác, đặc biệt là cho mục đích 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 chấp nhận lỗi nhập hơn, sẽ làm nổi bật các thành phần địa chỉ không xác minh được và chỉnh sửa dữ liệu đầu vào.
• Bạn cần cung cấp thêm thông tin về địa chỉ, chẳng hạn như Khu dân cư hay Khu thương mại (có ở một số khu vực).

Các bước tiếp theo

Tải sách trắng 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 xuống và xem hội thảo trên web 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ỉ .

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

• Xác thực địa chỉ cho quy trình thanh toán 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 trên Nền tảng Google Maps

Người đóng góp

Google duy trì bài viết này. Các cộng tác viên 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