Membuat kemampuan validasi lokasi menggunakan Google Maps Platform

Tujuan

Anda sering kali memerlukan validasi lokasi suatu tempat. Ada beberapa layanan di Google Maps Platform yang dapat membantu Anda dalam kasus penggunaan ini. Dokumen ini membantu Anda memilih antara dua layanan validasi lokasi utama - Address Validation API dan Geocoding API.

Address Validation API adalah penawaran dari Google Maps Platform yang membantu pelanggan memvalidasi apakah alamat tersebut akurat atau tidak.

Geocoding dengan Geocoding API adalah proses konversi alamat menjadi koordinat geografis, yang dapat Anda gunakan untuk menempatkan penanda pada peta atau posisi pada peta.

Ringkasan lengkap tentang perbedaan antara Validasi Alamat dan Geocoding API dapat ditemukan di sini.

Coba sekarang: Buka Konsol Google Cloud dan aktifkan Address Validation API dan Places API.

Kapan harus memilih Validasi Alamat vs. Geocoding API

Catatan tentang diagram alur di atas:

• Kasus penggunaan interaksi pengguna mengacu pada saat pengguna hadir untuk berinteraksi dengan hasil.
• Places Autocomplete adalah javascript API, sehingga cocok untuk diintegrasikan dengan Antarmuka Pengguna.
• Anda mungkin mengetahui adanya masalah kualitas data di alamat lama. Jadi, meskipun Anda mungkin hanya menginginkan geocode, sebaiknya jalankan lokasi tersebut melalui Address Validation API untuk memperbaiki set data.

Ada banyak situasi saat Anda mungkin memilih, berdasarkan pohon keputusan di atas, untuk menggunakan satu produk daripada produk lainnya. Tetapi situasi lain mungkin melibatkan penggunaan kedua produk untuk mencapai tujuan Anda.

Anda dapat memilih untuk menggunakan Address Validation API daripada Geocoding API saat:

• Ada kemungkinan besar data yang dipertanyakan, atau jika alamat yang salah akan berdampak negatif pada downstream. Hal ini karena Address Validation API memberikan lebih banyak masukan terkait alasan input tidak menerima hasil presisi tinggi.
• Anda harus memperbaiki input pengguna (misalnya, kesalahan ejaan atau kolom tidak ada), yang akan meningkatkan kemungkinan memberikan hasil yang akurat pada output.
• Wilayah target Anda menampilkan lebih banyak metadata dari Address Validation API dibandingkan dengan Geocoding API, seperti klasifikasi jenis bangunan sebagai tempat tinggal vs. komersial.

Anda dapat memilih untuk menggunakan Geocoding daripada Address Validation API saat:

• Tujuan utama Anda adalah mengambil lokasi suatu alamat dan akurasi masing-masing alamat mungkin tidak terlalu penting.
  • Misalnya, untuk membuat peta panas dari set data yang besar.
• Anda memerlukan solusi global, dan Address Validation API tidak tersedia di semua wilayah target.

Berikut ini beberapa contoh yang menunjukkan kemampuan Address Validation API dibandingkan dengan Geocoding API.

Contoh Alamat Tidak Valid

1 Fake St, Mountain View, CA 94043, USA

Address Validation API mengelompokkan input ini ke dalam komponen alamatnya masing-masing (jalan, kota, negara bagian, dll.). Fitur ini juga dapat memberikan masukan terperinci tentang alasan alamat tidak valid hingga tingkat PREMISE.

Jalan Palsu tidak ada di Mountain View, CA, dan Address Validation API mencerminkan hal tersebut pada detail level komponen yang ditampilkan:

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

Properti yang penting untuk diperiksa dalam kasus ini adalah confirmationLevel. Dengan menampilkan UNCONFIRMED_BUT_PLAUSIBLE terhadap Fake St, API menentukan bahwa mungkin saja sebuah jalan memiliki nama tersebut sebagai nama, tetapi tidak dapat dicocokkan dengan data alamat yang mendukungnya.

Dengan menggunakan hasil API sebagai masukan, dapat disimpulkan bahwa komponen jalan dari input ini (Fake St) salah.

Menggunakan alamat yang sama dengan Geocoding API, aplikasi ini dapat membuat kecocokan di "California" seperti yang Anda lihat di screenshot dari alat geocoding yang dapat Anda coba di sini:

Namun, hasilnya adalah geocode seluruh status, dengan masukan minimal terkait komponen mana yang berpotensi salah pada input.

Contoh Kesalahan Ejaan

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

Alamat di atas berisi beberapa kesalahan ejaan, satu pada nama jalan, dan satu lagi dalam daerah setempat.

Baik Address Validation dan Geocoding API, mampu memperbaiki kesalahan tersebut dan mendapatkan hasil 76 Buckingham Palace Road, London, SW1W 9TQ. Namun, Address Validation API dapat memberikan lebih banyak informasi tentang prosesnya.

Lihat salah satu komponen alamat yang salah eja pada input:

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

Address Validation API menampilkan tanda untuk menunjukkan bahwa koreksi telah dilakukan pada kolom. Logika bisnis dapat diterapkan pada tanda ini untuk memeriksa kembali koreksinya dengan penyedia data, seperti pelanggan dalam checkout e-commerce.

Contoh Kesalahan Data dan Ejaan

Bollschestraße 86, 12587, DE

Alamat di atas memiliki kesalahan ejaan dalam nama jalan, dan kota (lokalitas) Berlin tidak ada.

Address Validation API dapat memperbaiki kedua error ini dan menampilkan geocode level PREMISE, serta alamat yang diverifikasi ke level PREMISE:

Bölschestraße 86, 12587 Berlin, DE

Geocoding API tidak berhasil mengatasi error input dalam kasus ini, dan menampilkan hasil ZERO_RESULTS.

Contoh Metadata Alamat Tambahan

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

Alamat ini sudah benar, kecuali untuk nomor unit (Ste 123), yang tidak ada di dalam gedung.

Address Validation API dapat memvalidasi alamat ke PREMISE (111 8th Ave), dan memberikan beberapa metadata tentang properti, termasuk properti komersial

lokasi:

"business": true

Selain itu, nilai dpvConfirmation yang ditampilkan sebagai bagian dari uspsData dalam respons adalah S:

"dpvConfirmation": "S"

Nilai dpvConfirmation dari S menunjukkan bahwa alamat divalidasi ke level PREMISE, tetapi nomor unit yang diberikan dalam input tidak terkait dengan alamat tersebut.

Geocoding API tidak dapat memberikan informasi ini.

Memahami respons Geocoding API

Ringkasan

Jika Anda menggunakan Geocoding API, hasil geocode berisi berbagai petunjuk dalam respons yang dapat digunakan untuk memahami detail alamat yang diberikan.

Cara kerja Geocoding API adalah dengan me-resolve komponen alamat dalam hierarki.

Misalnya, **123 Example Street, Chicago, 60007, USA di-resolve dalam urutan berikut:

/ Example Street/ Chicago/ 60007/ USA akan dievaluasi dalam urutan tersebut. Kecocokan pertama dalam kasus ini adalah Chicago dan, lebih khusus lagi, Kode Pos 60007. Oleh karena itu, kode ini menampilkan Place_id berikut untuk Kode Pos tersebut:

ChIJwRKzf8ixD4gRHiXqucwr_HQ

Geocode API berisi info berikut dalam respons:

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

Geocoding API bisa mengonfirmasi jenis tempat untuk alamat ini. Daftar alamat types yang ditampilkan oleh Geocoding API dapat ditemukan di sini.

Jika tidak ada komponen input yang diselesaikan, API akan menampilkan:

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

Membuat permintaan hanya dengan alamat tanpa nomor rumah akan menampilkan hasil dalam bentuk:

"types": [
  "route"
]

Artinya, Geocoding API tidak dapat menemukan atau mencocokkan nomor jalan.

Catatan: Untuk mengetahui apakah alamat ada, periksa apakah ada parameter (seperti types, partial_match, results, status) yang ditetapkan dalam respons Geocoding API. Hal ini secara bertahap akan meningkatkan tingkat keyakinan bahwa alamat mungkin ada, tetapi tidak akan membuatnya 100% akurat. Itulah sebabnya kami membutuhkan Address Validation API.

Anda dapat menggunakan teknik di atas untuk meningkatkan keyakinan pada akurasi alamat hanya dari respons Geocoding API. Namun, tidak seperti hasil Address Validation API, Geocoding API tidak akan menampilkan masukan yang tepat untuk menentukan akurasi hasil.

Location type

Untuk memahami bagian ini dengan benar, Anda perlu memahami berbagai jenis lokasi yang dapat ditampilkan dari respons Geocoding API:

• ROOFTOP menunjukkan bahwa hasil yang ditampilkan adalah geocode akurat yang informasi lokasinya kita miliki secara akurat dengan presisi hingga ke alamat jalan.
• RANGE_INTERPOLATED menunjukkan bahwa hasil yang ditampilkan mencerminkan perkiraan (biasanya pada jalan) interpolasi antara dua titik tepat (seperti persimpangan). Hasil interpolasi umumnya dikembalikan bila rooftop-geocode tidak tersedia untuk alamat jalan.
• GEOMETRIC_CENTER menunjukkan bahwa hasil yang ditampilkan adalah pusat geometris dari hasil seperti polyline (misalnya, jalan) atau poligon (wilayah).
• APPROXIMATE menunjukkan bahwa hasil yang ditampilkan bukan salah satu di atas.

Jika Geocoding API menampilkan location_type dari ROOFTOP atau RANGE_INTERPOLATED, itu tidak berarti bahwa alamat tersebut ada. Demikian pula, jika Geocoding API ditampilkan dengan tanda partial_match yang ditetapkan ke true, ini mungkin masih menjadi hasil yang tepat untuk Anda.

Jenis pencocokan salah ini adalah masalah yang sangat sulit diselesaikan dengan Geocoding API. Setidaknya, Anda dapat mempertimbangkan untuk menerapkan beberapa validasi pascapemrosesan dasar pada negara dan lokalitas permintaan / respons. Lebih baik lagi, coba bandingkan alamat sebenarnya untuk menemukan kesalahan eja dan/atau alamat yang tidak lengkap.

Catatan: Jika memutuskan untuk menggunakan Geocoding API, sebaiknya lakukan pemeriksaan kualitas data antara permintaan awal dan respons Geocoding API secara rutin.

Pencocokan sebagian dan pencocokan salah

Jika alamat cocok sebagian, artinya Geocoding API tidak bisa mengidentifikasi alamat secara persis, maka responsnya berisi:

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

Hal yang lebih penting daripada jenis lokasi di atas adalah mempertimbangkan kapan partial_match = true dalam respons. partial_match menunjukkan bahwa Geocoding API tidak menampilkan kecocokan persis untuk permintaan asli, meskipun bisa saja cocok dengan sebagian alamat yang diminta.

Sebaiknya periksa permintaan awal untuk menemukan alamat yang tidak lengkap. Kecocokan parsial paling sering terjadi untuk alamat jalan yang tidak ditemukan dalam lokasi yang ditentukan dalam permintaan. Kecocokan parsial juga mungkin dikembalikan bila sebuah permintaan memiliki kecocokan terhadap dua atau beberapa lokasi di daerah yang sama.

Misalnya, "21 Henr St, Bristol, UK" akan menampilkan kecocokan sebagian untuk Henry Street dan Henrietta Street. Perhatikan, jika permintaan menyertakan komponen alamat yang salah eja, Geocoding API mungkin menyarankan alamat alternatif. Saran yang terpicu melalui cara ini tidak akan ditandai sebagai kecocokan parsial.

Alamat Sintetis

Geocoding API dapat menampilkan lokasi untuk alamat "sintetik" yang tidak ada sebagai lokasi presisi dalam database Google.

Dalam skenario seperti itu, objek respons sering kali berisi ID Tempat yang panjang, dan properti berikut: geometry.location_type=APPROXIMATE.

Jika Anda menemukan indikator ini dalam respons, pertimbangkan untuk menandai alamat input sebagai tidak valid dan coba validasi ulang dengan cara lain.

Catatan: Ini adalah contoh lain saat Address Validation API, yang memungkinkan Anda mendapatkan masukan langsung jika alamat tidak ada.

Memahami respons Address Validation API

Sudah ada dokumentasi yang bagus tentang cara memahami respons dari Address Validation API, sehingga kami tidak akan membahas detail lebih lanjut di sini.

• Ringkasan objek respons dapat ditemukan di sini.
• Demo yang menggambarkan berbagai komponen respons ada di sini
• Dalam Validasi Alamat untuk dokumen checkout terdapat deskripsi mendetail tentang cara membedakan alamat baik atau buruk.

Praktik terbaik

Menentukan geografi

Saat melakukan panggilan ke Address Validation atau Geocoding API, praktik terbaiknya adalah mencoba membatasi geografi untuk menelusuri alamat tersebut. Kedua API tersebut menerapkan hal ini dalam dua cara yang berbeda:

• Geocoding API - Pembiasan Wilayah

  Jika mengetahui bahwa geocode akan berada di negara tertentu, Anda akan mendapatkan hasil yang jauh lebih baik dengan menggunakan Pembiasan Region. Misalnya, jika Anda melakukan geocoding di Kanada, sebaiknya tambahkan &region=ca ke permintaan Anda agar mengarah ke Kanada. Perhatikan bahwa Pembiasan Wilayah hanya mengutamakan hasil dalam wilayah tersebut. Anda tetap bisa mendapatkan hasil di luar wilayah tersebut.

• Address Validation API - Kode Wilayah

  Dengan cara yang sama, Address Validation API memberikan hasil yang lebih akurat jika kode ISO2 diteruskan dalam permintaan, menggunakan kolom regionCode.

Menyimpan ID tempat

Untuk menyimpan informasi dari Google Maps Platform tentang lokasi untuk permintaan mendatang, Anda dapat menyimpan ID tempat tanpa batas waktu di database sebagai atribut lokasi. Anda hanya perlu membuat permintaan Find Place satu kali per ID tempat. Anda juga dapat menelusuri ID tempat setiap kali pengguna meminta detail transaksi.

Untuk memastikan Anda selalu memiliki informasi terbaru, perbarui ID tempat setiap 12 bulan menggunakan permintaan Place Details dengan parameter place_id.

Catatan: Pastikan Anda juga meninjau panduan praktik terbaik untuk Geocoding.

Kesimpulan

Dokumen ini menjelaskan perbedaan utama antara Validasi Alamat dan Geocoding API. Singkatnya, pertimbangkan untuk menggunakan Address Validation API saat:

• Diperlukan alamat surat yang akurat, terutama untuk tujuan pengiriman.
• Data input tersebut diketahui berkualitas buruk. Address Validation API lebih memaafkan error input, akan menandai komponen alamat yang tidak dapat diverifikasi, serta melakukan koreksi pada data input.
• Informasi lebih lanjut diperlukan untuk alamat, seperti Perumahan vs. Komersial (tersedia di wilayah tertentu).

Langkah Berikutnya

Download Laporan Resmi Meningkatkan checkout, pengiriman, dan operasi dengan alamat yang andal dan lihat Webinar Meningkatkan checkout, pengiriman, dan operasi dengan Validasi Alamat .

Saran bacaan lebih lanjut:

• Validasi Alamat untuk Checkout E-commerce
• Dokumentasi Place Autocomplete
• Dokumentasi Address Validation API
• Pelaporan Google Maps Platform

Kontributor

Google mengelola artikel ini. Kontributor berikut awalnya yang menulisnya.

Penulis utama:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Engineer Solusi

Sarthak Ganguly | Solutions Engineer