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 suatu alamat akurat atau tidak.

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

Ringkasan tingkat tinggi perbedaan antara Address Validation API dan Geocoding API dapat ditemukan di sini.

Kapan harus memilih Address Validation API 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 API JavaScript, sehingga cocok untuk diintegrasikan dengan Antarmuka Pengguna.
• Anda mungkin mengetahui masalah kualitas data di alamat yang ada. Jadi, meskipun Anda mungkin hanya menginginkan geocode, sebaiknya jalankan lokasi tersebut melalui Address Validation API untuk memperbaiki set data.

Ada banyak situasi saat Anda dapat memilih, berdasarkan pohon keputusan di atas, untuk menggunakan satu produk daripada produk lainnya. Namun, 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 meragukan, atau jika mendapatkan alamat yang salah akan berdampak negatif pada proses selanjutnya. Hal ini karena Address Validation API memberikan lebih banyak masukan tentang alasan input tidak menerima hasil presisi tinggi.
• Anda perlu mengoreksi input pengguna (misalnya, salah eja atau kolom yang tidak ada), yang meningkatkan kemungkinan 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 perumahan vs. komersial.

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

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

Berikut adalah 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 memecah input ini menjadi masing-masing komponen alamatnya (jalan, kota, negara bagian, dll.). API ini juga dapat memberikan masukan terperinci tentang alasan alamat tidak valid hingga tingkat PREMISE.

Fake St tidak ada di Mountain View, CA, dan Address Validation API mencerminkan hal tersebut pada detail tingkat komponen yang ditampilkan:

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

Properti penting yang perlu diperiksa dalam kasus ini adalah confirmationLevel. Dengan menampilkan UNCONFIRMED_BUT_PLAUSIBLE terhadap Fake St, API telah menentukan bahwa jalan tersebut dapat memiliki nama itu, tetapi tidak dapat dicocokkan dengan data alamat pendukung.

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

Dengan menggunakan alamat yang sama dengan Geocoding API, alamat tersebut dapat mencocokkan “California” seperti yang Anda lihat di screenshot dari alat geocoding yang dapat Anda coba di sini:

Namun, hasilnya adalah geocode seluruh negara bagian, dengan sedikit masukan mengenai komponen mana pada input yang berpotensi salah.

Contoh Kesalahan Ejaan

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

Alamat di atas berisi beberapa kesalahan ejaan, satu di nama jalan, dan yang lainnya di lokalitas.

Address Validation API dan Geocoding API dapat memperbaiki kesalahan ini dan mencapai hasil 76 Buckingham Palace Road, London, SW1W 9TQ. Namun, Address Validation API dapat memberikan informasi lebih lanjut tentang proses ini.

Lihat salah satu komponen alamat yang salah eja saat dimasukkan:

{
  "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 terhadap tanda ini untuk memeriksa ulang koreksi dengan penyedia data, seperti pelanggan saat checkout e-commerce.

Contoh Data Tidak Ada dan Kesalahan Ejaan

Bollschestraße 86, 12587, DE

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

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

Bölschestraße 86, 12587 Berlin, DE

Geocoding API tidak dapat 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, US

Alamat ini sudah benar, kecuali 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 bahwa properti tersebut adalah properti komersial

tempat:

"business": true

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

"dpvConfirmation": "S"

Nilai dpvConfirmation S menunjukkan bahwa alamat divalidasi ke tingkat 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 menyelesaikan komponen alamat dalam hierarki.

Misalnya, 123 Example Street, Chicago, 60007, USA diselesaikan dalam urutan berikut:

/ Example Street/ Chicago/ 60007/ USA akan dievaluasi dalam urutan tersebut. Kecocokan pertama dalam kasus ini adalah Chicago dan, khususnya, Kode Pos 60007. Oleh karena itu, API 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 dapat mengonfirmasi jenis tempat alamat ini. Daftar types alamat 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 jalan 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 akan secara bertahap meningkatkan tingkat keyakinan bahwa alamat mungkin ada, tetapi tidak akan membuatnya 100% akurat. Itulah sebabnya kita memerlukan Address Validation API.

Anda dapat menggunakan teknik di atas untuk meningkatkan keyakinan akan akurasi alamat dari respons Geocoding API saja. 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 harus memahami berbagai jenis lokasi yang dapat ditampilkan dari respons Geocoding API:

• ROOFTOP menunjukkan bahwa hasil yang ditampilkan adalah geocode yang akurat dan kami memiliki informasi lokasi yang akurat hingga presisi 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 tidak termasuk dalam kategori di atas.

Jika Geocoding API menampilkan location_type ROOFTOP atau RANGE_INTERPOLATED, bukan berarti alamat tersebut ada. Demikian pula, jika Geocoding API ditampilkan dengan tanda partial_match yang disetel ke true, hasil tersebut mungkin masih tepat untuk Anda.

Jenis pencocokan palsu ini sangat sulit diselesaikan dengan Geocoding API. Setidaknya, Anda dapat mempertimbangkan untuk menerapkan beberapa validasi pasca-pemrosesan dasar pada negara dan lokalitas permintaan / respons. Lebih baik lagi, periksa untuk membandingkan alamat jalan yang sebenarnya untuk mengetahui apakah ada salah eja dan/atau alamat yang tidak lengkap.

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

Pencocokan parsial dan pencocokan palsu

Jika alamat adalah kecocokan parsial, yang berarti Geocoding API tidak dapat mengidentifikasi alamat secara persis, maka respons berisi:

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

Yang lebih penting daripada jenis lokasi di atas adalah mempertimbangkan kapan partial_match = true ada dalam respons. partial_match menunjukkan bahwa Geocoding API tidak menampilkan kecocokan persis untuk permintaan asli, meskipun jika geocoder dapat menampilkan kecocokan parsial dengan alamat yang diminta.

Sebaiknya Anda memeriksa permintaan asal untuk mengetahui keberadaan alamat yang tidak lengkap. Kecocokan parsial paling sering terjadi untuk alamat jalan yang tidak ditemukan di 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 bahwa jika permintaan menyertakan komponen alamat yang salah eja, Geocoding API mungkin akan menyarankan alamat alternatif. Saran yang terpicu melalui cara ini tidak akan dinilai sebagai kecocokan parsial.

Alamat Sintetis

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

Dalam skenario tersebut, 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 di mana dengan Address Validation API, 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, jadi kami tidak akan membahasnya lebih lanjut di sini.

• Ringkasan objek respons dapat ditemukan di sini.
• Demo yang mengilustrasikan berbagai komponen respons ada di sini
• Dalam Dokumen Validasi Alamat untuk checkout, ada deskripsi mendetail tentang cara membedakan alamat yang valid dan tidak valid.

Praktik terbaik

Menentukan geografi

Saat melakukan panggilan ke Address Validation API atau Geocoding API, sebaiknya coba batasi geografi tempat alamat tersebut ditelusuri. Kedua API menerapkan hal ini dengan dua cara yang berbeda:

• Geocoding API - Region Biasing

  Jika Anda tahu bahwa geocode akan berada di negara tertentu, Anda akan mendapatkan hasil yang jauh lebih baik dengan menggunakan Pembiasaan Wilayah. Misalnya, jika Anda melakukan geocoding di Kanada, sebaiknya tambahkan &region=ca ke permintaan Anda untuk memfokuskan pada Kanada. Perhatikan bahwa Pembiasaan Wilayah hanya mengutamakan hasil dalam wilayah tersebut. Anda masih bisa mendapatkan hasil di luar wilayah tersebut.

• Address Validation API - Kode Wilayah

  Dengan cara yang sama, Address Validation API menghasilkan 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 placeID. 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 inti antara Address Validation API dan Geocoding API. Singkatnya, pertimbangkan untuk menggunakan Address Validation API saat:

• Alamat surat yang akurat wajib diisi, terutama untuk tujuan pengiriman.
• Data input diketahui berkualitas buruk. Address Validation API lebih toleran terhadap kesalahan input, akan menandai komponen alamat yang tidak dapat diverifikasi, dan melakukan koreksi pada data input.
• Informasi lebih lanjut diperlukan untuk alamat, seperti Perumahan vs. Komersial (tersedia di wilayah tertentu).

Langkah Berikutnya

Download Kertas Putih Meningkatkan kualitas checkout, pengiriman, dan operasi dengan alamat yang andal dan tonton Webinar Meningkatkan kualitas checkout, pengiriman, dan operasi dengan Validasi Alamat .

Bacaan lebih lanjut yang disarankan:

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

Kontributor

Google mengelola artikel ini. Kontributor berikut awalnya menulisnya.

Penulis utama:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer