Senin, 11 Februari 2019

Terasi (bagian 1): Proyek Analitik Transjakarta

Seri tulisan kali ini tidak ada hubungannya langsung dengan pemrograman kompetitif. Namun, saya menggunakan sejumlah ilmunya dalam perjalanan yang akan saya ceritakan berikut.

Setelah lulus dari perguruan tinggi, saya kerja di Cermati. Kantornya di dekat mall Central Park, Jakarta Barat. Kebetulan lokasinya sangat strategis, terdapat halte Transjakarta di dekatnya. Saya pikir untuk pergi dan pulang ke kantor menjadi sesederhana naik Transjakarta saja. Namun sebenarnya tidak sesederhana itu...

Waktu itu adalah tahun 2015. Saya tidak tahu apakah sekarang situasinya sudah membaik, tetapi kondisi lalu lintas tahun itu cukup mengenaskan. Daerah Jalan S. Parman terkenal sangat macet pada jam masuk atau pulang kantor. Awalnya saya pikir ada busway (jalur Transjakarta), yang membuat Transjakarta kebal kemacetan. Sayangnya, ternyata di Jalan S. Parman terdapat penyatuan busway dengan jalan raya yang membuat bus ikut kena macet...

Akibat dari kemacetan ini adalah:
  1. Pergerakan bus menjadi lambat, sehingga...
  2. Frekuensi kedatangan bus menjadi rendah, sehingga...
  3. Orang yang mengantre di halte menjadi ramai, sehingga...
  4. Begitu bus sampai di halte, tidak semua orang kedapatan menaiki bus, sehingga...
  5. Harus menunggu kedatangan bus berikutnya, sehingga...
  6. ... tekanan darah saya meningkat karena perjalanan dari rumah ke kantor menjadi lama.
Seluruh akibat itu saya rasakan setiap hari, ditambah dengan setiap kali naik TJ (Transjakarta) untuk jalan-jalan di Jakarta. Hingga suatu ketika saya muak, dan menjadi marah. Bagaimana mungkin fasilitas umum untuk masa depan beroperasi seperti ini?

Akhirnya energi amarah yang meluap-luap itu saya alirkan ke ide untuk membuat sistem yang dapat menghitung metrik-metrik Transjakarta, seperti waktu tunggu, waktu perjalanan dari halte ke halte, rata-rata kedatangan bus, dan sebagainya. Dengan metrik tersebut, saya dapat mengukur apakah untuk suatu perjalanan saya akan menggunakan Transjakarta. Apabila ternyata data menunjukkan perjalanannya akan memakan waktu lama, lebih baik saya naik ojek.

Sebagai bonus, barangkali saya bisa menghasilkan semacam laporan yang berisi "efisiensi" TJ. Bayangannya adalah tabel berisi seluruh halte dan trayek tujuan, berikut waktu tunggu rerata kedatangan bus. Tidak hanya itu, berbagai informasi lainnya juga bisa diturunkan. Laporan ini bisa disampaikan ke pihak TJ, pemerintah daerah, atau pihak yang bertanggung jawab atas lalu lintas. Kemudian mereka bisa menggunakannya untuk mengetahui situasi dan mengambil keputusan. Seperti:
  • "oh ternyata waktu tunggu di daerah Bendungan Hilir jam 6 sore mencapai 40 menit, mungkin sebaiknya kita tambahkan bus di sana"
  • "banyaknya bus yang beroperasi di koridor 11 ternyata tinggal 60% dari yang awalnya diatur, dikarenakan bus-busnya yang mulai rusak dan tidak beroperasi lagi. Saatnya kita remajakan"
  • "waktu tempuh antar halte di jalur Slipi jam 7 pagi sangat parah, ada apa gerangan? Apakah jalur busway di sana tidak steril karena kendaraan lain? Mungkin saatnya kita pasang CCTV di sana untuk mencatat plat nomor kendaraan-kendaraan liar itu, lalu kita denda"
Yah tentunya masih banyak yang bisa dilakukan kalau kita punya datanya. Berhubung saya sudah pensiun pemrograman kompetitif, sepertinya ide ini bisa diwujudkan sebagai proyek sampingan.

Saya juga memeriksa apakah sudah ada aplikasi yang serupa. Untungnya belum ada.


Formulasi Ide

Dasar dari semua yang hendak saya lakukan ini adalah statistik. Ada 2 hal yang akan dihitung:
  1. Diberikan halte awal, jam saat itu, dan halte tujuan. Tentukan rata-rata waktu menunggu di halte awal sampai mendapat bus. Sebut saja nilai ini "waktu tunggu".
  2. Diberikan halte awal, jam saat itu, dan halte tujuan yang bertetanggaan dengan halte awal. Tentukan rata-rata waktu tempuh bus untuk berpindah dari halte awal ke halte tujuan. Sebut saja nilai ini "waktu tempuh".
Sebenarnya nilai yang ingin ditemukan bukan hanya rata-rata, melainkan juga median, persentil 90 (p90), persentil 95 (p95), standar deviasi, dan sebagainya. Bahkan, kata orang bijak median mungkin lebih tepat digunakan karena lebih kebal terhadap pencilan (outlier).


Perhitungan Waktu Tunggu

Diperlukan permodelan distribusi data yang cocok untuk merepresentasikan "waktu kontinu sampai suatu kejadian terjadi".

Parameter yang diperlukan adalah (tentu saja) halte awal. Parameter lain yang adalah jam, sebab waktu tunggu jam 06.00 pastinya berbeda dengan waktu tunggu jam 17.15. Granularitas jam nantinya dapat diatur sesuka hati, apakah kita ingin mengelompokkan data per 15 menit, 10 menit, atau durasi lainnya. Kemudian parameter terakhir adalah halte tujuan. Meskipun biasanya halte Transjakarta hanya dilalui dua arah, sebenarnya kalau dipandang dari sisi teknis, bisa saja lebih dari dua. Misalnya bus yang lewat di halte S. Parman bisa saja:
  • sedang mengarah ke Utara, mungkin hanya sampai Grogol atau terus sampai Pluit. 
  • sedang mengarah ke Tenggara, mungkin hanya sampai PGC atau akan sampai di ujung, yaitu Pinang Ranti.
Dari sana saja kita tahu bahwa bus yang lewat di halte S. Parman bisa saja berhenti di 4 kemungkinan halte, tergantung koridor bus tersebut. Tentu saja bus yang hanya sampai PGC pasti lebih banyak dari bus yang sampai Pinang Ranti. Berikut gambaran kasar rutenya:


Anggaplah kini kita memiliki data 15 hari sebelumnya untuk seluruh bus yang sampai di halte S. Parman, sekitar pukul 06.00, dan sedang menuju ke Pinang Ranti. Bayangkan data ini digambarkan dalam diagram berikut, dengan h-x menyatakan "x hari sebelumnya", dan titik menyatakan ada bus sampai di halte tersebut pada hari dan jam yang bersangkutan:



Misalnya saya hendak ke Pinang Ranti, dan saya sedang berada di halte S. Parman pada saat 06.03. Melihat data 15 hari sebelumnya, saya bisa mengira-ngira berapa lama saya perlu menunggu dari data yang dimiliki. Caranya cukup menghitung rata-rata dari panjang batangan merah berikut:



Ketika seseorang lain tiba di halte pada 06.11. Ia bisa mengira-ngira dengan cara yang sama:



Tidak hanya rata-rata. Kita juga bisa tahu p90, yang artinya "90% peluang bahwa saya menunggu paling lama x menit".

Apabila diteliti secara lebih lanjut, "waktu kontinu sampai suatu kejadian terjadi" akan memenuhi  distribusi data eksponensial.


Perhitungan Waktu Tempuh

Mirip dengan cara sebelumnya, kita dapat mengumpulkan banyaknya titik data yang merepresentasikan waktu tempuh bus dari suatu halte ke halte tetangganya pada jam sekian.

Misalnya dalam 15 hari, waktu tempuh dari halte S. Parman ke Grogol untuk jam 05.45 sampai 06.15 adalah sebagai berikut:


Waktu tempuh rata-ratanya sesederhana rata-rata nilai-nilai tersebut. Boleh juga dihitung median, p90, atau p95 dari sana.


Nilai-Nilai Turunan

Dari kedua jenis informasi di atas, kita dapat menurunkan sejumlah informasi lainnya:
  • Waktu perkiraan untuk perjalanan yang bermula di halte A, pada pukul T, menuju ke halte tujuan B. Kita dapat menggunakan kombinasi rata-rata waktu tunggu dan waktu tempuh.
  • Rata-rata dari rata-rata waktu tunggu seluruh halte di suatu koridor, pada suatu periode waktu. Ketika nilainya besar, artinya koridor itu menderita waktu tunggu yang lama pada periode tersebut. Pengelola TJ mungkin perlu memperhatikan pengembangan pada koridor seperti ini.
  • Rata-rata, dari rata-rata, dari rata-rata waktu tunggu seluruh halte di suatu koridor selama sehari. Nilai ini bisa dimengerti sebagai "indeks kepuasan koridor". Koridor dengan waktu tunggu cepat sepanjang hari akan memiliki nilai yang rendah.
  • Ruas jalan yang luar biasa macet, dengan mengurutkan seluruh waktu tempuh antar halte bertetanggaan setiap segmen waktu. Ruas jalan seperti ini memberikan efek leher botol (bottleneck) yang sama saja membuat seluruh TJ di koridor tersebut berjalan lambat. Tindak lanjut mengurangi leher botol itu dipastikan meningkatkan kepuasan penggunaan TJ.
Seluruh data tersebut juga dapat dibandingkan dari waktu ke waktu. Misalnya pada tahun 2016, rata-rata waktu tunggu meningkat 14% dari tahun sebelumnya. Ada apa gerangan? Apakah banyak bus yang sudah rusak tetapi tidak diganti? Semua informasi ini bisa membantu Jakarta untuk "men-debug" masalah transportasi dengan TJ.

Sepertinya saya berpikir terlalu jauh. Namun rasanya semua itu masuk akal, dan saya segera mencatatnya. Cukup mengejutkan juga bahwa lamanya waktu pulang dari kantor ke rumah naik TJ cukup bagi saya untuk memikirkan semua itu.


Menamakan Proyek

Saya biasa menamakan proyek berdasarkan makanan terakhir yang saya makan. Berhubung waktu itu saya makan sambel terasi dari catering kantor, saya sebut saja proyek ini "Terasi". Kebetulan Terasi memiliki edit distance yang rada kecil dengan "transit".


Langkah Selanjutnya

Berikutnya saya perlu mencari tahu apakah Jakarta memiliki data seperti ini. Saya pernah ikut Hackathon Jakarta 2015, dan mereka memiliki API Tranjakarta. Ditambah lagi baru-baru itu sedang heboh "Jakarta Smart City", yang menggembor-gemborkan data Jakarta dibuka secara umum dalam bentuk API. Mungkin saya bisa periksa kembali API tersebut dan memanen data dari sana.

Sekian dulu untuk cerita pada kesempatan ini. Cerita selanjutnya akan membahas tentang eksekusi pemanenan data.

Tidak ada komentar :

Posting Komentar