जीटीएफ़एस के लिए ज़रूरी शर्तें

पार्टनर को ऐसा GTFS फ़ीड उपलब्ध कराना चाहिए जो सभी स्टैंडर्ड स्पेसिफ़िकेशन के साथ-साथ यहां दी गई शर्तों को भी पूरा करता हो. इस फ़ीड में, यात्रा की वे सभी योजनाएं शामिल होनी चाहिए जिन्हें पार्टनर को दिखाना है. यह जानकारी देने से, Google पर शेड्यूल और रास्ते की जानकारी दिखाई जा सकेगी. ध्यान दें कि अगर कोई पार्टनर चाहे, तो वह फ़ीड में दी गई कुछ या सभी यात्रा की योजनाओं के लिए, कीमत और उपलब्धता की ज़्यादा जानकारी दिखा सकता है.

डिफ़ॉल्ट ज़रूरी शर्तें

जीटीएफ़एस स्टैटिक रेफ़रंस - सभी डिफ़ॉल्ट ज़रूरी शर्तें लागू होती हैं.

जीटीएफ़एस के सबसे सही तरीके - कृपया सबसे सही तरीकों का पालन करें.

जीटीएफ़एस फ़ीड अपलोड करना - जीटीएफ़एस फ़ीड अपलोड करने के लिए, कृपया यह तरीका अपनाएं.

अपडेट: ध्यान दें कि फ़ीड अपलोड करने के बाद, उन्हें यहां बताई गई प्रोसेस के मुताबिक अपडेट किया जा सकता है. आम तौर पर, फ़ीड अपडेट होने में दो से तीन दिन लग सकते हैं.

अन्य ज़रूरी शर्तें

दायरा

एक GTFS फ़ीड में, किसी एक देश या उसके किसी हिस्से की जानकारी होनी चाहिए. एक देश से दूसरे देश की यात्राओं की जानकारी, पूरे महाद्वीप के लिए अलग-अलग फ़ीड में देनी होगी. अगर कोई GTFS फ़ीड किसी देश से ज़्यादा इलाके को कवर करता है, तो कृपया यात्रा और परिवहन टीम से संपर्क करें.
- GTFS की ZIP फ़ाइल में मौजूद फ़ाइलों का साइज़ 4 जीबी से कम होना चाहिए. इससे ज़्यादा साइज़ वाली फ़ाइलें, आम तौर पर खराब क्वालिटी की होती हैं. जैसे, frequencies.txt या इसी तरह की अन्य सुविधाओं के ज़रिए फ़ाइल के साइज़ को कम करने के विकल्पों को अनदेखा करना. इससे प्रोसेसिंग के दौरान समस्याएं आ सकती हैं. अगर आपको लगता है कि आपको 4 जीबी से बड़ी फ़ाइलों की ज़रूरत है, तो कृपया यात्रा और परिवहन टीम से संपर्क करें. इसके लिए, transport-help@google.com पर जाएं.
- जीटीएफ़एस फ़ीड में, सेवाओं के आने वाले समय के पूरे डेटा को GTFS डेटा के हर अपडेट के साथ उपलब्ध कराया जाना चाहिए. अलग-अलग समयावधि के हिसाब से सेवाओं का सेगमेंटेशन स्वीकार नहीं किया जाता.
किसी ऑपरेटर की सभी तारीखें, एक ही फ़ीड में शामिल होनी चाहिए.

अनुवाद

translations.txt का इस्तेमाल करके अनुवाद उपलब्ध कराए जा सकते हैं. साथ ही, इन देशों में अनुवाद उपलब्ध कराना ज़रूरी होगा:
- उपयोगकर्ताओं को जानकारी अलग-अलग स्क्रिप्ट में दी जा सकती है. इसके अलावा, लैटिन के अलावा किसी अन्य स्क्रिप्ट में भी जानकारी दी जा सकती है
- उपयोगकर्ताओं को जानकारी कई भाषाओं में दी जा सकती है. इसके अलावा, जहां इकाइयां उन भाषाओं में अलग-अलग नाम इस्तेमाल कर सकती हैं (जैसे, ब्रुसेल्स/ब्रसल/ब्रसेल्स)
इन इकाइयों का अनुवाद करना है
- एजेंसी/स्टॉप/रास्ते के नाम
- यात्रा/स्टॉप के हेडसाइन

रास्ते के नाम, यात्रा के छोटे नाम, और हेडसाइन

सभी यात्राओं के लिए हेडसाइन की जानकारी देनी होगी. इसके लिए, trips.txt फ़ील्ड का इस्तेमाल किया जा सकता है. ऐसा तब करें, जब यात्रा के दौरान हेडसाइन एक जैसा रहता हो. इसके अलावा, stop_times.txt फ़ील्ड का इस्तेमाल तब करें, जब यात्रा के अलग-अलग चरणों के दौरान हेडसाइन बदलता हो.
हेडसाइन में दी गई जानकारी, उपयोगकर्ताओं को असल जगह पर दिखने वाली जानकारी से मेल खानी चाहिए. उदाहरण के लिए, वाहन या साइनबोर्ड पर दिखाए गए हेडसाइन.
अगर किसी रास्ते का नाम है, तो उसे routes.txt में long_name के तौर पर दिया जाना चाहिए.
जब किसी रूट का कोई खास नंबर या अल्फ़ान्यूमेरिक आइडेंटिफ़ायर होता है, जो उस रूट पर दोनों दिशाओं में होने वाली सभी यात्राओं पर लागू होता है, तो उसे routes.txt में short_name के तौर पर दिया जाना चाहिए.
अगर रूट पर मौजूद यात्राओं के लिए अलग-अलग पहचानकर्ता हैं (उदाहरण के लिए, ट्रेन नंबर), तो इन पहचानकर्ताओं को यात्रा के छोटे नाम के तौर पर दिया जाना चाहिए.
लंबी दूरी की उन सेवाओं के लिए रूट का नाम चुनना मुश्किल हो जाता है जिनके रूट नंबर या नाम नहीं होते. ऐसी स्थितियों में सामान्य दिशा-निर्देश यह है कि रूट के नाम और हेडसाइन के कॉम्बिनेशन से, उपयोगकर्ता को वाहन की पहचान करने में मदद मिलनी चाहिए. उदाहरण के लिए, रूट के नाम के तौर पर बस चलाने वाली एजेंसी के नाम का इस्तेमाल किया जा सकता है. वहीं, यात्रा की मंज़िल (अगर वाहन पर दिखाई गई है) को यात्रा के हेडसाइन के तौर पर इस्तेमाल किया जाना चाहिए.

उदाहरण

मुंबई से वाराणसी जाने वाली भारतीय रेल की कामायनी एक्सप्रेस ट्रेन 11071. ध्यान दें: नंबर 11071, मुंबई से वाराणसी तक की किसी खास ट्रेन यात्रा की पहचान करता है. यह रूट की पहचान नहीं करता.
- routes.txt:
  - short_name: <empty>
  - long_name: कामायनी एक्सप्रेस
- trips.txt:
  - trip_short_name: 11071
  - हेडसाइन: वाराणसी
ब्यूनस आयर्स से कॉर्डोबा के लिए, शेवेलियर बस की बस. ध्यान दें: इस सेवा के लिए इस्तेमाल की गई बस पर, किसी खास रास्ते का नाम नहीं दिखता. इसके बजाय, इसमें साफ़ तौर पर ऑपरेटिंग एजेंसी का नाम और उसके डेस्टिनेशन की जानकारी दिखती है. इस यात्रा का कोई ऐसा नंबर/आइडेंटिफ़ायर नहीं है जो इसे एक ही एजेंसी की अन्य यात्राओं या एक ही रास्ते पर चलने वाली यात्राओं से अलग करता हो. ऐसे मामले में, एजेंसी के नाम (agencies.txt) और रूट के लंबे नाम (routes.txt) के तौर पर "Chevallier" का इस्तेमाल किया जा सकता है. हेडसाइन के लिए मंज़िल का इस्तेमाल किया जाना चाहिए. trip_short_name फ़ील्ड की वैल्यू खाली होनी चाहिए.
- routes.txt:
  - short_name: <empty>
  - long_name: Chevallier
- trips.txt:
  - trip_short_name: <empty>
  - हेडसाइन: कॉरडोबा

बंद होने का समय

stop_times.txt में arrival_time और departure_time, दोनों की वैल्यू दी जानी चाहिए.

यात्रा का स्ट्रक्चर

लंबी दूरी की यात्राओं के लिए, एक से ज़्यादा शहरों/इलाकों में सेवा देने वाली यात्राओं को बिना किसी सेगमेंट के शुरू से आखिर तक उपलब्ध कराया जाना चाहिए.उदाहरण के लिए, A->B->C [A->B,A->C,B->C] नहीं है. यहां A, B, C शहर के इलाके हैं. उदाहरण के लिए, ब्यूनस आयर्स से कोर्डबा जाने वाली लंबी दूरी की बस, जो रोसारियो में रुकती है, उसे इन तीन शहरों में रुकने वाली यात्रा के तौर पर दिखाया जाना चाहिए. न कि तीन यात्राओं के तौर पर, जैसे कि “ब्यूनस आयर्स - रोसारियो”, “ब्यूनस आयर्स - कोर्डबा”, और “रोसारियो - कोर्डबा”
अगर डेटा उपलब्ध कराने वाली कंपनी को यात्रा के सही स्ट्रक्चर के बारे में जानकारी नहीं मिल पाती है, तो शहर-शहर के हिसाब से यात्रा के अलग-अलग सेगमेंट की जानकारी, मामले के आधार पर दी जा सकती है. अगर एक शहर से दूसरे शहर के बीच की जाने वाली यात्राओं में, एक ही शहर में कई पिक-अप या ड्रॉप-ऑफ़ पॉइंट हैं, तो स्टॉप-टू-स्टॉप सेगमेंटेशन की अनुमति नहीं है. सभी पिक-अप पॉइंट और सभी ड्रॉप-ऑफ़ पॉइंट, एक ही यात्रा में शामिल होने चाहिए.

स्टेशन के स्ट्रक्चर

बड़े स्टेशनों में कई प्लैटफ़ॉर्म/बे होते हैं. ऐसे में, फ़ीड में स्टेशन-प्लैटफ़ॉर्म के संबंध की जानकारी देना ज़रूरी है. साथ ही, stops.txt में मौजूद platform_code फ़ील्ड के ज़रिए, बे/प्लैटफ़ॉर्म की पहचान करना ज़रूरी है. जो वाहन किसी खास बे या प्लैटफ़ॉर्म से लगातार रवाना होते हैं या वहां पहुंचते हैं उन्हें GTFS फ़ीड में उस बे या प्लैटफ़ॉर्म से लिंक किया जाना चाहिए. अगर अलग-अलग दिनों/समय पर ट्रेन के रवाना होने या पहुंचने का प्लैटफ़ॉर्म या बे बदलता है, तो यह जानकारी GTFS रीयलटाइम में दी जा सकती है.

स्टेशन/स्टॉप की जगह की जानकारी

बड़े स्टेशनों के लिए, स्टेशन की जगह को उसके सबसे प्रमुख पैदल यात्री वाले प्रवेश द्वार की जगह पर सेट किया जाना चाहिए. ऐसा तब करना चाहिए, जब स्टेशन में कोई इमारत या स्ट्रक्चर हो. अगर स्टेशन खुले में है, तो स्टेशन की जगह को यात्रियों के इंतज़ार करने की जगह पर सेट किया जाना चाहिए. बड़े स्टेशनों में कई प्लैटफ़ॉर्म या बे होते हैं.
सड़क के किनारे मौजूद छोटे स्टॉप के लिए, स्टॉप की जगह की जानकारी को बस के पोल की जगह की जानकारी पर सेट किया जाना चाहिए. ऐसा तब किया जाना चाहिए, जब बस के पोल की पहचान की जा सके. जब किसी बस पोल की पहचान नहीं की जा सकती, तो लोकेशन को सड़क की सही साइड पर और सड़क के किनारे मौजूद उस जगह के आस-पास रखना चाहिए जहां वाहन रुकता है. आम तौर पर, यह दूरी 10 मीटर के अंदर होनी चाहिए.

अन्य GTFS एक्सटेंशन

यह सिर्फ़ उन पार्टनर के लिए ज़रूरी है जो पार्टनर एपीआई लागू करके, कीमत/उपलब्धता की जानकारी दिखाना चाहते हैं.

Google Transit Ticketing एक्सटेंशन

पार्टनर को Google Transit Ticketing extension specification लागू करना चाहिए. यह GTFS-Ticketing extension का सबसेट है.
हम टिकट के आईडी के लिए ये ज़रूरी शर्तें लागू करते हैं:
- टिकट आईडी एक जैसे होने चाहिए. इसका मतलब है कि उन्हें कभी-कभी ही बदला जाना चाहिए और इसके लिए कोई वाजिब वजह होनी चाहिए. टिकटिंग आईडी बदलने पर, पिछले वर्शन के साथ काम करने की सुविधा की ज़रूरत होगी. यह सुविधा, कम से कम एक हफ़्ते तक उपलब्ध होनी चाहिए.
- एपीआई अनुरोधों में SegmentKey के पैरामीटर तय करने के लिए, ticketing_trip_id (trips.txt में) और ticketing_stop_id (ticketing_identifiers.txt में) ज़रूरी हैं. stop_sequence पर फ़ॉलबैक की सुविधा काम नहीं करती, क्योंकि यह सुविधा स्थिर नहीं है.

GTFS-Fares v1

स्टैटिक GTFS के रेफ़रंस में, fare_attributes.txt और fare_rules.txt फ़ाइलों के बारे में बताया गया है. ये फ़ाइलें ज़रूरी नहीं हैं. अगर कोई पार्टनर, पार्टनर एपीआई के साथ इंटिग्रेट करता है, तो ये फ़ाइलें नहीं दी जानी चाहिए.