मुख्य जीटीएफ़एस
सामान्य ट्रांज़िट फ़ीड नियम (जीटीएफ़एस) में सार्वजनिक परिवहन (बस, मेट्रो वगैरह) की सेवाओं के बारे में बताने के सबसे सही तरीके यहां सुझाए गए हैं. ये तरीके जीटीएफ़एस के सबसे सही तरीके कामकाजी ग्रुप के सदस्यों के अनुभव और खास ऐप्लिकेशन के लिए जीटीएफ़एस के तरीकों के सुझावों से निकलकर आए हैं. ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.
दस्तावेज़ की संरचना
तरीकों को तीन मुख्य सेक्शन में लगाया गया है:
- डेटासेट प्रकाशन और सामान्य तरीके: ये तरीके, जीटीएफ़एस डेटासेट की पूरी संरचना और जीटीएफ़एस डेटासेट को प्रकाशित करने के तरीके से जुड़े हैं.
- फ़ाइल के अनुसार व्यवस्थित सुझाए गए तरीके: जीटीएफ़एस में सुझावों को फ़ाइल और फ़ील्ड के मुताबिक व्यवस्थित किया जाता है. इससे मैप बनाने के तरीकों को वापस आधिकारिक जीटीएफ़एस रेफ़रंस तक पहुंचाया जा सके.
- केस के मुताबिक व्यवस्थित सुझाए गए तरीके: लूप वाले रास्ते जैसे कुछ खास केस में, तरीकों को एक से ज़्यादा फ़ाइल और फ़ील्ड पर लागू करना पड़ सकता है. इस तरह के सुझाव इस सेक्शन में इकट्ठा किए जाते हैं.
अक्सर पूछे जाने वाले सवाल
जीटीएफ़एस के ये सबसे सही तरीके क्यों ज़रूरी हैं?
जीटीएफ़एस के सबसे सही तरीकों के मकसद ये हैं:
- सार्वजनिक परिवहन ऐप्लिकेशन में असली उपयोगकर्ताओं के अनुभव को बेहतर बनाना
- ज़्यादा डेटा के दूसरी सुविधाओं के साथ काम करने की सेटिंग के साथ काम करना और सॉफ़्टवेयर डेवलपर के लिए ऐप्लिकेशन, प्रॉडक्ट, और सेवाओं को डिप्लॉय और स्केल करना आसान बनाना
- अलग-अलग तरह के ऐप्लिकेशन में जीटीएफ़एस को इस्तेमाल करने की सुविधा देना (यात्रा की योजना बनाने के अलावा दूसरी चीज़ों को मद्देनज़र रखते हुए)
समन्वय वाले जीटीएफ़एस के सबसे सही तरीकों के मौजूद ना होने पर, कई जीटीएफ़एस इस्तेमाल करने वाले ऐप्लिकेशन ऐसे तरीके से ज़रूरतें और उम्मीदें तय कर सकते हैं जिसमें समन्वय ना हो. इससे अलग-अलग ज़रूरतें और अलग-अलग ऐप्लिकेशन के लिए खास डेटासेट बन सकते हैं. इससे अलग-अलग तरह के ऐप्लिकेशन में जीटीएफ़एस का इस्तेमाल कम किया जा सकेगा. सबसे सही तरीकों को रिलीज़ करने से पहले ज़्यादा गलतफ़हमियां और असहमतियां थीं. इस वजह से सही तरह से बना जीटीएफ़एस डेटा मिला.
इन्हें कैसे डेवलप किया गया? इन्हें किसने डेवलप किया?
इन सबसे सही तरीकों को जीटीएफ़एस में शामिल 17 संगठनों के कामकाजी ग्रुप ने डेवलप किया. इसमें ऐप्लिकेशन सर्विस देने वाली कंपनियां और डेटा का इस्तेमाल करने वाले लोग शामिल थे. साथ ही, सार्वजनिक परिवहन की सेवा देने वाली कंपनियां, और जीटीएफ़एस में काफ़ी हद तक दख्ल रखने वाले सलाहकार भी इसका हिस्सा थे. कामकाजी ग्रुप को रॉकी माउंटेन इंस्टिट्यूट में संगठित और सम्मानित किया गया.
कामकाजी ग्रुप के सदस्यों ने हर सबसे सही तरीके के लिए वोट दिया. ज़्यादातर सबसे सही तरीकों को एकमत से मंज़ूरी दी गई. बहुत कम मामलों में, सबसे सही तरीकों को संगठनों के बहुमत के आधार पर मंज़ूरी दी गई.
सिर्फ़ जीटीएफ़एस के संदर्भ को क्यों नहीं बदला जा सकता?
अच्छा सवाल है! स्पेसिफ़िकेशन, डेटा के इस्तेमाल, और ज़रूरतों की जांच करने की प्रोसेस की वजह से स्पेसिफ़िकेशन में कुछ बदलावों की शुरुआत ज़रूर हुई (GitHub में बंद किए गए पुल के अनुरोध देखें). सबसे सही तरीकों के मुकाबले, स्पेसिफ़िकेशन के संदर्भों में किए संशोधनों के लिए ज़्यादा खोजबीन और टिप्पणियां की जाती हैं. हालांकि, इसके लिए अब भी सबसे अच्छी प्रक्रियाओं के सुझावों पर सहमति जताने की ज़रूरत थी.
कामकाजी ग्रुप ने अनुमान लगाया है कि जीटीएफ़एस के कुछ सबसे सही तरीके समय के साथ मुख्य जीटीएफ़एस संदर्भ का हिस्सा बन जाएंगे.
क्या जीटीएफ़एस के पुष्टि करने वाले टूल सबसे सही तरीकों के पालन की भी पुष्टि करते हैं?
फ़िलहाल, पुष्टि करने वाला कोई भी टूल यह जांच नहीं करता कि सबसे सही तरीकों का पालन हो रहा है या नहीं. पुष्टि करने वाले अलग-अलग टूल कुछ सबसे सही तरीकों के पालन होने की जांच करते हैं. जीटीएफ़एस के पुष्टि करने वाले लोगों की सूची के लिए टेस्टिंग फ़ीड देखें. अगर आप एक ऐसा जीटीएफ़एस का पुष्टि करने वाला टूल लिख रहे हैं जो इन सबसे सही तरीकों का संदर्भ लेता है, तो gtfs@rmi.org पर ईमेल करें.
मैं एक सार्वजनिक परिवहन एजेंसी से हूं. अपनी सॉफ़्टवेयर सर्विस देने वाली कंपनियों और विक्रेताओं से इन सबसे सही तरीकों का पालन करवाने के लिए मुझे क्या करना चाहिए?
अपने विक्रेता या सॉफ़्टवेयर सेवा देने वाली कंपनी को ये सबसे सही तरीके बताएं. हमारा सुझाव है कि आप जीटीएफ़एस के सबसे सही तरीकों के यूआरएल का संदर्भ दें. साथ ही, जीटीएफ़एस बनाने वाले सॉफ़्टवेयर की खरीद में मौजूद मुख्य स्पेसिफ़िकेशन संदर्भ का भी इस्तेमाल करें.
अगर मुझे पता चलता है कि कोई जीटीएफ़एस डेटा फ़ीड सबसे सही तरीकों का पालन नहीं करती, तो मुझे क्या करना चाहिए?
feed_info.txt
में अगर प्रस्तावित feed_contact_email
या feed_contact_url
मौजूद हों, तो उनका इस्तेमाल करके या सार्वजनिक परिवहन एजेंसी या फ़ीड बनाने वाली वेबसाइट की संपर्क जानकारी खोजकर, फ़ीड के संपर्क की पहचान करें. फ़ीड बनाने वाली वेबसाइट को समस्या बताते समय, उस जीटीएफ़एस के सबसे सही तरीके का लिंक दें जिस पर चर्चा हो रही है. इस दस्तावेज़ से लिंक करना देखें.
मुझे सबसे सही तरीकों में कुछ सुधार करवाना/ जुड़वाना है. यह कैसे होगा?
gtfs@rmi.org को ईमेल करें या कोई समस्या खोलें या GitHub के जीटीएफ़एस सबसे सही तरीके रेपो में पुल अनुरोध करें.
शामिल होने के लिए क्या करना होगा?
gtfs@rmi.org पर ईमेल भेजें.
डेटासेट प्रकाशन और आम तरीके
आम सुझाव |
---|
डेटासेट को एक सार्वजनिक और हमेशा मौजूद रहने वाले यूआरएल पर प्रकाशित करना चाहिए. इसमें zip फ़ाइल का नाम भी होना चाहिए. (उदाहरण, www.agency.org/gtfs/gtfs.zip). आम तौर पर, यूआरएल ऐसा होना चाहिए जिसे सीधे डाउनलोड किया जा सके. इसका इस्तेमाल करने वाले सॉफ़्टवेयर ऐप्लिकेशन को फ़ाइल ऐक्सेस करके डाउनलोड करने के लिए लॉग इन करने की ज़रूरत ना पड़े. किसी जीटीएफ़एस डेटासेट को खुले तौर पर डाउनलोड किया जा सकने वाला बनाने का सुझाव दिया जाता है (और यह सबसे आम तरीका भी है). हालांकि, अगर कोई डेटा सर्विस देने वाली कंपनी जीटीएफ़एस की लाइसेंसिंग या दूसरी वजहों से उसका ऐक्सेस नियंत्रित करना चाहती है, तो हम API (एपीआई) कुंजियों का इस्तेमाल करके नियंत्रित करने का सुझाव देते हैं. इससे ऑटोमेटिक डाउनलोड हो सकेंगे. |
जीटीएफ़एस डेटा को दोहरा-दोहराकर प्रकाशित किया जाता है. इससे एक स्थिर लोकेशन पर एक फ़ाइल में किसी सार्वजनिक परिवहन एजेंसी (एक या ज़्यादा) की सेवा का आधिकारिक ब्यौरा हमेशा मौजूद रहता है. |
जहां भी हो सके, डेटा के हर दोहराव में stop_id , route_id , और agency_id के लिए लगातार पहचानकर्ता (आईडी फ़ील्ड) बरकरार रखें. |
एक जीटीएफ़एस डेटासेट में मौजूदा और आने वाली सेवा (कभी-कभी इसे "मर्ज किया गया" डेटासेट कहते हैं) होनी चाहिए. Google ट्रांज़िटफ़ीड टूल की मर्ज करने की सुविधा का इस्तेमाल करके दो अलग-अलग जीटीएफ़एस फ़ीड से एक मर्ज किया गया डेटासेट बना सकते हैं.
|
फ़ीड से पुरानी सेवाएं (खत्म हो चुके कैलेंडर) हटाएं. |
अगर सेवा में बदलाव अगले सात दिनों या उससे कम समय में होने वाला है, तो जीटीएफ़एस-रीयलटाइम फ़ीड (सेवा से जुड़ी सलाह या यात्रा का अपडेट) से बदलाव की जानकारी दें, ना कि स्टैटिक जीटीएफ़एस डेटासेट से. |
जीटीएफ़एस डेटा को होस्ट करने वाले वेब सर्वर को इस तरह से कॉन्फ़िगर किया जाना चाहिए कि वह फ़ाइल में बदलाव की सही तारीख बताए (सेक्शन 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_lat और stop_lon |
स्टॉप की लोकेशन जितनी सटीक हो सके, उतनी होनी चाहिए. स्टॉप की जो लोकेशन दी जाए, उसमें और असल स्टॉप की पोज़िशन में चार मीटर से ज़्यादा का अंतर नहीं होना चाहिए. | ||||||||
स्टॉप की लोकेशन पैदल यात्रियों के रास्ते के बहुत पास होनी चाहिए, जहां से कोई यात्री सवार होगा (यानी, सड़क की सही साइड पर). | |||||||||
अगर स्टॉप की कोई लोकेशन अलग-अलग डेटा फ़ील्ड में शेयर की गई है (यानी, दो एजेंसी एक ही स्टॉप / बोर्डिंग की सुविधा का इस्तेमाल करती हैं), तो दोनों स्टॉप के लिए बताएं कि स्टॉप का इस्तेमाल वे ही दोनों stop_lat और stop_lon कर रहे हैं. |
|||||||||
stop_code |
अगर यात्रियों को स्टॉप नंबर या छोटे पहचानकर्ता दिखाए जाने वाले हैं, तो जीटीएफ़एस में stop_code को शामिल किया जाना चाहिए. |
||||||||
parent_station और location_type |
कई स्टेशन और टर्मिनल पर एक से ज़्यादा बोर्डिंग की सुविधाएं होती हैं (वाहन के आधार पर उन्हें बस बे, प्लैटफ़ॉर्म, जेटी, गेट या किसी और नाम से बुलाया जाता है). ऐसे मामलों में, फ़ीड बनाने वालों को स्टेशन, बोर्डिंग की सुविधाओं (जिन्हें चाइल्ड स्टॉप भी कहते हैं), और वे कैसे एक-दूसरे से जुड़े हैं यह बताना चाहिए.
|
||||||||
स्टेशन और चाइल्ड स्टॉप का नाम रखते समय, वे नाम सेट करें जिन्हें यात्री अच्छे से पहचानते हों, और यात्रियों की स्टेशन और बोर्डिंग की सुविधा (बस बे, प्लैटफ़ॉर्म, जेटी, गेट वगैरह) को पहचानने में मदद करें.
|
routes.txt
फ़ील्ड का नाम | सुझाव | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
अगर इसे agency.txt में परिभाषित किया गया है, तो शामिल किया जाना चाहिए. |
||||||||||||||||||||
route_short_name |
अगर सेवा कुछ समय के लिए दी गई है, तो route_short_name शामिल करें. यह एक जाना-पहचाना नाम होना चाहिए, जिसे यात्री पहचानते हों. यह 12 वर्णों से ज़्यादा का नहीं होना चाहिए. |
||||||||||||||||||||
route_long_name |
स्पेसिफ़िकेशन संदर्भ से परिभाषा: यह नाम आम तौर परतय करें और इस फ़ील्ड के मान के तौर पर एक खाली स्ट्रिंग का इस्तेमाल करें. लंबे नाम किस-किस तरह के हो सकते हैं, ये उदाहरण नीचे दिए गए हैं:
|
||||||||||||||||||||
route_long_name में route_short_name शामिल नहीं होना चाहिए. |
|||||||||||||||||||||
पॉप्युलेट करते समय किसी सेवा की पहचान का पूरा पद शामिल करें
route_long_name . उदाहरण:
|
|||||||||||||||||||||
route_id |
किसी दिए गए नामी रास्ते के लिए सभी यात्रा एक ही route_id से संदर्भित होनी चाहिए.
|
||||||||||||||||||||
अगर रास्तों के किसी ग्रुप में अलग-अलग नाम वाली शाखाएं (जैसे, 1A और 1B) शामिल हों, तो रास्ते की शाखाओं के मामले में route_short_name और route_long_name बताने के बारे में दिए गए सुझाव मानें. |
|||||||||||||||||||||
route_color और route_text_color |
यह निशानों और उस जानकारी जैसे ही होने चाहिए जो ग्राहकों के लिए प्रिंट की गई है और ऑनलाइन मौजूद है (और इसलिए, अगर वह दूसरी जगहों पर मौजूद नहीं है, तो उसे शामिल नहीं किया जाना चाहिए). |
trips.txt
- लूप वाले रास्तों के लिए खास मामला देखें लूप वाले रास्ते ऐसे मामले हैं जिनमें यात्रा एक ही जगह से शुरू होती है और वहीं पर खत्म. ये लीनियर रास्तों से अलग होते हैं जिनमें दोनों टर्मिनल अलग-अलग होते हैं. लूप वाले रास्तों को कुछ खास तरीकों से बताना चाहिए. लूप वाले रास्तों का मामला देखें.
- लासो आकार के रास्तों के लिए खास केस देखें लासो आकार के रास्ते लीनियर और लूप वाले रास्तों का मिला-जुला रूप होते हैं. इनमें वाहन रास्ते के एक ही हिस्से में लूप की तरह चलते हैं. लासो आकार के रास्तों को कुछ खास तरीकों से बताया जाना चाहिए. लासो आकार के रास्तों का मामला देखें.
फ़ील्ड का नाम | सुझाव | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
trip_headsign या stop_headsign फ़ील्ड में रास्तों के नाम (route_short_name और
route_long_name से मेल खाने वाले) ना दें. |
||||||||||||||
इनमें मंज़िल, दिशा और/या अन्य तरह की यात्राओं के बारे में बताने वाला टेक्स्ट शामिल होना चाहिए जो वाहन के हेडसाइन में दिखाई देता हो. इससे एक रास्ते पर अलग-अलग यात्राओं में फ़र्क़ करने में मदद मिलती है.
वाहन पर दिखाई गई दिशा की जानकारी से मेल खाना सबसे पहला और अहम लक्ष्य है जिससे जीटीएफ़एस डेटासेट में दिए गए हेडसाइन के बारे में बताया जा सकता है. अगर यह पहला लक्ष्य पूरा हो रहा है, तब ही बाकी की जानकारी शामिल की जानी चाहिए. अगर यात्रा के दौरान हेडसाइन बदलते हैं, तो stop_times.stop_headsign को trip_headsign से ओवरराइड करें. कुछ संभव मामलों के लिए नीचे सुझाव दिए गए हैं: |
|||||||||||||||
example_table:
|
|||||||||||||||
किसी भी हेडसाइन को "के लिए" या "की तरफ़" से शुरू ना करें. | |||||||||||||||
direction_id |
अगर किसी रास्ते की यात्रा उल्टी दिशाओं में चलती हैं, तो यात्रा के इन ग्रुप को direction_id फ़ील्ड की मदद से अलग करें. इसके लिए 0 और 1 मान इस्तेमाल करें. |
||||||||||||||
पूरे डेटासेट में 0 और 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 |
नीचे दिए गए मामलों में, "दक्षिण की ओर" ग्राहकों को गुमराह कर सकता है, क्योंकि इसे स्टेशन के साइन में इस्तेमाल नहीं किया गया है. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
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 |
अगर किसी अलाइनमेंट में लूप या इनलाइन मौजूद हैं (वाहन एक यात्रा में अलाइनमेंट की एक ही जगह से होकर गुज़रता है), तो इसे अगर यात्रा के दौरान कोई वाहन रास्ते में कुछ जगहों पर अलाइनमेंट पर से गुज़रता है, तो |
shape_dist_traveled फ़ील्ड की मदद से एजेंसी बता पाती है कि stop_times.txt में मौजूद स्टॉप किस तरह अपने आकार में फ़िट होते हैं. shape_dist_traveled फ़ील्ड के लिए आम तौर पर इस्तेमाल किए जाने वाले मानों में से एक है वाहन ने जिस आकार में सफ़र किया है, उसकी शुरुआत वाली जगह से मापी जाने वाली दूरी (ऐसा समझें कि यह किसी ओडोमीटर की रीडिंग है).
|
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 |
अगर ट्रांसफ़र के एक से ज़्यादा मौके हैं और उनमें से कोई सबसे अच्छा है (जैसे, अतिरिक्त सुविधाओं वाला ट्रांज़िट सेंटर या साथ लगी या जुड़ी हुई बोर्डिंग सुविधाओं/प्लैटफ़ॉर्म वाला स्टेशन), तो कोई सुझाया गया ट्रांसफ़र पॉइंट बताएं. |
ट्रांसफ़र का यह प्रकार भरोसेमंद तरीके से ट्रांसफ़र करने के लिए एक ज़रूरी समय अवधि को ओवरराइड कर देता है. उदाहरण के तौर पर, Google Maps मानता है कि सुरक्षित रूप से ट्रांसफ़र होने के लिए यात्रियों को तीन मिनट लगते हैं. दूसरे ऐप्लिकेशन कुछ और डिफ़ॉल्ट मान सकते हैं. |
|
अगर कोई रुकावट है या कोई दूसरी वजह है जिससे स्टॉप के बीच की यात्रा का समय बढ़ सकता हो, तो ट्रांसफ़र में लगने वाला कम से कम समय बताएं. |
|
अगर भौतिक रुकावटों की वजह से ट्रांसफ़र नहीं हो सकते या अगर पार करने के लिए मुश्किल सड़कों या फ़ुटपाथ टूटे होने की वजह से वे असुरक्षित या मुश्किल बन गए हैं, तो यह मान बताएं. |
|
अगर यात्राओं में इन-सीट (ब्लॉक) ट्रांसफ़र की अनुमति है, तो आने की यात्रा का आखिरी स्टॉप वही होना चाहिए जो जाने की यात्रा का पहला स्टॉप है. |
केस के अनुसार व्यवस्थित किए गए तरीकों के सुझाव
इस सेक्शन में सभी फ़ाइल और फ़ील्ड में खास केस और उनके नतीजों पर बात की गई है.
लूप वाले रास्ते
लूप वाले रास्तों पर, वाहनों की यात्रा एक ही लोकेशन से शुरू होकर उसी पर खत्म होती है (कई बार यह सार्वजनिक परिवहन या ट्रांसफ़र सेंटर होता है). वाहन आम तौर पर लगातार चलते रहते हैं. वाहन के लूप में चलना जारी रखने पर यात्रियों को उसमें सवार रहने दिया जाता है.
इसलिए हेडसाइन के सुझाव लगाए जाने चाहिए, ताकि सवारियों को पता रहे कि वाहन किस तरफ़ जा रहा है.
यात्रा की दिशा बदलने के बारे में बताने के लिए 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 में शामिल करें. नीचे उदाहरण दिया गया है. अक्सर, लूप के रास्ते में पहली और आखिरी यात्रा शामिल होती है, जो कि लूप को पूरा नहीं करतीं. ऐसी यात्राओं को भी शामिल करें.
|
|||||||||||||||
trips.direction_id |
अगर लूप उल्टी दिशाओं (जैसे, क्लॉकवाइज़ और काउंटरक्लॉकवाइज़) काम करता है, तो direction_id को 0 या 1 के रूप में बताएं. |
|||||||||||||||
trips.block_id |
एक ही block_id वाली लगातार लूप यात्राओं के बारे में बताएं. |
लासो आकार वाले रास्ते
लासो आकार वाले रास्तों में लूप वाले रास्ते और तय दिशा वाले रास्ते, दोनों की खासियतें होती हैं.
- 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 देना ज़रूरी है.
|
||||||||||
trip.trip_headsign |
यात्रा का हेडसाइन, उस यात्रा का ऐसा ब्यौरा होना चाहिए जो सबको समझ आए, जैसे शेड्यूल में दिखाया गया. "लूप से होकर लिंडेन से लिंडेन तक" (शिकागो का उदाहरण) या "B से होते हुए A से A तक" (सामान्य उदाहरण). |
शाखाएं
कुछ रास्तों में शाखाएं हो सकती हैं. अलाइनमेंट और स्टॉप इन दोनों शाखाओं पर पड़ते हैं. लेकिन, हर अलाइनमेंट या स्टॉप अलग-अलग स्टॉप और अलाइनमेंट सेक्शन से होता है. शाखाओं के बीच का संबंध रास्ते के नाम (एक या ज़्यादा), हेडसाइन, और यात्रा के छोटे नाम से बताया जा सकता है. इसके लिए नीचे दिए गए दिशा-निर्देशों को मानना होगा.
फ़ील्ड का नाम | सुझाव |
---|---|
सभी फ़ील्ड | यह सुझाव दिया जाता है कि शाखा वाले रास्तों का नाम रखते समय, यात्रियों की अन्य जानकारी वाली सामग्री का पालन भी करना चाहिए. नीचे दो मामलों का ब्यौरा और उदाहरण दिए गए हैं: |
अगर टाइमटेबल और सड़क पर लगे साइन से दो अलग-अलग नाम वाले रास्तों का पता चलता है (जैसे, 1A और
1B), तो जीटीएफ़एस में उसे इसी तरह बताना चाहिए. इसके लिए route_short_name और/या route_long_name फ़ील्ड का इस्तेमाल करना चाहिए. उदाहरण के लिए, GoDurham Transit के रास्तों 2, 2A, और 2B में ज़्यादातर रास्ते पर एक ही अलाइनमेंट होता है. हालांकि, वे कई अलग-अलग मायनों में एक-दूसरे से अलग हैं.
|
|
अगर एजेंसी से मिली जानकारी में शाखाओं का नाम और रास्ते का नाम एक ही है, तो trips.trip_headsign , stop_times.stop_headsign , और/या trips.trip_short_name फ़ील्ड का इस्तेमाल करें. उदाहरण के लिए, GoTriangle का रूट 300 दिन के अलग-अलग समय पर, अलग-अलग जगहों तक पहुंचता है. आवा-जाही के व्यस्त घंटों में सामान्य रास्ते पर अतिरिक्त लेग लगा दिए जाते हैं. इससे काम से लौट रहे लोगों के लिए शहर में आना और शहर से जाना आसान हो जाता है. |
इस दस्तावेज़ के बारे में जानकारी
मकसद
जीटीएफ़एस के सबसे सही तरीकों को बनाए रखने के मकसद हैं:
- सार्वजनिक परिवहन के डेटा को दूसरी सुविधाओं के साथ काम करने के लिए सहज बनाना
- सार्वजनिक परिवहन ऐप्लिकेशन में असली उपयोगकर्ताओं के अनुभव को बेहतर बनाना
- सॉफ़्टवेयर डेवलपर के लिए ऐप्लिकेशन, प्रॉडक्ट, और सेवाओं को डिप्लॉय और स्केल करना आसान बनाना.
- अलग-अलग तरह के ऐप्लिकेशन में जीटीएफ़एस को इस्तेमाल करने की सुविधा देना (यात्रा की योजना बनाने के अलावा दूसरी चीज़ों को मद्देनज़र रखते हुए)
प्रकाशित किए जा चुके जीटीएफ़एस के सबसे सही तरीकों में सुधार की पेशकश करने या सुधार करने का तरीका
जीटीएफ़एस के ऐप्लिकेशन और तरीके समय के साथ बदलते रहेंगे. इसलिए, इस दस्तावेज़ में समय-समय पर बदलाव हो सकते हैं. इस दस्तावेज़ में बदलाव का सुझाव देने के लिए, जीटीएफ़एस के सबसे सही तरीकों की GitHub रिपॉज़िटरी में एक पुल अनुरोध खोलें और बदलाव के बारे में बताएं. आप कोई भी टिप्पणी specifications@mobilitydata.org पर ईमेल भी कर सकते हैं.
इस दस्तावेज़ से लिंक करना
फ़ीड बनाने वालों को जीटीएफ़एस डेटा बनाने के लिए सही दिशा-निर्देश मिल सकें, इसके लिए कृपया यहां लिंक करें. हर एक सुझाव का एक ऐंकर लिंक होता है. सुझाव पर क्लिक करके इन-पेज ऐंकर लिंक का यूआरएल पाएं.
अगर जीटीएफ़एस का इस्तेमाल करने वाला ऐप्लिकेशन जीटीएफ़एस के सबसे सही तरीकों के लिए ऐसी ज़रूरतें या सुझाव पेश करता है जिनके बारे में यहां नहीं बताया गया है, तो हम सुझाव देते हैं कि उन ज़रूरतों के बारे में बताने वाला दस्तावेज़ प्रकाशित कर दें. इसके अलावा, सबसे सही तरीकों के साथ में और सुझावों वाला दस्तावेज़ भी प्रकाशित करें.
जीटीएफ़एस के सबसे सही तरीकों वाला कामकाजी ग्रुप
जीटीएफ़एस के सबसे सही तरीकों का कामकाजी ग्रुप, 2016-17 में रॉकी माउंटेन इंस्टिट्यूट में संगठित किया गया. इन ग्रुप में यातायात सेवा देने वाली कंपनियां, जीटीएफ़एस का इस्तेमाल करने वाले ऐप्लिकेशन, सलाहकार, और शिक्षा के क्षेत्र के संगठन शामिल थे. इन्होंने मिलकर आम तरीकों और जीटीएफ़एस डेटा के लिए किन चीज़ों की ज़रूरत है, इस बारे में बताया है. इस कामकाजी ग्रुप के मेंबर में शामिल हैं:
- Cambridge Systematics
- कैपिटल मेट्रो
- सेंटर फ़ॉर अर्बन ट्रांसपोर्टेशन रिसर्च ऐट यूनिवर्सिटी ऑफ़ साउथ फ़्लोरिडा
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- ओरेगॉन डिपार्टमेंट ऑफ़ ट्रांसपोर्टेशन
- Swiftly
- Transit
- Trillium
- TriMet
- विश्व बैंक
आज, इस दस्तावेज़ की देखरेख MobilityData इंटरनैशनल ऑर्गनाइज़ेशन करता है.