FAQ Isochrones API

Bagaimana cara menghitung isokron "perjalanan ke kantor" masuk (bepergian ke tujuan) versus isokron keluar (bepergian dari tempat asal)?

Penghitungan masuk dan keluar didukung di v1 API menggunakan parameter travelDirection (travel_direction):

  • FROM (Keluar): Menghitung area yang dapat dijangkau from titik asal dalam batas waktu yang ditentukan. Hal ini cocok untuk kasus penggunaan seperti zona pengiriman atau cakupan layanan.

  • TO (Masuk): Menghitung area tempat Anda dapat melakukan perjalanan to titik asal dalam batas waktu yang ditentukan. Hal ini cocok untuk aplikasi seperti fitur perjalanan ke kantor atau menentukan zona tangkapan di sekitar kantor pusat atau pusat transportasi umum.

Apa perbedaan antara empat mode perjalanan (DRIVE, TWO_WHEELER, BICYCLE, dan WALK)?

Setiap mode menggunakan aturan akses jaringan jalan, biaya belokan, dan model kecepatannya sendiri:

  • DRIVE: Melintasi jalan yang dapat dilalui kendaraan menggunakan kecepatan yang diposting atau kecepatan arus bebas atau kecepatan lalu lintas real-time (TRAFFIC_AWARE), hingga 3.600 detik (60 menit).
  • TWO_WHEELER: Melintasi jalan yang dapat diakses oleh kendaraan bermotor roda dua dengan kecepatan yang dimodelkan lebih rendah daripada DRIVE di jalan berkecepatan tinggi dan perutean TRAFFIC_AWARE opsional, hingga 3.600 detik (60 menit). Akibatnya, isokron TWO_WHEELER lebih besar dari BICYCLE, tetapi lebih kecil dari DRIVE di sepanjang jalan raya berkecepatan tinggi.
  • BICYCLE: Melintasi jalan yang dapat diakses sepeda, jalur sepeda, dan jalur dengan kecepatan yang disesuaikan untuk jenis dan kemiringan jalan (tidak termasuk jalan raya dan jalan bebas hambatan), hingga 7.200 detik (120 menit).
  • WALK: Melintasi trotoar, jalur, dan jalan pejalan kaki dengan kecepatan berjalan yang disesuaikan dengan kemiringan (mengabaikan pembatasan kendaraan satu arah), hingga 7.200 detik (120 menit).

Apakah Isochrones API menyertakan feri atau penyeberangan air?

Tidak. Isochrones API hanya melintasi koneksi jalan, jembatan, terowongan, dan jalur. Rute feri dan penyeberangan transportasi air dikecualikan di semua mode perjalanan. Pulau atau semenanjung yang hanya terhubung dengan feri tidak akan disertakan dalam isokron yang dihasilkan dari daratan utama.

Terkadang poligon yang ditampilkan terlihat kotak-kotak atau memiliki tepi bergerigi dan bertingkat, terutama untuk durasi yang lebih lama. Mengapa tingkat detail berubah?

Isochrones API secara dinamis menyesuaikan resolusi petak penghitungan spasialnya berdasarkan travel_duration dan travel_mode yang diminta:

  • Durasi Lebih Singkat: Gunakan petak beresolusi tinggi yang sangat disempurnakan karena total areanya kecil, sehingga menghasilkan batas yang mendetail.
  • Durasi Lebih Lama: Beralih ke petak yang lebih kasar dan beresolusi lebih rendah untuk mencakup area geografis yang luas secara efisien tanpa menyebabkan latensi yang parah.

Anda dapat menetapkan polygon_fidelity opsional ke HIGH, MEDIUM, atau LOW jika Anda memerlukan tingkat detail yang spesifik dan konsisten, terlepas dari durasinya.

Mengapa permintaan isokron untuk koordinat di dalam taman, danau, atau kompleks industri besar terkadang menampilkan error "Not Found"?

Isochrones API menghitung waktu perjalanan menggunakan jalan dan jalur. API harus "mengepaskan" titik ke segmen kompatibel terdekat sebelum memulai penghitungan jika koordinat asal yang Anda minta tidak berada di jalan yang dikenali.

Setiap mode perjalanan memiliki jarak penempatan maksimum sekitar 200 meter atau kurang. WALK dan BICYCLE menggunakan jarak yang lebih pendek daripada DRIVE dan TWO_WHEELER, dan DRIVE serta TWO_WHEELER mengabaikan jalur khusus pejalan kaki.

Jika koordinat asal Anda berada lebih jauh dari segmen jalan yang valid dan kompatibel dengan mode daripada jarak ini, snapping akan gagal, dan API akan menampilkan error NOT_FOUND. Untuk mengatasinya, pastikan koordinat Anda diposisikan di dekat jalan atau jalur publik.

Mengapa saya mendapatkan error saat meminta pemilihan rute berbasis lalu lintas untuk berjalan kaki atau bersepeda?

Kondisi lalu lintas real-time (TRAFFIC_AWARE) didukung untuk mode perjalanan DRIVE dan TWO_WHEELER. Jika Anda mencoba meminta isochrone untuk WALK atau BICYCLE dengan routingPreference yang ditetapkan ke TRAFFIC_AWARE, API akan menampilkan error 400 INVALID_ARGUMENT.

Saat saya merender respons GeoJSON di peta, bentuknya ditampilkan di tempat yang salah, terdistorsi, atau gagal dirender. Apa penyebabnya?

Hal ini hampir selalu disebabkan oleh ketidakcocokan urutan koordinat.

Sesuai dengan standar GeoJSON (RFC 7946), Isochrones API menampilkan koordinat dalam urutan [longitude, latitude]. Namun, banyak SDK pemetaan dan objek geometri kustom mengharapkan koordinat dalam urutan [latitude, longitude].

Jika rendering peta Anda salah, periksa cara SDK peta Anda menangani GeoJSON:

  • Google Maps JavaScript API: Jika Anda menggunakan Lapisan Data (map.data.addGeoJson()), urutan ini ditangani secara native dan tidak ada tindakan yang diperlukan.
  • Objek kustom atau SDK lainnya: Jika Anda mengurai respons secara manual menjadi objek LatLng, Anda harus melakukan loop melalui koordinat dalam payload GeoJSON dan mentransposisikan nilai [lng, lat] menjadi pasangan [lat, lng] sebelum merender.

Mengapa ada "lubang" kosong di dalam poligon isokron saya, dan dapatkah saya mendapatkan bentuk yang solid?

Lubang mewakili area tanpa jalan yang dapat dijangkau dalam batas waktu. Hal ini umum terjadi di wilayah dengan hutan luas, perairan, bandara, atau properti pribadi yang tidak dapat dilalui kendaraan atau pejalan kaki.

API v1 eksternal tidak mengekspos parameter untuk menghapus lubang secara otomatis. Jika aplikasi Anda memerlukan batas yang solid, misalnya, untuk melakukan pemeriksaan penampungan titik dalam poligon, Anda dapat:

  • Tetapkan parameter polygon_fidelity ke MEDIUM atau LOW untuk mendorong algoritma agar melakukan generalisasi dan penggabungan pada kesenjangan internal ini.
  • Gunakan library GIS sisi klien (seperti Turf.js) untuk mengurai GeoJSON dan hanya mengekstrak cincin koordinat pertama (shell eksterior), dengan menghapus cincin interior berikutnya (lubang).

Haruskah saya mengaktifkan opsi enable_smoothing untuk analisis spasial backend?

Tidak. Parameter enable_smoothing dirancang murni untuk estetika visual. Fungsi ini membulatkan sudut tajam petak penghitungan yang mendasarinya untuk membuat bentuk terlihat organik di peta.

Penghalusan tidak direkomendasikan untuk analisis spasial yang akurat karena mengubah verteks dan sedikit menggeser batas. Untuk penghitungan backend, kueri database, atau pengujian titik dalam poligon, biarkan enable_smoothing ditetapkan ke false untuk memastikan Anda menggunakan batas yang dihitung secara presisi secara matematis.