Membuat kemampuan validasi lokasi menggunakan Google Maps Platform

Tujuan

Anda sering kali perlu memvalidasi 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 akurat atau tidak.

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

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

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

Kapan harus memilih Address Validation 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 mungkin memilih, berdasarkan hierarki keputusan di atas, untuk menggunakan satu produk daripada produk lainnya. Namun, situasi lain mungkin melibatkan penggunaan kedua produk tersebut untuk memenuhi sasaran Anda.

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

• Ada kemungkinan besar data yang dipertanyakan, atau jika mendapatkan alamat yang salah akan berdampak negatif pada downstream. Hal ini karena Address Validation API memberikan lebih banyak masukan tentang alasan input tidak menerima hasil dengan presisi tinggi.
• Anda perlu mengoreksi input pengguna (misalnya, kesalahan ejaan 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 jika:

• Tujuan utama Anda adalah mengambil lokasi alamat dan akurasi setiap alamat mungkin tidak 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 membagi input ini menjadi masing-masing komponen alamatnya (jalan, kota, negara bagian, dll.). Layanan 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 harus diperiksa dalam hal ini adalah confirmationLevel. Dengan menampilkan UNCONFIRMED_BUT_PLAUSIBLE terhadap Fake St, API telah menentukan bahwa jalan dapat memiliki nama tersebut, 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, API ini dapat mencocokkan “California” seperti yang Anda lihat pada screenshot dari alat geocoding yang dapat Anda coba di sini:

Namun, hasilnya adalah geocode dari seluruh status, dengan masukan minimal tentang komponen mana pada input yang berpotensi rusak.

Contoh Kesalahan Ejaan

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

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

Address Validation API dan Geocoding API dapat memperbaiki kesalahan ini dan mendapatkan hasil 76 Buckingham Palace Road, London, SW1W 9TQ. Namun, Address Validation API dapat memberikan informasi lebih lanjut 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 terhadap tanda ini untuk memeriksa ulang koreksi dengan penyedia data, seperti pelanggan di checkout e-commerce.

Contoh Data Tidak Ada dan Error Ejaan

Bollschestraße 86, 12587, DE

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

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

Dalam hal ini, Geocoding API tidak berhasil mengatasi error input, 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 bahwa properti tersebut bersifat komersial

premises:

"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 dikaitkan dengan alamat tersebut.

Geocoding API tidak dapat memberikan informasi ini.

Memahami respons Geocoding API

Ringkasan

Jika Anda menggunakan Geocoding API, hasil geocode akan 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 hal ini adalah Chicago dan, lebih khusus lagi, Kode Pos 60007. Oleh karena itu, Place_id berikut akan ditampilkan 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 yang dimiliki alamat ini. Daftar alamat types yang ditampilkan oleh Geocoding API dapat ditemukan di sini.

Jika tidak ada komponen input yang di-resolve, 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 pada 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 perlu memahami berbagai jenis lokasi yang dapat ditampilkan dari respons Geocoding API:

• ROOFTOP menunjukkan bahwa hasil yang ditampilkan adalah geocode presisi 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) yang diinterpolasi 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 dari yang disebutkan di atas.

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

Jenis pencocokan palsu ini adalah masalah yang sangat sulit dipecahkan dengan Geocoding API. Setidaknya, Anda dapat mempertimbangkan untuk menerapkan beberapa validasi pascapemrosesan dasar pada negara dan lokalitas permintaan / respons. Lebih baik lagi, bandingkan alamat jalan yang sebenarnya untuk mengetahui adanya 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.

Kecocokan parsial dan pencocokan palsu

Jika alamat memiliki kecocokan parsial, yang berarti Geocoding API tidak dapat mengidentifikasi alamat secara akurat, respons akan berisi:

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

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 jika Geocoding API dapat menampilkan kecocokan parsial dengan alamat yang diminta.

Sebaiknya Anda memeriksa permintaan asal untuk mengetahui adanya 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" 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 dengan cara ini tidak akan ditandai 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, sebaiknya tandai alamat input sebagai tidak valid dan coba validasi ulang dengan cara lain.

Catatan: Ini adalah contoh lain saat menggunakan 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 kita tidak akan membahas detail 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, terdapat deskripsi mendetail tentang cara membedakan alamat yang baik dan buruk.

Praktik terbaik

Menentukan geografi

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

• Geocoding API - Region Biasing

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

• Address Validation API - Region Code

  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 jika:

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

Langkah Berikutnya

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

Bacaan lebih lanjut yang disarankan:

• 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 menulisnya.

Penulis utama:

Henrik Valve | Solutions Engineer

Thomas Anglaret | Solutions Engineer

Sarthak Ganguly | Solutions Engineer