Praktik Terbaik untuk GTFS

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:

Pertanyaan Umum (FAQ)

Mengapa Praktik Terbaik GTFS ini penting?

Tujuan Praktik Terbaik GTFS:

  • Untuk menyempurnakan 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.
  • Set data GTFS yang dipublikasikan harus selalu valid setidaknya selama 7 hari ke depan, dan idealnya selama operator yakin bahwa jadwal layanan akan terus beroperasi.
  • Jika memungkinkan, set data GTFS harus mencakup layanan untuk setidaknya 30 hari ke depan.
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 bus, 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.
  • Jika kata tersebut adalah bagian dari namanya (Stasiun Pasar Senen, Terminal Blok M)
  • Jika stop_name terlalu umum (misalnya, kode tersebut adalah nama kota). "Stasiun", "Terminal", atau kata lain memperjelas maknanya.
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 bus 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.
  • Stasiun atau terminal harus ditetapkan sebagai data dalam stops.txt dengan location_type = 1.
  • Setiap fasilitas naik turun penumpang harus ditetapkan sebagai perhentian dengan location_type = 0 . Kolom parent_station harus merujuk stop_id untuk stasiun tempat fasilitas naik turun penumpang berada.
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.).
Nama Stasiun Induk Nama Perhentian Turunan
Chicago Union Station Chicago Union Station Platform 19
San Francisco Ferry Building Terminal San Francisco Ferry Building Terminal Gate E
Downtown Transit Center Downtown Transit Center Bay B

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 route_short_name dan seringkali akan menyertakan perhentian atau tujuan rute. Setidaknya, salah satu dari route_short_name maupun route_long_name harus ditentukan, atau mungkin keduanya jika sesuai. Jika rute tidak memiliki nama panjang, tentukan route_short_name dan gunakan string kosong sebagai nilai untuk kolom ini.

Berikut adalah contoh beberapa jenis nama panjang:

Jalur Perjalanan atau Koridor Utama
Nama Rute Jenis Agen
“N”/“Judah” route_short_name/
route_long_name
Muni, di San Francisco
“6“/“ML King Jr Blvd“ route_short_name/
route_long_name
TriMet, di Portland, OR.
“6”/“Nation - Étoile” route_short_name/
route_long_name
RATP, di Paris, Prancis.
“U2”/ “Pankow – Ruhleben” route_short_name/
route_long_name
BVG, di Berlin, Jerman
Deskripsi Layanan
“Hartwell Area Shuttle“
route_long_name tidak boleh berisi route_short_name.
Sertakan penetapan selengkapnya, termasuk identitas layanan, saat mengisi route_long_name. Contoh:
Identitas Layanan Rekomendasi Contoh
"MAX Light Rail"
TriMet, di Portland, Oregon
route_long_name harus menyertakan merek (MAX) dan penetapan rute yang spesifik "MAX Red Line"
"MAX Blue Line"
"Rapid Ride"
ABQ Ride, di Albuquerque, New Mexico
route_long_name harus menyertakan merek (Rapid Ride) dan penetapan rute yang spesifik "Rapid Ride Red Line"
"Rapid Ride Blue Line"
route_id Semua perjalanan pada rute bernama tertentu harus merujuk ke route_id yang sama.
  • Rute dengan arah yang berbeda tidak boleh dipisahkan menjadi nilai route_id yang berbeda.
  • Rute dengan jam operasional yang berbeda tidak boleh dipisahkan menjadi nilai route_id yang berbeda (yaitu, jangan membuat data berbeda pada routes.txt untuk layanan “Downtown Pagi” dan “Downtown Petang”).
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 pergantian 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:
Deskripsi Rute Rekomendasi
2A. Khusus tujuan akhir Masukkan tujuan akhir. Misalnya, "Transit Center", “Portland City Center”, atau “Jantzen Beach”.
2B. Tujuan akhir dengan waypoint <destination> melalui <waypoint> “Highgate melalui Charing Cross”. Jika waypoint dihapus dari layar jurusan yang ditampilkan kepada penumpang setelah waypoint tersebut dilewati, gunakan stop_times.stop_headsign untuk menetapkan jurusan berikutnya.
2C. Nama tempat regional dengan perhentian lokal Jika akan ada beberapa perhentian dalam borough atau kota tujuan, gunakan stop_times.stop_headsign begitu tiba di kota tujuan.
2D. Hanya rute Tunjukkan dengan menggunakan istilah seperti “Arah Utara”, “Arah Dalam Kota”, “Searah Jarum Jam”, atau arah yang serupa.
2E. Arah dengan tujuan <direction> ke <terminus name> mis. “Arah Selatan ke San Jose”.
2F. Arah dengan tujuan dan waypoint <direction> melalui <waypoint> ke <destination> (“Arah Utara melalui Charing Cross ke Highgate”).
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
  • Jika 1 = Arah Keluar pada rute Merah, maka 1 = Arah Keluar pada rute Hijau
  • Jika 1 = Arah Utara pada Rute X, maka 1 = Arah Utara pada Route Y
  • Jika 1 = Searah jarum jam pada Rute X, maka 1 = Searah jarum jam pada Rute Y

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 stop_headsign menggantikan trip_headsign (di trips.txt). Nilai stop_headsign harus disediakan saat teks ditampilkan di perubahan jurusan selama perjalanan. Nilai stop_headsign tidak “berpindah” ke perhentian berikutnya, sehingga nilai harus diulangi jika layar perhentian tidak berubah. Intinya, nilai jurusan juga harus sesuai dengan tanda di stasiun.

Pada kasus di bawah ini, “Arah Selatan” akan menyesatkan pelanggan karena tanda ini tidak digunakan di tanda stasiun.

Di NYC, untuk Kereta 2 yang menuju Arah Selatan:
Untuk baris stop_times.txt: Gunakan nilai stop_headsign:
Sampai Manhattan Manhattan & Brooklyn
Sampai Downtown Downtown & Brooklyn
Sampai Brooklyn Brooklyn
Begitu Sampai di Brooklyn Brooklyn (New Lots Av)
Di Boston, untuk Kereta Red Line menuju Arah Selatan, untuk cabang Braintree:
Untuk baris stop_times.txt: Gunakan nilai stop_headsign:
Sampai Downtown Inbound to Braintree
Begitu Sampai di Downtown Braintree
Setelah Downtown Outbound to Braintree
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 shapes.txt dan stop_times.txt jika garis menyertakan jalur memutar atau inline (kendaraan melintasi atau melalui bagian yang sama pada garis dalam satu perjalanan).

Rute Inline

Jika kendaraan melintasi atau melalui kembali titik pada garis rute dalam suatu perjalanan, shape_dist_traveled sangat penting untuk memperjelas bagian titik pada jalur shapes.txt sesuai dengan data di stop_times.txt.

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).
  • Garis rute (di shapes.txt) harus dalam radius 100 meter dari lokasi perhentian yang dilayani suatu rute.
  • Ringkas garis agar shapes.txt tidak berisi titik yang tidak relevan (yaitu, hapus titik tidak relevan di segmen garis lurus, lihat pembahasan peringkasan masalah garis).

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 0 atau (kosong): Ini adalah titik transfer yang direkomendasikan antar-rute.

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.

1: Ini adalah titik transfer berjangka waktu di antara dua rute. Kendaraan yang berangkat sebaiknya menunggu kendaraan yang datang, menyisakan waktu yang cukup bagi penumpang untuk berpindah dari satu rute ke rute lainnya.

Jenis transfer ini mengganti interval yang diperlukan agar dapat berpindah rute dengan lancar. Sebagai contoh, Google Maps mengasumsikan bahwa penumpang memerlukan waktu 3 menit agar dapat melakukan transfer. Aplikasi lain mungkin mengasumsikan default yang berbeda.

2: Transfer memerlukan jumlah waktu minimum antara kedatangan dan keberangkatan untuk memastikan koneksi. Waktu yang diperlukan untuk transfer ditentukan oleh min_transfer_time.

Tentukan waktu minimum untuk melakukan transfer jika ada gangguan atau faktor lainnya yang menambah waktu perjalanan antarperhentian.

3: Transfer tidak dapat dilakukan di antara beberapa rute di lokasi ini.

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 meliputi 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.

Di bawah: Rute memutar. Kendaraan kembali ke titik awal dalam satu perjalanan. Beberapa rute memutar melayani perjalanan satu arah, dan rute lainnya melayani dua arah.
Rute Memutar

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.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
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.

Di bawah ini: Rute simpul merupakan rute memutar dari A ke A melalui B yang dibagi dalam tiga bagian:
  • langsung dari A ke B;
  • memutar dari B kembali ke B;
  • langsung dari B ke A.
Rute Simpul
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:
  • Satu nilai/data trip_id di trips.txt
  • Beberapa nilai/data 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.
    Contoh:
    "A melalui B"
    "A"
    Purple Line Chicago Transit Authority
    "Arah Selatan ke Rute Memutar"
    "Arah Utara melalui Rute Memutar"
    "Arah Utara ke Linden"
    Jalur Bus Edmonton Transit Service, rute 39
    "Rutherford"
    "Century Park"
    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.

    Di bawah: Tiga kemungkinan konfigurasi untuk cabang rute. Garis utama berwarna hitam. Garis cabang berwarna emas.
    Konfigurasi Cabang Rute
    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. Sebagai 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.
    • Rute 2 adalah layanan inti, yang beroperasi hampir sepanjang hari.
    • Rute 2 mencakup penyimpangan rute pada malam hari, hari Minggu, dan hari libur di Main Street.
    • Rute 2A dan 2B beroperasi di siang hari, Senin sampai Sabtu.
    • Rute 2B melayani perhentian tambahan yang berbeda dari garis jalur yang digunakan bersama.
    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 perubahan 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:

    Sekarang, dokumen ini dikelola oleh Organisasi Internasional MobilityData.