GTFS Utama
Ini adalah rekomendasi praktik untuk mendeskripsikan layanan transportasi umum di General Transit Feed Specification (GTFS). Praktik ini telah disintesis dari pengalaman anggota grup kerja Praktik Terbaik GTFS dan rekomendasi praktik GTFS khusus aplikasi. Untuk memahami latar belakangnya, lihat Pertanyaan Umum (FAQ).
Struktur Dokumen
Praktik dibagi menjadi tiga bagian utama:
- Praktik Umum & Penayangan Set Data: Praktik ini berkaitan dengan keseluruhan struktur set data GTFS dan cara set data GTFS dipublikasikan.
- Rekomendasi Praktik yang Diatur Menurut File: Rekomendasi diatur berdasarkan file dan kolom di GTFS untuk memfasilitasi praktik pemetaan kembali ke referensi GTFS resmi.
- Rekomendasi Praktik yang Diatur Menurut Kasus: Dalam kasus tertentu, seperti rute memutar, praktik terbaik mungkin perlu diterapkan di beberapa file dan kolom. Rekomendasi untuk hal tersebut digabungkan dalam bagian ini.
Pertanyaan Umum (FAQ)
Mengapa Praktik Terbaik GTFS ini penting?
Tujuan Praktik Terbaik GTFS:
- Untuk meningkatkan kualitas pengalaman pengguna akhir saat menggunakan aplikasi transportasi umum
- Mendukung interoperabilitas data yang luas sehingga developer software dapat lebih mudah men-deploy dan menskalakan aplikasi, produk, dan layanan
- Memfasilitasi penggunaan GTFS dalam berbagai kategori aplikasi (di luar fokus aslinya yang berkaitan dengan perencanaan perjalanan)
Tanpa Praktik Terbaik GTFS yang terkoordinasi, berbagai aplikasi yang menggunakan GTFS mungkin menetapkan persyaratan dan ekspektasi dengan cara yang tidak teratur, sehingga menyebabkan persyaratan dan set data khusus aplikasi yang berbeda, serta kemampuan interoperabilitas yang rendah. Sebelum Praktik Terbaik ini dirilis, terdapat banyak ketidakjelasan dan pertentangan mengenai praktik yang benar dalam membentuk data GTFS.
Bagaimana Praktik Terbaik GTFS ini dibuat? Siapa yang membuatnya?
Praktik Terbaik ini dibuat oleh grup kerja yang terdiri dari 17 organisasi yang terlibat dalam GTFS, termasuk penyedia aplikasi dan konsumen data, penyedia transportasi umum, dan konsultan yang sangat terlibat dalam GTFS. Grup kerja ini dibentuk dan difasilitasi oleh Rocky Mountain Institute.
Anggota Grup Kerja memberikan suaranya untuk setiap Praktik Terbaik. Sebagian besar Praktik Terbaik disetujui oleh seluruh anggota. Untuk kasus yang jarang terjadi, Praktik Terbaik disetujui oleh sebagian besar anggota organisasi.
Mengapa tidak mengubah referensi GTFS saja?
Pertanyaan yang bagus. Proses pemeriksaan Spesifikasi, penggunaan data, dan kebutuhan memang menyebabkan beberapa perubahan pada Spesifikasi (lihat permintaan pull yang sudah dijawab di GitHub ). Amendemen referensi Spesifikasi tunduk pada standar pengawasan dan komentar yang lebih tinggi dibandingkan dengan standar untuk Praktik Terbaik. Namun, ada sekumpulan rekomendasi Praktik Terbaik yang masih perlu disepakati.
Grup kerja memprediksi bahwa beberapa Praktik Terbaik GTFS akhirnya akan menjadi bagian dari referensi GTFS utama.
Apakah alat validator GTFS memeriksa kesesuaian feed dengan Praktik Terbaik ini?
Untuk saat ini, tidak ada alat validator yang memeriksa kesesuaian feed dengan semua Praktik Terbaik. Namun, ada alat validator yang memeriksa kesesuaian feed dengan beberapa praktik terbaik ini. Untuk melihat daftar alat validator GTFS, buka Feed Pengujian. Jika Anda menulis alat validator GTFS yang merujuk pada Praktik Terbaik ini, kirim email ke gtfs@rmi.org.
Saya mewakili perusahaan transportasi umum. Apa langkah yang dapat saya lakukan agar penyedia layanan dan vendor software kami mengikuti Praktik Terbaik ini?
Tunjukkan Praktik Terbaik ini kepada vendor atau penyedia layanan software Anda. Sebaiknya Anda mengirimkan URL Praktik Terbaik GTFS, serta Referensi Spesifikasi inti sebagai persyaratan untuk software pembuat GTFS.
Apa yang harus saya lakukan jika melihat feed data GTFS yang tidak sesuai dengan Praktik Terbaik ini?
Identifikasi kontak untuk feed tersebut, menggunakan kolom
feed_contact_email atau feed_contact_url yang diusulkan di
feed_info.txt jika ada, atau lihat informasi kontak di situs perusahaan transportasi umum
atau pembuat feed. Saat menyampaikan masalah ke pembuat feed, berikan link ke
Praktik Terbaik GTFS yang dipermasalahkan. Lihat
Penautan ke Dokumen ini.
Saya ingin mengusulkan modifikasi/penambahan untuk Praktik Terbaik. Bagaimana cara melakukannya?
Kirim email ke gtfs@rmi.org atau buat laporan masalah maupun permintaan pull di repo Praktik Terbaik GTFS di GitHub.
Bagaimana cara berpartisipasi?
Kirim email ke gtfs@rmi.org.
Praktik Umum & Penayangan Set Data
| Rekomendasi Umum |
|---|
| Set data harus dipublikasikan di URL permanen publik, termasuk nama file zip. (mis., www.agency.org/gtfs/gtfs.zip). Idealnya, URL harus dapat didownload secara langsung tanpa perlu login untuk mengakses file, guna memfasilitasi download oleh aplikasi software yang menggunakan GTFS. Meskipun membuat set data GTFS yang dapat didownload secara umum ini direkomendasikan (dan merupakan praktik yang paling umum), jika penyedia data perlu mengontrol akses ke GTFS untuk pemberian lisensi atau alasan lainnya, sebaiknya kontrol akses ke set data GTFS menggunakan kunci API, yang akan memfasilitasi download otomatis. |
| Data GTFS dipublikasikan dalam iterasi sehingga satu file di lokasi yang stabil selalu berisi deskripsi layanan resmi terbaru untuk perusahaan transportasi umum. |
Gunakan ID (kolom ID) untuk stop_id,
route_id, dan agency_id yang sama di seluruh iterasi data jika memungkinkan.
|
Satu set data GTFS harus berisi layanan saat ini dan mendatang (terkadang disebut set data
“gabungan”). Fungsi penggabungan
alat transitfeed Google dapat digunakan untuk
membuat set data gabungan dari dua feed GTFS yang berbeda.
|
| Hapus layanan lama (kalender yang sudah tidak berlaku) dari feed. |
| Jika perubahan layanan akan diterapkan paling lambat 7 hari ke depan, tampilkan perubahan layanan ini melalui feed GTFS-realtime (petunjuk layanan atau pembaruan perjalanan), bukan set data GTFS statis. |
| Data GTFS yang dihosting server web harus dikonfigurasi agar dapat melaporkan tanggal modifikasi file dengan benar (lihat HTTP/1.1 - Request for Comments 2616, di Bagian 14.29). |
Rekomendasi Praktik yang Diatur Menurut File
Bagian ini menunjukkan praktik yang diatur menurut file dan kolom, yang sesuai dengan referensi GTFS.
Semua File
| Nama Kolom | Rekomendasi |
|---|---|
| Huruf Besar/Kecil | Semua string teks yang ditampilkan kepada pelanggan (termasuk nama perhentian, nama rute, dan jurusan) harus menggunakan Huruf Besar/Kecil (bukan HURUF BESAR SEMUA), mengikuti ketentuan lokal terkait penggunaan kapitalisasi untuk nama tempat pada layar yang bisa menampilkan karakter huruf kecil. |
| Contoh: | |
| Brighton Churchill Square | |
| Villiers-sur-Marne | |
| Market Street | |
| Singkatan | Hindari penggunaan singkatan di seluruh feed untuk nama dan teks lainnya (mis., St. untuk Street) kecuali lokasi tersebut disebut dengan nama singkatannya (mis., “JFK Airport”). Singkatan mungkin menimbulkan masalah aksesibilitas pada software pembaca layar dan antarmuka pengguna suara. Software yang menggunakan GTFS dapat dirancang untuk secara andal mengubah kata asli menjadi singkatan pada tampilan, tetapi mengubah singkatan menjadi kata asli cenderung memiliki risiko error yang lebih besar. |
agency.txt
| Nama Kolom | Rekomendasi |
|---|---|
agency_id |
Harus disertakan, meskipun hanya ada satu perusahaan transportasi umum di feed. (Lihat juga rekomendasi
untuk menyertakan agency_id dalam
routes.txt dan
fare_attributes.txt) |
agency_lang |
Harus disertakan. |
agency_phone |
Harus disertakan kecuali tidak ada nomor telepon layanan pelanggan. |
agency_email |
Harus disertakan kecuali tidak ada email layanan pelanggan. |
agency_fare_url |
Harus disertakan kecuali transportasi umum perusahaan tersebut sepenuhnya gratis. |
Contoh:
- Layanan bus dijalankan oleh beberapa perusahaan kecil. Namun, ada satu perusahaan besar yang bertanggung jawab atas penjadwalan dan penjualan tiket, serta dari sudut pandang pengguna, bertanggung jawab atas layanan bus. Perusahaan besar tersebut harus ditetapkan sebagai perusahaan dalam feed. Meskipun secara internal data dikelompokkan menurut masing-masing operator kecil bus, hanya satu perusahaan yang boleh ditetapkan dalam feed.
- Penyedia feed menjalankan portal penjualan tiket, tetapi ada berbagai perusahaan yang sebenarnya mengoperasikan layanan tersebut dan dianggap sebagai pihak yang bertanggung jawab oleh pengguna. Perusahaan yang sebenarnya mengoperasikan layanan bus harus ditetapkan sebagai perusahaan dalam feed.
stops.txt
| Nama Kolom | Rekomendasi | ||||||||
|---|---|---|---|---|---|---|---|---|---|
stop_id |
Perhentian yang berada di lokasi fisik berbeda (yaitu, lokasi akurat berbeda yang
ditetapkan untuk kendaraan di rute yang ditentukan untuk berhenti, umumnya dibedakan berdasarkan rambu,
halte, atau informasi publik lain, berlokasi di ujung jalan yang berbeda atau
yang merepresentasikan fasilitas naik turun penumpang seperti peron atau perhentian bus, meskipun jaraknya
dekat) harus memiliki stop_id yang berbeda. |
||||||||
stop_id adalah ID internal, yang tidak ditujukan untuk ditampilkan kepada penumpang. |
|||||||||
Jaga agar stop_id untuk perhentian yang sama di seluruh iterasi data tetap konsisten (lihat Praktik Umum & Penayangan Set Data). |
|||||||||
stop_name |
stop_name harus sesuai dengan nama publik perusahaan untuk perhentian,
stasiun, atau fasilitas naik turun, misalnya, yang tertera di jadwal, dipublikasikan di internet, dan/atau
ditampilkan di lokasi. |
||||||||
| Jika tidak ada nama perhentian yang dipublikasikan, ikuti ketentuan pemberian nama perhentian yang konsisten di seluruh feed. | |||||||||
| Hindari penggunaan singkatan selain untuk tempat yang lebih sering disebut dengan nama singkatannya. Lihat Singkatan (#2) di bagian Semua File. | |||||||||
| Masukkan nama perhentian dalam huruf besar kecil, mengikuti ketentuan lokal, berdasarkan rekomendasi untuk semua kolom teks yang ditampilkan kepada pelanggan. | |||||||||
Secara default, stop_name tidak boleh berisi kata-kata umum atau berlebihan seperti
“Stasiun” atau “Terminal”, tetapi untuk beberapa kasus ekstrem, hal ini diperbolehkan.
|
|||||||||
stop_lat & stop_lon |
Lokasi perhentian harus seakurat mungkin. Ketidakakuratan lokasi yang diperbolehkan adalah maksimal empat meter dari posisi perhentian yang sebenarnya. | ||||||||
| Lokasi perhentian harus ditempatkan sangat dekat dengan lokasi pejalan kaki tempat penumpang akan menaiki bus (yaitu, sisi jalan yang benar). | |||||||||
Jika feed data yang berbeda memiliki lokasi perhentian yang sama (yaitu, dua perusahaan menggunakan
perhentian/fasilitas naik turun yang sama persis), tunjukkan bahwa perhentiannya sama dengan menggunakan
stop_lat dan stop_lon yang sama persis untuk kedua perhentian tersebut. |
|||||||||
stop_code |
stop_code harus disertakan di GTFS jika terdapat nomor perhentian atau ID pendek yang ditampilkan
kepada penumpang. |
||||||||
parent_station & location_type |
Ada banyak stasiun atau terminal yang memiliki beberapa fasilitas naik turun penumpang (bergantung pada modanya,
yang mungkin disebut perhentian bus, peron, dermaga, gerbang, atau istilah lainnya). Untuk kasus tersebut, pembuat
feed harus mendeskripsikan stasiun, fasilitas naik turun penumpang (juga disebut sebagai perhentian turunan), dan
keterkaitannya.
|
||||||||
Saat memberi nama stasiun dan perhentian turunan, tetapkan nama yang dapat dikenali oleh penumpang, dan
dapat membantu penumpang mengetahui stasiun dan fasilitas naik turun penumpang (perhentian bus, peron, dermaga,
gerbang, dll.).
|
routes.txt
| Nama Kolom | Rekomendasi | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
Harus disertakan jika ditetapkan dalam agency.txt. |
||||||||||||||||||||
route_short_name |
Sertakan route_short_name jika ada penetapan layanan singkat. Ini harus
berupa nama layanan yang dikenali penumpang, maksimal 12 karakter. |
||||||||||||||||||||
route_long_name |
Definisi dari referensi Spesifikasi:
Nama ini umumnya lebih deskriptif daripada Berikut adalah contoh beberapa jenis nama panjang:
|
||||||||||||||||||||
route_long_name tidak boleh berisi route_short_name. |
|||||||||||||||||||||
Sertakan penetapan selengkapnya, termasuk identitas layanan, saat mengisi
route_long_name. Contoh:
|
|||||||||||||||||||||
route_id |
Semua perjalanan pada rute bernama tertentu harus merujuk ke route_id yang sama.
|
||||||||||||||||||||
Jika grup rute menyertakan cabang dengan nama yang berbeda (mis., 1A dan 1B), ikuti
rekomendasi pada kasus
cabang rute untuk menentukan
route_short_name dan route_long_name. |
|||||||||||||||||||||
route_color & route_text_color |
Reklame serta informasi pelanggan yang dicetak dan di internet harus sama (sehingga jika tidak ada di salah satunya, informasi tidak akan disertakan). | ||||||||||||||||||||
trips.txt
- Lihat kasus khusus untuk rute memutar: Rute memutar adalah kasus saat perjalanan dimulai dan berakhir di perhentian yang sama, kebalikan dari rute linier, yang memiliki dua perhentian akhir berbeda. Rute memutar harus dideskripsikan berdasarkan praktik tertentu. Lihat kasus Rute memutar.
- Lihat kasus khusus untuk rute simpul: Rute simpul adalah campuran dari geometri linear dan memutar, yang dilalui kendaraan secara memutar hanya di sebagian rutenya. Rute simpul harus dideskripsikan berdasarkan praktik tertentu. Lihat kasus Rute simpul.
| Nama Kolom | Rekomendasi | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
Jangan masukkan nama rute (route_short_name dan
route_long_name yang cocok) di kolom trip_headsign atau
stop_headsign. |
||||||||||||||
Harus berisi tujuan, rute, dan/atau teks penanda perjalanan lainnya yang ditampilkan di
layar jurusan kendaraan yang dapat digunakan untuk membedakan setiap perjalanan pada suatu rute.
Menampilkan informasi rute yang konsisten di kendaraan adalah tujuan utama dan prioritas
untuk menentukan jurusan yang dimasukkan dalam set data GTFS. Informasi lainnya harus
disertakan hanya jika tidak bertentangan dengan tujuan utama ini. Jika jurusan berubah selama
perjalanan, ganti trip_headsign dengan stop_times.stop_headsign. Berikut
adalah rekomendasi untuk beberapa kasus yang mungkin terjadi: |
|||||||||||||||
example_table:
|
|||||||||||||||
| Jangan mulai jurusan dengan kata "Ke" atau "Menuju". | |||||||||||||||
direction_id |
Jika perjalanan pada layanan rute berlawanan arah, bedakan kelompok perjalanan ini dengan
kolom direction_id, menggunakan nilai 0 dan 1. |
||||||||||||||
Gunakan nilai 0 dan 1 secara konsisten di seluruh set data, yaitu
|
stop_times.txt
Rute memutar: Rute memutar memerlukan pertimbangan stop_times khusus. (Lihat:
Kasus rute memutar)
| Nama Kolom | Rekomendasi | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_type & drop_off_type |
Perjalanan nonkomersial (deadhead) yang tidak melayani penumpang harus ditandai dengan
nilai 1 pada pickup_type dan drop_off_type untuk semua
baris stop_times. |
||||||||||||
Pada perjalanan komersial, “timepoint” internal untuk memantau performa operasional dan
tempat lainnya seperti lokasi perhentian tempat penumpang tidak dapat naik atau turun harus ditandai dengan
pickup_type = 1 (tidak melayani pengangkutan) dan drop_off_type = 1 (tidak melayani
penurunan) |
|||||||||||||
timepoint |
Kolom timepoint harus disediakan. Kolom tersebut menentukan
operator stop_times mana yang akan berupaya untuk menampilkan bahwa waktu perhentian sudah akurat
(timepoint=1), dan bahwa waktu perhentian lainnya merupakan estimasi
(timepoint=0). |
||||||||||||
arrival_time & departure_time |
Kolom arrival_time dan departure_time harus menentukan nilai
waktu jika memungkinkan, termasuk waktu interpolasi atau waktu estimasi yang tidak mengikat di antara beberapa
timepoint. |
||||||||||||
stop_headsign |
Nilai
Pada kasus di bawah ini, “Arah Selatan” akan menyesatkan pelanggan karena tanda ini tidak digunakan di tanda stasiun. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| shape_dist_traveled | shape_dist_traveled harus disediakan untuk rute yang memiliki jalur memutar atau inline
(kendaraan melintasi atau melalui bagian yang sama pada garis dalam satu perjalanan). Lihat
rekomendasi shapes.shape_dist_traveled. |
||||||||||||
calendar.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | calendar_dates.txt hanya boleh berisi jumlah pengecualian yang dibatasi pada
jadwal. Layanan dengan jadwal teratur harus dikonfigurasi menggunakan calendar.txt.
|
Menyertakan kolom calendar.service_name juga dapat memudahkan orang awam dalam
membaca GTFS, meskipun kolom ini tidak digunakan di spesifikasi. |
calendar_dates.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | calendar_dates.txt hanya boleh berisi jumlah pengecualian yang dibatasi pada
jadwal. Layanan dengan jadwal teratur harus dikonfigurasi menggunakan calendar.txt.
|
Menyertakan kolom calendar.service_name juga dapat memudahkan orang awam dalam
membaca GTFS, meskipun kolom ini tidak digunakan di spesifikasi. |
fare_attributes.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | agency_id harus disertakan di fare_attributes.txt jika
kolomnya disertakan di agency.txt. |
| Jika tidak bisa membuat model yang akurat untuk sistem tarif, sebaiknya biarkan kosong agar tidak menimbulkan kesalahpahaman yang lebih parah. | |
Sertakan tarif (fare_attributes.txt dan fare_rules.txt), lalu buat
model tarif seakurat mungkin. Dalam kasus ekstrem, yakni saat tidak dapat membuat model untuk tarif secara akurat,
tarif harus ditampilkan dengan harga yang lebih mahal, bukan lebih murah, sehingga pelanggan tidak akan
mencoba menaiki transportasi umum dengan tarif yang kurang. Jika model untuk sebagian besar tarif tidak dapat dibuat
dengan benar, jangan sertakan informasi tarif di feed. |
fare_rules.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | agency_id harus disertakan di fare_attributes.txt jika
kolomnya disertakan di agency.txt. |
| Jika tidak bisa membuat model yang akurat untuk sistem tarif, sebaiknya biarkan kosong agar tidak menimbulkan kesalahpahaman yang lebih parah. | |
Sertakan tarif (fare_attributes.txt dan fare_rules.txt), lalu buat
model tarif seakurat mungkin. Dalam kasus ekstrem, yakni saat tidak dapat membuat model untuk tarif secara akurat,
tarif harus ditampilkan dengan harga yang lebih mahal, bukan lebih murah, sehingga pelanggan tidak akan
mencoba menaiki transportasi umum dengan tarif yang kurang. Jika model untuk sebagian besar tarif tidak dapat dibuat
dengan benar, jangan sertakan informasi tarif di feed. |
shapes.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | Idealnya, untuk garis yang digunakan bersama (yaitu, saat Rute 1 dan 2 berada di bagian jalur atau rel yang sama), bagian garis yang digunakan bersama tersebut harus sama persis. Hal ini membantu mempermudah kartografi transportasi umum berkualitas tinggi. |
| Garis harus mengikuti garis tengah jalan yang dilalui kendaraan.
Garis ini dapat berupa garis tengah jalan jika tidak ada lajur khusus, atau
garis tengah sisi jalan yang searah laju kendaraan bergerak. Garis tidak boleh “berbelok tajam” ke arah perhentian pinggir jalan, peron, atau lokasi pemberangkatan. |
|
shape_dist_traveled |
Harus disediakan di 
Jika kendaraan melintasi atau melalui kembali titik pada garis rute dalam suatu perjalanan,
|
Kolom shape_dist_traveled memungkinkan perusahaan untuk menentukan secara jelas bagaimana
perhentian dalam file stop_times.txt sesuai dengan masing-masing bentuknya. Nilai
umum yang digunakan untuk kolom shape_dist_traveled adalah jarak dari
titik awal bentuk yang dilalui kendaraan (semacam nilai
odomoter).
|
feed_info.txt
feed_info.txt harus disertakan, bersama semua kolom di bawah.
| Nama Kolom | Rekomendasi |
|---|---|
feed_start_date & feed_end_date |
Harus disertakan |
feed_version |
Harus disertakan |
feed_contact_email & feed_contact_url |
Masukkan setidaknya salah satunya |
frequencies.txt
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | Waktu perhentian sebenarnya diabaikan untuk perjalanan yang direferensikan oleh frequencies.txt; hanya
interval waktu perjalanan antarperhentian yang penting bagi perjalanan berbasis frekuensi.
Agar jelas/dapat dipahami orang awam, sebaiknya waktu perhentian pertama pada perjalanan
yang direferensikan di frequencies.txt harus dimulai pada 00:00:00 (nilai
arrival_time pertama dari 00:00:00). |
block_id |
Dapat dimasukkan untuk perjalanan berbasis frekuensi. |
transfers.txt
transfers.transfer_type dapat berupa salah satu dari empat nilai
yang ditentukan dalam GTFS. Definisi
transfer_type ini dikutip dari Spesifikasi GTFS di bawah,
dengan rekomendasi praktik tambahan.
| Nama Kolom | Rekomendasi |
|---|---|
transfer_type |
Jika ada beberapa pilihan transfer yang menyertakan opsi yang lebih baik (yaitu, pusat transit dengan fasilitas tambahan atau stasiun dengan peron/fasilitas naik turun penumpang yang bersebelahan atau terhubung), tentukan titik transfer yang direkomendasikan. |
Setiap konsumen data menghitung jumlah waktu yang diperlukan untuk interval kedatangan dan keberangkatan ini berdasarkan
algoritme mereka sendiri. Jika nilai ini tidak cukup, atau jika ada kondisi lain yang tidak dipertimbangkan
konsumen, Anda dapat mengganti penghitungan waktu setelah Anda menetapkan
|
|
Tentukan waktu minimum untuk melakukan transfer jika ada gangguan atau faktor lainnya yang menambah waktu perjalanan antarperhentian. |
|
Tentukan nilai ini jika transfer tidak dapat dilakukan karena halangan fisik, atau jika transfer tidak aman atau rumit karena penyeberangan jalan atau area yang sulit di jaringan pejalan kaki. |
|
| Jika transfer tanpa pindah (blok) diizinkan di antara perjalanan, perhentian terakhir untuk perjalanan kedatangan harus sama dengan perhentian pertama untuk perjalanan keberangkatan. |
Rekomendasi Praktik yang Diatur Menurut Kasus
Bagian ini membahas kasus tertentu yang memiliki implikasi di seluruh file dan kolom.
Rute Memutar
Pada rute memutar, perjalanan kendaraan dimulai dan berakhir di lokasi yang sama (terkadang berupa transit atau pusat transfer). Kendaraan biasanya beroperasi terus-menerus dan mengizinkan penumpang untuk tetap berada di kendaraan saat kendaraan melanjutkan rute memutarnya.
Oleh karena itu, rekomendasi jurusan harus diterapkan agar dapat menampilkan arah tujuan kendaraan kepada penumpang.
Untuk menunjukkan perubahan arah pada perjalanan, masukkan stop_headsigns di
file stop_times.txt. stop_headsign mendeskripsikan arah perjalanan
yang berangkat dari perhentian yang ditentukan. Dengan menambahkan stop_headsigns untuk setiap
perhentian pada suatu perjalanan, Anda dapat mengubah informasi jurusan selama perjalanan.
Jangan tetapkan satu perjalanan melingkar di file stop_times.txt untuk rute yang
beroperasi antara dua titik akhir (seperti saat bus yang sama bolak-balik melewati suatu rute). Sebagai gantinya, buat
perjalanan tersebut menjadi dua arah perjalanan yang berbeda.
Contoh model perjalanan melingkar:
Perjalanan melingkar dengan perubahan jurusan untuk setiap perhentian:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"B" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"C" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"D" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"E" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"A" |
trip_1 |
06:35:00 |
06:35:00 |
stop_A |
6 |
"" |
Perjalanan melingkar dengan dua jurusan:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"outbound" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"outbound" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"outbound" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"inbound" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"inbound" |
trip_1 |
06:35:00 |
06:35:00 |
stop_F |
6 |
"inbound" |
trip_1 |
06:40:00 |
06:40:00 |
stop_A |
7 |
"" |
| Nama Kolom | Rekomendasi | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
Buat model pulang pergi untuk rute memutar dalam satu perjalanan. | |||||||||||||||
stop_times.stop_id |
Sertakan perhentian pertama/terakhir dua kali di stop_times.txt untuk perjalanan yang merupakan rute
memutar. Contohnya seperti di bawah ini. Sering kali, rute memutar dapat menyertakan perhentian pertama dan terakhir yang tidak melalui
keseluruhan rute memutar. Sertakan perjalanan ini juga.
|
|||||||||||||||
trips.direction_id |
Jika rute memutar bergerak ke arah yang berbeda (yaitu, searah dan berlawanan arah jarum jam),
tetapkan direction_id sebagai 0 atau 1. |
|||||||||||||||
trips.block_id |
Tunjukkan perjalanan memutar yang berkelanjutan dengan block_id yang sama. |
Rute Simpul
Rute simpul menggabungkan aspek rute memutar dan rute berarah.
- langsung dari A ke B;
- memutar dari B kembali ke B;
- langsung dari B ke A.
| Contoh: |
|---|
| Rute Kereta Bawah Tanah (Chicago) |
| Rute Bus dari Pinggiran Kota ke Pusat Kota (St. Albert atau Edmonton) |
| Brown Line CTA (Situs CTA dan TransitFeeds) |
| Nama Kolom | Rekomendasi | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
Rute selengkapnya untuk “kendaraan pulang pergi” (lihat ilustrasi
di atas) terdiri atas perjalanan dari A ke B, lalu memutar menuju B dan kembali ke A. Keseluruhan
perjalanan pulang pergi kendaraan dapat dinyatakan dengan:
trip_id di trips.txt
trip_id di trips.txt,
dengan perjalanan berkelanjutan ditunjukkan dengan block_id. |
||||||||||
stop_times.stop_headsign |
Perhentian di sepanjang bagian A-B akan diteruskan ke kedua arah.
stop_headsign memfasilitasi arah yang berbeda pada perjalanan. Oleh karena itu, sebaiknya masukkan
stop_headsign untuk perjalanan ini.
|
||||||||||
trip.trip_headsign |
Jurusan perjalanan harus berupa deskripsi global perjalanan, seperti yang ditampilkan di jadwal. Dapat berupa “Linden ke Linden melalui Rute Memutar” (contoh Chicago), atau “A ke A melalui B” (contoh umum). |
Cabang
Beberapa rute dapat menyertakan cabang. Cabang tersebut memiliki garis dan perhentian yang sama, tetapi setiap cabang juga memiliki bagian garis dan perhentian yang berbeda. Hubungan antarcabang dapat ditunjukkan dengan nama rute, jurusan, dan nama pendek perjalanan menggunakan panduan mendetail di bawah.
| Nama Kolom | Rekomendasi |
|---|---|
| Semua Kolom | Dalam penamaan rute cabang, sebaiknya ikuti informasi lainnya dari penumpang. Di bawah ini adalah deskripsi dan contoh dari dua kasus: |
Jika jadwal dan reklame di jalan mewakili dua rute dengan nama yang berbeda (mis., 1A dan
1B), maka tampilkan rute ini sebagaimana mestinya di GTFS, menggunakan kolom route_short_name dan/atau
route_long_name. Contoh: Rute 2, 2A, dan 2B pada Transportasi Umum GoDurham
melalui garis yang sama di sebagian besar rutenya, tetapi rute tersebut memiliki beberapa
aspek berbeda.
|
|
Jika informasi yang diberikan perusahaan mendeskripsikan cabang sebagai rute dengan nama yang sama, gunakan
kolom trips.trip_headsign, stop_times.stop_headsign, dan/atau
trips.trip_short_name. Misalnya: Rute 300 GoTriangle melakukan perjalanan ke
lokasi berbeda tergantung pada waktu. Selama jam sibuk transportasi umum, segmen ekstra akan
ditambahkan ke rute standar untuk mengakomodasi pekerja yang menuju ke dalam atau luar
kota. |
Tentang Dokumen Ini
Tujuan
Tujuan dari mengelola Praktik Terbaik GTFS adalah untuk:
- Mendukung interoperabilitas data transportasi umum yang lebih baik
- Menyempurnakan pengalaman pengguna akhir saat menggunakan aplikasi transportasi umum
- Mempermudah developer software dalam men-deploy dan menskalakan aplikasi, produk, dan layanan
- Memfasilitasi penggunaan GTFS dalam berbagai kategori aplikasi (di luar fokus aslinya yang berkaitan dengan perencanaan perjalanan)
Cara mengusulkan atau mengubah Praktik Terbaik GTFS yang dipublikasikan
Aplikasi dan praktik GTFS terus berkembang, sehingga dokumen ini mungkin perlu diperbarui dari waktu ke waktu. Untuk mengajukan amendemen pada dokumen ini, ajukan permintaan pull di repositori GitHub Praktik Terbaik GTFS dan berikan dokumen pendukung untuk perubahan tersebut. Anda juga dapat mengirimkan komentar melalui email ke specifications@mobilitydata.org.
Penautan ke Dokumen Ini
Untuk memberikan pedoman formasi data GTFS yang benar kepada pembuat feed, cantumkan URL praktik terbaik ini. Setiap rekomendasi memiliki link anchor. Klik rekomendasi untuk mendapatkan URL link anchor dalam halaman.
Jika aplikasi yang menggunakan GTFS membuat persyaratan atau rekomendasi untuk praktik data GTFS yang tidak dijelaskan di sini, sebaiknya publikasikan dokumen dengan persyaratan atau rekomendasi tersebut untuk melengkapi praktik terbaik umum ini.
Grup Kerja Praktik Terbaik GTFS
Grup Kerja Praktik Terbaik GTFS dibentuk oleh Rocky Mountain Institute pada tahun 2016-17, yang terdiri dari penyedia transportasi umum, developer aplikasi yang menggunakan GTFS, konsultan, dan lembaga pendidikan untuk menentukan praktik umum dan ekspektasi terhadap data GTFS. Anggota grup kerja ini antara lain:
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research di University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation
- Swiftly
- Transit
- Trillium
- TriMet
- Bank Dunia
Sekarang, dokumen ini dikelola oleh Organisasi Internasional MobilityData.