Info Terbaru Perjalanan

Info terbaru perjalanan menunjukkan fluktuasi dalam jadwal. Kami menantikan info terbaru perjalanan untuk semua perjalanan yang telah Anda jadwalkan, yang dapat diproses secara realtime. Info terbaru ini akan memberikan perkiraan waktu kedatangan atau keberangkatan untuk perhentian di sepanjang rute. Info terbaru 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 satu info terbaru perjalanan untuk setiap perjalanan terjadwal. Jika tidak ada info terbaru perjalanan untuk perjalanan terjadwal, berarti tidak ada data realtime yang tersedia untuk perjalanan tersebut. Konsumen data tidak boleh berasumsi bahwa perjalanan akan berjalan tepat waktu.

Info Terbaru Waktu Perhentian

Info terbaru perjalanan terdiri dari satu atau beberapa info terbaru waktu perhentian kendaraan, yang dirujuk sebagai pesan StopTimeUpdate. Ini dapat diberikan untuk waktu perhentian terdahulu dan di 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 info terbaru untuk perhentian ini.

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

  • 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 info terbaru 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 pesan StopTimeUpdate untuk stop_id tersebut dalam perjalanan tersebut.

Info terbaru dapat memberikan waktu yang tepat untuk arrival dan/atau departure di sebuah perhentian dalam StopTimeUpdate menggunakan StopTimeEvent. Info ini harus berisi time atau delay absolut (yaitu offset dari waktu terjadwal dalam detik). Kolom delay hanya dapat digunakan jika info terbaru perjalanan merujuk ke perjalanan GTFS terjadwal, bukan perjalanan berbasis frekuensi. Dalam hal ini, waktu harus sama dengan waktu terjadwal + keterlambatan. Anda juga dapat menetapkan uncertainty prediksi bersama dengan StopTimeEvent, yang dibahas secara lebih mendetail di bagian Ketidakpastian di bagian bawah halaman ini.

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

Info terbaru harus diurutkan berdasarkan stop_sequence (atau stop_ids sesuai urutannya dalam perjalanan).

Jika satu atau beberapa perhentian tidak ada di sepanjang perjalanan, info terbaru disebarluaskan ke semua perhentian selanjutnya. Ini berarti memperbarui 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 (StopTimeEvent) untuk stop_sequence perhentian saat ini menunjukkan bahwa perjalanan tersebut benar-benar tepat waktu.

Contoh 2

Untuk perjalanan yang sama, tiga pesan StopTimeUpdate 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:

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

Deskripsi Perjalanan

Informasi yang diberikan oleh deskripsi perjalanan bergantung pada hubungan jadwal perjalanan yang Anda perbarui. 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, tetapi sekarang sudah dihapus.

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

Sistem dengan nilai trip_id berulang

Untuk sistem yang menggunakan nilai trip_id berulang, misalnya perjalanan yang dimodelkan 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 pembaruan feed berikutnya harus menggunakan start_time yang sama saat merujuk ke perjalanan yang sama. StopTimeUpdate 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, 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 (tetapi 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 uncertainty 240.