Persyaratan GTFS

Partner harus menyediakan feed GTFS yang memenuhi semua spesifikasi standar, serta spesifikasi yang tercantum di bawah. Feed ini harus mencakup semua itinerari yang ingin ditampilkan partner. Dengan memberikan informasi ini, informasi jadwal dan rute dapat ditampilkan di Google. Perhatikan bahwa partner dapat memilih untuk menampilkan informasi harga dan ketersediaan tambahan untuk beberapa atau semua itinerari dalam feed yang diberikan jika mereka memilih.

Persyaratan default

Referensi GTFS Statis - semua persyaratan default diterapkan.

Praktik terbaik GTFS - ikuti praktik terbaik seolah-olah praktik tersebut wajib dilakukan.

Mengupload data GTFS - ikuti proses ini untuk mengupload data GTFS.

Pembaruan: Perhatikan bahwa setelah diupload, feed dapat diperbarui dengan mengikuti proses yang dijelaskan di sini. Secara umum, pembaruan feed ini dapat memakan waktu 2-3 hari untuk diterapkan sepenuhnya.

Persyaratan tambahan

Cakupan

• Satu feed GTFS harus mencakup satu negara atau sebagian negara. Perjalanan yang melintasi perbatasan negara harus disediakan dalam feed di seluruh benua yang terpisah. Jika feed GTFS mencakup area yang lebih besar dari negara, hubungi Tim Transportasi Perjalanan.
  • File dalam file zip GTFS harus tetap berukuran kurang dari 4 GB. File yang lebih besar dari ukuran ini biasanya merupakan tanda praktik yang buruk, seperti mengabaikan opsi kompresi yang ditawarkan oleh frequencies.txt atau fitur serupa. Hal ini dapat menyebabkan masalah selama pemrosesan. Jika Anda merasa memerlukan file yang lebih besar dari 4 GB, hubungi tim Travel Transport di [e-mail].
  • Data untuk seluruh periode pengoperasian layanan mendatang dalam feed GTFS harus diberikan dengan setiap pembaruan data GTFS. Segmentasi layanan berdasarkan jangka waktu yang berbeda tidak dapat diterima.
• Semua tanggal untuk operator tertentu harus ada dalam satu feed.

Terjemahan

• Terjemahan dapat diberikan menggunakan translations.txt dan akan diwajibkan di negara-negara tempat:
  • Informasi kepada pengguna dapat diberikan dalam skrip yang berbeda, atau dalam skrip selain Latin
  • Informasi kepada pengguna dapat diberikan dalam beberapa bahasa, atau jika entitas dapat menggunakan penamaan yang berbeda dalam bahasa tersebut (misalnya, Brussels/Brussel/Bruxelles)
• Entitas yang akan diterjemahkan
  • nama agensi/halte/rute
  • tanda tujuan/perhentian perjalanan

Nama rute, nama pendek perjalanan, dan jurusan

• Tanda jurusan harus diberikan untuk semua perjalanan baik di trips.txt (jika tanda jurusan tetap konsisten selama perjalanan) atau di stop_times.txt (jika tanda jurusan berubah selama tahap yang berbeda dalam perjalanan).
• Papan nama harus sesuai dengan informasi yang mungkin ditemukan pengguna di lokasi. Misalnya, papan jurusan yang ditampilkan di kendaraan atau di papan nama.
• Jika rute memiliki nama, nama tersebut harus diberikan sebagai long_name di routes.txt.
• Jika rute memiliki nomor atau ID alfanumerik tertentu yang berlaku untuk semua perjalanan di rute tersebut dan di kedua arah, ID tersebut harus diberikan sebagai short_name di routes.txt.
• Jika perjalanan dalam rute memiliki ID masing-masing (misalnya, nomor kereta), ID tersebut harus diberikan sebagai nama pendek perjalanan.
• Untuk layanan jarak jauh yang tidak memiliki nomor atau nama rute, memilih nama rute menjadi masalah. Pedoman umum dalam situasi seperti ini adalah kombinasi nama rute dan papan tujuan akan membantu pengguna mengidentifikasi kendaraan secara jelas. Misalnya, nama lembaga pengelola dapat digunakan sebagai nama rute, sedangkan tujuan perjalanan (jika ditampilkan di kendaraan) harus digunakan sebagai papan jurusan perjalanan.

Contoh

• Kereta Indian Railways Kamayani Express 11071 dari Mumbai ke Varanasi. Catatan: nomor 11071 mengidentifikasi perjalanan kereta tertentu dari Mumbai ke Varanasi, bukan rutenya sendiri.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Bus dari Buenos Aires ke Córdoba yang dioperasikan oleh Chevallier Bus. Catatan: Bus yang mengoperasikan layanan ini tidak menampilkan nama rute tertentu. Sebagai gantinya, nama lembaga pengelola dan tujuannya ditampilkan dengan jelas. Perjalanan tertentu ini tidak memiliki nomor/ID individu yang membedakannya dari perjalanan lain yang dioperasikan oleh agensi yang sama atau melayani rute yang sama. Dalam hal ini, Anda dapat menggunakan "Chevallier" sebagai nama lembaga transportasi umum (di agencies.txt) dan route_long_name (di routes.txt). Tujuan harus digunakan untuk papan penunjuk arah. trip_short_name harus tetap kosong.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

Waktu berhenti

arrival_time dan departure_time harus diberikan di stop_times.txt.

Struktur perjalanan

• Perjalanan jarak jauh yang melayani beberapa kota/area harus diberikan secara end-to-end tanpa segmentasi (misalnya, A->B->C, bukan [A->B,A->C,B->C]), dengan A, B, C adalah area kota. Misalnya, bus jarak jauh yang melakukan perjalanan dari Buenos Aires ke Córdoba, dengan perhentian di Rosario harus ditampilkan sebagai perjalanan dengan perhentian di ketiga kota ini, bukan sebagai tiga perjalanan “Buenos Aires - Rosario”, “Buenos Aires - Córdoba”, dan “Rosario - Córdoba”.
• Jika penyedia data tidak dapat memperoleh informasi tentang struktur perjalanan yang benar, perjalanan antar-kota yang tersegmentasi dapat diberikan berdasarkan kasus per kasus. Jika perjalanan antar-kota tersebut memiliki beberapa titik penjemputan atau pengantaran dalam satu kota (area kota), segmentasi perhentian ke perhentian tidak diizinkan — semua titik penjemputan dan semua titik pengantaran harus dicantumkan dalam satu perjalanan.

Struktur stasiun

Untuk stasiun besar yang memiliki beberapa peron/tempat parkir, hubungan stasiun-peron harus ditentukan dalam feed, dan tempat parkir/peron tertentu harus diidentifikasi melalui kolom platform_code di stops.txt. Kendaraan yang secara konsisten berangkat dari atau tiba di tempat parkir atau peron tertentu harus ditautkan ke tempat parkir atau peron tersebut di feed GTFS. Jika platform atau tempat keberangkatan atau kedatangan berubah pada hari/waktu keberangkatan yang berbeda, informasi ini dapat diberikan di GTFS realtime.

Lokasi stasiun/perhentian

• Untuk stasiun besar yang memiliki beberapa peron atau tempat parkir bus, lokasi stasiun harus ditetapkan ke lokasi pintu masuk pejalan kaki yang paling terlihat (jika stasiun memiliki bangunan atau struktur) atau ke lokasi area tunggu penumpang (untuk stasiun luar ruangan).
• Untuk halte yang lebih kecil di sisi jalan, lokasi halte harus ditetapkan ke lokasi tiang bus jika dapat diidentifikasi. Jika tiang bus tertentu tidak dapat diidentifikasi, lokasi harus ditempatkan di sisi jalan yang benar, dan di sekitar lokasi sebenarnya di sepanjang jalan (idealnya, dalam jarak 10 m) tempat kendaraan berhenti.

Ekstensi GTFS tambahan

Hanya diperlukan untuk partner yang ingin menampilkan informasi harga/ketersediaan dengan menerapkan API partner.

Ekstensi Penjualan Tiket Google Transit

• Partner harus menerapkan spesifikasi ekstensi Penjualan Tiket Google Transit yang merupakan subkumpulan ekstensi Penjualan Tiket GTFS.
• Kami memberlakukan persyaratan berikut pada ID Tiket:
  • ID tiket harus stabil (yaitu, diizinkan untuk berubah jarang, karena alasan yang baik). Jika ID tiket berubah, kompatibilitas mundur akan diperlukan (untuk periode minimum setidaknya 1 minggu).
  • Untuk menentukan parameter SegmentKey dalam permintaan API, ticketing_trip_id (di trips.txt) dan ticketing_stop_id (di ticketing_identifiers.txt) diperlukan. Penggantian pada stop_sequence adalah tidak didukung karena tidak stabil.

GTFS-Tarif v1

Referensi GTFS Statis menentukan file fare_attributes.txt dan fare_rules.txt opsional. Jika partner terintegrasi dengan partner API, file ini tidak boleh diberikan.