Lewati ke isi

Proses amandemen spesifikasi

Itu GTFS Spesifikasi tidak diatur dalam batu. Sebaliknya, ini adalah spesifikasi terbuka yang dikembangkan dan dikelola oleh komunitas agen transit, pengembang, dan pemangku kepentingan lain yang menggunakannyaGTFS . Diharapkan komunitas produsen dan konsumen iniGTFS data akan memiliki proposal untuk memperluas spesifikasi guna mengaktifkan kemampuan baru. Untuk membantu mengelola proses tersebut, prosedur dan pedoman berikut telah ditetapkan.

Spesifikasi resmi, referensi dan dokumentasi ditulis dalam bahasa Inggris. Jika sebuah Translation ke bahasa yang berbeda berbeda dari aslinya bahasa Inggris, yang terakhir diutamakan. Semua komunikasi dilakukan dalam bahasa Inggris.

  1. Buat cabang git dengan memperbarui semua bagian definisi protokol, spesifikasi, dan file dokumentasi yang relevan (kecuali untuk terjemahan).
  2. Buat permintaan tarik di https://github.com/google/transit . Permintaan penarikan harus berisi deskripsi tambalan yang diperluas. Pencipta pull request menjadi advokat .
  3. Setelah permintaan tarik didaftarkan, permintaan tersebut harus diumumkan oleh advokatnya di GTFS perubahan Mengubah milis , termasuk tautan ke permintaan penarikan. Setelah diumumkan, pull request dianggap sebagai proposal. Permintaan penarikan juga harus diedit untuk memuat tautan ke pengumuman Google Grup sehingga dapat dengan mudah dirujuk silang.
  4. Pembahasan proposal berikut. Komentar pull request harus digunakan sebagai satu-satunya forum diskusi.
    • Pembahasan berlangsung selama advokat merasa perlu, tetapi harus sekurang-kurangnya 7 hari kalender.
    • Advokat bertanggung jawab untuk memperbarui proposal secara tepat waktu (yaitu pull request) berdasarkan komentar yang mereka setujui.
    • Pada setiap titik ditime advokat dapat mengklaim proposal diabaikan.
  5. Advokat dapat meminta pemungutan suara pada versi proposal kapan sajatime mengikuti interval 7 hari awal yang diperlukan untuk diskusi.
    • Sebelum menyerukan pemungutan suara, setidaknya satuGTFS produser dan satuGTFS konsumen harus menerapkan perubahan yang diusulkan. Diharapkan bahwaGTFS produser(s) termasuk perubahan dalam menghadapi publikGTFS beri makan dan berikan tautan ke data itu dalam komentar permintaan tarik, dan bahwaGTFS konsumen menyediakan tautan dalam komentar permintaan tarik ke aplikasi yang memanfaatkan perubahan dengan cara yang tidak sepele (yaitu, mendukung fungsionalitas baru atau yang lebih baik).
  6. Vote berlangsung selama periode minimum yang cukup untuk menutupi 7FULL hari kalender dan 5FULL hari kerja Swiss. Vote berakhir pada 23:59:59 UTC.
    • Advokat harus mengumumkan yang spesifikendtime padastart suara.
    • Selama masa voting hanya diperbolehkan perubahan redaksional proposal (salah ketik, susunan kata boleh berubah asalkan tidak mengubah arti).
    • Siapapun diperbolehkan untuk memilih ya/tidak dalam bentuk komentar untuk pull request, dan suara dapat diubah sampaiend dari periode pemungutan suara. Jika pemilih mengubah suaranya, disarankan untuk melakukannya dengan memperbarui komentar suara asli dengan mencoret suara dan menulis suara baru.
    • Suara sebelumstart periode pemungutan suara tidak dipertimbangkan.
    • Pembukaan dan penutupan pemungutan suara harus diumumkan di GTFS-perubahan Mengubah milis .
  7. Usul diterima jika sudah ada kesepakatan bulat ya dengan minimal 3 suara.
    • Suara pengusul tidak dihitung terhadap total 3 suara. Misalnya, jika Pengusul X membuat pull request dan memilih ya, dan Pengguna Y dan Z memilih ya, ini dihitung sebagai total 2 suara ya.
    • Suara menentang harus dimotivasi, dan idealnya memberikan umpan balik yang dapat ditindaklanjuti.
    • Jika pemungutan suara gagal, maka advokat dapat memilih untuk melanjutkan pengerjaan proposal, atau meninggalkan proposal. Salah satu keputusan advokat harus diumumkan di GTFS-perubahan Mengubah milis .
    • Jika advokat melanjutkan pengerjaan proposal, maka pemungutan suara baru dapat dilakukan kapan sajatime .
  8. Setiap pull request yang tidak aktif selama 30 hari kalender akan ditutup. Saat pull request ditutup, proposal terkait dianggap ditinggalkan. Advokat dapat membuka kembali pull request kapan sajatime jika mereka ingin melanjutkan atau mempertahankan percakapan.
  9. Jika proposal diterima:
    • Google berkomitmen untuk menggabungkan versi pull request yang telah dipilih (asalkan kontributor telah menandatangani PLK, dan melakukan pull request dalam waktu 5 hari kerja.
    • Terjemahan tidak boleh dimasukkan ke dalam pull request asli. Google bertanggung jawab untuk memperbarui terjemahan yang relevan ke dalam bahasa yang didukung, tetapi murniTranslation tarik permintaan dari komunitas diterima dan akan diterima segera setelah semua komentar editorial ditangani.
  10. Hasil akhir dari pull request (diterima atau diabaikan) harus diumumkan di utas Google Grup yang sama tempat permintaan pull awalnya diumumkan.

Prinsip Panduan

Untuk melestarikan visi asliGTFS , sejumlah prinsip panduan telah ditetapkan untuk dipertimbangkan saat memperluas spesifikasi:

Umpan harus mudah dibuat dan diedit
Kami memilih CSV sebagai dasar spesifikasi karena mudah dilihat dan diedit menggunakan program spreadsheet dantext editor, yang berguna untuk agensi yang lebih kecil. Ini juga mudah dihasilkan dari sebagian besar bahasa pemrograman dan basis data, yang bagus untuk penerbit umpan yang lebih besar.

Umpan harus mudah diuraikan
Pembaca umpan harus dapat mengekstrak informasi yang mereka cari dengan usaha sesedikit mungkin. Perubahan dan penambahan feed harus bermanfaat seluas mungkin, untuk meminimalkan jumlah jalur kode yang perlu diterapkan oleh pembaca feed. (Namun, membuat pembuatan lebih mudah harus diutamakan, karena pada akhirnya akan ada lebih banyak penerbit umpan daripada pembaca umpan.)

Spesifikasinya tentang informasi penumpang
GTFS terutama berkaitan dengan informasi penumpang. Artinya, spek harus menyertakan informasi yang dapat membantu alat-alat listrik untuk pengendara, pertama dan terutama. Ada potensi sejumlah besar informasi berorientasi operasi yang mungkin ingin ditransmisikan oleh agen transit secara internal antar sistem.GTFS tidak dimaksudkan untuk tujuan itu dan ada potensi standar data berorientasi operasi lain yang mungkin lebih tepat.

Perubahan pada spesifikasi harus kompatibel ke belakang
Saat menambahkan fitur ke spesifikasi, kami ingin menghindari perubahan yang akan membuat feed yang ada menjadi tidak valid. Kami tidak ingin membuat lebih banyak pekerjaan untuk penerbit feed yang ada hingga mereka ingin menambahkan kemampuan ke feed mereka. Selain itu, jika memungkinkan, kami ingin parser yang ada dapat terus membaca bagian lama dari umpan yang lebih baru.

Fitur spekulatif tidak disarankan
Setiap fitur baru menambah kerumitan pembuatan dan pembacaan feed. Oleh karena itu, kami ingin berhati-hati untuk hanya menambahkan fitur yang kami tahu bermanfaat. Idealnya, proposal apa pun akan diuji dengan menghasilkan data untuk sistem transit nyata yang menggunakan fitur baru dan perangkat lunak penulisan untuk membaca dan menampilkannya. Perhatikan bahwaGTFS dengan mudah memungkinkan ekstensi ke format melalui penambahan kolom dan file tambahan yang diabaikan oleh parser & validator resmi, sehingga proposal dapat dengan mudah dibuat prototipe dan diuji pada umpan yang ada.


Riwayat Revisi

14 Maret 2023

  • Menambahkan media tarif. Lihat diskusi .

26 Juli 2022

  • Menambahkan transfer perjalanan-ke-perjalanan dengan opsi di kursi. Lihat diskusi

17 Mei 2022

  • GTFS-Fares v2 implementasi basis. Lihat diskusi

22 Oktober 2021

  • Ditambahkan Utama dan Asingid bidang. Lihat diskusi

05 Oktober 2021

  • Menambahkan transfer Trip-to-trip dan rute-ke-rute. Lihat diskusi

15 September 2021

  • Gerbang tarif yang diizinkan (pathway_mode=6) menjadi dua arah. Lihat diskusi .

13 September 2021

  • Memperbarui praktik terbaik stop_name . Lihat diskusi .

27 Agustus 2021

4 Januari 2021

  • Deskripsi yang diklarifikasi tentang stop_times. stop_id stop_id . Lihat diskusi .
  • Didefinisikan tanda-tanda bidang positif dan bukan nol. Lihat diskusi .

2 Oktober 2020

  • Jenis kolom frequencies.headway_secs diubah dari non-negatif menjadi bilangan bulat positif. Lihat diskusi .

25 Mei 2020

  • Ditetapkan pathways.txt ,levels.txt dan attributions.txt sebagai tabel yang dapat diterjemahkan. Menambahkan rekomendasi untuk menerjemahkan nilai signposted_as multibahasa. Lihat diskusi .

13 Mei 2020

  • Menambahkan continuous_pickup dan continuous_drop_off ke routes.txt dan stop_times.txt . Berubah shape_id dari "Optional" ke "Conditionally required". Lihat diskusi .

24 Maret 2020

  • Ditetapkantext -to-speech dan menambahkan tts_stop_name ke stops.txt. Lihat diskusi .

5 Februari 2020

  • Menambahkan trolleybus dan monorel route_types . Lihat diskusi .

9 Januari 2020

  • Ditambahkan translations.txt. Lihat diskusi .

26 Desember 2019

  • Definisi yang diperbarui untuk trem kabel dan lift udara masuk route_type. Lihat diskusi .

20 Desember 2019

  • Ditambahkan attributions.txt. Lihat diskusi .

26 Agustus 2019

  • Ditentukan bahwa stop_lat dan stop_lon ditempatkan di tempat penumpang menunggu untuk naikvehicle . Lihat diskusi .

9 Juli 2019

  • Ditambahkanarrival dandeparturetime praktik terbaik. Lihat diskusi .
  • Menambahkan praktik terbaik headsign. Lihat diskusi .
  • Ditambahkan stop_id praktik terbaik. Lihat diskusi .

25 Juni 2019

  • Hubungan yang diklarifikasi dariShape poin dan berhenti. Lihat diskusi .

4 April 2019

  • Menambahkan kolom platform_code di stops.txt. Lihat diskusi .

27 Maret 2019

  • Ditambahkan pathways.txt dan levels.txt . Lihat diskusi .

6 Februari 2019

  • Editorial dan perubahan pemformatan untuk kejelasan. Lihat diskusi .

2 Oktober 2018

  • Jenis bidang yang difaktorkan. Lihat diskusi .

14 September 2018

  • Menambahkan konsep "Conditionally required". Lihat diskusi .

4 September 2018

  • Menyatukan definisi agency_lang dan feed_lang . Lihat diskusi .

27 Agustus 2018

  • Diperbarui CHANGES.md dan tanggal revisi terakhir. Lihat diskusi .

22 Agustus 2018

  • Menambahkan bidang feed_contact_email dan feed_contact_url di feed_info.txt mengajukan. Lihat diskusi .

11 Desember 2017

  • Menambahkan route_sort_order ke routes.txt. Lihat diskusi .

15 Maret 2017

  • Diklarifikasi bahwa suara pengusul tidak diperhitungkan dalam total. Lihat diskusi .
  • Ditentukan bahwa sebelum melakukan pemungutan suara, setidaknya satuGTFS produser dan satuGTFS konsumen harus menerapkan perubahan yang diusulkan. Lihat diskusi .

7 Februari 2017

  • Hubungan yang diklarifikasi dari block_id dan service_id. Lihat diskusi .
  • Diklarifikasi bahwa layanan berbasis frekuensi dimulai padavehicledeparture . Lihat diskusi .
  • Deskripsi yang diklarifikasi dari stop_id dan stop_code . Lihat diskusi .

11 Desember 2017

  • Menambahkan bidang route_sort_order di routes.txt mengajukan. Lihat diskusi .

27 November 2016

  • Menambahkan pintu masuk stasiun sebagai stops.location_type . Lihat diskusi .

2 September 2016

  • Dokumentasi yang diperbarui untuk ditambahkan agency_id dibawah fare_attributes.txt . Lihat diskusi .

16 Maret 2016

3 Februari 2016

  • Menambahkan agency_email ke agency.txt proposal untuk spesifikasi: diskusi

2 Februari 2015

  • Ditambahkan stop_times.txt proposal 'titik waktu' untuk spesifikasi: diskusi

17 Februari 2014

  • Ditambahkan trips.txt Proposal 'bikes_allowed' untuk spek: diskusi

15 Oktober 2012

  • Ditambahkan trips.txt 'wheelchair_accessible' proposal untuk spesifikasi: diskusi

20 Juni 2012

  • Menambahkan proposal 'wheelchair_boarding' ke spec: diskusi

2 Februari 2012

  • Menambahkan proposal 'stop_timezone' ke spec: diskusi

18 Januari 2012

  • Memigrasikan dokumentasi dari code.google.com lama ke lokasi barunya di developers.google.com.

26 September 2011

  • Menambahkan proposal 'feed_info' ke spec: diskusi

6 September 2011

  • Menambahkan proposal 'agency_fare_url' ke spec: diskusi
  • Menambahkan proposal 'exact_times' ke spec: diskusi

30 Maret 2009

  • Bagian baru tentang membuat umpan transit tersedia untuk umum. Ini sebelumnya tidak dibahas di grup, karena ini bukan sepenuhnya perubahan pada cara data ditafsirkan atau ditulis. Namun, beberapa orang di Google berpendapat bahwa akan informatif jika menyertakan diskusi tentang penggunaan non-GoogleGTFS , karena semakin banyak aplikasi yang bisa dimanfaatkanGTFS -data yang diformat.
  • Klarifikasi format CSV: diskusi .
  • Panduan tambahan tentang cara memilih warna kontras dalam deskripsi kolom route_color dan route_text_color.
  • trip_short_name, seperti yang diusulkan dan diuji di utas ini: a dan b.
  • Perbaikan untuk kesalahan kecil dalam data sampel yang disertakan diend dokumen (memberikan stop S7 parent_station S8).
  • Menambahkan informasi "agency_lang" ke data sampel diend dokumen, seperti yang disarankan oleh Marcy selama periode komentar: diskusi .
  • Memperbarui tautan ke OCTAGTFS umpan di sidebar
  • Lihat ringkasan asli .

26 Februari 2009

  • Menghapus sebagian besar instruksi pengiriman umpan khusus Google, karena ada banyak aplikasi lain yang menggunakanGTFS data pada titik ini.
  • Memperbaiki tautan yang rusak di sidebar ke feed publik Orange County OCTA.

7 Agustus 2008

  • Memulihkan bidang stop_url, yang secara tidak sengaja dihilangkan pada versi 6 Agustus
  • Menambahkan agency_phone ke data sampel
  • Menambahkan penyebutan perjanjian penggunaan data saat mengirimkan feed ke Google

6 Agustus 2008

  • Ditambahkantransfers.txt file, memungkinkan penayang feed memberikan petunjuk tentang perilaku transfer yang disukai ( proposal asli )
  • Menambahkan kolom location_type dan parent_station ke stops.txt , memungkinkan titik perhentian dikelompokkan ke dalam stasiun ( proposal asli )
  • Menambahkan kolom agency_phone untuk memberikan nomor telepon suara untuk agensi ( proposal asli )
  • Menambahkan bagian "Menguji Umpan Anda" yang menyebutkan alat pengujian sumber terbuka
  • Menambahkan klarifikasi tentang format CSV, agency_timezone, agency_lang, route_color, route_text_color, waktu_kedatangan, waktu_keberangkatan,calendar.txt vs.calendar_dates.txt , tabel tarif, danfrequencies.txt
  • Menambahkan tautan ke dokumen riwayat umpan, dan mengoreksi beberapa tautan umpan publik
  • Gambar contoh yang diperbarui untuk menggambarkan UI Google Maps saat ini
  • Data sampel yang diperbarui/diperbaiki dalam dokumen

29 Februari 2008

  • Menambahkan bidang stop_code di stops.txt untuk memungkinkan spesifikasi kode berhenti yang menghadap pengendara ( proposal asli )
  • Klarifikasi deskripsi route_short_name dan route_long_name di routes.txt
  • Memperjelas deskripsi waktu_kedatangan dan waktu_keberangkatan di stop_times.txt
  • Memperbaiki kesalahan ketik di bagian Data Sampel

20 Nopember 2007

  • Deskripsi block_id yang diklarifikasi
  • Bahasa diubah untuk tidak menekankan Google Transit (karena aplikasi non-Google menggunakanGTFS , dan perutean transit kini menjadi fitur terintegrasi Google Maps), dan untuk memperbaiki berbagai kesalahan ketik
  • Contoh tangkapan layar yang diperbarui untuk mencerminkan presentasiGTFS di UI Google Maps saat ini
  • Memperbarui alamat email kontak Google untuk penyedia data transit
  • Pemformatan diperbarui

5 Oktober 2007

  • Berubahstop_sequence danshape_pt_sequence untuk memungkinkan peningkatan bilangan bulat non-negatif
  • Deskripsi yang diklarifikasi dan kesalahan ketik yang diperbaiki

31 Mei 2007

  • Memperbarui gaya halaman, menjadikan HTML lebih bersih dan lebih mudah diakses
  • Menambahkan tautan ke contoh umpan publik dan situs bermanfaat lainnya
  • Contoh yang dihapus dari masing-masing deskripsi kolom

9 April 2007

  • Menambahkan bagian tentang mengirimkan umpan .
  • Menambahkan Contoh umpan Agen Transit Demo .
  • Ditambahkan catatan itucalendar.txt dapat dihilangkan jika semua tanggal layanan ditentukancalendar_dates.txt .
  • Terbuatagency_id kolom opsional di feed yang hanya berisi satu agensi. Hal ini memungkinkan feed yang ada tanpaagency_id untuk tetap berlaku.
  • Menambahkan spesifikasi yang lebih lengkap untuk agency_url, stop_url, dan route_url, serta nilai contoh tambahan untuk kolom tersebut.
  • Ditambahkan 6 (Gondola) dan 7 (Funicular) sebagai valid route_type nilai-nilai.

8 Maret 2007

  • Edit kecil untuk memindahkan bidang stop_url dari stop_times.txt , yang salah ditentukan dalam pembaruan 28 Februari, ke stops.txt , tempatnya.

5 Maret 2007

  • Edit kecil untuk mengklarifikasi deskripsi bidang route_long_name.

28 Februari 2007

  • Penambahan dari frequencies.txt untuk dukungan jadwal berbasis headway.
  • Beberapa agensi sekarang diizinkan di feed yang sama. Juga ditambahkan baru agency_id di kedua agency.txt dan routes.txt yang memungkinkan Anda menentukan rute mana yang dioperasikan oleh agen mana.
  • Penambahan URL per-rute dan per-stop.
  • Penambahan dari direction_id lapangan di trips.txt .
  • Dukungan untuk pertengahantrip perubahan headsign dengan penambahan bidang stop_headsign di stop_times.txt .
  • Dukungan untuk warna rute dengan tambahan route_color dan route_text_color opsional routes.txt .
  • Menghapus kemampuan untuk menentukan perhentian menggunakan alamat jalan. Versi spesifikasi sebelumnya memungkinkan Anda memberikan lokasi perhentian transit menggunakan alamat jalan di bidang stop_street, stop_city, stop_region, stop_postcode, dan stop_country. Sekarang lokasi perhentian harus diberikan menggunakan stop_lat untuklatitude dan stop_lon untuklongitude , yang lebih berguna untuk sebagian besar aplikasi.
  • Penambahan kereta gantungvehicle ketik untuk route_type lapangan di routes.txt .
  • Lihat ringkasan posting blog Headway asli dari perubahan tersebut.

29 Nopember 2006

  • Ditambahkan dukungan untuktrip Shape informasi melalui shapes.txt
  • Memperjelas definisi dari stop_sequence
  • Ditandai pickup_type dan drop_off_type opsional

31 Oktober 2006

  • Menambahkan dukungan untuk informasi tarif
  • Tanggal yang dihapus dari nama file individual
  • Mengubah route_type definisi nilai
  • Diizinkan untuk memposting beberapa file feed secara bersamaantime , selama periode layanan mereka tidak tumpang tindih
  • Memperbaiki block_id di trips.txt sehingga ditandai dengan benar Opsional
  • Perhatikan bahwa tajuk kolom harus disertakan

29 September 2006

  • Edit kecil untuk memperbaiki beberapa kesalahan dalam contoh.

25 September 2006

  • Versi awal.