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 vài dịch vụ trong Nền tảng Google Maps 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 – 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).

Thời điểm chọn API xác thực địa chỉ 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 người dùng là thời điểm một người dùng có mặt để tương tác với các kết quả.
• Tính năng Tự động hoàn thành địa điểm 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 tình huống 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 vào 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:

• Khả năng cao là dữ liệu có vấn đề hoặc việc nhận địa chỉ không chính xác sẽ có tác động tiêu cực về sau. 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 mã hoá địa lý, chẳng hạn như phân loại loại toà nhà là để ở và toà nhà thương mại.

Bạn có thể chọn sử dụng tính năng 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 mã hoá địa lý.

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, CA và API xác thực địa chỉ phản ánh điều đó trên 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 so với 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ợ.

Sử dụng kết quả API làm phản hồi, có thể suy luận rằng thành phần đường phố của đầu vào này (Fake St) bị 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ề các thành phần trên đầu vào có khả năng 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à Mã hóa địa lý đều có thể sửa những sai lầm 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

API mã hoá địa lý không thể khắc phục thành công lỗi đầu vào trong trường hợp này 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à.

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

cơ sở:

"business": true

Ngoài ra, giá trị dpvConfirmation được trả về như một phần của 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ã hoá địa lý chứa nhiều đầu mối trong phản hồi có thể được sử dụng để hiểu chi tiết về địa chỉ đã 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ả phù hợ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 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 đó có nghĩa là API mã hoá địa lý không thể tìm thấy hoặc khớp 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 API Xác thực địa chỉ.

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ả API xác thực địa chỉ, API mã hoá địa lý 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 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ị ước chừ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 việc triển khai một số xác thực xử lý hậu kỳ cơ bản cho 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 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ý.

So khớp một phần và so 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í ở 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 những chỉ báo này trong câu trả lời, hãy cân nhắc việc đánh dấu địa chỉ bạn nhập là không hợp lệ và thử xác thực lại địa chỉ đó bằng một cách 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

Tài liệu hữu ích về cách hiểu phản hồi từ Address Validation API (API Xác thực địa chỉ) đã có rất nhiều tài liệu hữu ích, vì vậy chúng ta sẽ không đi sâu thêm 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ạ 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 cuộc gọi đến API Xác thực địa chỉ hoặc API Mã hoá địa lý, cách tốt nhất là cố gắng giới hạn khu vực đị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 đó.

• API Xác thực địa chỉ – Mã khu vực

  Tương tự như vậy, 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 mã địa điểm mỗi khi người dùng yêu cầu thông tin 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 12 tháng một lần 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 ý: Hãy nhớ xem lại hướng dẫn về các phương pháp hay nhất về Mã hóa đị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 Đị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 xác định 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 về Cải thiện quy trình thanh toán, giao hàng và hoạt động với địa chỉ đáng tin cậy rồi xem Hội thảo trực tuyến về 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 về đị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. Những cộng tác viên sau đây là người viết bài đầu tiên.

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