GTFS gereksinimleri

İş ortağı, tüm standart spesifikasyonları ve aşağıda listelenenleri 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 bilgilerin sağlanması, tarife ve rota bilgilerinin Google'da görünmesini sağlar. İş ortakları, isterlerse sağlanan feed'de seyahat planlarının bazıları veya tamamı için ek fiyat ve müsaitlik durumu bilgileri gösterebilir.

Varsayılan gereksinimler

Statik GTFS referansı: Tüm varsayılan gereksinimler uygulanır.

GTFS En iyi uygulamaları - Lütfen en iyi uygulamaları gerekliymiş gibi takip edin.

GTFS feed'lerini yükleme - GTFS feed'ini yüklemek için lütfen bu işlemi uygulayın.

Güncellemeler: Yüklenen feed'lerin, burada açıklanan süreç izlenerek güncellenebileceğini unutmayın. Bu feed güncellemelerinin tam olarak uygulanması genellikle 2-3 gün sürebilir.

Diğer şartlar

Kapsam

• Tek bir GTFS feed'i tek bir ülkeyi veya bir ülkenin bir kısmını kapsamalıdır. Ülke sınırları arası seyahatler, kıta genelinde ayrı feed'ler halinde sağlanmalıdır. GTFS feed'i bir ülkeden daha büyük bir konuyu kapsıyorsa lütfen Seyahat Taşımacılık Ekibi ile iletişime geçin.
  • GTFS zip dosyasındaki dosyalar 4 GB'tan küçük olmalıdır. Bundan büyük dosyalar genellikle kötü uygulamalara işaret eder. Örneğin, frequencies.txt tarafından sunulan sıkıştırma seçeneklerini veya benzer özelliklerin göz ardı edilmesi. Bu, 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 [e-mail] adresinden Travel Transport ekibiyle iletişime geçin.
  • Her GTFS veri güncellemesiyle birlikte bir GTFS feed'i içinde hizmetlerin gelecekteki çalışma döneminin tamamına ait veriler sağlanmalıdır. Hizmetlerin farklı zaman aralıklarına göre segmentlere ayrılması kabul edilmez.
• Belirli bir operatöre ilişkin tüm tarihler tek bir feed'de yer almalıdır.

Çeviriler

• Çeviriler translations.txt aracılığıyla sağlanabilir ve aşağıdaki ülkelerde gereklidir:
  • Kullanıcılara farklı alfabeler kullanılarak veya Latince dışında alfabeler kullanılarak sağlanabilir
  • Kullanıcılara bilgiler birden çok dilde sağlanabilir veya tüzel kişiler bu dillerde farklı adlar kullanabilir (ör. Brüksel/Brüksel/Bruxelles)
• Çevrilecek varlıklar
  • acente/durma/güzergah adları
  • yol/durdurma tabelaları

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

• Tüm yolculuklar için trips.txt (yol işareti boyunca tutarlı kalırsa) veya stop_times.txt (yolculuğunun farklı aşamalarında kafa işareti değişirse) için baş işaretleri verilmelidir.
• Başlıkların, kullanıcıların yerde bulabilecekleri bilgilerle eşleşmesi gerekir. Örneğin, araçta veya tabelalarda baş işaretleri gösterilebilir.
• Bir rotanın adı varsa routes.txt içinde long_name olarak sağlanmalıdır.
• Bir rota, söz konusu rota üzerindeki tüm yolculuklar için ve her iki yöndeki yolculuklar için geçerli olan belirli bir numaraya veya alfanümerik tanımlayıcıya sahipse bu tanımlayıcı, routes.txt özelliğinde kısa_ad olarak sağlanmalıdır.
• Rota üzerindeki yolculukların bağımsız tanımlayıcıları varsa (örneğin, tren numaraları), bu tür tanımlayıcılar seyahat kısa adları olarak sağlanmalıdır.
• Rota numaraları veya adları olmayan uzun mesafe hizmetler için rota adı seçmek sorunlu hale gelir. Bu tür durumlarda genel kural, rota adı ve başlık işaretinin birlikte kullanılmasıdır. Bu kombinasyon, kullanıcının aracı açık bir şekilde tanımlamasına yardımcı olur. Örneğin, rota adı olarak, işleten kurumun adı kullanılabilirken yolculuğun hedefi (araçta gösteriliyorsa) işaret işareti olarak kullanılmalıdır.

Örnekler

• Mumbai'den Varanasi'ye 11071 numaralı Hindistan Demiryolları Kamayani Ekspres Treni. Not: 11071 numarası, Mumbai'den Varanasi'ye belirli bir tren seyahatini tanımlar, rotanın kendisini değil.
  • routes.txt:
    • kısa_ad: <boş>
    • uzun_ad: Kamayani Express
  • trips.txt:
    • trip_short_name: "11071"
    • başlık işareti: Varanasi
• Buenos Aires'ten Córdoba'ya giden otobüs, Chevallier Bus tarafından işletilir. Not: Bu hizmeti çalıştıran otobüste belirli bir rota adı gösterilmez. Bunun yerine, faaliyet gösterdiği kurumun adını ve hedefini belirgin bir şekilde gösterir. Bu seyahatin, aynı acente tarafından yürütülen veya aynı rotaya hizmet veren diğer seyahatlerden ayırt edilmesini sağlayan özel bir numarası/tanımlayıcısı yoktur. Bu durumda hem ajans adı (agencies.txt içinde) hem de rota (routes.txt için) olarak "Chevallier" kullanılabilir. trip_short_name alanı boş bırakılmalıdır.
  • routes.txt:
    • kısa_ad: <boş>
    • long_name: "Şövalye"
  • trips.txt:
    • trip_short_name: <boş>
    • başlık işareti: Córdoba

Durdurulma zamanları

stop_times.txt için hem varış_saati hem de çıkış_saati belirtilmelidir.

Gezi yapısı

• Birden fazla şehre/bölgeye hizmet veren uzun mesafe seyahatleri,segmentasyon yapılmadan uçtan uca sağlanmalıdır (ör.A,B, C şehir alanlarıdır (ör. A->B, A->C, B->C] değil). Örneğin, Buenos Aires'ten Córdoba'ya giden uzun mesafeli bir otobüs, Rosario'da duraklı bir yolculuk olarak gösterilmelidir. "Buenos Aires - Rosario", "Buenos Aires - Córdoba" ve "Rosario - Córdoba" şeklinde üç yolculuk olarak değil, bu üç şehirde duraklı bir yolculuk olarak gösterilmelidir.
• Veri sağlayıcının doğru seyahat yapısı hakkında bilgi edinemediği durumlarda, bölümlere göre ayrılmış şehirler arası seyahatler tek tek sağlanabilir. Bu tür bir şehirden şehre seyahatlerde bir şehirde (şehir bölgesi) birden fazla alma veya bırakma noktası varsa durak durak segmentasyonuna izin verilmez. Tüm teslim noktaları ve tüm bırakma noktaları tek bir yolculukta listelenmelidir.

İstasyon yapıları

Birden fazla platformu/boyunu olan büyük istasyonlar için istasyon-platform ilişkileri feed'de belirtilmeli ve belirli körfezler/platformlar stops.txt içindeki platform_code alanı aracılığıyla tanımlanmalıdır. Sürekli olarak belirli bir koydan veya platformdan kalkan/gelen araçlar, GTFS feed'inde bu körfeze veya platforma bağlanmalıdır. Kalkış/varış platformu veya körfezi farklı kalkış günlerinde/saatlerinde değişirse bu bilgiler GTFS gerçek zamanlı olarak sağlanabilir.

İstasyon/durma konumları

• Birden fazla platformu veya körfezi olan büyük istasyonlarda istasyonun konumu, en belirgin yaya girişinin konumuna (istasyonda veya bir yapıya sahipse) ya da yolcu bekleme alanına (açık hava istasyonları için) ayarlanmalıdır.
• Yol kenarındaki daha küçük duraklar için durak konumu, otobüs direğinin tanımlanabilmesi durumunda olduğu yere ayarlanmalıdır. Belirli bir otobüs direği tanımlanamıyorsa konum, yolun doğru tarafına ve aracın duracağı yol boyunca gerçek konumun yakınına (ideal olarak 10 metre) yerleştirilmelidir.

Ek GTFS uzantıları

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

Google Transit Ticketing uzantısı

• İş ortakları, GTFS-Ticketing uzantısının bir alt kümesi olan Google Transit Ticketing uzantısı spesifikasyonunu uygulamalıdır.
• Bilet işlemleri kimliklerine aşağıdaki şartları uygularız:
  • Bilet işlemleri kimlikleri sabit olmalıdır (yani iyi bir nedenle, nadir olarak değişmelerine izin verilmelidir). Kayıt kimliklerinin değiştiği durumlarda geriye dönük uyumluluk (en az 1 haftalık süre boyunca) gerekir.
  • API isteklerindeki SegmentKey parametrelerini belirlemek için ticketing_trip_id (trips.txt içinde) ve ticketing_stop_id (ticketing_identifiers.txt için) gereklidir. stop_sequence yedeği, kararlı olmadığı için desteklenmiyor.

GTFS-Ücretleri 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 entegre olursa bu dosyalar sağlanmamalıdır.