Update Perjalanan

Update perjalanan menunjukkan fluktuasi dalam jadwal. Kami menantikan update perjalanan untuk semua perjalanan yang telah Anda jadwalkan yang dapat diproses secara realtime. Update ini akan memberikan perkiraan waktu kedatangan atau keberangkatan untuk perhentian di sepanjang rute. Update perjalanan juga dapat memberikan skenario yang lebih kompleks, saat perjalanan dibatalkan, ditambahkan ke jadwal, atau bahkan diubah rutenya.

Pengingat: Di GTFS, perjalanan adalah urutan dari dua perhentian atau lebih yang terjadi pada waktu tertentu.

Maksimum harus ada 1 update perjalanan untuk setiap perjalanan terjadwal. Jika tidak ada update perjalanan untuk perjalanan terjadwal, berarti tidak ada data realtime yang tersedia untuk perjalanan tersebut. Konsumen data seharusnya tidak berasumsi bahwa perjalanan akan berjalan tepat waktu.

Update Waktu Perhentian

Update perjalanan terdiri dari satu atau beberapa update waktu perhentian kendaraan, yang disebut sebagai StopTimeUpdates. Ini dapat diberikan untuk waktu perhentian masa lalu dan masa mendatang. Anda diizinkan, tetapi tidak diwajibkan, untuk menghapus waktu perhentian terdahulu. Produsen tidak boleh menghapus StopTimeUpdate terdahulu jika mengacu ke perhentian dengan waktu kedatangan terjadwal di masa mendatang untuk perjalanan tertentu (yaitu, kendaraan telah melewati perhentian lebih awal dari jadwal), karena jika dihapus berarti tidak ada update untuk perhentian ini.

Misalnya, jika data berikut muncul di feed GTFS-realtime:

  • Perhentian 4 - Diprediksi pukul 10:18 (dijadwalkan pukul 10:20 – 2 menit lebih awal)
  • Perhentian 5 - Diprediksi pukul 10:30 (dijadwalkan pukul 10:30 – tepat waktu)

...prediksi untuk Perhentian 4 tidak boleh dihapus dari feed sampai pukul 10:21, meskipun bus tersebut sudah melewati perhentian pada pukul 10:18. Jika StopTimeUpdate untuk Perhentian 4 dihapus dari feed pada pukul 10:18 atau 10:19, dan waktu kedatangan terjadwal adalah pukul 10:20, konsumen akan beranggapan bahwa tidak ada informasi real-time untuk Perhentian 4 pada saat itu, dan data jadwal dari GTFS akan digunakan.

Setiap StopTimeUpdate dikaitkan dengan sebuah perhentian. Biasanya ini dapat dilakukan dengan menggunakan stop_sequence GTFS atau stop_id GTFS. Namun, jika Anda memberikan update untuk sebuah perjalanan tanpa trip_id GTFS, Anda harus menetapkan stop_id karena stop_sequence tidak memiliki nilai. stop_id masih harus merujuk ke stop_id di GTFS. Jika stop_id yang sama dikunjungi beberapa kali dalam sebuah perjalanan, stop_sequence harus diberikan di semua StopTimeUpdates untuk stop_id tersebut dalam perjalanan tersebut.

Update dapat memberikan waktu yang tepat untuk kedatangan dan/atau keberangkatan di sebuah perhentian dalam StopTimeUpdates menggunakan StopTimeEvent. Hal ini harus berisi waktu atau keterlambatan absolut (yaitu offset dari waktu terjadwal dalam detik). Keterlambatan hanya dapat digunakan jika update perjalanan merujuk ke perjalanan GTFS terjadwal, bukannya perjalanan berbasis frekuensi. Dalam hal ini, waktu harus sama dengan waktu terjadwal + keterlambatan. Anda juga dapat menetapkan ketidakpastian prediksi bersama dengan StopTimeEvent, yang dibahas secara lebih mendetail di bagian Ketidakpastian di bagian bawah halaman ini.

Untuk setiap StopTimeUpdate, hubungan jadwal default adalah terjadwal. (Perhatikan bahwa ini berbeda dengan hubungan jadwal untuk perjalanan). Anda dapat mengubahnya menjadi dilewati jika perhentian tidak akan disinggahi, atau tidak ada data jika Anda hanya memiliki data realtime untuk sebagian perjalanan.

Update harus diurutkan berdasarkan stop_sequence (atau stop_id sesuai urutannya dalam perjalanan).

Jika 1 atau beberapa perhentian tidak ada di sepanjang perjalanan, update disebarluaskan ke semua perhentian selanjutnya. Ini berarti mengupdate waktu perhentian untuk perhentian tertentu akan mengubah semua perhentian selanjutnya tanpa ada informasi lainnya.

Contoh 1

Untuk perjalanan dengan 20 perhentian, StopTimeUpdate dengan keterlambatan kedatangan dan keterlambatan keberangkatan 0 (StopTimeEvents) untuk stop_sequence perhentian saat ini menunjukkan bahwa perjalanan tersebut benar-benar tepat waktu.

Contoh 2

Untuk perjalanan yang sama, tiga StopTimeUpdates diberikan:

  • keterlambatan 300 detik untuk stop_sequence 3
  • keterlambatan 60 detik untuk stop_sequence 8
  • keterlambatan dengan durasi yang belum ditetapkan untuk stop_sequence 10

Ini akan ditafsirkan sebagai:

  • stop_sequences 1,2 mengalami keterlambatan yang tidak diketahui.
  • stop_sequences 3,4,5,6,7 mengalami keterlambatan 300 detik.
  • stop_sequences 8,9 mengalami keterlambatan 60 detik.
  • stop_sequences 10,..,20 memiliki keterlambatan yang tidak diketahui.

Deskripsi Perjalanan

Informasi yang diberikan oleh deskripsi perjalanan bergantung pada hubungan jadwal perjalanan yang Anda update. Ada sejumlah pilihan untuk Anda tetapkan:

Nilai Komentar
Scheduled Perjalanan ini berjalan sesuai jadwal GTFS, atau cukup mendekati untuk tetap dikaitkan.
Added Perjalanan ini tidak dijadwalkan dan telah ditambahkan. Misalnya, untuk menangani permintaan, atau mengganti kendaraan yang rusak.
Unscheduled Perjalanan ini berjalan dan tidak pernah dikaitkan dengan jadwal. Misalnya, jika tidak ada jadwal dan bus beroperasi dalam layanan antar-jemput.
Canceled Perjalanan ini telah dijadwalkan, namun sekarang sudah dihapus.

Dalam kebanyakan kasus, Anda harus menyediakan trip_id dari perjalanan terjadwal di GTFS yang terkait dengan update ini.

Sistem dengan trip_id berulang

Untuk sistem yang menggunakan trip_id berulang, misalnya perjalanan yang dibuat modelnya menggunakan frequencies.txt, yaitu perjalanan berbasis frekuensi, trip_id itu sendiri bukanlah ID unik dari satu perjalanan, karena tidak memiliki komponen waktu tertentu. Untuk mengidentifikasi secara unik perjalanan semacam itu dalam TripDescriptor, tiga ID harus diberikan:

  • trip_id
  • start_time
  • start_date

start_time harus dipublikasikan terlebih dulu, dan setiap update feed berikutnya harus menggunakan start_time yang sama saat merujuk ke perjalanan yang sama. StopTimeUpdates harus digunakan untuk menunjukkan penyesuaian; start_time tidak harus berupa waktu keberangkatan yang tepat dari stasiun pertama, meskipun harus mendekati waktu tersebut.

Misalnya diputuskan pukul 10:00, 25 Mei 2015, bahwa perjalanan dengan trip_id=T akan dimulai pada start_time=10:10:00, dan informasi ini diberikan melalui feed realtime pada pukul 10:01. Pada pukul 10:05, secara tiba-tiba diketahui bahwa perjalanan tidak akan dimulai pukul 10:10, tetapi pada pukul 10:13. Dalam feed realtime yang baru, kami masih dapat mengidentifikasi perjalanan ini sebagai (T, 2015-05-25, 10:10:00), tetapi memberikan StopTimeUpdate dengan keberangkatan dari perhentian pertama pada pukul 10:13:00.

Pencocokan perjalanan alternatif

Perjalanan yang tidak berbasis frekuensi juga dapat diidentifikasi secara unik oleh TripDescriptor yang mencakup kombinasi dari:

  • route_id
  • direction_id
  • start_time
  • start_date

dengan start_time adalah waktu mulai terjadwal seperti yang ditentukan dalam jadwal statis, selama kombinasi id yang diberikan ditetapkan ke perjalanan unik.

Ketidakpastian

Ketidakpastian berlaku untuk waktu dan nilai keterlambatan StopTimeUpdate. Ketidakpastian kurang lebih menentukan error yang diantisipasi dalam keterlambatan sebenarnya sebagai bilangan bulat dalam hitungan detik (namun perhatikan, makna statistik yang tepat belum didefinisikan). Ketidakpastian dapat berada di angka 0, misalnya untuk kereta yang dikemudikan dengan kontrol waktu komputer.

Misalnya, bus jarak jauh yang memiliki estimasi keterlambatan 15 menit dan tiba di perhentian berikutnya dalam jangka waktu error 4 menit (yaitu +2 / -2 menit) akan memiliki nilai Ketidakpastian 240.