Lewati ke isi

GTFSSchedule Praktik terbaik

Ini adalah praktik yang direkomendasikan untuk mendeskripsikan layanan transportasi umum di General Transit Feed Specification (GTFS). Praktik-praktik ini dirangkum dari pengalaman para anggota GTFS Best Practices working group dan application-specific GTFS practice recommendations.

Untuk latar belakang lebih lanjut, lihat Pertanyaan yang Sering Diajukan .

Struktur Dokumen

Praktik diatur ke dalam empat bagian utama:

Publikasi Dataset & Praktik Umum

  • Kumpulan data harus dipublikasikan di URL publik dan permanen, termasuk nama file zip. (misalnya, www.agency.org/gtfs/gtfs.zip). Idealnya, URL harus dapat langsung diunduh tanpa memerlukan login untuk mengakses file, untuk memfasilitasi pengunduhan dengan menggunakan aplikasi perangkat lunak. Meskipun disarankan (dan merupakan praktik yang paling umum) untuk membuat set data GTFS dapat didownload secara terbuka, jika penyedia data memang perlu mengontrol akses ke GTFS karena alasan lisensi atau lainnya, disarankan untuk mengontrol akses ke set data GTFS menggunakan kunci API. yang akan memfasilitasi pengunduhan otomatis.
  • GTFS data diterbitkan dalam iterasi sehingga satu file di lokasi yang stabil selalu berisi deskripsi resmi layanan terbaru untuk agen transit (atau agen).
  • Pertahankan pengidentifikasi persisten (bidang id) untukstop_id ,route_id , danagency_id di seluruh iterasi data bila memungkinkan.
  • SatuGTFS kumpulan data harus berisi layanan saat ini dan yang akan datang (terkadang disebut kumpulan data "gabungan"). Fungsi penggabungan alat transitfeed Google dapat digunakan untuk membuat kumpulan data gabungan dari dua yang berbedaGTFS feed.
  • Setiap saat, diterbitkanGTFS kumpulan data harus valid setidaknya selama 7 hari ke depan, dan idealnya selama operator yakin bahwaSchedule akan terus dioperasikan.
  • Jika memungkinkan,GTFS kumpulan data harus mencakup setidaknya 30 hari layanan berikutnya.
  • Hapus layanan lama (kalender kedaluwarsa) dari umpan.
  • Jika modifikasi layanan akan berlaku dalam 7 hari atau kurang, nyatakan perubahan layanan ini melalui feed GTFS-realtime (nasihat layanan atau pembaruan perjalanan) dan bukan kumpulan data GTFS statis.
  • Hosting server webGTFS data harus dikonfigurasi untuk melaporkan tanggal modifikasi file dengan benar (lihat HTTP/1.1 - Permintaan Komentar 2616, di bawah Bagian 14.29).

Rekomendasi Praktik Disusun oleh File

Bagian ini menunjukkan praktik yang diatur berdasarkan file dan bidang, selaras denganGTFS referensi .

Semua data

Nama Bidang Rekomendasi
Kasus Campuran Semua string teks yang menghadap pelanggan (termasuk nama perhentian, nama rute, dan tanda kepala) harus menggunakan Huruf Campuran (bukan SEMUA CAPS), mengikuti konvensi lokal untuk kapitalisasi nama tempat pada tampilan yang mampu menampilkan karakter huruf kecil.
Contoh:
Lapangan Brighton Churchill
Villiers-sur-Marne
Jalan Pasar
Singkatan Hindari penggunaan singkatan di seluruh feed untuk nama dan teks lainnya (misalnya St. for Street) kecuali jika suatu lokasi disebut dengan nama singkatannya (misalnya "Bandara JFK"). Singkatan mungkin bermasalah untuk aksesibilitas oleh perangkat lunak pembaca layar dan antarmuka pengguna suara. Mengkonsumsi perangkat lunak dapat direkayasa untuk secara andal mengonversi kata-kata lengkap menjadi singkatan untuk ditampilkan, tetapi mengonversi dari singkatan ke kata-kata lengkap rentan terhadap risiko kesalahan yang lebih besar.

agency.txt

Nama Bidang Rekomendasi
agency_id Harus disertakan, meskipun hanya ada satu agensi dalam feed. (Lihat juga rekomendasi untuk menyertakanagency_id diroutes.txt danfare_attributes.txt )
agency_phone Harus disertakan kecuali tidak ada telepon layanan pelanggan seperti itu.
agency_email Harus disertakan kecuali tidak ada email layanan pelanggan tersebut.
agency_fare_url Harus disertakan kecuali agen sepenuhnya bebas tarif.

Contoh:

  • Layanan bus dijalankan oleh beberapa agen bus kecil. Tapi ada satu agensi besar yang bertanggung jawab untuk penjadwalan dan tiket dan dari sudut pandang pengguna bertanggung jawab atas layanan bus. Satu agensi besar harus didefinisikan sebagai agensi dalam feed. Bahkan jika data dibagi secara internal oleh operator bus kecil yang berbeda, seharusnya hanya ada satu agensi yang ditentukan dalam umpan.

  • Penyedia feed menjalankan portal tiket, tetapi ada beberapa agen berbeda yang benar-benar mengoperasikan layanan dan diketahui oleh pengguna sebagai pihak yang bertanggung jawab. Agensi yang benar-benar mengoperasikan layanan harus didefinisikan sebagai agensi dalam feed.

stops.txt

Nama Bidang Rekomendasi
stop_name Jika tidak ada nama perhentian yang dipublikasikan, ikuti konvensi penamaan perhentian yang konsisten di seluruh umpan.
Secara default,stop_name tidak boleh mengandung kata-kata umum atau berlebihan seperti “Station” atau “Stop”, tetapi beberapa kasus tepi diperbolehkan.
  • Ketika itu sebenarnya bagian dari nama (Stasiun Union, Stasiun Pusat
  • Ketikastop_name terlalu umum (seperti jika itu adalah nama kota). “Stasiun”, “Terminal”, atau dengan kata lain memperjelas artinya.
stop_lat &stop_lon Lokasi pemberhentian harus seakurat mungkin. Lokasi pemberhentian seharusnya memiliki kesalahan__ tidak lagi__ dari empat meter jika dibandingkan dengan posisi berhenti yang sebenarnya.
Lokasi pemberhentian harus ditempatkan sangat dekat dengan jalur pejalan kaki di mana penumpang akan naik (yaitu sisi jalan yang benar).
Jika lokasi perhentian dibagikan di seluruh umpan data yang terpisah (yaitu dua agensi menggunakan fasilitas perhentian / boarding yang sama persis), tunjukkan bahwa perhentian dibagikan dengan menggunakan yang sama persisstop_lat danstop_lon untuk kedua halte.
parent_station &location_type Banyak stasiun atau terminal memiliki beberapa fasilitas boarding (tergantung pada mode, mereka mungkin disebut bus bay, platform, dermaga, gerbang, atau istilah lain). Dalam kasus seperti itu, produsen pakan harus menjelaskan stasiun, fasilitas boarding (juga disebut perhentian anak), dan hubungannya.
  • Stasiun atau terminal harus didefinisikan sebagai catatan dalamstops.txt denganlocation_type = 1 .
  • Setiap fasilitas boarding harus didefinisikan sebagai perhentian denganlocation_type = 0 . Ituparent_station bidang harus merujuk kestop_id stasiun tempat fasilitas boarding berada.
Saat menamai stasiun dan perhentian anak, tetapkan nama yang dikenal baik oleh pengendara, dan dapat membantu pengendara untuk mengidentifikasi stasiun dan fasilitas boarding (ruang bus, peron, dermaga, gerbang, dll.).
Nama Stasiun Induk Nama Berhenti Anak
Stasiun Chicago Union Peron Stasiun Chicago Union 19
Terminal Gedung Feri San Francisco Gerbang Terminal Gedung Feri San Francisco E
Pusat Transit Pusat Kota Pusat Transit Pusat Kota Bay B

routes.txt

Nama Bidang Rekomendasi
agency_id Harus disertakan, meskipun hanya ada satu agensi di feed. (Lihat juga rekomendasi untuk disertakan agency_id di dalam agency.txt Dan fare_attributes.txt )
route_short_name Termasukroute_short_name jika ada penunjukan layanan singkat. Ini harus menjadi nama layanan penumpang yang umum diketahui, tidak lebih dari 12 karakter.
route_long_name Definisi dari referensi Spesifikasi: Nama ini umumnya lebih deskriptif daripada route_short_name dan akan sering menyertakan tujuan atau pemberhentian rute. Setidaknya satu dari route_short_name atau route_long_name harus ditentukan, atau berpotensi keduanya jika sesuai. Jika rute tidak memiliki nama yang panjang, sebutkan a route_short_name dan gunakan string kosong sebagai nilai untuk bidang ini.
Contoh jenis nama panjang di bawah ini:
Jalur atau Koridor Perjalanan Utama
Nama Rute Membentuk Agen
"N"/"Yehuda" route_short_name /
route_long_name		 Muni , di San Francisco
“6“/“ML King Jr Blvd“ route_short_name /
route_long_name		TriMet, di Portland, Oregon
“6”/“Nation - Étoile”route_short_name/
route_long_name		RATP, di Paris, Perancis
“U2”-“Pankow – Ruhleben”route_short_name-
route_long_name		BVG, di Berlin, Jerman
Deskripsi Layanan
“Hartwell Area Shuttle“
route_long_name tidak boleh mengandungroute_short_name .
Sertakan penunjukan lengkap termasuk identitas layanan saat mengisiroute_long_name . Contoh:
Identitas Layanan Rekomendasi Contoh
"MAX Kereta Api Ringan"
TriMet, di Portland, Oregon		 Itu route_long_name harus menyertakan merek (MAX) dan penunjukan rute tertentu "MAX Garis Merah" "MAX Garis Biru"
"Perjalanan Cepat"
ABQ Ride, di Albuquerque, New Mexico		 Itu route_long_name harus menyertakan merek (Rapid Ride) dan penunjukan rute tertentu "Jalur Merah Naik Cepat"
"Jalur Cepat Naik Biru"
route_id Semua perjalanan pada rute bernama tertentu harus mengacu pada hal yang samaroute_id .
  • Arah yang berbeda dari suatu rute tidak boleh dipisahkan menjadi berbedaroute_id nilai-nilai.
  • Rentang operasi yang berbeda dari suatu rute tidak boleh dipisahkan menjadiroute_id nilai-nilai. yaitu jangan membuat catatan yang berbeda diroutes.txt untuk layanan "Pusat Kota AM" dan "Pusat Kota PM").
    		•
    Jika grup rute menyertakan cabang dengan nama yang jelas (misalnya 1A dan 1B), ikuti rekomendasi di rute ranting kasus untuk menentukanroute_short_name danroute_long_name .
    route_color &route_text_color Harus konsisten dengan papan nama dan informasi pelanggan tercetak dan online (dan dengan demikian tidak termasuk jika tidak ada di tempat lain).

    trips.txt

    • Lihat kasus khusus untuk rute loop: Rute loop adalah kasus di mana perjalanan dimulai dan berakhir di perhentian yang sama, berlawanan dengan rute linier, yang memiliki dua terminal berbeda. Rute loop harus dijelaskan mengikuti praktik khusus. Lihat Kasus rute loop.
    • Lihat kasus khusus untuk rute lasso: Rute lasso adalah hibrida dari geometri linier dan lingkaran, di mana kendaraan berjalan dalam lingkaran hanya untuk sebagian rute. Rute Lasso harus dijelaskan mengikuti praktik khusus. Lihat kasus rute Lasso.
    Nama Bidang Rekomendasi
    trip_headsign Jangan berikan nama rute (cocokroute_short_name danroute_long_name ) dalamtrip_headsign ataustop_headsign bidang.
    Harus memuat tujuan, arah, dan/atau teks penunjukan perjalanan lainnya yang tertera pada headsign kendaraan yang dapat digunakan untuk membedakan perjalanan dalam suatu rute. Konsistensi dengan informasi arah yang ditampilkan pada kendaraan adalah tujuan utama dan utama untuk menentukan rambu-rambu yang disediakan diGTFS kumpulan data. Informasi lain harus dimasukkan hanya jika tidak membahayakan tujuan utama ini. Jika tanda kepala berubah selama perjalanan, timpatrip_headsign denganstop_times.stop_headsign . Di bawah ini adalah rekomendasi untuk beberapa kemungkinan kasus:
    Deskripsi Rute Rekomendasi
    2A. Hanya tujuan Berikan tujuan terminal. misalnya "Pusat Transit", "Pusat Kota Portland", atau "Pantai Jantzen">
    2B. Tujuan dengan titik arah melalui "Gerbang Tinggi melalui Charing Cross". Jika titik jalan dipindahkan dari penunjuk arah kepada penumpang setelah kendaraan melewati titik jalan tersebut, gunakan stop_times.stop_headsign untuk mengatur headsign yang diperbarui.>
    2C. Nama tempat regional dengan pemberhentian lokal Jika akan ada beberapa pemberhentian di dalam kota atau wilayah tujuan, gunakan stop_times.stop_headsign setelah mencapai kota tujuan.>
    2D. Arah saja Tunjukkan menggunakan istilah seperti “Northbound”, “Inbound”, “Searah jarum jam”, atau arah serupa.>
    2E. Arah dengan tujuan ke misalnya “Ke selatan ke San Jose”>
    2F. Arah dengan tujuan dan titik arah melalui ke (“Northbound melalui Charing Cross ke Highgate”).>
    Jangan memulai tanda kepala dengan kata-kata “Kepada” atau “Menuju”.
    direction_id Gunakan nilai 0 dan 1 secara konsisten di seluruh kumpulan data. yaitu
    • Jika 1 = Keluar di jalur Merah, maka 1 = Keluar di jalur Hijau
    • Jika 1 = Arah Utara pada Rute X, maka 1 = Arah Utara pada Rute Y
    • Jika 1 = searah jarum jam pada Rute X maka 1 = searah jarum jam pada Rute Y

    stop_times.txt

    Rute loop: Rute loop memerlukan pertimbangan stop_times khusus. (Lihat: Kasus rute loop )

    Nama Bidang Rekomendasi
    pickup_type &drop_off_type Perjalanan non-pendapatan (deadhead) yang tidak menyediakan layanan penumpang harus ditandai denganpickup_type dandrop_off_type Nilai dari1 untuk semuastop_times baris.
    Pada perjalanan pendapatan, "titik waktu" internal untuk memantau kinerja operasional dan tempat-tempat lain seperti garasi yang tidak dapat dinaiki penumpang harus ditandai denganpickup_type = 1 (tidak tersedia penjemputan) dandrop_off_type = 1 (tidak tersedia pengantaran).
    timepoint Kolom timepoint harus disediakan. Ini menentukan stop_times mana yang akan dipatuhi oleh operator secara ketat ( timepoint=1 ), dan waktu berhenti lainnya adalah perkiraan ( timepoint=0 ).
    arrival_time &departure_time arrival_time dandeparture_time bidang harus menentukan nilai waktu bila memungkinkan, termasuk perkiraan waktu yang tidak mengikat atau waktu interpolasi antara titik waktu.
    stop_headsign Secara umum, nilai tanda kepala juga harus sesuai dengan tanda di stasiun.

    Dalam kasus di bawah ini, “Ke arah Selatan” akan menyesatkan pelanggan karena tidak digunakan di rambu stasiun.
    Di NYC, untuk 2 orang menuju Southbound:
    Untukstop_times.txt baris: Menggunakan stop_headsign nilai:
    Sampai Manhattan Tercapai Manhattan & Brooklyn
    Sampai Pusat Kota Tercapai Pusat kota & Brooklyn
    Sampai Brooklyn Tercapai Brooklyn
    Begitu Brooklyn Tercapai Brooklyn (Lot Baru Av)
    Di Boston, untuk Jalur Merah menuju Selatan, untuk cabang Braintree:
    Untukstop_times.txt baris: Menggunakan stop_headsign nilai:
    Sampai Pusat Kota Tercapai Masuk ke Braintree
    Setelah Pusat Kota Tercapai pohon otak
    Setelah Pusat Kota Keluar ke Braintree
    shape_dist_traveled shape_dist_traveled harus disediakan untuk rute yang memiliki looping atau inlining (kendaraan melintasi atau melewati bagian alinyemen yang sama dalam satu perjalanan). Lihatshapes.shape_dist_traveled rekomendasi.

    calendar.txt

    Nama Bidang Rekomendasi
    Semua bidang Termasukcalendar.service_name bidang juga dapat meningkatkan keterbacaan manusia dariGTFS , meskipun ini tidak diadopsi dalam spesifikasi.

    calendar_dates.txt

    Nama Bidang Rekomendasi
    Semua bidang Termasukcalendar.service_name bidang juga dapat meningkatkan keterbacaan manusia dariGTFS , meskipun ini tidak diadopsi dalam spesifikasi.

    fare_attributes.txt

    Nama Bidang Rekomendasi
    agency_id Harus disertakan, meskipun hanya ada satu agensi di feed. (Lihat juga rekomendasi untuk disertakan agency_id di dalam agency.txt Dan routes.txt )
    Jika sistem tarif tidak dapat dimodelkan secara akurat, hindari kebingungan lebih lanjut dan biarkan kosong.
    Termasuk tarif (fare_attributes.txt danfare_rules.txt ) dan buat modelnya seakurat mungkin. Dalam kasus tepi di mana tarif tidak dapat dimodelkan secara akurat, tarif harus direpresentasikan sebagai lebih mahal daripada lebih murah sehingga pelanggan tidak akan mencoba naik dengan tarif yang tidak mencukupi. Jika sebagian besar tarif tidak dapat dimodelkan dengan benar, jangan sertakan informasi tarif dalam feed.

    fare_rules.txt

    Nama Bidang Rekomendasi
    Semua bidang Jika sistem tarif tidak dapat dimodelkan secara akurat, hindari kebingungan lebih lanjut dan biarkan kosong.
    Termasuk tarif (fare_attributes.txt danfare_rules.txt ) dan buat modelnya seakurat mungkin. Dalam kasus tepi di mana tarif tidak dapat dimodelkan secara akurat, tarif harus direpresentasikan sebagai lebih mahal daripada lebih murah sehingga pelanggan tidak akan mencoba naik dengan tarif yang tidak mencukupi. Jika sebagian besar tarif tidak dapat dimodelkan dengan benar, jangan sertakan informasi tarif dalam feed.

    shapes.txt

    Nama Bidang Rekomendasi
    Semua bidang Idealnya, untuk alinyemen yang digunakan bersama (yaitu dalam kasus di mana Rute 1 dan 2 beroperasi pada segmen jalan raya atau rel yang sama) maka bagian alinyemen yang dibagikan harus sama persis. Ini membantu memfasilitasi kartografi transit berkualitas tinggi.
    Alignment harus mengikuti garis tengah kanan jalan yang dilalui kendaraan. Ini bisa berupa garis tengah jalan jika tidak ada lajur yang ditentukan, atau garis tengah sisi jalan yang bergerak ke arah pergerakan kendaraan.

    Penjajaran tidak boleh "bergejolak" ke halte, peron, atau lokasi boarding.
    shape_dist_traveled Harus disediakan di keduanyashapes.txt danstop_times.txt jika suatu alinyemen mencakup looping atau inlining (kendaraan melintasi atau melewati bagian alinyemen yang sama dalam satu perjalanan).
    Jika kendaraan menelusuri kembali atau melintasi alinyemen rute pada titik-titik dalam perjalanan, shape_dist_traveled penting untuk memperjelas bagaimana bagian dari poin dishapes.txt berbaris sesuai dengan catatan distop_times.txt .
    Itushape_dist_traveled bidang memungkinkan agen untuk menentukan dengan tepat bagaimana berhenti distop_times.txt file sesuai dengan bentuknya masing-masing. Nilai umum yang digunakan untukshape_dist_traveled bidang adalah jarak dari awal bentuk seperti yang ditempuh oleh kendaraan (pikirkan sesuatu seperti pembacaan odometer).
  • Alinyemen rute (dalamshapes.txt ) harus berada dalam jarak 100 meter dari lokasi pemberhentian yang dilayani oleh suatu perjalanan.
  • Sederhanakan perataan sehinggashapes.txt tidak mengandung poin asing (yaitu menghilangkan poin tambahan pada segmen garis lurus; lihat pembahasan masalah penyederhanaan garis).
    		•

    frequencies.txt

    Nama Bidang Rekomendasi
    Semua bidang Waktu berhenti yang sebenarnya diabaikan untuk perjalanan yang dirujuk olehfrequencies.txt ; hanya interval waktu perjalanan antar perhentian yang signifikan untuk perjalanan berbasis frekuensi. Untuk kejelasan/keterbacaan manusia, disarankan agar waktu perhentian pertama dari sebuah perjalanan dirujuk dalamfrequencies.txt harus dimulai pada 00:00:00 (pertamaarrival_time nilai 00:00:00).
    block_id Dapat disediakan untuk perjalanan berbasis frekuensi.

    transfers.txt

    transfers.transfer_type dapat menjadi salah satu dari empat nilai yang didefinisikan dalamGTFS . Definisi transfer_type ini dikutip dariGTFS Spesifikasi di bawah, dicetak miring , dengan rekomendasi latihan tambahan.

    Nama Bidang Rekomendasi
    transfer_type 0 atau (kosong): Ini adalah titik transfer yang disarankan antar rute.
    Jika ada beberapa peluang transfer yang menyertakan opsi superior (yaitu pusat transit dengan fasilitas tambahan atau stasiun dengan fasilitas/platform boarding yang berdekatan atau terhubung), tentukan titik transfer yang direkomendasikan.
    1: Ini adalah titik transfer waktunya antara dua rute. Kendaraan yang berangkat diharapkan menunggu kendaraan yang datang, dengan waktu yang cukup bagi penumpang untuk berpindah antar rute.
    Jenis transfer ini mengesampingkan interval yang diperlukan untuk melakukan transfer dengan andal. Sebagai contoh, Google Maps mengasumsikan bahwa penumpang membutuhkan 3 menit untuk melakukan transfer dengan aman. Aplikasi lain mungkin mengasumsikan default lainnya.
    2: Transfer ini membutuhkan waktu minimum antara kedatangan dan keberangkatan untuk memastikan koneksi. Waktu yang diperlukan untuk mentransfer ditentukan oleh min_transfer_time .
    Tentukan waktu transfer minimum jika ada halangan atau faktor lain yang meningkatkan waktu tempuh antar perhentian.
    3: Transfer tidak dimungkinkan antar rute di lokasi ini.
    Tentukan nilai ini jika transfer tidak mungkin dilakukan karena hambatan fisik, atau jika dibuat tidak aman atau rumit karena penyeberangan jalan yang sulit atau celah di jaringan pejalan kaki.
    Jika transfer di tempat duduk (blok) diperbolehkan di antara perjalanan, maka perhentian terakhir dari perjalanan yang tiba harus sama dengan perhentian pertama dari perjalanan yang berangkat.

    feed_info.txt

    feed_info.txt harus disertakan, dengan semua bidang di bawah ini.

    Nama Bidang Rekomendasi
    feed_start_date &feed_end_date Harus disertakan
    feed_version Harus disertakan
    feed_contact_email &feed_contact_url Sediakan setidaknya satu

    Rekomendasi Praktik Disusun berdasarkan Kasus

    Bagian ini mencakup kasus-kasus tertentu dengan implikasi di seluruh file dan bidang.

    Rute Putaran

    Pada rute loop, perjalanan kendaraan dimulai dan berakhir di lokasi yang sama (kadang-kadang pusat transit atau transfer). Kendaraan biasanya beroperasi terus menerus dan memungkinkan penumpang untuk tetap berada di atas kapal saat kendaraan melanjutkan putarannya.

    Oleh karena itu, rekomendasi rambu-rambu depan harus diterapkan untuk menunjukkan kepada pengendara arah ke mana kendaraan itu pergi.

    Untuk menunjukkan perubahan arah perjalanan, berikan stop_headsigns distop_times.txt mengajukan. stop_headsign menjelaskan arah perjalanan yang berangkat dari perhentian yang telah ditentukan. Menambahkan stop_headsigns ke setiap perhentian perjalanan memungkinkan Anda mengubah informasi headsign sepanjang perjalanan.

    Jangan menentukan satu perjalanan melingkar distop_times.txt file untuk rute yang beroperasi di antara dua titik akhir (seperti ketika bus yang sama bolak-balik). Sebaliknya, bagi perjalanan menjadi dua arah perjalanan yang terpisah.

    Contoh pemodelan perjalanan melingkar:

    • Perjalanan melingkar dengan mengubah tanda kepala untuk setiap pemberhentian
    trip_id jam kedatangan waktu keberangkatan stop_id stop_sequence stop_headsign
    perjalanan_1 06:10:00 06:10:00 stop_A 1 "B"
    perjalanan_1 06:15:00 06:15:00 berhenti_B 2 "C"
    perjalanan_1 06:20:00 06:20:00 stop_C 3 "D"
    perjalanan_1 06:25:00 06:25:00 berhenti_D 4 "E"
    perjalanan_1 06:30:00 06:30:00 stop_E 5 "SEBUAH"
    perjalanan_1 06:35:00 06:35:00 stop_A 6 ""
    • Perjalanan melingkar dengan dua tanda kepala
    trip_id jam kedatangan waktu keberangkatan stop_id stop_sequence stop_headsign
    perjalanan_1 06:10:00 06:10:00 stop_A 1 "keluar"
    perjalanan_1 06:15:00 06:15:00 berhenti_B 2 "keluar"
    perjalanan_1 06:20:00 06:20:00 stop_C 3 "keluar"
    perjalanan_1 06:25:00 06:25:00 berhenti_D 4 "masuk"
    perjalanan_1 06:30:00 06:30:00 stop_E 5 "masuk"
    perjalanan_1 06:35:00 06:35:00 stop_F 6 "masuk"
    perjalanan_1 06:40:00 06:40:00 stop_A 7 ""
    Nama Bidang Rekomendasi
    trips.trip_id Buat model perjalanan pulang pergi lengkap untuk loop dengan satu perjalanan.
    stop_times.stop_id Sertakan perhentian pertama/terakhir dua kali dalamstop_times.txt untuk perjalanan yang loop. Contoh di bawah ini. Seringkali, rute loop dapat mencakup perjalanan pertama dan terakhir yang tidak melewati seluruh loop. Sertakan perjalanan ini juga.
    trip_idstop_idstop_sequence
    9000 101 1
    9000 102 2
    9000 103 3
    9000 101 4
    trips.direction_id Jika loop beroperasi dalam arah yang berlawanan (yaitu searah jarum jam dan berlawanan arah jarum jam), maka tentukandirection_id sebagai 0 atau1 .
    trips.block_id Tunjukkan perjalanan loop berkelanjutan dengan yang samablock_id .

    Rute Lasso

    Rute Lasso menggabungkan aspek rute loop dan rute terarah.

    Contoh:
    Rute Kereta Bawah Tanah ( Chicago )
    Rute Bus Pinggiran Kota ke Pusat Kota ( St. Albert atau Edmonton )
    Garis Coklat CTA ( Situs web CTA dan Umpan Transit )
    Nama Bidang Rekomendasi
    trips.trip_id Keseluruhan “perjalanan pulang pergi dengan kendaraan” (lihat ilustrasi di atas ) terdiri dari perjalanan dari A ke B ke B dan kembali ke A. Seluruh perjalanan pulang pergi kendaraan dapat dinyatakan dengan:
  • SEBUAH__ lajang__ trip_id nilai/catatan dalamtrips.txt
  • Beberapa trip_id nilai/catatan dalamtrips.txt , dengan perjalanan terus menerus ditunjukkan olehblock_id .
    		•
    stop_times.stop_headsign Perhentian di sepanjang bagian AB akan dilalui di kedua arah.stop_headsign memfasilitasi membedakan arah perjalanan. Oleh karena itu, menyediakanstop_headsign direkomendasikan untuk trips.example_table ini:
    Contoh:
    "A melalui B"
    "SEBUAH"
    Otoritas Transit Chicago Garis Ungu
    "Selatan ke Loop"
    "Ke utara melalui Loop"
    "Utara ke Linden"
    Jalur Bus Layanan Transit Edmonton, di sini yang 39
    "Rutherford"
    "Taman Abad"
    trip.trip_headsign Tanda kepala perjalanan harus berupa deskripsi global perjalanan, seperti yang ditampilkan dalam jadwal. Bisa jadi "Linden ke Linden via Loop" (contoh Chicago), atau "A ke A via B" (contoh umum).

    Ranting

    Beberapa rute mungkin termasuk cabang. Alignment dan stop dibagi di antara cabang-cabang ini, tetapi masing-masing juga melayani bagian stop dan alignment yang berbeda. Hubungan antar cabang dapat ditunjukkan dengan nama rute, rambu, dan nama pendek perjalanan menggunakan panduan lebih lanjut di bawah ini.

    Nama Bidang Rekomendasi
    Semua bidang Dalam memberi nama rute cabang, disarankan untuk mengikuti materi informasi penumpang lainnya. Di bawah ini adalah deskripsi dan contoh dari dua kasus:
    Jika jadwal dan rambu di jalan mewakili dua rute dengan nama yang berbeda (misalnya 1A dan 1B), maka tunjukkan ini seperti diGTFS , menggunakanroute_short_name dan/atauroute_long_name bidang. Contoh: GoDurham Transit rute 2, 2A, dan 2B berbagi keselarasan umum di sebagian besar rute, tetapi mereka bervariasi dalam beberapa aspek yang berbeda.
    • Rute 2 adalah layanan inti, berjalan hampir setiap jam.
    • Rute 2 termasuk penyimpangan pada malam Main Street, Minggu, dan hari libur.
    • Rute 2A dan 2B beroperasi pada jam kerja siang hari Senin sampai Sabtu.
    • Rute 2B melayani pemberhentian tambahan dalam penyimpangan jalur penyelarasan bersama.
    Jika informasi yang disediakan agensi menggambarkan cabang sebagai rute bernama yang sama, maka gunakantrips.trip_headsign ,stop_times.stop_headsign , dan/atautrips.trip_short_name bidang. Contoh: GoTriangle rute 300 perjalanan ke lokasi yang berbeda tergantung pada waktu hari. Selama jam-jam puncak komuter, kaki ekstra ditambahkan ke rute standar untuk mengakomodasi pekerja yang masuk dan keluar kota.

    Pertanyaan yang Sering Diajukan (FAQ)

    Mengapa ini?GTFS Praktik Terbaik penting?

    Tujuan dariGTFS Praktik Terbaik adalah:

    • Untuk meningkatkan pengalaman pelanggan pengguna akhir di aplikasi transportasi umum
    • Mendukung interoperabilitas data yang luas untuk memudahkan pengembang perangkat lunak menyebarkan dan menskalakan aplikasi, produk, dan layanan
    • Memfasilitasi penggunaanGTFS dalam berbagai kategori aplikasi (di luar fokus aslinya pada perencanaan perjalanan)

    Tanpa terkoordinasiGTFS Praktik Terbaik, berbagaiGTFS -aplikasi yang menggunakan mungkin menetapkan persyaratan dan harapan dengan cara yang tidak terkoordinasi, yang mengarah ke persyaratan yang berbeda dan kumpulan data khusus aplikasi dan interoperabilitas yang lebih sedikit. Sebelum rilis Praktik Terbaik, ada ambiguitas dan ketidaksepakatan yang lebih besar dalam apa yang membentuk dengan benarGTFS data.

    Bagaimana mereka dikembangkan? Siapa yang mengembangkannya?

    Praktik Terbaik ini dikembangkan oleh kelompok kerja yang terdiri dari 17 organisasi yang terlibat dalamGTFS , termasuk penyedia aplikasi & konsumen data, penyedia transit, dan konsultan dengan keterlibatan luas dalamGTFS . Kelompok kerja dibentuk dan difasilitasi oleh Rocky Mountain Institute .

    Anggota Kelompok Kerja memberikan suara pada setiap Praktik Terbaik. Kebanyakan Praktik Terbaik disetujui dengan suara bulat. Dalam sebagian kecil kasus, Praktik Terbaik disetujui oleh sebagian besar organisasi.

    Mengapa tidak mengubahnya saja?GTFS referensi?

    Pertanyaan bagus! Proses pemeriksaan Spesifikasi, penggunaan data, dan kebutuhan memang memicu beberapa perubahan pada Spesifikasi (lihat permintaan tarik tertutup di GitHub ). Amandemen referensi spesifikasi tunduk pada pemeriksaan dan komentar yang lebih tinggi daripada Praktik Terbaik. Namun, masih ada kebutuhan untuk menyepakati serangkaian rekomendasi Praktik Terbaik yang jelas.

    Kelompok kerja mengantisipasi bahwa beberapaGTFS Praktik Terbaik pada akhirnya akan menjadi bagian dari intiGTFS referensi.

    MengerjakanGTFS alat validator memeriksa kesesuaian dengan Praktik Terbaik ini?

    Saat ini tidak ada alat validator yang memeriksa kesesuaian dengan semua Praktik Terbaik. Berbagai alat validator memeriksa kesesuaian dengan beberapa praktik terbaik ini. Untuk daftar alat validator GTFS, lihat GTFS Validators. Jika Anda menulis alat validator GTFS yang merujuk pada Praktik Terbaik ini, silakan kirim email ke specifications@mobilitydata.org.

    Saya mewakili agen transit. Langkah apa yang dapat saya ambil agar penyedia layanan dan vendor perangkat lunak kami mengikuti Praktik Terbaik ini?

    Rujuk vendor atau penyedia layanan perangkat lunak Anda ke Praktik Terbaik ini. Kami merekomendasikan untuk merujuk keGTFS URL Praktik Terbaik, serta Referensi Spesifikasi inti dalam pengadaan untukGTFS -memproduksi perangkat lunak.

    Apa yang harus saya lakukan jika saya melihatGTFS umpan data tidak sesuai dengan Praktik Terbaik ini?

    Identifikasi kontak untuk umpan, menggunakan bidang feed_contact_email atau feed_contact_url yang diusulkan difeed_info.txt jika ada, atau mencari informasi kontak di agen transit atau situs web produsen pakan. Saat mengomunikasikan masalah tersebut ke produsen pakan, tautkan ke spesifikGTFS Praktik Terbaik yang sedang dibahas. (Lihat "Menautkan ke Dokumen ini" ).

    Saya ingin mengusulkan modifikasi/penambahan pada Praktik Terbaik. Bagaimana cara melakukannya?

    Kirim email ke specifications@mobilitydata.org atau buka permintaan terbitan atau pull di repo Praktik Terbaik GTFS GitHub.

    Bagaimana cara saya terlibat?

    Kirim email ke specifications@mobilitydata.org.

    Tentang Dokumen Ini

    Tujuan

    Tujuan memeliharaGTFS Praktik Terbaik adalah:

    • Mendukung interoperabilitas data transit yang lebih besar
    • Tingkatkan pengalaman pelanggan pengguna akhir di aplikasi transportasi umum
    • Permudah pengembang perangkat lunak untuk menerapkan dan menskalakan aplikasi, produk, dan layanan
    • Memfasilitasi penggunaanGTFS dalam berbagai kategori aplikasi (di luar fokus aslinya pada perencanaan perjalanan)

    Bagaimana mengusulkan atau mengubah diterbitkanGTFS Praktik terbaik

    Aplikasi dan praktik GTFS terus berkembang, sehingga dokumen ini mungkin perlu diubah dari waktu ke waktu. Untuk mengusulkan amandemen terhadap dokumen ini, buka pull request di GTFS Best Practices GitHub repository dan dukung perubahan tersebut. Anda dapat mengirimkan komentar apa pun melalui email ke specifications@mobilitydata.org.

    Menautkan ke Dokumen Ini

    Silakan tautkan di sini untuk memberikan panduan kepada produsen pakan untuk pembentukan yang benarGTFS data. Setiap rekomendasi individu memiliki tautan jangkar. Klik rekomendasi untuk mendapatkan URL tautan jangkar dalam halaman.

    Jika sebuahGTFS -aplikasi yang memakan membuat persyaratan atau rekomendasi untukGTFS praktik data yang tidak dijelaskan di sini, disarankan untuk menerbitkan dokumen dengan persyaratan atau rekomendasi tersebut untuk melengkapi praktik terbaik umum ini.

    GTFS Kelompok Kerja Praktik Terbaik

    ItuGTFS Kelompok Kerja Praktik Terbaik diselenggarakan oleh Rocky Mountain Institute pada 2016-17, yang terdiri dari penyedia transportasi umum, pengembangGTFS -mengkonsumsi aplikasi, konsultan, dan organisasi akademik untuk mendefinisikan praktik umum dan harapan untukGTFS data.Anggota kelompok kerja ini meliputi:

    Hari ini, dokumen ini dikelola oleh MobilityData .