Persyaratan GTFS

Partner harus memberikan data GTFS yang memenuhi semua spesifikasi standar, ditambah yang tercantum di bawah. Feed ini harus mencakup semua itinerari yang ingin ditampilkan oleh partner. Memberikan informasi ini akan memungkinkan informasi jadwal dan rute muncul di Google. Perhatikan bahwa partner dapat memilih untuk menampilkan informasi harga dan ketersediaan tambahan untuk beberapa atau semua itinerari dalam feed yang disediakan jika mereka mau.

Persyaratan default

Referensi GTFS statis - semua persyaratan default diterapkan.

Praktik Terbaik GTFS - ikuti praktik terbaik seolah-olah praktik tersebut diwajibkan.

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

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

Persyaratan tambahan

Cakupan

• Satu data GTFS harus mencakup satu negara atau sebagian negara. Perjalanan yang melintasi perbatasan negara harus diberikan di feed terpisah di seluruh benua. Jika data GTFS mencakup data yang lebih besar dari suatu negara, hubungi Tim Transportasi Perjalanan.
  • File dalam file ZIP GTFS harus tetap berukuran di bawah 4 GB. File yang lebih besar dari 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 keseluruhan periode operasi layanan di masa mendatang dalam feed GTFS harus diberikan bersama setiap pembaruan data GTFS. Segmentasi layanan menurut jangka waktu yang berbeda tidak dapat diterima.
• Semua tanggal untuk operator tertentu harus berada dalam satu feed.

Terjemahan

• Terjemahan dapat diberikan melalui translations.txt dan akan diperlukan di negara tempat:
  • Informasi kepada pengguna dapat diberikan dalam skrip yang berbeda, atau dalam skrip selain bahasa 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 perusahaan/perhentian/rute
  • jurusan perjalanan/perhentian

Nama rute, nama pendek, dan jurusan perjalanan

• Jurusan harus diberikan untuk semua perjalanan dalam trips.txt (jika layar jurusan tetap konsisten selama perjalanan) atau di stop_times.txt (jika jurusan berubah selama tahap perjalanan yang berbeda).
• Jurusan harus sesuai dengan informasi yang mungkin ditemukan pengguna di lapangan. Misalnya, jurusan yang ditampilkan di kendaraan atau di papan reklame.
• Jika rute memiliki nama, nama tersebut harus diberikan sebagai long_name di routes.txt.
• Jika rute memiliki nomor tertentu atau ID alfanumerik yang berlaku untuk semua perjalanan pada rute tersebut dan di kedua arah, rute tersebut harus diberikan sebagai short_name di routes.txt.
• Jika perjalanan dalam rute memiliki ID individual (misalnya, nomor kereta), ID tersebut harus diberikan sebagai nama pendek perjalanan.
• Untuk layanan jarak jauh yang tidak memiliki nomor atau nama rute, pemilihan nama rute akan menjadi masalah. Pedoman umum dalam situasi tersebut adalah kombinasi nama rute dan jurusan akan membantu pengguna mengidentifikasi kendaraan dengan jelas. Misalnya, nama perusahaan yang beroperasi dapat digunakan sebagai nama rute, sedangkan tujuan perjalanan (jika ditampilkan di kendaraan) harus digunakan sebagai jurusan perjalanan.

Contoh

• Indian Railways Kamayani Express Train 11071 dari Mumbai ke Varanasi. Catatan: nomor 11071 mengidentifikasi perjalanan kereta tertentu dari Mumbai ke Varanasi, bukan rute itu sendiri.
  • routes.txt:
    • short_name: <kosong>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • jurusan: Varanasi
• Bus dari Buenos Aires ke Córdoba dioperasikan dengan Bus Chevallier. Catatan: Bus yang mengoperasikan layanan ini tidak menampilkan nama rute tertentu. Sebagai gantinya, profil ini menampilkan nama agensi operasi dan tujuannya dengan jelas. Perjalanan khusus ini tidak memiliki nomor/ID individual yang membedakannya dari perjalanan lain yang dioperasikan oleh perusahaan transportasi umum yang sama atau yang melayani rute yang sama. Dalam hal ini, Anda dapat menggunakan “Chevallier” sebagai nama perusahaan transportasi umum (dalam agencies.txt) dan nama long_name rute (dalam routes.txt). Tujuan harus digunakan untuk jurusan. trip_short_name harus tetap kosong.
  • routes.txt:
    • short_name: <kosong>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <kosong>
    • jurusan: Córdoba

Waktu berhenti

arrival_time dan arrival_time harus diberikan dalam stop_times.txt.

Struktur perjalanan

• Perjalanan jarak jauh yang melayani beberapa kota/area harus diberikan secara menyeluruh 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 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 kota ke kota yang tersegmentasi dapat diberikan berdasarkan kasus per kasus. Jika perjalanan kota ke kota tersebut memiliki beberapa titik penjemputan atau pengantaran dalam suatu 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 platform/bay, hubungan stasiun-platform harus ditentukan dalam feed, dan bay/platform spesifik harus diidentifikasi melalui kolom platform_code di stops.txt. Kendaraan yang secara konsisten berangkat dari/tiba di teluk atau platform tertentu harus ditautkan ke teluk atau platform tersebut di data GTFS. Jika platform keberangkatan/kedatangan atau teluk berubah pada hari/waktu keberangkatan yang berbeda, informasi ini dapat diberikan di realtime.

Lokasi stasiun/pemberhentian

• Untuk stasiun besar yang memiliki beberapa platform atau teluk, lokasi stasiun harus ditetapkan ke lokasi pintu masuk pejalan kaki yang paling menonjol (jika stasiun memiliki bangunan atau struktur) atau ke lokasi area tunggu penumpang (untuk stasiun outdoor).
• Untuk perhentian yang lebih kecil di sisi jalan, lokasi perhentian harus disetel ke lokasi kutub bus jika satu perhentian 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 bagi partner yang ingin menampilkan informasi harga/ketersediaan dengan menerapkan API partner.

Perluasan Penjualan Tiket Google Transit

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

Tarif GTFS v1

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