Trang này được dịch bởi Cloud Translation API.

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

Thường thì bạn 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 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ý.

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ể xem thông tin tổng quan cấp cao về sự khác biệt giữa API xác thực địa chỉ và API mã hoá địa lý tại đây.

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

Address-Validation-vs-Geocoding

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

Trường hợp sử dụng tương tác với người dùng là thời điểm một 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 của địa điểm là một API JavaScript, nên 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 vấn đề về chất lượng dữ liệu trong các địa chỉ hiện tại của mình. Do đó, mặc dù có thể 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 (API Xác thực địa chỉ) để chỉnh sửa 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 còn lại dựa trên cây quyết định nêu 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:

Có nhiều khả năng dữ liệu có vấn đề hoặc việc nhận được địa chỉ không chính xác sẽ gây 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 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 đầu vào của người dùng (ví dụ: lỗi chính tả hoặc thiếu các trường), điều này làm tăng khả năng nhận được kết quả chính xác trên đầ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à nhà ở và thương mại.

Bạn có thể chọn sử dụ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à API xác thực địa chỉ hiện chỉ có ở một số 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 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 nhập này thành các thành phần địa chỉ riêng lẻ (đường, thành phố, tiểu bang, v.v.). Trình quản lý thẻ này cũng có thể đưa ra phản hồi chi tiết về lý do địa chỉ không hợp lệ xuống cấp PREMISE.

Đường giả không tồn tại ở Mountain View, CA và API xác thực địa chỉ 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 dựa trên đường 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, 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ý, bạn có thể tạo kết quả trùng khớ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ể dùng thử tại đây:

alt_text

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 rất ít về thành phần nào trong dữ liệu đầu vào có thể bị lỗi.

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

76 Buckingamm đường Palace, 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à 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 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ả trong thông tin nhập:

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

API xác thực địa chỉ trả về một cờ để cho biết trường này đã được chỉnh sửa. 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ư khách hàng trong quy trình thanh toán thương mại điện tử.

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

Bollschestraße 86, 12587, Đức

Địa chỉ ở trên có lỗi chính tả trong tên đường và thiếu thành phố (địa phương) của 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 và 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 các lỗi nhập 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 của đị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ố nhà (Số 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ỉ tới PREMISE (111 8th Ave) và cung cấp một số siêu dữ liệu về cơ sở lưu trú, bao gồm cả việc đây là 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 của 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 đượ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 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ý, thì kết quả mã địa lý chứa nhiều gợi ý trong phản hồi có thể dùng để hiểu chi tiết địa chỉ được cung cấp.

Cách thức hoạt động của API mã hoá địa lý là 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 sẽ phân giải theo thứ tự sau:

/ Example Street/ Chicago/ 60007/ USA sẽ được đánh giá theo thứ tự đó. Điểm 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 đó, thuộc tính này 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ã hóa địa lý có thể xác nhận loại địa điểm này thuộc về. Bạn có thể tìm thấy danh sách địa chỉ types được API mã hóa địa lý 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, thì API sẽ trả về:

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

Khi gửi yêu cầu chỉ có địa chỉ đường phố không có số nhà, người dùng sẽ nhận được kết quả dưới dạng như sau:

"types": [
  "route"
]

Điều đó có nghĩa là API mã hoá địa lý không thể tìm thấy hoặc không thể tìm thấy 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 không (chẳng hạn như types, partial_match, results, status) được đặt trong phản hồi của API mã hoá địa lý). Việc này sẽ 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 có Address Validation API (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 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ề 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 phần 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ã hóa đị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 độ chính xác của địa chỉ đường phố.
Hàm RANGE_INTERPOLATED cho biết kết quả được 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ư 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ư hình nhiều đường (ví dụ: đường phố) hoặc đa giác (khu vực).
tiêu chuẩn cho biết rằng kết quả trả về không thuộc trường hợp nào ở trên.

Nếu API mã hoá địa lý trả về location_type của ROOFTOP hoặc RANGE_INTERPOLATED, điều này 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ì đó có thể vẫn là kết quả phù hợp cho bạn.

Kiểu khớ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ố phương pháp xác thực cơ bản sau khi xử lý cho quốc gia và địa phương của yêu cầu / phản hồi. Tốt hơn nữa, bạn nên so sánh địa chỉ đường phố thực tế để tìm 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 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 đị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í, điều quan trọng hơn các loại vị trí ở trên là cần xem xét khi partial_match = true có trong phản hồ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 có thể khớp với một phần của địa chỉ được yêu cầu.

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

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

Hiện đã có nhiều tài liệu hữu ích về cách hiểu được phản hồi của API xác thực địa chỉ, vì vậy, chúng ta sẽ không tìm hiể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ạ 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ó mô tả chi tiết về cách phân biệt địa chỉ tốt với địa chỉ kém.

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ý, tốt nhất là bạn nên giới hạn khu vực địa lý mà họ muốn 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 biết các 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 Xu hướng khu vực. Ví dụ: nếu bạn đang mã hoá địa lý ở Canada, chúng tôi khuyên bạn nên thêm &region=ca vào yêu cầu của mình để thiên vị hướng tới Canada. Xin 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 kết quả bên ngoài khu vực này.
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ẽ đưa ra kết quả chính xác hơn nếu mã ISO2 được chuyển vào 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ừ Nền tảng Google Maps 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 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 kiếm mã địa điểm mỗi khi người dùng yêu cầu cung cấp 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 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ã hoá địa lý.

Kết luận

Tài liệu này mô tả sự khác biệt cốt lõi giữa API xác thực địa chỉ và API mã hóa đị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 phải có địa chỉ gửi thư chính xác, đặc biệt đối với mục đích giao hàng.
Dữ liệu đầu vào được xác định là có chất lượng kém. API xác thực địa chỉ dễ bỏ qua các 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.
Địa chỉ cần cung cấp thêm thông tin, chẳng hạn như để ở hoặc 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ê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ỉ .

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

Người đóng góp

Google duy trì bài viết này. Những cộng tác viên sau đây ban đầu đã viết bài đăng 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