GTFS gereksinimleri

İş ortağı, tüm standart spesifikasyonların yanı sıra aşağıda listelenen spesifikasyonları karşılayan bir GTFS feed'i sağlamalıdır. Bu feed, iş ortağının göstermek istediği tüm seyahat planlarını kapsamalıdır. Bu bilgileri sağladığınızda Google'da program ve rota bilgileri gösterilir. İş ortaklarının, isterlerse sağlanan feed'deki seyahat planlarının bir kısmı veya tamamı için ek fiyat ve stok durumu bilgilerini göstermeyi tercih edebileceğini unutmayın.

Varsayılan şartlar

Statik GTFS referansı: Tüm varsayılan koşullar uygulanır.

GTFS ile ilgili en iyi uygulamalar: Lütfen en iyi uygulamaları zorunluymuş gibi uygulayın.

GTFS feed'lerini yükleme: GTFS feed'ini yüklemek için lütfen bu süreci uygulayın.

Güncellemeler: Feed'ler yüklendikten sonra burada açıklanan işlem uygulanarak güncellenebilir. Genel olarak bu feed güncellemelerinin tam olarak uygulanması 2-3 gün sürebilir.

Diğer şartlar

Kapsam

  • Tek bir GTFS feed'i tek bir ülkeyi veya bir ülkenin bir bölümünü kapsamalıdır. Ülke sınırlarını aşan geziler, kıta genelinde ayrı feed'lerde sağlanmalıdır. Bir GTFS feed'i bir ülkeden daha büyük bir alanı kapsıyorsa lütfen Seyahat Taşımacılığı Ekibi ile iletişime geçin.
    • GTFS zip dosyasındaki dosyaların boyutu 4 GB'tan küçük olmalıdır. Bundan daha büyük dosyalar genellikle frequencies.txt tarafından sunulan sıkıştırma seçeneklerinin veya benzer özelliklerin göz ardı edilmesi gibi kötü uygulamaların bir işaretidir. Bu durum, işleme sırasında sorunlara neden olabilir. 4 GB'tan büyük dosyalara ihtiyacınız olduğunu düşünüyorsanız lütfen transport-help@google.com adresinden Seyahat ve Ulaşım Ekibi ile iletişime geçin.
    • GTFS feed'indeki hizmetlerin gelecekteki tüm çalışma dönemine ait veriler, GTFS verilerinin her güncellemesinde sağlanmalıdır. Hizmetlerin farklı zaman aralıklarına göre segmentlere ayrılması kabul edilmez.
  • Belirli bir operatörün tüm tarihleri tek bir feed'de yer almalıdır.

Çeviriler

  • Çeviriler translations.txt kullanılarak sağlanabilir ve şu ülkelerde zorunlu olacaktır:
    • Kullanıcılara yönelik bilgiler farklı alfabelerle veya Latin alfabesi dışında bir alfabeyle sağlanabilir.
    • Kullanıcılara bilgiler birden fazla dilde sağlanabilir veya kuruluşlar bu dillerde farklı adlandırmalar kullanabilir (ör.Brüksel/Brussel/Bruxelles).
  • Çevrilecek öğeler
    • ajans/durak/rota adları
    • seyahat/durak tabelaları

Rota adları, gezi kısa adları ve hedef tabelaları

  • Tüm yolculuklar için trips.txt (yolculuk boyunca hedef tabelası değişmiyorsa) veya stop_times.txt (yolculuğun farklı aşamalarında hedef tabelası değişiyorsa) biçiminde hedef tabelası sağlanmalıdır.
  • Tabela, kullanıcıların yerde bulabileceği bilgilerle eşleşmelidir. Örneğin, araçta veya tabelalarda gösterilen yön tabelaları.
  • Bir rotanın adı varsa routes.txt içinde long_name olarak sağlanmalıdır.
  • Bir rotanın, bu rotadaki tüm yolculuklar ve her iki yön için geçerli olan belirli bir sayısı veya alfasayısal tanımlayıcısı varsa bu tanımlayıcı, routes.txt içinde short_name olarak sağlanmalıdır.
  • Rottaki gezilerin ayrı tanımlayıcıları (ör. tren numaraları) varsa bu tanımlayıcılar, gezi kısa adları olarak sağlanmalıdır.
  • Rota numarası veya adı olmayan uzun mesafeli hizmetlerde rota adı seçmek sorunlu hale gelir. Bu gibi durumlarda genel kural, rota adı ile hedef tabelanın kombinasyonunun kullanıcının aracı net bir şekilde tanımlamasına yardımcı olmasıdır. Örneğin, işleten ajansın adı rota adı olarak kullanılabilir. Seyahatin varış noktası (araçta gösteriliyorsa) ise seyahat hedefi olarak kullanılmalıdır.

Örnekler

  • Mumbai'den Varanasi'ye giden Indian Railways Kamayani Express Treni 11071. Not: 11071 numarası, rotayı değil, Mumbai'den Varanasi'ye yapılan belirli bir tren yolculuğunu tanımlar.
    • routes.txt:
      • short_name: <empty>
      • long_name: Kamayani Express
    • trips.txt:
      • trip_short_name: 11071
      • headsign: Varanasi
  • Chevallier Bus tarafından işletilen Buenos Aires-Córdoba otobüsü. Not: Bu hizmeti veren otobüs belirli bir rota adı göstermez. Bunun yerine, işleten ajansın adını ve varış noktasını belirgin bir şekilde gösterir. Bu gezi, aynı ajans tarafından düzenlenen veya aynı rotada hizmet veren diğer gezilerden ayıran bir numaraya/tanımlayıcıya sahip değil. Bu durumda, hem ajans adı (agencies.txt içinde) hem de rota uzun adı (routes.txt içinde) olarak "Chevallier" kullanılması kabul edilebilir. Hedef, yön tabelası için kullanılmalıdır. trip_short_name boş kalmalıdır.
    • routes.txt:
      • short_name: <empty>
      • long_name: Chevallier
    • trips.txt:
      • trip_short_name: <empty>
      • headsign: Córdoba

Durdurma zamanları

Hem arrival_time hem de departure_time, stop_times.txt biçiminde sağlanmalıdır.

Gezi yapısı

  • Birden fazla şehre/bölgeye hizmet veren uzun mesafeli yolculuklar,uçtan uca ve segmentlere ayrılmadan sağlanmalıdır (ör.A->B->C, [A->B,A->C, B->C] şeklinde olmamalıdır). Burada A, B ve C şehir bölgeleridir. Örneğin, Buenos Aires'ten Córdoba'ya giden ve Rosario'da duran uzun mesafeli bir otobüs, "Buenos Aires - Rosario", "Buenos Aires - Córdoba" ve "Rosario - Córdoba" olmak üzere üç yolculuk olarak değil, bu üç şehirde durakları olan bir yolculuk olarak gösterilmelidir.
  • Veri sağlayıcının doğru gezi yapısıyla ilgili bilgileri alamadığı durumlarda, şehirler arası geziler bölümlere ayrılmış şekilde sunulabilir. Şehirler arası bu tür yolculuklarda bir şehir (şehir alanı) içinde birden fazla teslim alma veya bırakma noktası varsa duraktan durağa segmentasyona izin verilmez. Tüm teslim alma noktaları ve tüm bırakma noktaları tek bir yolculukta listelenmelidir.

İstasyon yapıları

Birden fazla platformu/peronu olan büyük istasyonlar için istasyon-platform ilişkileri feed'de belirtilmeli ve stops.txt içindeki platform_code alanı aracılığıyla belirli peronlar/platformlar tanımlanmalıdır. Belirli bir perondan veya platformdan düzenli olarak kalkan ya da belirli bir perona veya platforma düzenli olarak varan araçlar, GTFS feed'inde ilgili perona veya platforma bağlanmalıdır. Kalkış veya varış platformu ya da peronu farklı kalkış günlerinde/saatlerinde değişiyorsa bu bilgi GTFS Gerçek Zamanlı'da sağlanabilir.

İstasyon/durak konumları

  • Birden fazla platformu veya peronu olan büyük istasyonlarda, istasyonun konumu en belirgin yaya girişinin (istasyonun binası veya yapısı varsa) ya da yolcu bekleme alanının (açık hava istasyonları için) konumuna ayarlanmalıdır.
  • Yol kenarındaki daha küçük duraklarda, durak yeri belirlenebiliyorsa otobüs direğinin bulunduğu yer olarak ayarlanmalıdır. Belirli bir otobüs direği tanımlanamadığında konum, yolun doğru tarafına ve araçların durduğu gerçek konumun yakınına (ideal olarak 10 metre içinde) yerleştirilmelidir.

Ek GTFS uzantıları

Yalnızca fiyat/stok durumu bilgilerini iş ortağı API'lerini uygulayarak göstermek isteyen iş ortakları için gereklidir.

Google Transit bilet işlemleri uzantısı

  • İş ortakları, GTFS-Ticketing uzantısının bir alt kümesi olan Google Transit bilet işlemleri uzantısı spesifikasyonunu uygulamalıdır.
  • Bilet kimlikleri için aşağıdaki koşulları uygularız:
    • Bilet kimlikleri sabit olmalıdır (ör. iyi bir nedenden dolayı nadiren değiştirilmesine izin verilir). Bilet kimliklerinin değiştiği durumlarda geriye dönük uyumluluk (en az 1 hafta süreyle) gereklidir.
    • API isteklerindeki SegmentKey parametrelerini belirlemek için ticketing_trip_id (trips.txt içinde) ve ticketing_stop_id (ticketing_identifiers.txt içinde) gereklidir. stop_sequence üzerinde yedekleme, kararlı olmadığı için desteklenmez.

GTFS-Fares v1

Statik GTFS referansı, isteğe bağlı fare_attributes.txt ve fare_rules.txt dosyalarını belirtir. Bir iş ortağı, iş ortağı API'leriyle entegrasyon yaparsa bu dosyalar sağlanmamalıdır.