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

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

डिफ़ॉल्ट आवश्यकताएं

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

GTFS के सबसे सही तरीके - ज़रूरत पड़ने पर, कृपया सबसे सही तरीक़ों को अपनाएं.

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

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

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

स्कोप

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

अनुवाद

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

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

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

उदाहरण

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

खत्म होने का समय

traffic_time और detect_time, दोनों stop_times.txt में दिए जाने चाहिए.

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

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

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

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

स्टेशन/स्टॉप के स्थान

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

कुछ और GTFS एक्सटेंशन

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

Google Transit का टिकट एक्सटेंशन

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

GTFS-किराये v1

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