जीटीएफ़एस के लिए सबसे सही तरीके

ध्यान दें: इस दस्तावेज़ में मौजूद कॉन्टेंट को जीटीएफ़एस के लिए सबसे सही तरीके पेज से लिया गया है.

मुख्य जीटीएफ़एस

सामान्य ट्रांज़िट फ़ीड नियम (जीटीएफ़एस) में सार्वजनिक परिवहन (बस, मेट्रो वगैरह) की सेवाओं के बारे में बताने के सबसे सही तरीके यहां सुझाए गए हैं. ये तरीके जीटीएफ़एस के सबसे सही तरीके अपनाने वाले कामकाजी ग्रुप के सदस्यों के अनुभव और खास ऐप्लिकेशन के लिए जीटीएफ़एस के तरीकों के सुझावों से निकलकर आए हैं. ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.

दस्तावेज़ की संरचना

तरीकों को तीन मुख्य सेक्शन में रखा गया है:

• डेटासेट प्रकाशन और सामान्य तरीके: ये तरीके, जीटीएफ़एस डेटासेट की पूरी संरचना और जीटीएफ़एस डेटासेट को प्रकाशित करने के तरीके से जुड़े हैं.
• फ़ाइल के मुताबिक व्यवस्थित किए गए तरीकों के सुझाव: जीटीएफ़एस में सुझावों को फ़ाइल और फ़ील्ड के मुताबिक व्यवस्थित किया जाता है. जिससे मैप बनाने के तरीकों को वापस आधिकारिक जीटीएफ़एस रेफ़रंस तक पहुंचाया जा सके.
• केस के मुताबिक व्यवस्थित किए गए तरीकों के सुझाव: लूप वाले रास्ते जैसे कुछ खास केस में, तरीकों को एक से ज़्यादा फ़ाइल और फ़ील्ड पर लागू करना पड़ सकता है. इस तरह के सुझाव इस सेक्शन में इकट्ठा किए जाते हैं.

अक्सर पूछे जाने वाले सवाल

जीटीएफ़एस के ये सबसे सही तरीके क्यों ज़रूरी हैं?

जीटीएफ़एस के सबसे सही तरीकों के मकसद ये हैं:

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

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

इन्हें कैसे डेवलप किया गया? इन्हें किसने डेवलप किया?

इन सबसे सही तरीकों को जीटीएफ़एस में शामिल 17 संगठनों के कामकाजी ग्रुप ने डेवलप किया. इसमें ऐप्लिकेशन सर्विस देने वाली कंपनियां और डेटा का इस्तेमाल करने वाले लोग शामिल थे. साथ ही, सार्वजनिक परिवहन की सेवा देने वाली कंपनियां, और जीटीएफ़एस में काफ़ी हद तक दखल रखने वाले सलाहकार भी इसका हिस्सा थे. कामकाजी ग्रुप को रॉकी माउंटेन इंस्टिट्यूट में बुलाया और सम्मानित किया गया.

कामकाजी ग्रुप के सदस्यों ने हर सबसे सही तरीके के लिए वोट दिया. ज़्यादातर सबसे सही तरीकों को एकमत से मंज़ूरी दी गई. बहुत कम मामलों में, सबसे सही तरीकों को संगठनों के बहुमत के आधार पर मंज़ूरी दी गई.

सिर्फ़ जीटीएफ़एस के संदर्भ को क्यों नहीं बदला जा सकता?

अच्छा सवाल है! स्पेसिफ़िकेशन, डेटा के इस्तेमाल, और ज़रूरतों की जांच करने की प्रोसेस की वजह से स्पेसिफ़िकेशन में कुछ बदलावों की शुरुआत ज़रूर हुई (GitHub में बंद किए गए पुल के अनुरोध देखें). सबसे सही तरीकों के मुकाबले, स्पेसिफ़िकेशन के संदर्भों में किए संशोधनों के लिए ज़्यादा खोजबीन और टिप्पणियां की जाती हैं. हालांकि, इसके लिए अब भी सबसे अच्छी प्रक्रियाओं के सुझावों पर सहमति जताने की ज़रूरत थी.

कामकाजी ग्रुप ने अनुमान लगाया है कि जीटीएफ़एस के कुछ सबसे सही तरीके समय के साथ मुख्य जीटीएफ़एस संदर्भ का हिस्सा बन जाएंगे.

क्या जीटीएफ़एस के पुष्टि करने वाले टूल सबसे सही तरीकों के पालन की भी पुष्टि करते हैं?

फ़िलहाल, पुष्टि करने वाला कोई भी टूल यह जांच नहीं करता कि सबसे सही तरीकों का पालन हो रहा है या नहीं. पुष्टि करने वाले अलग-अलग टूल कुछ सबसे सही तरीकों के पालन होने की जांच करते हैं. जीटीएफ़एस के पुष्टि करने वाले टूल की सूची के लिए टेस्टिंग फ़ीड देखें. अगर आप एक ऐसा जीटीएफ़एस का पुष्टि करने वाला टूल लिख रहे हैं जो इन सबसे सही तरीकों का संदर्भ लेता है, तो [e-mail] पर ईमेल करें.

मैं एक सार्वजनिक परिवहन एजेंसी से हूं. अपनी सॉफ़्टवेयर सर्विस देने वाली कंपनियों और विक्रेताओं से इन सबसे सही तरीकों का पालन करवाने के लिए मुझे क्या करना चाहिए?

अपने विक्रेता या सॉफ़्टवेयर सेवा देने वाली कंपनी को ये सबसे सही तरीके बताएं. हमारा सुझाव है कि आप जीटीएफ़एस के सबसे सही तरीकों के यूआरएल का संदर्भ दें. साथ ही, जीटीएफ़एस बनाने वाले सॉफ़्टवेयर की खरीद में मौजूद मुख्य स्पेसिफ़िकेशन संदर्भ का भी इस्तेमाल करें.

अगर मुझे पता चलता है कि कोई जीटीएफ़एस डेटा फ़ीड सबसे सही तरीकों का पालन नहीं करती, तो मुझे क्या करना चाहिए?

feed_info.txt में अगर प्रस्तावित feed_contact_email या feed_contact_url मौजूद हों, तो उनका इस्तेमाल करके या सार्वजनिक परिवहन एजेंसी या फ़ीड बनाने वाली वेबसाइट की संपर्क जानकारी खोजकर, फ़ीड के संपर्क की पहचान करें. फ़ीड बनाने वाली वेबसाइट को समस्या बताते समय, उस जीटीएफ़एस के सबसे सही तरीके का लिंक दें जिस पर चर्चा हो रही है. इस दस्तावेज़ से लिंक करना देखें.

मुझे सबसे सही तरीकों में कुछ सुधार करवाना/ जुड़वाना है. यह कैसे होगा?

[e-mail] को ईमेल करें या कोई समस्या खोलें या GitHub के जीटीएफ़एस सबसे सही तरीके रेपो में पुल का अनुरोध करें.

शामिल होने के लिए क्या करना होगा?

[e-mail] पर ईमेल भेजें.

डेटासेट प्रकाशन और आम तरीके

आम सुझाव
डेटासेट को एक सार्वजनिक और हमेशा मौजूद रहने वाले यूआरएल पर प्रकाशित करना चाहिए. इसमें zip फ़ाइल का नाम भी होना चाहिए. (उदाहरण, www.agency.org/gtfs/gtfs.zip). आम तौर पर, यूआरएल ऐसा होना चाहिए जिसे सीधे डाउनलोड किया जा सके. इसका इस्तेमाल करने वाले सॉफ़्टवेयर ऐप्लिकेशन को फ़ाइल ऐक्सेस करके डाउनलोड करने के लिए लॉग इन करने की ज़रूरत ना पड़े. किसी जीटीएफ़एस डेटासेट को खुले तौर पर डाउनलोड किया जा सकने वाला बनाने का सुझाव दिया जाता है (और यह सबसे आम तरीका भी है). हालांकि, अगर कोई डेटा सर्विस देने वाली कंपनी जीटीएफ़एस की लाइसेंसिंग या दूसरी वजहों से उसका ऐक्सेस नियंत्रित करना चाहती है, तो हम API (एपीआई) कुंजियों का इस्तेमाल करके नियंत्रित करने का सुझाव देते हैं. इससे ऑटोमेटिक डाउनलोड हो सकेंगे.
जीटीएफ़एस डेटा को दोहरा-दोहराकर प्रकाशित किया जाता है. इससे एक स्थिर लोकेशन पर एक फ़ाइल में किसी सार्वजनिक परिवहन एजेंसी (एक या ज़्यादा) की सेवा का आधिकारिक ब्यौरा हमेशा मौजूद रहता है.
जहां भी हो सके, डेटा के हर दोहराव में stop_id, route_id, और agency_id के लिए लगातार पहचानकर्ता (आईडी फ़ील्ड) बरकरार रखें.
एक जीटीएफ़एस डेटासेट में मौजूदा और आने वाली सेवा (कभी-कभी इसे "मर्ज किया गया" डेटासेट कहते हैं) होनी चाहिए. Google ट्रांज़िटफ़ीड टूल की मर्ज करने की सुविधा का इस्तेमाल करके दो अलग-अलग जीटीएफ़एस फ़ीड से एक मर्ज किया गया डेटासेट बना सकते हैं. किसी भी समय, प्रकाशित किया गया जीटीएफ़एस डेटासेट कम से कम अगले सात दिनों तक मान्य होना चाहिए. आदर्श रूप से, इसे तब तक मान्य होना चाहिए, जब तक ऑपरेटर को भरोसा हो कि यही शेड्यूल चलता रहेगा. अगर हो सके, तो जीटीएफ़एस डेटासेट में अगले 30 दिनों की सेवा की जानकारी होनी चाहिए.
फ़ीड से पुरानी सेवाएं (खत्म हो चुके कैलेंडर) हटाएं.
अगर सेवा में बदलाव अगले सात दिनों या उससे कम समय में होने वाला है, तो जीटीएफ़एस-रीयलटाइम फ़ीड (सेवा से जुड़ी सलाह या यात्रा का अपडेट) से बदलाव की जानकारी दें, ना कि स्टैटिक जीटीएफ़एस डेटासेट से.
जीटीएफ़एस डेटा को होस्ट करने वाले वेब सर्वर को इस तरह से कॉन्फ़िगर किया जाना चाहिए कि वह फ़ाइल में बदलाव की सही तारीख बताए (सेक्शन 14.29 के तहत, एचटीटीपी/1.1 - टिप्पणियों के लिए अनुरोध 2616 देखें).

फ़ाइल के मुताबिक व्यवस्थित किए गए तरीकों के सुझाव

इस सेक्शन में फ़ाइल और फ़ील्ड के मुताबिक व्यवस्थित किए गए तरीके दिखाए गए हैं. यह जीटीएफ़एस संदर्भ के मुताबिक है.

सभी फ़ाइलें

फ़ील्ड का नाम	सुझाव
छोटे-बड़े अक्षर	खरीदार को दिखाई देने वाली सभी टेक्स्ट स्ट्रिंग (इनमें स्टॉप के नाम, रास्तों के नाम, और हेडसाइन शामिल हैं) अंग्रेज़ी के छोटे-बड़े अक्षरों (सिर्फ़ कैपिटल में नहीं) में लिखी जानी चाहिए. जिन डिसप्ले पर छोटे अक्षर भी दिखाई दे सकते हैं, उन पर जगहों के नाम को बड़े अक्षर से शुरू करने के लिए स्थानीय मानकों पर ध्यान देना चाहिए.
	उदाहरण:
	Brighton Churchill Square
	Villiers-sur-Marne
	Market Street
शॉर्ट फ़ॉर्म	नामों और अन्य टेक्स्ट (जैसे स्ट्रीट के लिए St.) के लिए पूरी फ़ीड में शॉर्ट फ़ॉर्म का इस्तेमाल ना करने की कोशिश करें. अगर किसी लोकेशन को उसके शॉर्ट फ़ॉर्म वाले नाम से ही जाना जाता है (जैसे, "JFK Airport") तो इनका इस्तेमाल कर सकते हैं. स्क्रीन रीडर सॉफ़्टवेयर और आवाज़ का इस्तेमाल करने वाले इंटरफ़ेस पर शॉर्ट फ़ॉर्म पढ़ने में दिक्कत हो सकती है. उपभोक्ता सॉफ़्टवेयर को इस तरह से बनाया जा सकता है कि वे भरोसेमंद तरीके से डिसप्ले के लिए पूरे शब्दों की शॉर्ट फ़ॉर्म बना सकें. लेकिन, शॉर्ट फ़ॉर्म से पूरे शब्द में बदलने की कोशिश करने पर गलती होने का खतरा ज़्यादा होता है.

agency.txt

फ़ील्ड का नाम	सुझाव
agency_id	अगर फ़ीड में सिर्फ़ एक एजेंसी है, तो भी शामिल किया जाना चाहिए. (agency_id को routes.txt और fare_attributes.txt में शामिल करने के सुझाव भी देखें)
agency_lang	शामिल किया जाना चाहिए.
agency_phone	अगर कोई ऐसा ग्राहक सेवा फ़ोन नंबर मौजूद नहीं है, तो शामिल किया जाना चाहिए.
agency_email	अगर कोई ऐसा ग्राहक सेवा ईमेल पता मौजूद नहीं है, तो शामिल किया जाना चाहिए.
agency_fare_url	अगर एजेंसी में किराया नहीं लिया जाता, तो शामिल किया जाना चाहिए.

उदाहरण:

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

stops.txt

फ़ील्ड का नाम	सुझाव
stop_id	जो स्टॉप अलग-अलग जगहों पर हैं (जैसे, वाहनों के लिए तय रास्ते पर बताई गई अलग-अलग सटीक जगहें जहां उन्हें रुकना है, शायद इनमें साइन, शेल्टर या इस तरह की दूसरी सार्वजनिक जानकारी की मदद से फ़र्क़ किया जा सके, जो कि अलग-अलग गलियों के कोने पर मिलेगी या फिर ये जगहें अलग बोर्डिंग की सुविधा के बारे में बताएंगी, जैसे कि प्लैटफ़ॉर्म या बस बे, भले ही ये एक-दूसरे के पास में हों), उनका stop_id अलग होना चाहिए.
	stop_id एक अंदरूनी आईडी है, जिसे यात्रियों को नहीं दिखाया जाता.
	डेटा के सभी दोहराव में हर स्टॉप के लिए एक ही stop_id रखें (डेटासेट प्रकाशन और आम तरीके देखें).
stop_name	stop_name वही होना चाहिए जो स्टॉप, स्टेशन या बोर्डिंग सेवा का नाम एजेंसी ने सबके लिए तय किया है. जैसे, जो टाइमटेबल में प्रिंट किया गया है, ऑनलाइन प्रकाशित किया गया है और/या जगह पर मौजूद है.
	जब किसी स्टॉप का नाम प्रकाशित न किया गया हो, तो फ़ीड में जिस चलन के तहत स्टॉप का नाम रखा गया है उसी का इस्तेमाल करें.
	जिन जगहों को उनके शॉर्ट फ़ॉर्म वाले नाम से ही जाना जाता है, उनके अलावा किसी भी जगह के नाम में शॉर्ट फ़ॉर्म इस्तेमाल करने से बचें. सभी फ़ाइलें के नीचे शॉर्ट फ़ॉर्म (#2) देखें.
	ग्राहकों को दिखाई देने वाले सभी टेक्स्ट फ़ील्ड के लिए स्टॉप के नाम छोटे-बड़े अक्षरों में दें. उन्हें स्थानीय नियमों के मुताबिक रखें और सुझावों के मुताबिक ही लिखें.
	डिफ़ॉल्ट रूप से, stop_name में जेनरिक या फ़ालतू शब्द, जैसे "स्टेशन" या "स्टॉप" नहीं होने चाहिए, लेकिन एक आद मामले में ऐसा हो सकता है. जब यह नाम का ही एक हिस्सा हो (यूनियन स्टेशन, सेंट्रल स्टेशन) जब stop_name बहुत जेनरिक हो (जैसे, अगर यह शहर का नाम ही हो). “स्टेशन”, “टर्मिनल” या अन्य शब्द लिखने से मतलब साफ़ हो जाता है.
stop_lat और stop_lon	स्टॉप की लोकेशन जितनी सटीक हो सके, उतनी होनी चाहिए. स्टॉप की जो लोकेशन दी जाए, उसमें और असल स्टॉप की पोज़िशन में चार मीटर से ज़्यादा का अंतर नहीं होना चाहिए.
	स्टॉप की लोकेशन पैदल यात्रियों के रास्ते के बहुत पास होनी चाहिए, जहां से कोई यात्री सवार होगा (यानी, सड़क की सही साइड पर).
	अगर स्टॉप की कोई लोकेशन अलग-अलग डेटा फ़ील्ड में शेयर की गई है (यानी, दो एजेंसी एक ही स्टॉप / बोर्डिंग की सुविधा का इस्तेमाल करती हैं), तो दोनों स्टॉप के लिए बताएं कि स्टॉप का इस्तेमाल वे ही दोनों stop_lat और stop_lon कर रहे हैं.
stop_code	अगर यात्रियों को स्टॉप नंबर या छोटे पहचानकर्ता दिखाए जाने वाले हैं, तो जीटीएफ़एस में stop_code को शामिल किया जाना चाहिए.
parent_station और location_type	कई स्टेशन और टर्मिनल पर एक से ज़्यादा बोर्डिंग की सुविधाएं होती हैं (वाहन के आधार पर उन्हें बस बे, प्लैटफ़ॉर्म, जेटी, गेट या किसी और नाम से बुलाया जाता है). ऐसे मामलों में, फ़ीड बनाने वालों को स्टेशन, बोर्डिंग की सुविधाओं (जिन्हें चाइल्ड स्टॉप भी कहते हैं), और वे कैसे एक-दूसरे से जुड़े हैं यह बताना चाहिए. स्टेशन या टर्मिनल को stops.txt में एक रिकॉर्ड के तौर पर दिखाया जाना चाहिए जिसकी location_type = 1 हो. बोर्डिंग की हर सुविधा को location_type = 0 वाले एक स्टॉप के तौर पर बताया जाना चाहिए. बोर्डिंग की सुविधा जिस स्टेशन में है, parent_station को उसके stop_id से संदर्भ लेना चाहिए.
	स्टेशन और चाइल्ड स्टॉप का नाम रखते समय, वे नाम सेट करें जिन्हें यात्री अच्छे से पहचानते हों, और यात्रियों की स्टेशन और बोर्डिंग की सुविधा (बस बे, प्लैटफ़ॉर्म, जेटी, गेट वगैरह) को पहचानने में मदद करें. पैरेंट स्टेशन का नाम चाइल्ड स्टॉप का नाम शिकागो यूनियन स्टेशन शिकागो यूनियन स्टेशन प्लैटफ़ॉर्म 19 सैन फ़्रांसिस्को फ़ेरी बिल्डिंग टर्मिनल सैन फ़्रांसिस्को फ़ेरी बिल्डिंग टर्मिनल गेट ई डाउनटाउन ट्रांज़िट सेंटर डाउनटाउन ट्रांज़िट सेंटर बे बी

routes.txt

फ़ील्ड का नाम	सुझाव
agency_id	अगर इसे agency.txt में परिभाषित किया गया है, तो शामिल किया जाना चाहिए.
route_short_name	अगर सेवा कुछ समय के लिए दी गई है, तो route_short_name शामिल करें. यह एक जाना-पहचाना नाम होना चाहिए, जिसे यात्री पहचानते हों. यह 12 वर्णों से ज़्यादा का नहीं होना चाहिए.
route_long_name	स्पेसिफ़िकेशन संदर्भ से परिभाषा: यह नाम आम तौर पर route_short_name से ज़्यादा जानकारी देता है और अक्सर इसमें रास्ते की मंज़िल या स्टॉप शामिल होता है. route_short_name या route_long_name में से किसी एक की जानकारी देना ज़रूरी है. अगर ऐसा करना सही हो, तो दोनों ही दिए जाने चाहिए. अगर रास्ते का कोई लंबा नाम नहीं है, तो route_short_nameroute_short_name तय करें और इस फ़ील्ड के मान के तौर पर एक खाली स्ट्रिंग का इस्तेमाल करें. लंबे नाम किस-किस तरह के हो सकते हैं, ये उदाहरण नीचे दिए गए हैं: प्राथमिक यात्रा का पाथ या कॉरिडोर रास्ते का नाम फ़ॉर्म एजेंसी “N”/“जूडा” route_short_name/ route_long_name Muni, in San Francisco “6“/“ML King Jr Blvd“ route_short_name/ route_long_name TriMet, in Portland, Or. “6”/“Nation - Étoile” route_short_name/ route_long_name RATP, in Paris France. “U2”/ “Pankow – Ruhleben” route_short_name/ route_long_name BVG, in Berlin, Germany सेवा का ब्यौरा “हार्टवेल एरिया शटल“
	route_long_name में route_short_name शामिल नहीं होना चाहिए.
	पॉप्युलेट करते समय किसी सेवा की पहचान का पूरा पद शामिल करें route_long_name. उदाहरण: सेवा की पहचान सुझाव उदाहरण "MAX Light Rail" TriMet, in Portland, Oregon route_long_name में ब्रैंड (MAX) और खास रास्ते का पद शामिल होना चाहिए. "MAX लाल लाइन" "MAX नीली लाइन" "Rapid Ride" ABQ Ride, in Albuquerque, New Mexico route_long_name में ब्रैंड (रैपिड राइड) और तय किया गया खास रास्ता शामिल होना चाहिए "रैपिड राइड लाल लाइन" "रैपिड राइड नीली लाइन"
route_id	किसी दिए गए नामी रास्ते के लिए सभी यात्रा एक ही route_id से संदर्भित होनी चाहिए. किसी रास्ते की अलग-अलग दिशाओं को अलग-अलग route_id मानों में नहीं बांटना चाहिए. किसी रास्ते पर जारी सफ़र की अलग-अलग अवधि को अलग-अलग route_id मानों में नहीं बांटना चाहिए. इसका मतलब, "सुबह का डाउनटाउन" और "शाम का डाउनटाउन" सेवाओं के लिए routes.txt में अलग-अलग रिकॉर्ड न रखें).
	अगर रास्तों के किसी ग्रुप में अलग-अलग नाम वाली शाखाएं (जैसे, 1A और 1B) शामिल हों, तो रास्ते की शाखाओं के मामले में route_short_name और route_long_name बताने के बारे में दिए गए सुझाव मानें.
route_color और route_text_color	यह निशानों और उस जानकारी जैसे ही होने चाहिए जो ग्राहकों के लिए प्रिंट की गई है और ऑनलाइन मौजूद है (और इसलिए, अगर वह दूसरी जगहों पर मौजूद नहीं है, तो उसे शामिल नहीं किया जाना चाहिए).

trips.txt

• लूप वाले रास्तों के लिए खास मामला देखें: Loop routes वाले रास्ते ऐसे मामले हैं जिनमें यात्रा एक ही जगह से शुरू होती है और वहीं पर खत्म. ये लीनियर रास्तों से अलग होते हैं जिनमें दोनों टर्मिनल अलग-अलग होते हैं. लूप वाले रास्तों को कुछ खास तरीकों से बताना चाहिए. लूप वाले रास्तों का मामला देखें.
• लासो आकार के रास्तों के लिए खास केस देखें: लासो आकार के रास्ते लीनियर और लूप वाले रास्तों का मिला-जुला रूप होते हैं. इनमें वाहन रास्ते के एक ही हिस्से में लूप की तरह चलते हैं. लासो आकार के रास्तों को कुछ खास तरीकों से बताया जाना चाहिए. लासो आकार के रास्तों का मामला देखें.

फ़ील्ड का नाम	सुझाव
trip_headsign	trip_headsign या stop_headsign फ़ील्ड में रास्तों के नाम (route_short_name और route_long_name से मेल खाने वाले) ना दें.
	इनमें मंज़िल, दिशा और/या अन्य तरह की यात्राओं के बारे में बताने वाला टेक्स्ट शामिल होना चाहिए जो वाहन के हेडसाइन में दिखाई देता हो. इससे एक रास्ते पर अलग-अलग यात्राओं में फ़र्क़ करने में मदद मिलती है. वाहन पर दिखाई गई दिशा की जानकारी से मेल खाना सबसे पहला और अहम लक्ष्य है जिससे जीटीएफ़एस डेटासेट में दिए गए हेडसाइन के बारे में बताया जा सकता है. अगर यह पहला लक्ष्य पूरा हो रहा है, तब ही बाकी की जानकारी शामिल की जानी चाहिए. अगर यात्रा के दौरान हेडसाइन बदलते हैं, तो stop_times.stop_headsign को trip_headsign से ओवरराइड करें. कुछ संभव मामलों के लिए नीचे सुझाव दिए गए हैं:
	example_table: रास्ते का ब्यौरा सुझाव 2A. सिर्फ़ मंज़िल के लिए सिर्फ़ टर्मिनस की मंज़िल बताएं, जैसे "ट्रांज़िट सेंटर", "पोर्टलैंड सिटी सेंटर" या "जैंटज़ेन बीच". 2B. मंज़िल और बीच में रुकने की जगहें <waypoint> से होती हुई <destination> “Highgate via Charing Cross”. अगर हेडसाइन से हटा दी गई रास्ते में रुकने की जगह (जगहें) यात्रियों को वहां से वाहन गुज़रने के बाद दिखाई दे रही हैं, तो अपडेट किया गया हेडसाइन सेट करने के लिए stop_times.stop_headsign का इस्तेमाल करें. 2C. स्थानीय स्टॉप वाला इलाके का नाम अगर मंज़िल के किसी शहर या नगर में एक से ज़्यादा स्टॉप हैं, तो मंज़िल वाले शहर पहुंचने के बाद stop_times.stop_headsign का इस्तेमाल करें. 2D. सिर्फ़ दिशा "उत्तर की तरफ़", "अंदर की तरफ़", "क्लॉकवाइज़" या ऐसे ही दिशा के बारे में बताने वाले दूसरे शब्द इस्तेमाल करें. 2E. मंज़िल के साथ दिशा <direction> से <terminus name> जैसे, “दक्षिण में सैन होज़े की तरफ़”. 2F. मंज़िल और रास्ते में रुकने के लिए जगहों के साथ दिशा <waypoint> से <destination> की तरफ़ <direction> (“ चारिंग क्रॉस से हाइगेट उत्तर की तरफ़”).
	किसी भी हेडसाइन को "के लिए" या "की तरफ़" से शुरू ना करें.
direction_id	अगर किसी रास्ते की यात्रा उल्टी दिशाओं में चलती हैं, तो यात्रा के इन ग्रुप को direction_id फ़ील्ड की मदद से अलग करें. इसके लिए 0 और 1 मान इस्तेमाल करें.
	पूरे डेटासेट में 0 और 1 मान एक ही तरह से इस्तेमाल करें. जैसे, अगर लाल रास्ते पर 1 = जाने वाला है, तो हरे रास्ते पर 1 = जाने वाला अगर X रास्ते पर 1 = उत्तर की तरफ़ है, तो Y रास्ते पर 1 = उत्तर की तरफ़ अगर X रास्ते पर 1 = क्लॉकवाइज़ है, तो Y रास्ते पर 1 = क्लॉकवाइज़

stop_times.txt

लूप वाले रास्ते: लूप वाले रास्तों के लिए खास stop_times ज़रूरी होते हैं. (लूप वाले रास्तों का मामला देखें)

फ़ील्ड का नाम	सुझाव
pickup_type और drop_off_type	बिना आय वाली (डेडहेड) यात्राएं जो यात्री सेवा नहीं देतीं, उन्हें सभी stop_times लाइनों के लिए, pickup_type और drop_off_type का मान 1 दिया जाना चाहिए.
	आय वाली यात्राओं के लिए, वाहन के प्रदर्शन पर नज़र रखने वाले आंतरिक "टाइमिंग पॉइंट" और ऐसी दूसरी जगहें, जैसे कि गैराज, जहां से यात्री सवार नहीं हो सकते, उन्हें pickup_type = 1 (पिकअप उपलब्ध नहीं है) और drop_off_type = 1 (ड्रॉप ऑफ़ उपलब्ध नहीं है) के तौर पर मार्क किया जाना चाहिए.
timepoint	timepoint फ़ील्ड भरा जाना चाहिए. इससे पता चलता है कि ऑपरेटर किन stop_times का कड़ाई से पालन करने की कोशिश करेगा (timepoint=1), और स्टॉप टाइम के अनुमान (timepoint=0) क्या होंगे.
arrival_time और departure_time	arrival_time और departure_time फ़ील्ड में हर बार मुमकिन होने पर समय का मान बताया जाना चाहिए. इसमें गैर-ज़रूरी अनुमानित या टाइम पॉइंट के बीच इंटरपोलेट किए गए समय शामिल हैं.
stop_headsign	stop_headsign मान trip_headsign ( trips.txt में) को ओवरराइड करते हैं. जब किसी यात्रा के दौरान हेडसाइन पर दिखाया जाने वाला टेक्स्ट बदलता है, तो stop_headsign मान दिए जाने चाहिए. stop_headsign मान बाद के स्टॉप पर “कैरी” नहीं होते. इसलिए अगर स्टॉप हेडसाइन पहले जैसा ही रहेगा, तो मान दोहराए जाने चाहिए. आम तौर पर, हेडसाइन मान स्टेशन पर मौजूद साइन से मिलने चाहिए. नीचे दिए गए मामलों में, "दक्षिण की ओर" ग्राहकों को गुमराह कर सकता है, क्योंकि इसे स्टेशन के साइन में इस्तेमाल नहीं किया गया है.
	एनवायसी में, दक्षिण की ओर जा रहे 2 के लिए: stop_times.txt लाइन के लिए: stop_headsign मान इस्तेमाल करें: मैनहैटन तक पहुंचने तक Manhattan & Brooklyn डाउनटाउन तक पहुंचने तक Downtown & Brooklyn ब्रुकलिन तक पहुंचने तक Brooklyn ब्रुकलिन पहुंच जाने के बाद Brooklyn (New Lots Av)
	बॉस्टन में, दक्षिण की तरफ़ जा रही लाल लाइन के लिए, ब्रेनट्री शाखा के लिए: stop_times.txt लाइन के लिए: stop_headsign मान इस्तेमाल करें: डाउनटाउन तक पहुंचने तक Inbound to Braintree डाउनटाउन पहुंच जाने के बाद Braintree डाउनटाउन के बाद Outbound to Braintree
shape_dist_traveled	shape_dist_traveled उन रास्तों के लिए दिया जाना चाहिए जिन पर लूप या इनलाइन मौजूद हैं (वाहन, एक यात्रा में अलाइनमेंट की एक ही जगह से होकर गुज़रता है). shapes.shape_dist_traveled सुझाव देखें.

calendar.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	calendar_dates.txt में शेड्यूल के सीमित संख्या में अपवाद होने चाहिए. नियमित रूप से शेड्यूल की जाने वाली सेवाओं को calendar.txtका इस्तेमाल करके कॉन्फ़िगर किया जाना चाहिए.
	calendar.service_name फ़ील्ड शामिल करने से इंसानों के लिए जीटीएफ़एस को पढ़ना आसान हो सकता है. लेकिन, इसे स्पेसिफ़िकेशन में शामिल नहीं किया गया है.

calendar_dates.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	calendar_dates.txt में शेड्यूल के सीमित संख्या में अपवाद होने चाहिए. नियमित रूप से शेड्यूल की जाने वाली सेवाओं को calendar.txtका इस्तेमाल करके कॉन्फ़िगर किया जाना चाहिए.
	calendar.service_name फ़ील्ड शामिल करने से इंसानों के लिए जीटीएफ़एस को पढ़ना आसान हो सकता है. लेकिन, इसे स्पेसिफ़िकेशन में शामिल नहीं किया गया है.

fare_attributes.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	अगर फ़ील्ड को agency.txt में शामिल किया जाता है, तो agency_id को fare_attributes.txt में शामिल किया जाना चाहिए.
	अगर किराये के सिस्टम को सटीक रूप से नहीं बनाया जा सकता, तो भ्रम की स्थिति बढ़ाने से बचें और उसे खाली छोड़ दें.
	किराये (fare_attributes.txt और fare_rules.txt) शामिल करें और उन्हें ज़्यादा से ज़्यादा सटीक तरह से बनाएं. ऐसे मामलों में जहां किराये को सटीक रूप से मॉडल नहीं किया जा सकता, वहां किराये को बढ़ाकर बताना चाहिए ना कि घटाकर. इससे ग्राहक अपने पास पैसे काफ़ी ना होने पर सवार होने की कोशिश नहीं करेंगे. अगर बहुत सारे किरायों को सही से नहीं बनाया जा सकता, तो फ़ीड में किराये की जानकारी शामिल ना करें.

fare_rules.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	अगर फ़ील्ड को agency.txt में शामिल किया जाता है, तो agency_id को fare_attributes.txt में शामिल किया जाना चाहिए.
	अगर किराये के सिस्टम को सटीक रूप से नहीं बनाया जा सकता, तो भ्रम की स्थिति बढ़ाने से बचें और उसे खाली छोड़ दें.
	किराये (fare_attributes.txt और fare_rules.txt) शामिल करें और उन्हें ज़्यादा से ज़्यादा सटीक तरह से बनाएं. ऐसे मामलों में जहां किराये को सटीक रूप से मॉडल नहीं किया जा सकता, वहां किराये को बढ़ाकर बताना चाहिए ना कि घटाकर. इससे ग्राहक अपने पास पैसे काफ़ी ना होने पर सवार होने की कोशिश नहीं करेंगे. अगर बहुत सारे किरायों को सही से नहीं बनाया जा सकता, तो फ़ीड में किराये की जानकारी शामिल ना करें.

shapes.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	आदर्श रूप से, अगर दो रास्तों के लिए एक अलाइनमेंट इस्तेमाल होता है (जैसे, 1 और 2 दोनों रास्तों के एक ही सड़क या ट्रैक पर ऑपरेट करने के मामले में), तो अलाइनमेंट का शेयर होने वाला हिस्सा सही से मेल खाना चाहिए. इससे अच्छी क्वालिटी का परिवहन का नक्शा बनाने में मदद मिलती है.
	अलाइनमेंट हमेशा सही रास्ते के बीच में से निकलना चाहिए जिस पर वाहन चलता है. अगर कोई गली तय नहीं है, तो यह स्ट्रीट के बीच की रेखा हो सकती है. इसके अलावा, यह सड़क की उस साइड के बीच की रेखा भी हो सकती है जिस पर वाहन चल रहा है. अलाइनमेंट किसी फ़ुटपाथ के स्टॉप, प्लैटफ़ॉर्म या बोर्डिंग की लोकेशन तक तीखे मोड़ से नहीं पहुंचना चाहिए.
shape_dist_traveled	अगर किसी अलाइनमेंट में लूप या इनलाइन मौजूद हैं (वाहन एक यात्रा में अलाइनमेंट की एक ही जगह से होकर गुज़रता है), तो इसे shapes.txt और stop_times.txt दोनों में दिया जाना चाहिए. अगर यात्रा के दौरान कोई वाहन रास्ते में कुछ जगहों पर अलाइनमेंट पर से गुज़रता है, तो shape_dist_traveled ज़रूरी है. इससे यह बताने में मदद मिलती है कि shapes.txt के पॉइंट के हिस्से stop_times.txt के रिकॉर्ड से मेल खाते हैं.
	shape_dist_traveled फ़ील्ड की मदद से एजेंसी बता पाती है कि stop_times.txt में मौजूद स्टॉप किस तरह अपने आकार में फ़िट होते हैं. shape_dist_traveled फ़ील्ड के लिए आम तौर पर इस्तेमाल किए जाने वाले मानों में से एक है वाहन ने जिस आकार में सफ़र किया है, उसकी शुरुआत वाली जगह से मापी जाने वाली दूरी (ऐसा समझें कि यह किसी ओडोमीटर की रीडिंग है). रास्ते के अलाइनमेंट (shapes.txt में), उन स्टॉप की लोकेशन के 100 मीटर के दायरे में होना चाहिए जहां यात्रा के दौरान वाहन रुकता है. अलाइनमेंट को आसान बनाएं, ताकि shapes.txt में कोई बाहरी पॉइंट शामिल ना हो (जैसे, सीधी रेखा वाले सेगमेंट पर से अतिरिक्त पॉइंट हटा दें, लाइन को आसान बनाने की समस्या पर चर्चा देखें).

feed_info.txt

feed_info.txt को नीचे सभी फ़ील्ड के साथ शामिल किया जाना चाहिए.

फ़ील्ड का नाम	सुझाव
feed_start_date और feed_end_date	शामिल होना चाहिए
feed_version	शामिल होना चाहिए
feed_contact_email और feed_contact_url	कम से कम किसी एक की जानकारी दें

frequencies.txt

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	स्टॉप के असल समय को frequencies.txt के संदर्भ वाली यात्राओं के लिए नज़रअंदाज़ कर दिया जाता है; फ़्रीक्वेंसी पर आधारित यात्राओं के लिए सिर्फ़ स्टॉप के बीच के सफ़र की अवधि ही अहम होती है. ठीक से/इंसानों को समझ में आए, इसके लिए सुझाव दिया जाता है कि यात्रा के पहले स्टॉप के समय का संदर्भ frequencies.txt में, 00:00:00 (00:00:00 का पहला arrival_time मान) से शुरू होना चाहिए.
block_id	फ़्रीक्वेंसी पर आधारित यात्राओं के लिए दिया जा सकता है.

transfers.txt

transfers.transfer_type उन चार मानों में से एक हो सकता है जिन्हें जीटीएफ़एस में दिया गया है. transfer_type की ये परिभाषाएं नीचे दी गई जीटीएफ़एस स्पेसिफ़िकेशन से ली गई हैं. इनके साथ कुछ अतिरिक्त तरीकों के सुझाव भी दिए गए हैं.

फ़ील्ड का नाम	सुझाव
transfer_type	0 या (खाली): यह रास्तों के बीच में एक सुझाया गया ट्रांसफ़र पॉइंट है. अगर ट्रांसफ़र के एक से ज़्यादा मौके हैं और उनमें से कोई सबसे अच्छा है (जैसे, अतिरिक्त सुविधाओं वाला ट्रांज़िट सेंटर या साथ लगी या जुड़ी हुई बोर्डिंग सुविधाओं/प्लैटफ़ॉर्म वाला स्टेशन), तो कोई सुझाया गया ट्रांसफ़र पॉइंट बताएं.
	1: यह दो रास्तों के बीच का समय आधारित ट्रांसफ़र पॉइंट है. जाने वाले वाहन से उम्मीद की जाती है कि वह आ रहे वाहन के लिए इंतज़ार करे. इससे यात्री को दो रास्तों के बीच ट्रांसफ़र होने के लिए काफ़ी समय मिल जाएगा. ट्रांसफ़र का यह प्रकार भरोसेमंद तरीके से ट्रांसफ़र करने के लिए एक ज़रूरी समय अवधि को ओवरराइड कर देता है. उदाहरण के तौर पर, Google Maps मानता है कि सुरक्षित रूप से ट्रांसफ़र होने के लिए यात्रियों को तीन मिनट लगते हैं. दूसरे ऐप्लिकेशन कुछ और डिफ़ॉल्ट मान सकते हैं.
	2: इस ट्रांसफ़र में कनेक्शन बनाने के लिए आने और जाने के समय में कम से कम अंतर होना ज़रूरी है. ट्रांसफ़र के लिए ज़रूरी समय min_transfer_time में बताया जाता है. अगर कोई रुकावट है या कोई दूसरी वजह है जिससे स्टॉप के बीच की यात्रा का समय बढ़ सकता हो, तो ट्रांसफ़र में लगने वाला कम से कम समय बताएं.
	3: इस लोकेशन के रास्तों के बीच में ट्रांसफ़र नहीं हो सकते. अगर भौतिक रुकावटों की वजह से ट्रांसफ़र नहीं हो सकते या अगर पार करने के लिए मुश्किल सड़कों या फ़ुटपाथ टूटे होने की वजह से वे असुरक्षित या मुश्किल बन गए हैं, तो यह मान बताएं.
	अगर यात्राओं में इन-सीट (ब्लॉक) ट्रांसफ़र की अनुमति है, तो आने की यात्रा का आखिरी स्टॉप वही होना चाहिए जो जाने की यात्रा का पहला स्टॉप है.

केस के अनुसार व्यवस्थित किए गए तरीकों के सुझाव

इस सेक्शन में सभी फ़ाइल और फ़ील्ड में खास केस और उनके नतीजों पर बात की गई है.

लूप वाले रास्ते

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

नीचे: लूप वाला रास्ता. वाहन यात्रा पूरी करने के बाद उसी जगह पर लौट आता है जहां से यात्रा शुरू हुई थी. लूप वाले कुछ रास्तों पर एक ही दिशा में यात्रा की जा सकती है. जबकि दूसरे रास्तों पर आने-जाने दोनों की दिशाओं में यात्रा की जा सकती है.

इसलिए हेडसाइन के सुझाव लगाए जाने चाहिए, ताकि सवारियों को पता रहे कि वाहन किस तरफ़ जा रहा है.

यात्रा की दिशा बदलने के बारे में बताने के लिए stop_times.txt फ़ाइल में stop_headsigns बताएं. stop_headsign से यात्रा की दिशा के बारे में पता चलता है. वे यात्राएं जो उस स्टॉप से शुरू हो रही हैं, जहां के लिए इसे परिभाषित किया गया है. किसी यात्रा के हर स्टॉप पर stop_headsigns जोड़ने से आप यात्रा के दौरान हेडसाइन की जानकारी बदल सकते हैं.

stop_times.txt फ़ाइल में किसी ऐसे रास्ते के लिए एक दोतरफ़ा यात्रा परिभाषित ना करें जो दो एंडपॉइंट के बीच होता है (जैसे कि जब एक ही बस आती-जाती है). इसके बजाय, यात्रा को दो अलग-अलग यात्रा की दिशाओं में बांटें.

एक ही रास्ते से दोतरफ़ा यात्रा की मॉडलिंग के उदाहरण:

दोतरफ़ा यात्रा, जिसमें हर स्टॉप पर हेडसाइन बदलता है

Trip_id	arrival_time	departure_time	stop_id	stop_sequence	stop_headsign
trip_1	06:10:00	06:10:00	stop_A	1	"B"
trip_1	06:15:00	06:15:00	stop_B	2	"C"
trip_1	06:20:00	06:20:00	stop_C	3	"D"
trip_1	06:25:00	06:25:00	stop_D	4	"E"
trip_1	06:30:00	06:30:00	stop_E	5	"A"
trip_1	06:35:00	06:35:00	stop_A	6	""

दो हेडसाइन वाली दोतरफ़ा यात्रा:

Trip_id	arrival_time	departure_time	stop_id	stop_sequence	stop_headsign
trip_1	06:10:00	06:10:00	stop_A	1	"outbound"
trip_1	06:15:00	06:15:00	stop_B	2	"outbound"
trip_1	06:20:00	06:20:00	stop_C	3	"outbound"
trip_1	06:25:00	06:25:00	stop_D	4	"inbound"
trip_1	06:30:00	06:30:00	stop_E	5	"inbound"
trip_1	06:35:00	06:35:00	stop_F	6	"inbound"
trip_1	06:40:00	06:40:00	stop_A	7	""

फ़ील्ड का नाम	सुझाव
trips.trip_id	एक यात्रा वाले लूप के लिए पूरी दोतरफ़ा यात्रा को मॉडल करें.
stop_times.stop_id	जो यात्रा एक लूप है, उसके लिए पहले/आखिरी स्टॉप को दो बार stop_times.txt में शामिल करें. नीचे उदाहरण दिया गया है. अक्सर, लूप के रास्ते में पहली और आखिरी यात्रा शामिल होती है, जो कि लूप को पूरा नहीं करतीं. ऐसी यात्राओं को भी शामिल करें. trip_id stop_id stop_sequence 9000 101 1 9000 102 2 9000 103 3 9000 101 4
trips.direction_id	अगर लूप उल्टी दिशाओं (जैसे, क्लॉकवाइज़ और काउंटरक्लॉकवाइज़) काम करता है, तो direction_id को 0 या 1 के रूप में बताएं.
trips.block_id	एक ही block_id वाली लगातार लूप यात्राओं के बारे में बताएं.

लासो आकार वाले रास्ते

लासो आकार वाले रास्तों में लूप वाले रास्ते और तय दिशा वाले रास्ते, दोनों की खासियतें होती हैं.

नीचे: लासो वाले रास्ते B से होते हुए A से A तक वाले लूप वाले रास्ते हैं. इसमें तीन सेक्शन हैं:

• A से B तक सीधा सेक्शन;
• B से और B तक लूप;
• B से A तक सीधा सेक्शन.

उदाहरण:
सबवे वाले रास्ते (शिकागो)
बस सबअर्ब से डाउनटाउन के रास्ते (सेंट ऐल्बर्ट या एडमॉन्टन)
CTA ब्राउन लाइन (CTA वेबसाइट और ट्रांज़िट फ़ीड)

फ़ील्ड का नाम	सुझाव
trips.trip_id	"वाहन की दोतरफ़ा यात्रा" के पूरे दायरे में (ऊपर मौजूद तस्वीर देखें) A से B से B और वापस A तक की यात्रा शामिल होती है. वाहन की एक पूरी दोतरफ़ा यात्रा को ऐसे बताया जा सकता है: trips.txt में अकेला trip_id मान/रिकॉर्ड trips.txt में trip_id के एक से ज़्यादा मान/रिकॉर्ड, जिनमें block_id से लगातार यात्रा का पता चल रहा हो.
stop_times.stop_headsign	A-B सेक्शन पर मौजूद स्टॉप से दोनों ही दिशाओं में गुज़रना होगा. stop_headsign की मदद से यात्रा की दिशाओं में फ़र्क़ किया जा सकता है. इसलिए, इन यात्राओं के लिए stop_headsign देना ज़रूरी है. उदाहरण: "B से होकर A" "A" शिकागो ट्रांज़िट अथॉरिटी की बैंगनी लाइन "लूप के लिए दक्षिण की तरफ़" "लूप से होकर उत्तर की तरफ़" "लिंडेन के लिए उत्तर की तरफ़" एडमॉन्टन ट्रांज़िट सर्विस बस लाइन, यहां 39 "रदरफ़ोर्ड" "सेंचुरी पार्क"
trip.trip_headsign	यात्रा का हेडसाइन, उस यात्रा का ऐसा ब्यौरा होना चाहिए जो सबको समझ आए, जैसे शेड्यूल में दिखाया गया. "लूप से होकर लिंडेन से लिंडेन तक" (शिकागो का उदाहरण) या "B से होते हुए A से A तक" (सामान्य उदाहरण).

शाखाएं

कुछ रास्तों में शाखाएं हो सकती हैं. अलाइनमेंट और स्टॉप इन दोनों शाखाओं पर पड़ते हैं. लेकिन, हर अलाइनमेंट या स्टॉप अलग-अलग स्टॉप और अलाइनमेंट सेक्शन के बारे में बताता है. शाखाओं के बीच का संबंध रास्ते के नाम (एक या ज़्यादा), हेडसाइन, और यात्रा के छोटे नाम से बताया जा सकता है. इसके लिए नीचे दिए गए दिशा-निर्देशों को मानना होगा.

नीचे: रास्ते की शाखाओं के तीन संभावित कॉन्फ़िगरेशन. पहला अलाइनमेंट काले रंग में है. शाखा का रंग सुनहरा है.

फ़ील्ड का नाम	सुझाव
सभी फ़ील्ड	यह सुझाव दिया जाता है कि शाखा वाले रास्तों का नाम रखते समय, यात्रियों की अन्य जानकारी वाली सामग्री को भी फ़ॉलो करना चाहिए. नीचे दो मामलों का ब्यौरा और उदाहरण दिए गए हैं:
अगर टाइमटेबल और सड़क पर लगे साइन से दो अलग-अलग नाम वाले रास्तों का पता चलता है (जैसे, 1A और 1B), तो जीटीएफ़एस में उसे इसी तरह बताना चाहिए. इसके लिए route_short_name और/या route_long_name फ़ील्ड का इस्तेमाल करना चाहिए. उदाहरण के लिए, GoDurham Transit के रास्तों 2, 2A, और 2B में ज़्यादातर रास्ते पर एक ही अलाइनमेंट होता है. हालांकि, वे कई अलग-अलग मायनों में एक-दूसरे से अलग हैं. रूट 2 एक मुख्य सेवा है, जिस पर ज़्यादातर समय ट्रैफ़िक चलता है. रूट 2 में रात को, रविवार को और छुट्टी के दिन मेन स्ट्रीट से थोड़ा घूमकर जाना पड़ता है. रूट 2A और 2B पर सोमवार से शनिवार दिन के समय ट्रैफ़िक रहता है. इन तीनों रास्तों के अलाइनमेंट पाथ से रूट 2B थोड़ा अलग है, क्योंकि इसमें अतिरिक्त स्टॉप हैं.
अगर एजेंसी से मिली जानकारी में शाखाओं का नाम और रास्ते का नाम एक ही है, तो trips.trip_headsign, stop_times.stop_headsign, और/या trips.trip_short_name फ़ील्ड का इस्तेमाल करें. उदाहरण के लिए, GoTriangle का रूट 300 दिन के अलग-अलग समय पर, अलग-अलग जगहों तक पहुंचता है. आवा-जाही के व्यस्त घंटों में सामान्य रास्ते पर अतिरिक्त लेग लगा दिए जाते हैं. इससे काम से लौट रहे लोगों के लिए शहर में आना और शहर से जाना आसान हो जाता है.

इस दस्तावेज़ के बारे में जानकारी

मकसद

जीटीएफ़एस के सबसे सही तरीकों को बनाए रखने के मकसद हैं:

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

प्रकाशित किए जा चुके जीटीएफ़एस के सबसे सही तरीकों में सुधार की पेशकश करने या सुधार करने का तरीका

जीटीएफ़एस के ऐप्लिकेशन और तरीके समय के साथ बदलते रहेंगे. इसलिए, इस दस्तावेज़ में समय-समय पर बदलाव हो सकते हैं. इस दस्तावेज़ में बदलाव का सुझाव देने के लिए, जीटीएफ़एस के सबसे सही तरीकों की GitHub रिपॉज़िटरी में एक पुल अनुरोध खोलें और बदलाव के बारे में बताएं. आप कोई भी टिप्पणी [e-mail] पर ईमेल भी कर सकते हैं.

इस दस्तावेज़ से लिंक करना

फ़ीड बनाने वालों को जीटीएफ़एस डेटा बनाने के लिए सही दिशा-निर्देश मिल सकें, इसके लिए कृपया यहां लिंक करें. हर एक सुझाव का एक ऐंकर लिंक होता है. सुझाव पर क्लिक करके इन-पेज ऐंकर लिंक का यूआरएल पाएं.

अगर जीटीएफ़एस का इस्तेमाल करने वाला ऐप्लिकेशन जीटीएफ़एस के सबसे सही तरीकों के लिए ऐसी ज़रूरतें या सुझाव पेश करता है जिनके बारे में यहां नहीं बताया गया है, तो हम सुझाव देते हैं कि उन ज़रूरतों के बारे में बताने वाला दस्तावेज़ प्रकाशित कर दें. इसके अलावा, सबसे सही तरीकों के साथ में और सुझावों वाला दस्तावेज़ भी प्रकाशित करें.

जीटीएफ़एस के सबसे सही तरीकों वाला कामकाजी ग्रुप

जीटीएफ़एस के सबसे सही तरीकों का कामकाजी ग्रुप, 2016-17 में रॉकी माउंटेन इंस्टिट्यूट में संगठित किया गया. इस ग्रुप में यातायात सेवा देने वाली कंपनियां, जीटीएफ़एस का इस्तेमाल करने वाले ऐप्लिकेशन, सलाहकार, और शिक्षा के क्षेत्र के संगठन शामिल थे. इन्होंने मिलकर यह बताया है कि आम तरीकों और जीटीएफ़एस डेटा के लिए किन चीज़ों की ज़रूरत है. इस कामकाजी ग्रुप के मेंबर में शामिल हैं:

• Cambridge Systematics
• कैपिटल मेट्रो
• यूनिवर्सिटी ऑफ़ साउथ फ़्लोरिडा का सेंटर फ़ॉर अर्बन ट्रांसपोर्टेशन रिसर्च
• Conveyal
• Google
• IBI Group
• Mapzen
• Microsoft
• Moovel
• ओरेगॉन डिपार्टमेंट ऑफ़ ट्रांसपोर्टेशन
• Swiftly
• Transit
• Trillium
• TriMet
• विश्व बैंक

आज, इस दस्तावेज़ की देखरेख MobilityData इंटरनैशनल ऑर्गनाइज़ेशन करता है.