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ã hóa địa lý.

API Xác thực địa chỉ 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ý mà bạn có thể sử dụng để đặt điểm đánh dấu trên bản đồ hoặc một vị trí trên bản đồ.

Bạn có thể tìm thấy tổng quan cấp cao về sự khác biệt giữa API xác thực địa chỉ và API mã hóa địa lý tại đây.

Thử ngay: Truy cập vào bảng điều khiển Google Cloud rồi bật API Xác thực địa chỉ và API Địa điểm.

Thời điểm chọn API xác thực địa chỉ so với API mã hoá địa lý

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

• Trường hợp sử dụng hoạt động tương tác của 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 trên đị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ể nhận thấy các vấn đề về chất lượng dữ liệu trong các địa chỉ hiện tại của mình. Vì vậy, mặc dù có thể chỉ muốn mã hoá địa lý, nhưng bạn nên chạy các vị trí đó thông qua Address Validation API (API Xác thực địa chỉ) để chỉnh 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. Nhưng các tình huống khác có thể liên quan đến việc sử dụng cả hai sản phẩm để đạt được mục tiêu của bạn.

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

• Rất có khả năng 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. Điều này là do API xác thực địa chỉ cung cấp thêm ý kiến phản hồi về lý do khiến 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 thông tin do người dùng nhập (ví dụ: lỗi chính tả hoặc các trường bị thiếu) để tăng khả năng trả về kết quả chính xác trên dữ liệu đầ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ừ 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 Mã hóa đị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 địa chỉ và độ chính xác của địa chỉ cá nhân 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 có một giải pháp toàn cầu và API xác thực địa chỉ không có sẵn ở tất cả 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, Hoa Kỳ

API xác thực địa chỉ chia nhỏ thông tin đầu vào này thành các thành phần địa chỉ riêng lẻ (đường, thành phố, tiểu bang, v.v.). Công cụ này cũng có thể đưa ra phản hồi chi tiết về lý do khiến địa chỉ không hợp lệ đến 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 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 so với Fake St, API đã xác định rằng một đường phố có thể có tên đó nhưng không thể 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 luận rằng thành phần đường phố của đầu vào này (Fake St) bị lỗi.

Sử dụng cùng một địa chỉ với API mã hóa địa lý, nó có thể tìm ra kết quả phù hợp trên “California” như bạn thấy trong ảnh chụp màn hình từ công cụ mã hóa địa lý mà bạn có thể 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 ở tên đường phố và lỗi còn lại ở đị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 dữ liệu:

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

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

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

Bollschestraße 86, 12587, Đức

Địa chỉ ở trên bị lỗi chính tả trong tên đường và thiếu thành phố (địa phương) 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ư một đị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ụ khác về siêu dữ liệu địa chỉ

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

Địa chỉ này đúng ngoại trừ số nhà (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ở vật chất:

"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 S cho biết địa chỉ đã được xác thực đến cấp PREMISE, nhưng số đơn vị đã cung cấp trong dữ liệu đầu vào không được liên kết với địa chỉ đó.

API mã hóa đị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 manh 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 API mã hoá địa lý hoạt động là bằng cách phân giải các thành phần địa chỉ trong 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

Geocode API chứa những thông tin sau trong phản hồi:

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

API mã hoá địa lý có thể xác nhận địa chỉ này thuộc loại địa điểm nào. Bạn có thể tìm thấy danh sách địa chỉ types do API mã hóa địa lý 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"
}

Việc thực hiện yêu cầu chỉ có địa chỉ đường phố mà không có số nhà sẽ trả về kết quả trong biểu mẫu:

"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 địa chỉ có tồn tại hay không, hãy kiểm tra xem có thông số nào (chẳng hạn như types, partial_match, results, status)) được đặt trong phản hồi của API mã hoá địa lý hay không. Điều này sẽ dần dần làm tăng mức độ tin cậy mà 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ỉ từ phản hồi API mã hóa đị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 đúng mục này, bạn cần hiểu các loại vị trí khác nhau có thể được trả về từ phản hồi của API mã hoá địa lý:

• ROOFTOP cho biết rằng 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 độ chính xác của địa chỉ đường phố.
• RANGE_INTERPOLATED cho biết kết quả trả về phản ánh một 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 địa chỉ đường phố.
• GEOMETRIC_CENTER cho biết kết quả được trả về là trung tâm hình học của kết quả, chẳng hạn như một hình nhiều đường (ví dụ: đường phố) hoặc đa giác (vùng).
• Hàm REFERRER cho biết rằng kết quả được trả về không thuộc loại nào ở trên.

Nếu API mã hoá địa lý trả về location_type 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 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 hợp sai này là một vấn đề rất khó để giải quyết bằng API mã hoá địa lý. Ít nhất, bạn có thể cân nhắ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 xem xét so sánh địa chỉ đường phố thực tế để phát hiện lỗi chính tả và/hoặc địa chỉ không đầy đủ.

Lưu ý: Nếu quyết định sử dụng API mã hoá địa lý, bạn nên thường xuyên thực hiện việc 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 địa chỉ khớp một phần, nghĩa là API 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"
         ]

Thậm chí, quan trọng hơn các loại vị trí ở trên là xem xét khi nào partial_match = true trong câu trả lời. partial_match cho biết rằng API 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ù API này có thể khớp với một phần địa chỉ được yêu cầu.

Bạn nên kiểm tra yêu cầu ban đầu để tìm địa chỉ chưa hoàn chỉnh. Kết quả phù hợp một phần thường xảy ra đối với các đị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ả trùng khớp một phần cho cả đường Henry và đường Henryetta. Lưu ý rằng nếu yêu cầu bao gồm thành phần địa chỉ bị sai chính tả, API mã hoá địa lý có thể đề xuất địa chỉ thay thế. Các đề 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 mã hóa địa lý có thể trả về vị trí cho "tổng hợp" những địa chỉ 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, trong đó với API Xác thực địa chỉ, bạn sẽ nhận được ý kiến phản hồi trực tiếp nếu không có địa chỉ.

Tìm hiểu về phản hồi của API xác thực địa chỉ

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 câu trả lời có tại đây
• Trong tài liệu về Xác thực địa chỉ cho quy trình thanh toán, bạn sẽ thấy mô tả chi tiết về cách phân biệt địa chỉ tốt và địa chỉ 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 triển khai việc này theo hai cách khác nhau:

• API mã hoá địa lý – Xu hướng khu vực

  Nếu bạn biết mã địa lý sẽ nằm trong một quốc gia nhất định, thì bạn nhận được kết quả tốt hơn nhiều bằng cách sử dụng Xu hướng khu vực. Ví dụ: nếu đang mã hoá địa lý ở Canada, bạn nên thêm &region=ca vào yêu cầu của mình để hướng về Canada. Hãy lưu ý rằng Xu hướng 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 chuyển trong yêu cầu bằng trường regionCode.

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

Để lưu trữ thông tin vị trí từ Nền tảng Google Maps 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 gửi yêu cầu Tìm địa điểm một lần cho mỗi mã địa điểm. 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 nhậ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 Chi tiết địa điểm bằng thông 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ả sự 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 API Xác thực địa chỉ khi:

• Bạn cần có địa chỉ gửi thư chính xác, đặc biệt là khi giao hàng.
• Dữ liệu đầu vào được xác định là có chất lượng kém. Address Validation API (API Xác thực địa chỉ) giúp người dùng dễ dàng chấp nhận lỗi đầu vào hơn, sẽ làm nổi bật các thành phần địa chỉ không thể xác minh và chỉnh sửa dữ liệu đầu vào.
• Bạn cần phải cung cấp thêm thông tin cho một địa chỉ, chẳng hạn như khu dân cư và thương mại (chỉ áp dụng ở 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ên web 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ỉ .

Bạn nên đọc thêm:

• Xác thực địa chỉ cho quy trình thanh toán thương mại điện tử
• Tài liệu tự động hoàn thành về địa điểm
• Tài liệu về API xác thực địa chỉ
• 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