संदर्भ

इस दस्तावेज़ में उन फ़ाइलों के फ़ॉर्मैट और स्ट्रक्चर के बारे में बताया गया है जिनमें जीटीएफ़एस डेटासेट शामिल है.

विषय-सूची

1. शब्दों के मतलब
2. फ़ील्ड के टाइप
3. डेटासेट वाली फ़ाइलें
4. फ़ाइल की ज़रूरतें
5. फ़ील्ड के मतलब
   • agency.txt
   • stops.txt
   • routes.txt
   • trips.txt
   • stop_times.txt
   • calendar.txt
   • calendar_dates.txt
   • fare_attributes.txt
   • fare_rules.txt
   • shapes.txt
   • frequencies.txt
   • transfers.txt
   • pathways.txt
   • levels.txt
   • feed_info.txt
   • translations.txt
   • attributions.txt

शब्दों के मतलब

इस सेक्शन में उन शब्दों के बारे में बताया गया है जो इस दस्तावेज़ में इस्तेमाल हुए हैं.

• डेटासेट - ऐसी फ़ाइलों का पूरा सेट जिनके बारे में इस विशेषता के तहत बताया गया है. डेटासेट में बदलाव करने पर, डेटासेट का नया वर्शन बन जाता है. डेटासेट को एक सार्वजनिक और हमेशा मौजूद रहने वाले यूआरएल पर प्रकाशित करना चाहिए. इसमें zip फ़ाइल का नाम भी होना चाहिए. (उदाहरण के लिए, https://www.agency.org/gtfs/gtfs.zip).
• रिकॉर्ड - अलग-अलग फ़ील्ड वैल्यू से बना एक बुनियागी डेटा स्ट्रक्चर जो एक इकाई (उदाहरण के लिए, सार्वजनिक परिवहन एजेंसी, स्टॉप, रूट वगैरह) के बारे में जानकारी देता है. टेबल में, एक लाइन के तौर पर दिखाया जाता है.
• फ़ील्ड - किसी ऑब्जेक्ट या इकाई की प्रॉपर्टी. टेबल में, एक कॉलम के तौर पर दिखाया जाता है.
• फ़ील्ड की वैल्यू - फ़ील्ड में डाली गई वैल्यू. टेबल में, एक सेल के तौर पर दिखाया जाता है.
• ज़रूरी फ़ील्ड - फ़ील्ड को डेटासेट में शामिल करना ज़रूरी है. साथ ही, हर रिकॉर्ड के लिए उस फ़ील्ड में एक वैल्यू देनी भी ज़रूरी है. कुछ ज़रूरी फ़ील्ड में, वैल्यू के तौर पर स्ट्रिंग को खाली छोड़ने की अनुमति होती है (इस विशेषता को खाली के तौर पर दिखाया गया है). खाली स्ट्रिंग डालने के लिए, उस फ़ील्ड में दर्ज कॉमा के बीच में मौजूद टेक्स्ट को हटा दें.
• वैकल्पिक - फ़ील्ड को डेटासेट से हटाया जा सकता है. अगर कोई वैकल्पिक कॉलम शामिल किया गया है, तो उस फ़ील्ड में कुछ एंट्री खाली स्ट्रिंग के तौर पर रखी जा सकती हैं. खाली स्ट्रिंग डालने के लिए, उस फ़ील्ड में दर्ज कॉमा के बीच में मौजूद टेक्स्ट को हटा दें. ध्यान रखें कि छोड़ा गया फ़ील्ड उस फ़ील्ड के बराबर है, जो पूरी तरह खाली है.
• शर्त के मुताबिक ज़रूरी फ़ील्ड - कुछ शर्तों के तहत इस फ़ील्ड या फ़ाइल का होना ज़रूरी है. फ़ील्ड या फ़ाइल की जानकारी में इन शर्तों के बारे में बताया गया होता है. इन शर्तों के अलावा, इस फ़ील्ड या फ़ाइल का होना ज़रूरी नहीं होता.
• सेवा का दिन - सेवा का दिन वह अवधि है जिसका इस्तेमाल रूट शेड्यूलिंग दिखाने के लिए होता है. सेवा के दिन की सटीक परिभाषा, हर एजेंसी के हिसाब से अलग-अलग होती है, लेकिन सेवा के दिन अक्सर कैलेंडर के दिन के हिसाब से नहीं होते हैं. अगर सेवा एक दिन शुरू होती है और अगले दिन खत्म होती है, तो सेवा का दिन 24:00:00 से ज़्यादा हो सकता है. उदाहरण के लिए, कोई सेवा अगर शुक्रवार को 08:00:00 बजे से शनिवार को 02:00:00 तक चलती है, तो उसका एक सेवा दिन 08:00:00 से 26:00:00 के तौर पर दिखाया जाता है.

फ़ील्ड के टाइप

• रंग - रंग जिसे छह अंकों के हेक्साडेसिमल नंबर के तौर पर एन्कोड किया जाता है. सही वैल्यू जनरेट करने के लिए https://htmlcolorcodes.com पर जाएं (इसके आगे दिया गया "#" कोड का हिस्सा नहीं है).
  उदाहरण: सफ़ेद रंग के लिए FFFFFF, काले रंग के लिए 000000 या NYMTA में A,C,E लाइनों के लिए 0039A6.
• मुद्रा कोड - ISO 4217 वर्णमाला से बना मुद्रा कोड. मौजूदा मुद्रा की सूची के लिए, https://en.wikipedia.org/wiki/ISO_4217#Active_codes देखें.
  उदाहरण: कैनेडियन डॉलर के लिए CAD, यूरो के लिए EUR या जापानी येन के लिए JPY.
• तारीख - YYYYMMDD फ़ॉर्मैट में सेवा का दिन. सेवा के एक दिन की अवधि 24:00:00 से ज़्यादा हो सकती है, इसलिए सेवा के एक दिन में अक्सर अगले दिन (दिनों) की जानकारी शामिल होती है.
  उदाहरण: 13 सितंबर, 2018 के लिए 20180913.
• ईमेल - एक ईमेल पता.
  उदाहरण: [e-mail]
• Enum - एक विकल्प, जो "ब्यौरा" कॉलम में पहले से तय वैल्यू (न बदलने वाला अंक) के सेट से मिलता है.
  उदाहरण: route_type फ़ील्ड में ट्राम के लिए 0 है, सबवे के लिए 1...
• आईडी - आईडी फ़ील्ड की वैल्यू एक अंदरूनी आईडी है, जो यात्रियों को नहीं दिखाई देता है. यह UTF-8 वर्णों से बना एक क्रम होता है. हमारा सुझाव है कि सिर्फ़ ऐसे ASCII वर्णों का इस्तेमाल करें जो प्रिंट किए जा सकें. एक .txt फ़ाइल में दिए गए आईडी का संदर्भ अक्सर दूसरी .txt फ़ाइल में लिया जाता है.
  उदाहरण: stops.txt का stop_id फ़ील्ड एक आईडी है. stop_times.txt का stop_id फ़ील्ड, stops.stop_id से संदर्भ लेने वाला एक आईडी है.
• भाषा कोड - एक आईईटीएफ़ BCP 47 वाला भाषा कोड. आईईटीएफ़ BCP 47 के बारे में जानने के लिए, http://www.rfc-editor.org/rfc/bcp/bcp47.txt और http://www.w3.org/International/articles/language-tags/ देखें.
  उदाहरण: अंग्रेज़ी के लिए en, अमेरिकी अंग्रेज़ी के लिए en-US या जर्मन के लिए de.
• अक्षांश - दशमलव डिग्री में WGS84. इसकी वैल्यू -90.0 के बराबर या इससे ज़्यादा और 90.0 के बराबर या इससे कम होनी चाहिए.
  उदाहरण: रोम में कलॉसियम के लिए 41.890169.
• देशांतर - दशमलव डिग्री में WGS84. इसकी वैल्यू -180.0 के बराबर या इससे ज़्यादा और 180.0 के बराबर या इससे कम होनी चाहिए.
  उदाहरण: रोम में कलॉसियम के लिए 12.492269.
• सकारात्मक फ़्लोट - एक फ़्लोटिंग पॉइंट संख्या 0 से ज़्यादा या उसके बराबर.
• सकारात्मक पूर्णांक - एक पूर्णांक, जो 0 के बराबर या उससे ज़्यादा हो.
• फ़ोन नंबर: - एक फ़ोन नंबर.
• समय - HH:MM:SS फ़ॉर्मैट में समय (H:MM:SS फ़ॉर्मैट भी स्वीकार किया जाता है). सेवा के दिन के समय को "दोपहर के 12 बजे से 12 घंटे पहले" तक मापा जाता है (आम तौर पर, यह आधी रात यानी रात 12 बजे का समय होता है, उन दिनों को छोड़कर जब डेलाइट सेविंग समय बदलता है. ज़्यादा जानकारी के लिए, दिशा-निर्देश लेख) देखें. आधी रात के बाद आने वाले समय के लिए, समय को HH:MM:SS फ़ॉर्मैट में ऐसी वैल्यू के तौर पर डालें, जो स्थानीय समय के 24:00:00 से ज़्यादा हो. यह उस दिन के लिए होगी, जिस दिन यात्रा का शेड्यूल शुरू होगा.
  उदाहरण: दिन के 2:30 बजे 14:30:00 या अगले दिन, रात के 1:35 बजे के लिए 25:35:00.
• टेक्स्ट - UTF-8 वर्णों वाली स्ट्रिंग होती है, जो दिखाई जाती है. इसका फ़ॉर्मैट ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके.
• समय क्षेत्र - https://www.iana.org/time-zones से लिया गया TZ समय क्षेत्र. समय क्षेत्र के नाम में स्पेस नहीं होना चाहिए, हालांकि उसमें अंडरस्कोर हो सकता है. सही वैल्यू की सूची के लिए, http://en.wikipedia.org/wiki/List_of_tz_zones देखें.
  उदाहरण: Asia/Tokyo, America/Los_Angeles या Africa/Cairo.
• यूआरएल - एक पूरी तरह-क्वालिफ़ाइड यूआरअल, जिसमें http:// या https:// हो. साथ ही, उसमें मौजूद विशेष वर्णों को सही तरीके से मार्क किया गया हो, ताकि उन्हें यूआरएल के हिस्से के तौर पर नहीं, बल्कि अलग पढ़ा जा सके. पूरी तरह से सही यूआरएल बनाने के बारे में जानने के लिए, http://www.w3.org/Addressing/URL/4_URI_Recommentations.html देखें.

डेटासेट वाली फ़ाइलें

यह विशेषता इन फ़ाइलों के बारे में बताती है:

फ़ाइल का नाम	ज़रूरी है	बताता है
agency.txt	ज़रूरी है	सार्वजनिक परिवहन एजेंसियों को, उनकी तरफ़ से दी जाने वाली सेवा के साथ इस डेटासेट में दिखाया गया है.
stops.txt	ज़रूरी है	वे स्टॉप जहां से वाहन यात्री को बैठाते या छोड़ते हैं. स्टेशन और उसमें अंदर आने के दरवाज़े के बारे में भी बताता है.
routes.txt	ज़रूरी है	सार्वजनिक परिवहन के रास्ते. रास्ता, ऐसी यात्राओं का समूह है जिसे यात्रियों को एक सेवा के तौर पर दिखाया जाता है.
trips.txt	ज़रूरी है	हर रास्ते के लिए यात्राएं. यात्रा का मतलब होता है, किसी बताई गई समयावधि के दौरान आने वाले दो या दो से ज़्यादा स्टॉप का क्रम.
stop_times.txt	ज़रूरी है	हर यात्रा के लिए, गाड़ी के स्टॉप पर पहुंचने और वहां से निकलने का समय.
calendar.txt	कुछ शर्तों के मुताबिक ज़रूरी है	सेवा के दिन, हफ़्ते के हिसाब से शेड्यूल करके बताए जाते हैं. इनमें शुरू और खत्म होने की तारीख दर्ज होती हैं. अगर calendar_dates.txt में सेवा की सभी तारीखें नहीं दी गई हैं, तो इस फ़ाइल की ज़रूरत होगी.
calendar_dates.txt	कुछ शर्तों के मुताबिक ज़रूरी है	calendar.txt में बताई गई सेवाओं के अपवाद. अगर calendar.txt नहीं है, तो calendar_dates.txt ज़रूरी है और इसमें सेवा की सभी तारीखें होनी चाहिए.
fare_attributes.txt	ज़रूरी नहीं	उन रास्तों के लिए किराये की जानकारी जहां सार्वजनिक परिवहन एजेंसी सेवाएं देती है.
fare_rules.txt	ज़रूरी नहीं	यात्रा की योजना पर किराया लागू करने के नियम.
shapes.txt	ज़रूरी नहीं	वाहन के आने-जाने के रास्ते को तय करने वाले नियम. इन्हें रूट अलाइनमेंट भी कहा जाता है.
frequencies.txt	ज़रूरी नहीं	हेडवे वाली सेवा के लिए हेडवे (यात्राओं के बीच का समय) या पहले से तय शेड्यूल वाली सेवा के लिए कंप्रेस किया गया वर्शन.
transfers.txt	ज़रूरी नहीं	रास्तों के बीच ट्रांसफ़र पॉइंट पर कनेक्शन बनाने के नियम.
pathways.txt	ज़रूरी नहीं	स्टेशनों के बीच सभी जगहों को एक साथ जोड़ने वाले रास्ते.
levels.txt	ज़रूरी नहीं	स्टेशन के अंदर के लेवल.
feed_info.txt	कुछ शर्तों के मुताबिक ज़रूरी है	डेटासेट मेटाडेटा, जिसमें प्रकाशक, वर्शन, और खत्म होने की जानकारी शामिल है.
translations.txt	ज़रूरी नहीं	सार्वजनिक परिवहन एजेंसी की अनुवाद की गई जानकारी.
attributions.txt	ज़रूरी नहीं	डेटासेट पर लागू किए गए एट्रिब्यूशन की जानकारी देता है.

फ़ाइल की ज़रूरतें

ये ज़रूरतें डेटासेट फ़ाइलों के फ़ॉर्मैट और कॉन्टेंट पर लागू होती हैं:

• सभी फ़ाइलों को कॉमा से अलग किए गए टेक्स्ट के तौर पर सेव करना चाहिए.
• हर फ़ाइल की पहली लाइन में फ़ील्ड के नाम होने चाहिए. फ़ील्ड के मतलब सेक्शन का हर सब-सेक्शन, जीटीएफ़एस डेटासेट में मौजूद किसी एक फ़ाइल से मेल खाता है. साथ ही, उस फ़ाइल में इस्तेमाल किए जाने वाले फ़ील्ड के नामों को सूची में रखता है.
• हर फ़ील्ड का नाम केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होता है.
• फ़ील्ड वैल्यू में टैब, नई लाइन शुरू करने का निशान या नई लाइनें नहीं होनी चाहिए.
• कोट की हुई या कॉमा वाली फ़ील्ड वैल्यू को कोटेशन मार्क (चिह्न) के अंदर होना चाहिए. इसके साथ ही, फ़ील्ड वैल्यू में हर कोटेशन मार्क (चिह्न) से पहले एक कोटेशन मार्क (चिह्न) होना चाहिए. यह Microsoft Excel की कॉमा से अलग की गई (CSV) फ़ाइलों जैसा होता है. CSV फ़ाइल फ़ॉर्मैट की ज़्यादा जानकारी के लिए, http://tools.ietf.org/html/rfc4180 देखें. यह उदाहरण बताता है कि कॉमा से अलग की गई फ़ाइल में, कोई फ़ील्ड वैल्यू कैसी दिखेगी:
  • मूल फ़ील्ड वैल्यू: Contains "quotes", commas and text
  • CSV फ़ाइल में फ़ील्ड वैल्यू: "Contains ""quotes"", commas and text"
• फ़ील्ड वैल्यू में एचटीएमएल टैग, टिप्पणी या एस्केप सिक्वेंस नहीं होने चाहिए.
• फ़ील्ड या फ़ील्ड नामों के बीच से किसी भी अतिरिक्त स्पेस को हटा दें. कई पार्सर, स्पेस को वैल्यू का हिस्सा समझ लेते हैं, जिसके कारण गड़बड़ियां हो सकती हैं.
• हर लाइन को CRLF या LF लाइनब्रेक वर्ण के साथ खत्म होना चाहिए.
• सभी यूनिकोड वर्णों के साथ काम करने के लिए, फ़ाइलें UTF-8 में एन्कोड होनी चाहिए. यूनिकोड बाइट-ऑर्डर चिह्न (BOM) वर्ण वाली फ़ाइलें सही हैं. BOM वर्ण और UTF-8 के बारे में ज़्यादा जानने के लिए, http://unicode.org/faq/utf_bom.html#BOM देखें.
• सभी डेटासेट फ़ाइलों को zip करके एक साथ रखना चाहिए.

फ़ील्ड के मतलब

agency.txt

फ़ाइल: ज़रूरी

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
agency_id	आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	सार्वजनिक परिवहन के ब्रैंड के बारे में बताता है. यह ब्रैंड दरअसल सार्वजनिक परिवहन एजेंसी ही होती है. ध्यान रखें कि कुछ मामलों में, जहां एक एजेंसी अलग-अलग तरह की सेवाएं देती है वहां एजेंसी और ब्रैंड अलग-अलग होते हैं. यह दस्तावेज़ "ब्रैंड" के बजाय "एजेंसी" शब्द का इस्तेमाल करता है. डेटासेट में कई एजेंसी का डेटा हो सकता है. यह फ़ील्ड तब ज़रूरी होता है, जब डेटासेट में एक से ज़्यादा सार्वजनिक परिवहन एजेंसी का डेटा होता है. अगर ऐसा न हो, तो यह फ़ील्ड ज़रूरी नहीं होता है.
agency_name	टेक्स्ट	ज़रूरी है	सार्वजनिक परिवहन एजेंसी का पूरा नाम.
agency_url	यूआरएल	ज़रूरी है	सार्वजनिक परिवहन एजेंसी का यूआरएल.
agency_timezone	समय क्षेत्र	ज़रूरी है	समय क्षेत्र, जहां सार्वजनिक परिवहन एजेंसी है. अगर डेटासेट में एक से ज़्यादा एजेंसी हैं, तो सभी का agency_timezone एक ही होना चाहिए.
agency_lang	भाषा का कोड	ज़रूरी नहीं	वह प्राथमिक भाषा जिसका इस्तेमाल यह सार्वजनिक परिवहन एजेंसी करती है. यह फ़ील्ड जीटीएफ़एस ग्राहकों को डेटासेट के लिए कैपिटलाइज़ेशन के नियम और दूसरी खास-भाषा सेटिंग चुनने में मदद करता है.
agency_phone	फ़ोन नंबर	ज़रूरी नहीं	बताई गई एजेंसी का टेलीफ़ोन नंबर. यह फ़ील्ड एक स्ट्रिंग वैल्यू है जो एजेंसी के सेवा देने के इलाके का टेलीफ़ोन नंबर दिखाता है. इसमें नंबर की संख्याओं को ग्रुप करने के लिए विराम चिह्न हो सकते हैं और होने चाहिए. डायल किए जा सकने वाले टेक्स्ट (उदाहरण के लिए, TriMet के 503-238-RIDE) की अनुमति है, लेकिन फ़ील्ड में कोई अन्य, ब्यौरा देने वाला टेक्स्ट नहीं होना चाहिए.
agency_fare_url	यूआरएल	ज़रूरी नहीं	उस वेब पेज का यूआरएल जिसकी मदद से यात्री उस एजेंसी के टिकट या किराये से जुड़ी दूसरी चीज़ें ऑनलाइन खरीद सकते हैं.
agency_email	ईमेल	ज़रूरी नहीं	एजेंसी का ग्राहक सेवा डिपार्टमेंट हमेशा ईमेल पते पर नज़र रखता है. यह ईमेल पता संपर्क करने का ज़रिया होना चाहिए, ताकि एजेंसी के ग्राहक सेवा प्रतिनिधि से यात्री सीधे संपर्क किया जा सके.

stops.txt

फ़ाइल: ज़रूरी

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
stop_id	आईडी	ज़रूरी है	स्टॉप, स्टेशन या स्टेशन के अंदर आने वाले दरवाज़े की पहचान करता है. "स्टेशन में अंदर आने का दरवाज़ा" शब्द का मतलब स्टेशन में आने और स्टेशन से बाहर जाने वाले दरवाज़े, दोनों से है. स्टॉप, स्टेशन या स्टेशन में अंदर आने के दरवाज़ों को जगहें कहा जाता है. कई रास्ते एक ही स्टॉप का इस्तेमाल कर सकते हैं.
stop_code	टेक्स्ट	ज़रूरी नहीं	छोटा टेक्स्ट या संख्या, जो यात्रियों के लिए जगह के बारे में बताती है. इन कोड का इस्तेमाल अक्सर फ़ोन पर आधारित सार्वजनिक परिवहन की जानकारी देने वाले सिस्टम में किया जाता है. इसे साइनेज (बोर्ड वगैरह) पर भी प्रिंट किया जाता है, ताकि इसकी मदद से यात्री स्टॉप शेड्यूल या किसी खास स्टॉप पर वाहन की जानकारी आसानी से रीयल टाइम में पा सकें. यह अगर लोगों को दिखता है, तो stop_code और stop_id, दोनों एक हो सकते हैं. यह फ़ील्ड उन जगहों के लिए खाली छोड़ देना चाहिए, जिनमें यात्रियों को कोड नहीं दिखता.
stop_name	टेक्स्ट	कुछ शर्तों के मुताबिक ज़रूरी है	जगह का नाम. ऐसे नाम का इस्तेमाल करें, जिसे लोग और पर्यटक अपनी मातृभाषा और स्थानीय भाषा में समझ सकें. अगर जगह, बोर्डिंग की जगह (location_type=4) हो, तो stop_name में बोर्डिंग की जगह का नाम वैसा ही होना चाहिए जैसा एजेंसी ने दिखाया है. इसमें सिर्फ़ एक अक्षर (जैसे कुछ यूरोपीय इंटरसिटी रेलवे स्टेशन में) या "व्हीलचेयर बोर्डिंग की जगह" (न्यूयॉर्क सिटी का सबवे) या "छोटी ट्रेन का आगे का हिस्सा" (पेरिस आरईआर) जैसे टेक्स्ट हो सकते हैं. कुछ शर्तों के तहत ज़रूरी: • ऐसी जगहों के लिए ज़रूरी है जो स्टॉप (location_type=0), स्टेशन (location_type=1) या अंदर आने या बाहर जाने की जगह (location_type=2) हैं. • इस फ़ील्ड को उन जगहों के लिए भी इस्तेमाल (ज़रूरी नहीं) कर सकते हैं जो सामान्य नोड (location_type=3) या बोर्डिंग की जगह (location_type=4) हैं.
stop_desc	टेक्स्ट	ज़रूरी नहीं	उस जगह का ब्यौरा, जिससे उपयोगी और ज़रूरी जानकारी मिलती हो. किसी जगह का डुप्लीकेट नाम न बनाएं.
stop_lat	अक्षांश	कुछ शर्तों के मुताबिक ज़रूरी है	जगह का अक्षांश. कुछ शर्तों के मुताबिक ज़रूरी है: • ऐसी जगहों के लिए ज़रूरी है, जो स्टॉप (location_type=0), स्टेशन (location_type=1) या अंदर आने या बाहर जाने की जगह (location_type=2) हैं. • इस फ़ील्ड को उन जगहों के लिए भी इस्तेमाल (ज़रूरी नहीं) कर सकते हैं जो सामान्य नोड (location_type=3) या बोर्डिंग की जगह (location_type=4) हैं.
stop_lon	देशांतर	कुछ शर्तों के मुताबिक ज़रूरी है	जगह का देशांतर. कुछ शर्तों के मुताबिक ज़रूरी है: • ऐसी जगहों के लिए ज़रूरी है, जो स्टॉप (location_type=0), स्टेशन (location_type=1) या अंदर आने या बाहर जाने की जगह (location_type=2) हैं. • इस फ़ील्ड को उन जगहों के लिए भी इस्तेमाल (ज़रूरी नहीं) कर सकते हैं जो सामान्य नोड (location_type=3) या बोर्डिंग की जगह (location_type=4) हैं.
zone_id	आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	किसी स्टॉप के लिए किराये की दर के बारे में बताता है. fare_rules.txt का इस्तेमाल करके किराये की जानकारी देने के लिए यह फ़ील्ड ज़रूरी है, वरना यह वैकल्पिक है. अगर यह रिकॉर्ड कोई स्टेशन या किसी स्टेशन में अंदर आने का दरवाज़ा दिखाता है, तो zone_id को अनदेखा कर दिया जाता है.
stop_url	यूआरएल	ज़रूरी नहीं	किसी जगह की जानकारी देने वाले वेब पेज का यूआरएल. यह agency.agency_url और routes.route_url की फ़ील्ड वैल्यू से अलग होना चाहिए.
location_type	Enum	ज़रूरी नहीं	जगह किस तरह की है: • 0 (या खाली): स्टॉप (या प्लैटफ़ॉर्म). वह जगह जहां से यात्री सार्वजनिक परिवहन में बैठते हैं या उतरते हैं. इसे प्लैटफ़ॉर्म कहा जाता है, जब उसे parent_station में बताया जाता है. • 1: स्टेशन. कोई इमारत या इलाका, जिसमें एक या ज़्यादा प्लैटफ़ॉर्म हो सकते हैं. • 2: आने/जाने की जगह. वह जगह, जहां किसी रास्ते से यात्री स्टेशन में आ सकते हैं या बाहर निकल सकते हैं. अगर कई स्टेशनों में आने/बाहर जाने का एक ही दरवाज़ा है, तो यह दोनों को जोड़ने वाले पैदल रास्तों से जुड़ा हो सकता है. हालांकि, डेटा देने वाले को किसी एक स्टेशन को पैरंट स्टेशन के तौर पर चुनना होगा. • 3: सामान्य नोड. स्टेशन के अंदर की ऐसी जगह जो किसी और location_type से मेल नहीं खाती. इस जगह का इस्तेमाल pathways.txt में बताए रास्तों को साथ जोड़ने के लिए किया जा सकता है. • 4: वाहन में बैठने की जगह. प्लैटफ़ॉर्म की वह जगह, जहां से यात्री वाहनों में बैठते और/या उतरते हैं.
parent_station	stops.stop_id का संदर्भ देने वाला आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	stops.txt में बताई गई अलग-अलग जगहों के क्रम के बारे में बताता है. इसमें पैरंट जगह का आईडी शामिल होता है, जो इस तरह है: • स्टॉप/प्लैटफ़ॉर्म (location_type=0): parent_station फ़ील्ड में स्टेशन का आईडी शामिल होता है. • स्टेशन (location_type=1): यह फ़ील्ड खाली रहना चाहिए. • आने/बाहर जाने की जगह (location_type=2) या सामान्य नोड (location_type=3): parent_station फ़ील्ड में स्टेशन का आईडी होता है (location_type=1) • बोर्डिंग की जगह (location_type=4): parent_station फ़ील्ड में प्लैटफ़ॉर्म का आईडी होता है. कुछ शर्तों के मुताबिक ज़रूरी है: • ऐसी जगहों के लिए ज़रूरी है, जो आने के दरवाज़े (location_type=2), सामान्य नोड (location_type=3) या बोर्डिंग की जगह (location_type=4) हैं.• • स्टॉप/प्लैटफ़ॉर्म के लिए इस्तेमाल (ज़रूरी नहीं) कर सकते हैं (location_type=0). • स्टेशन के लिए इस्तेमाल की अनुमति नहीं है (location_type=1).
stop_timezone	समय क्षेत्र	ज़रूरी नहीं	जगह का समय क्षेत्र. अगर जगह का कोई पैरंट स्टेशन है, तो वह खुद के समय क्षेत्र की जगह पैरंट स्टेशन के समय क्षेत्र का इस्तेमाल करती है. स्टेशन और खाली stop_timezone वाले बिना पैरंट के स्टॉप उस समय क्षेत्र का इस्तेमाल करते हैं जो agency.agency_timezone में बताया गया है. अगर stop_timezone की वैल्यू दी गई है, तो stop_times.txt में, agency.agency_timezone के बताए समय क्षेत्र के हिसाब से रात 12 बजे के बाद का समय दर्ज किया जाना चाहिए. इससे यह पक्का होता है कि यात्रा में समय की वैल्यू हमेशा यात्रा के दौरान बढ़ती है, चाहे यात्रा के दौरान कोई भी समयक्षेत्र पार हुआ हो.
wheelchair_boarding	Enum	ज़रूरी नहीं	यह बताता है कि व्हीलचेयर वाले यात्री इस जगह से वाहन पर चढ़ सकते हैं या नहीं. सही विकल्प ये हैं: बिना पैरंट स्टॉप के लिए: 0 या खाली - स्टॉप के लिए व्हील चेयर लाने या ले जाने की सुविधा के बारे में कोई जानकारी नहीं. 1 - इस स्टॉप से कुछ ऐसे वाहन गुज़रते हैं जिनमें व्हीलचेयर वाले यात्री चढ़ सकते हैं. 2 - इस स्टॉप पर व्हीलचेयर से वाहन में चढ़ने की सुविधा उपलब्ध नहीं है. बच्चों के स्टॉप के लिए: 0 या खाली - अगर पैरंट स्टेशन में बताया गया है, तो स्टॉप का बर्ताव wheelchair_boarding के मुताबिक रहेगा. 1 - स्टेशन के बाहर से किसी खास स्टॉप/प्लैटफ़ॉर्म तक व्हील चेयर से पहुंचने के लिए कुछ रास्ते बने हुए हैं. 2 - स्टेशन के बाहर से किसी खास स्टॉप/प्लैटफ़ॉर्म तक व्हील चेयर से पहुंचने के लिए कोई रास्ता नहीं है. स्टेशन में आने/जाने के लिए: 0 या खाली - अगर पैरंट स्टेशन में बताया गया है, तो स्टेशन में आने के दरवाज़े का wheelchair_boarding, पैरंट स्टेशन के मुताबिक ही होगा. 1 - इस स्टेशन में व्हीलचेयर की मदद से आ सकते हैं. 2 - स्टेशन में आने के दरवाज़े से स्टॉप/प्लैटफ़ॉर्म तक व्हील चेयर से पहुंचने के लिए कोई रास्ता नहीं है.
level_id	levels.level_id का संदर्भ देने वाला आईडी	ज़रूरी नहीं	जगह का लेवल. अलग किए गए एक से ज़्यादा स्टेशन एक ही लेवल का इस्तेमाल कर सकते हैं.
platform_code	टेक्स्ट	ज़रूरी नहीं	प्लैटफ़ॉर्म स्टॉप (किसी स्टेशन से जुड़े स्टॉप) के लिए प्लैटफ़ॉर्म पहचानकर्ता. यह सिर्फ़ प्लैटफ़ॉर्म पहचानकर्ता होना चाहिए (जैसे, G या 3). "प्लैटफ़ॉर्म" या "ट्रैक" (या फ़ीड की दूसरी भाषाओं में इनका अनुवाद) जैसे शब्द शामिल नहीं किए जाने चाहिए. इसकी मदद से फ़ीड उपभोक्ता, प्लैटफ़ॉर्म पहचानकर्ता को ज़्यादा आसानी से अंतरराष्ट्रीय और स्थानीय भाषा में समझ सकते हैं.

routes.txt

फ़ाइल: ज़रूरी

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
route_id	आईडी	ज़रूरी है	रास्ते की पहचान करता है.
agency_id	agency.agency_id का संदर्भ देने वाला आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	बताए गए रास्ते के लिए एजेंसी. यह फ़ील्ड तब ज़रूरी होता है, जब डेटासेट agency.txt में एक से ज़्यादा एजेंसी के रूट के लिए डेटा देता है. इसके अलावा, यह ज़रूरी नहीं है.
route_short_name	टेक्स्ट	कुछ शर्तों के मुताबिक ज़रूरी है	किसी रास्ते का छोटा नाम. यह आम तौर पर एक छोटा सा पहचानकर्ता होता है, जैसे "32", "100X" या "ग्रीन". इसका इस्तेमाल यात्री किसी रास्ते की पहचान करने के लिए करते हैं, लेकिन यह इस बात का संकेत नहीं देता कि रास्ता किन जगहों को दिखाता है. route_short_name या route_long_name में से किसी एक की जानकारी देना ज़रूरी है. अगर ऐसा करना सही हो, तो दोनों ही दिए जाने चाहिए.
route_long_name	टेक्स्ट	कुछ शर्तों के मुताबिक ज़रूरी है	किसी रास्ते का पूरा नाम. इस नाम में आम तौर पर route_short_name की तुलना में ज़्यादा जानकारी शामिल होती है. इसमें मंज़िल तक पहुंचने वाले रास्ते या स्टॉप की जानकारी शामिल होती है. route_short_name या route_long_name में से किसी एक की जानकारी देना ज़रूरी है. अगर ऐसा करना सही हो, तो दोनों ही दिए जाने चाहिए.
route_desc	टेक्स्ट	ज़रूरी नहीं	उस रास्ते का ब्यौरा, जो काम की और ज़रूरी जानकारी देता है. किसी रास्ते का डुप्लीकेट नाम न बनाएं. जैसे: "A" ट्रेन इनवुड-207 स्ट्रीट, मेनहट्टन और फ़ार रॉकअवे-मॉट एवेन्यू, क्वींस के बीच हर समय चलती है. साथ ही, करीब सुबह 6 बजे से लेकर आधी रात तक, अतिरिक्त "A" ट्रेन इनवुड-207 स्ट्रीट और लेफ़र्ट्स बुलेवार्ड के बीच चलती हैं (आम तौर पर लेफ़र्ट्स बुलेवार्ड और फ़ार रॉकअवे के बीच ट्रेन वैकल्पिक रूप से चलती रहती हैं).
route_type	Enum	ज़रूरी है	किसी रास्ते पर इस्तेमाल किए गए परिवहन के साधन के बारे में बताता है. सही विकल्प ये हैं: 0 - ट्राम, स्ट्रीटकार, लाइट रेल. महानगरीय क्षेत्र में चलने वाली कोई लाइट रेल या सड़क यात्रा का कोई और साधन. 1 - सबवे, मेट्रो. महानगरीय क्षेत्र में चलने वाला कोई अंडरग्राउंड रेल सिस्टम. 2 - रेल. इसका इस्तेमाल शहर के अंदर एक जगह से दूसरी जगह जाने के लिए या लंबी दूरी की यात्रा के लिए किया जाता है. 3 - बस. इसका इस्तेमाल छोटी- और लंबी-दूरी के बस वाले रास्तों के लिए किया जाता है. 4 - फ़ेरी. छोटी और लंबी दूरी की नाव सेवा के लिए इस्तेमाल की जाती है. 5 - केबल ट्राम इसका इस्तेमाल सड़क के साथ-साथ चलने वाली रेल कार के लिए किया जाता है. उदाहरण के लिए, सैन फ़्रांसिस्को की केबल कार सेवा. 6 - एरियल लिफ्ट, केबल (तार) के सहारे हवा में चलने वाली केबल कार (जैसे, गोंडोला लिफ्ट, एरियल ट्रामवे). केबल ट्रांसपोर्ट सिस्टम जिसमें एक या ज़्यादा केबल (तार) की मदद से केबिन, कार, गंडोला या ओपन चेयर केबल कारें चलती हैं. 7 - फ़्यूनिक्यूलर. खड़ी या सीधी चढ़ाई वाले रास्तों के लिए डिज़ाइन किया गया रेल सिस्टम. 11 - ट्रॉलीबस. इलेक्ट्रिक बसें, जिनके ऊपर एक पोल लगा होता है. इस पोल की मदद से, ऊपर से गुज़रने वाली तारों से इन्हें बिजली मिलती है. 12 - मोनोरेल. ऐसा रेलवे सिस्टम जिसमें सिर्फ़ एक रेल ट्रैक या बीम होती है.
route_url	यूआरएल	ज़रूरी नहीं	किसी खास रास्ते के बारे में जानकारी देने वाले वेब पेज का यूआरएल. agency.agency_url वैल्यू से अलग होना चाहिए.
route_color	रंग	ज़रूरी नहीं	रास्ते के लिए तय किए रंग का संकेत, जो लोगों को दिखने वाले कॉन्टेंट से मेल खाता है. इसे निकालने या खाली छोड़ने पर, डिफ़ॉल्ट रंग सफ़ेद (FFFFFF) होता है. route_color और route_text_color के बीच रंग के अंतर को काली-सफ़ेद स्क्रीन पर देखे जाने पर उसमें सही कंट्रास्ट दिखना चाहिए.
route_text_color	रंग	ज़रूरी नहीं	route_color के बैकग्राउंड में लिखे जाने वाले टेक्स्ट के लिए सही रंग, ताकि टेक्स्ट को आसानी से पढ़ा जा सके. इसे निकालने या खाली छोड़ने पर, डिफ़ॉल्ट रंग काला (000000) होता है. route_color और route_text_color के बीच रंग के अंतर को काली-सफ़ेद स्क्रीन पर देखे जाने पर उसमें सही कंट्रास्ट दिखना चाहिए.
route_sort_order	सकारात्मक पूर्णांक	ज़रूरी नहीं	रास्तों को ऐसे क्रम में लगाता है, जो आसानी से ग्राहकों को दिखाए जा सकते हैं. छोटी route_sort_order वैल्यू वाले रास्ते पहले दिखाए जाने चाहिए.
continuous_pickup	Enum	ज़रूरी नहीं	यह बताता है कि सार्वजनिक परिवहन के वाहन के रास्ते में, यात्री कहीं से भी चढ़ सकता है. इस रूट पर, हर यात्रा के रास्ते को shapes.txt में बताया गया है. सही विकल्प हैं: 0 - लगातार स्टॉप के पिक अप. 1 या खाली - लगातार स्टॉप का पिक अप नहीं. 2 - लगातार स्टॉप के पिक अप के लिए एजेंसी को फ़ोन करना ज़रूरी है. 3 - लगातार स्टॉप के पिक अप के लिए, ड्राइवर से बात करना ज़रूरी है. routes.txt में बताया गया लगातार होने वाले पिकअप का डिफ़ॉल्ट व्यवहार stop_times.txt में बदला जा सकता है.
continuous_drop_off	Enum	ज़रूरी नहीं	यह बताता है कि यात्रा के दौरान यात्री रास्ते में कहीं भी सार्वजनिक परिवहन से उतर सकता है. इस रूट पर, हर यात्रा के रास्ते को shapes.txt से बताया गया है. सही विकल्प हैं: 0 - स्टॉप के लगातार ड्रॉप-ऑफ़. 1 या खाली - लगातार स्टॉप के ड्रॉप-ऑफ़ नहीं. 2 - लगातार स्टॉप के ड्रॉप-ऑफ़ के लिए एजेंसी को कॉल करना ज़रूरी है. 3 - लगातार स्टॉप के ड्रॉप-ऑफ़ के लिए ड्राइवर से बात करना ज़रूरी है. routes.txt में बताया गया लगातार ड्रॉप-ऑफ़ का डिफ़ॉल्ट व्यवहार stop_times.txt में बदला गया.

trips.txt

फ़ाइल: ज़रूरी

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
route_id	routes.route_id का संदर्भ देने वाला आईडी	ज़रूरी है	रास्ते की पहचान करता है.
service_id	calendar.service_id या calendar_dates.service_id का आईडी बताना	ज़रूरी है	एक या ज़्यादा रास्तों के लिए सेवा उपलब्ध होने पर तारीखों के सेट की पहचान करता है.
trip_id	आईडी	ज़रूरी है	किसी यात्रा की पहचान करता है.
trip_headsign	टेक्स्ट	ज़रूरी नहीं	साइनेज बोर्ड पर दिखाई देने वाला टेक्स्ट जिससे यात्रियों को यात्रा की मंज़िल के बारे में जानकारी मिलती है. एक ही रास्ते पर सेवा के अलग-अलग पैटर्न के बीच अंतर करने के लिए इस फ़ील्ड का इस्तेमाल करें. अगर यात्रा के दौरान हेडसाइन (ऊपर की तरफ़ मंज़िल बताने वाला संकेत) बदल जाता है, तो stop_times.stop_headsign के लिए वैल्यू डालकर trip_headsign को बदला जा सकता है.
trip_short_name	टेक्स्ट	ज़रूरी नहीं	लोगों को दिखाई देने वाले टेक्स्ट से यात्रा की जानकारी मिलती है, जैसे रेल यात्रा के लिए ट्रेन के नंबर की पहचान करना. अगर यात्री आम तौर पर, यात्रा के नाम पर निर्भर नहीं रहते हैं, तो इस फ़ील्ड को खाली छोड़ दें. अगर trip_short_name वैल्यू दी गई है, तो इसे सेवा के दिन की अवधि में यात्रा की खास तौर पर पहचान करनी चाहिए. इसका इस्तेमाल मंज़िल के नामों या सीमित/बताई गई मंज़िलों के लिए नहीं किया जाना चाहिए.
direction_id	Enum	ज़रूरी नहीं	यात्रा की दिशा बताता है. इस फ़ील्ड का इस्तेमाल रूटिंग में नहीं किया जाता है. यह समय सारणी प्रकाशित करते समय दिशाओं के मुताबिक यात्राओं को अलग-अलग करने का तरीका बताता है. सही विकल्प हैं: 0 - कहीं जाने के लिए यात्रा (उदाहरण के लिए, एक जगह से दूसरी जगह जाने के लिए यात्रा). 1 - वापस आने के लिए यात्रा (उदाहरण के लिए, एक जगह से उसी जगह वापस लौटना जहां से यात्रा शुरू हुई थी). उदाहरण: यात्राओं के किसी ग्रुप में से हर दिशा में होने वाली यात्रा को कोई नाम देने के लिए trip_headsign और direction_id फ़ील्ड का एक साथ इस्तेमाल कर सकते हैं. trips.txt फ़ाइल में ये रिकॉर्ड हो सकते हैं और टाइम टेबल में इनका इस्तेमाल किया जा सकता है: trip_id,...,trip_headsign,direction_id 1234,...,Airport,0 1505,...,Downtown,1
block_id	आईडी	ज़रूरी नहीं	उस ब्लॉक की पहचान करता है, जिससे यात्रा जुड़ी है. एक ब्लॉक में एक ही यात्रा या एक ही वाहन से एक के बाद एक होने वाली कई यात्राएं शामिल होती हैं. इन्हें शेयर किए गए सेवा के दिनों और block_id से बताया जाता है. block_id में अलग-अलग सेवा के दिनों में होने वाली यात्राएं मौजूद हो सकती हैं, जो अलग-अलग ब्लॉक बनाती हैं. नीचे दिया गया उदाहरण देखें
shape_id	shapes.shape_id का संदर्भ देने वाला आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	किसी ऐसी जगह के आकार की पहचान करता है जिसमें वाहन की यात्रा की जानकारी दर्ज होती है. यह कुछ शर्तों के मुताबिक ज़रूरी है: अगर यात्रा का लगातार व्यवहार, रूट लेवल या स्टॉप के समय के लेवल पर बताया गया है, तो इस फ़ील्ड की ज़रूरत होती है. अगर ऐसा नहीं है, तो यह फ़ील्ड ज़रूरी नहीं है.
wheelchair_accessible	Enum	ज़रूरी नहीं	वह जगह या रास्ता दिखाता है, जहां व्हीलचेयर लाने और ले जाने की सुविधा हो. सही विकल्प हैं: 0 या खाली - यात्रा के लिए कोई सुलभता जानकारी उपलब्ध नहीं. 1 - इस यात्रा में इस्तेमाल किए जाने वाले वाहन में कम से कम एक व्हीलचेयर वाला यात्री बैठ सकता है. 2 - इस यात्रा में व्हीलचेयर वाले किसी भी यात्री को शामिल नहीं किया जा सकता.
bikes_allowed	Enum	ज़रूरी नहीं	बताता है कि साइकल की अनुमति है या नहीं. सही विकल्प हैं: 0 या खाली - यात्रा के लिए साइकल की कोई जानकारी नहीं. 1 - इस यात्रा में इस्तेमाल किए जाने वाले वाहन में कम से कम एक साइकल की अनुमति है. 2 - इस यात्रा में साइकल की अनुमति नहीं है.

उदाहरण: ब्लॉक और सेवा के दिन

नीचे दिया गया उदाहरण सप्ताह के हर दिन अलग-अलग ब्लॉक के साथ मान्य है.

route_id	trip_id	service_id	block_id	(पहले स्टॉप का समय)	(आखिरी स्टॉप का समय)
red	trip_1	mon-tues-wed-thurs-fri-sat-sun	red_loop	22:00:00	22:55:00
red	trip_2	fri-sat-sun	red_loop	23:00:00	23:55:00
red	trip_3	fri-sat	red_loop	24:00:00	24:55:00
red	trip_4	mon-tues-wed-thurs	red_loop	20:00:00	20:50:00
red	trip_5	mon-tues-wed-thurs	red_loop	21:00:00	21:50:00

ऊपर दी गई टेबल के लिए ध्यान दें:

• उदाहरण के लिए, शुक्रवार से शनिवार की सुबह तक, एक ही वाहन trip_1, trip_2, और trip_3 (रात 10:00 से लेकर 12:55 बजे तक) ऑपरेट करता है. ध्यान दें कि आखिरी यात्रा शनिवार 12:00 बजे (रात) से लेकर 12:55 बजे (रात) तक होती है, लेकिन वह शुक्रवार के "कामकाजी दिन" का हिस्सा है, क्योंकि समय 24:00:00 से लेकर 24:55:00 तक है.
• सोमवार, मंगलवार, बुधवार, और गुरुवार को रात 8:00 बजे से 10:55 बजे तक के ब्लॉक में एक ही वाहन trip_1, trip_4, और trip_5 ऑपरेट करता है.

stop_times.txt

फ़ाइल: ज़रूरी

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
trip_id	trips.trip_id का संदर्भ देने वाला आईडी	ज़रूरी है	किसी यात्रा की पहचान करता है.
arrival_time	समय	कुछ शर्तों के मुताबिक ज़रूरी है	किसी रास्ते में खास यात्रा के दौरान आने वाले खास स्टॉप पर पहुंचने का समय. अगर किसी स्टॉप पर आने और जाने के लिए अलग-अलग समय नहीं हैं, तो arrival_time और departure_time के लिए एक ही वैल्यू डालें. सेवा के दिन में आधी रात के बाद आने वाले समय के लिए, समय को HH:MM:SS फ़ॉर्मैट में ऐसी वैल्यू के तौर पर डालें, जो स्थानीय समय में 24:00:00 से ज़्यादा हो. यह उस दिन के लिए होगा जिस दिन यात्रा का शेड्यूल शुरू होगा. शेड्यूल किए गए स्टॉप वे टाइम पॉइंट होते हैं, जहां वाहन आने और जाने के समय का पालन सख्ती से करता है. अगर यह स्टॉप एक टाइम पॉइंट नहीं है, तो यह सुझाव दिया जाता है कि अनुमानित या कोई इंटरपोलेट किया गया समय दिया जाए. अगर यह उपलब्ध नहीं है, तो arrival_time को खाली छोड़ा जा सकता है. इसके अलावा, यह बताएं कि इंटरपोलेट किए गए समय timepoint=0 की मदद से दिए गए हैं. अगर इंटरपोलेट किए गए समय timepoint=0 की मदद से दिए गए हैं, तो timepoint=1 के साथ टाइम पॉइंट बताए जाने चाहिए. जो भी स्टॉप टाइम पॉइंट हैं उनके लिए, पहुंचने का समय दें. किसी यात्रा के लिए, पहले और आखिरी स्टॉप पर पहुंचने का समय तय करना ज़रूरी है.
departure_time	समय	कुछ शर्तों के मुताबिक ज़रूरी है	किसी खास स्टॉप से किसी रूट की यात्रा पर निकलने का समय. सेवा के दिन, आधी रात के बाद आने वाले समय को HH:MM:SS फ़ॉर्मैट में ऐसी वैल्यू के तौर पर डालें, जो स्थानीय समय में 24:00:00 से ज़्यादा हो. यह उस दिन के लिए होगा जिस दिन यात्रा का शेड्यूल शुरू होगा. अगर किसी स्टॉप पर आने और जाने के लिए अलग-अलग समय नहीं हैं, तो arrival_time और departure_time के लिए एक ही वैल्यू डालें. टाइम पॉइंट के सही इस्तेमाल के बारे में ज़्यादा जानकारी के लिए arrival_time ब्यौरा देखें. जब भी संभव हो departure_time फ़ील्ड में समय की वैल्यू बताई जानी चाहिए. इसमें गैर-ज़रूरी अनुमानित या टाइम पॉइंट के बीच इंटरपोलेट किए गए समय शामिल हैं.
stop_id	stops.stop_id का संदर्भ देने वाला आईडी	ज़रूरी है	उस स्टॉप की पहचान करता है जिस पर सेवा दी जाती है. यात्रा के दौरान सेवा के दायरे में आने वाले सभी स्टॉप का रिकॉर्ड stop_times.txt में होना चाहिए. संदर्भ के तौर पर दी गई जगहें, स्टॉप होने चाहिए, न कि स्टेशन या स्टेशन के दरवाज़े. कोई स्टॉप एक ही यात्रा के दौरान कई बार सेवा के दायरे में आ सकता है. साथ ही, कई यात्राएं और रास्ते एक ही स्टॉप पर सेवा दे सकते हैं.
stop_sequence	सकारात्मक पूर्णांक	ज़रूरी है	किसी खास यात्रा के लिए स्टॉप का क्रम. यात्रा के साथ-साथ वैल्यू बढ़नी चाहिए, लेकिन उनका लगातार बढ़ना ज़रूरी नहीं है. उदाहरण: यात्रा की पहली जगह का stop_sequence=1 हो सकता है, दूसरी जगह का stop_sequence=23, तीसरी जगह का stop_sequence=40 और इसी तरह आगे हो सकता है.
stop_headsign	टेक्स्ट	ज़रूरी नहीं	साइनेज बोर्ड पर दिखाई देने वाला टेक्स्ट जिससे यात्रियों को यात्रा की मंज़िल के बारे में जानकारी मिलती है. स्टॉप के बीच हेडसाइन (ऊपर की तरफ़ मंज़िल बताने वाला संकेत) के बदलने पर यह फ़ील्ड डिफ़ॉल्ट trips.trip_headsign को बदल देता है. अगर हेडसाइन पूरी यात्रा में दिखता है, तो इसके बजाय trips.trip_headsign का इस्तेमाल करें. एक stop_time के लिए तय की गई वैल्यू stop_headsign उसी यात्रा में बाद के stop_time पर लागू नहीं होता. अगर आप एक ही यात्रा में कई stop_time के लिए trip_headsign को ओवरराइड करना चाहते हैं, तो हर stop_time लाइन में stop_headsign वैल्यू दोहराई जानी चाहिए.
pickup_type	Enum	ज़रूरी नहीं	पिकअप का तरीका बताता है. सही विकल्प हैं: 0 या खाली - नियमित तौर पर शेड्यूल किया गया पिकअप. 1 - पिकअप की सुविधा मौजूद नहीं है. 2 - पिकअप की व्यवस्था के लिए एजेंसी को कॉल करना ज़रूरी है. 3 - पिकअप की व्यवस्था के लिए ड्राइवर से बात करना ज़रूरी है.
drop_off_type	Enum	ज़रूरी नहीं	ड्रॉप करने की सुविधा के बारे में जानकारी देता है. सही विकल्प हैं: 0 या खाली - नियमित तौर पर ड्रॉप करने का शेड्यूल. 1 - ड्रॉप करने की सुविधा मौजूद नहीं है. 2 - ड्रॉप-ऑफ़ के लिए एजेंसी को फ़ोन करना ज़रूरी है. 3 - ड्रॉप-ऑफ़ के लिए ड्राइवर से बात करना ज़रूरी है.
continuous_pickup	Enum	ज़रूरी नहीं	यह बताता है कि यात्री सार्वजनिक परिवहन के वाहन के रास्ते में, कहीं से भी चढ़ सकता है. यात्रा के stop_sequence में, stop_time से अगले stop_time के बीच के रास्ते को shapes.txt से बताया गया है. सही विकल्प हैं: 0 - लगातार स्टॉप के पिक अप. 1 या खाली - लगातार स्टॉप का पिक अप नहीं. 2 - लगातार पिक अप के लिए किसी एजेंसी को फ़ोन करना ज़रूरी है. 3 - लगातार स्टॉप के पिक अप के लिए ड्राइवर से बात करना ज़रूरी है. stop_times.txt में बताया गया लगातार पिक अप का व्यवहार routes.txt में बताए गए किसी व्यवहार को बदलता है.
continuous_drop_off	Enum	ज़रूरी नहीं	यह बताता है कि shapes.txt से बताए गए यात्रा के रास्ते, stop_sequence के stop_time से अगले stop_time तक यात्री रास्ते में कहीं से भी सार्वजनिक परिवहन से उतर सकता है. 0 - लगातार स्टॉप के ड्रॉप-ऑफ़. 1 या खाली - लगातार ड्रॉप-ऑफ़ नहीं. 2 - लगातार ड्रॉप-ऑफ़ के लिए एजेंसी को कॉल करना ज़रूरी है. 3 - ड्रॉप-ऑफ़ के लिए ड्राइवर से बात करना ज़रूरी है. stop_times.txt में किसी भी बताए गए ड्रॉप-ऑफ़ का व्यवहार routes.txt में बताए गए व्यवहार को बदल सकता है.
shape_dist_traveled	सकारात्मक फ़्लोट	ज़रूरी नहीं	पहले स्टॉप से लेकर इस रिकॉर्ड में बताए गए स्टॉप तक जुड़ी हुई जगह के साथ पूरी की गई वास्तविक दूरी. यह फ़ील्ड बताता है कि यात्रा के दौरान किसी भी दो स्टॉप के बीच जगह का कितना आकार बनाना चाहिए. यह उन यूनिट में ही होना चाहिए जो shapes.txt में इस्तेमाल की गई हैं. shape_dist_traveled के लिए इस्तेमाल की जाने वाली वैल्यू stop_sequence के साथ बढ़नी चाहिए; इनका इस्तेमाल वापस आने के लिए की जाने वाली यात्रा को दिखाने के लिए नहीं किया जा सकता. उदाहरण: अगर कोई बस जगह की शुरुआत से स्टॉप तक 5.25 किलोमीटर की दूरी तय करती है, shape_dist_traveled=5.25.
timepoint	Enum	ज़रूरी नहीं	यह जानकारी देता है कि वाहन, स्टॉप के लिए तय किए गए आने और जाने के समय का सख्ती से पालन करता है या नहीं या फिर वे अनुमानित और/या इंटरपोलेट किए गए समय हैं. इस फ़ील्ड की मदद से जीटीएफ़एस प्रोड्यूसर इंटरपोलेट किए गए स्टॉप समय दे सकते हैं. साथ ही, यह बता सकते हैं कि समय अनुमानित है. सही विकल्प हैं: 0 - समय अनुमानित माना जाता है. 1 या खाली - समय सटीक माने जाते हैं.

calendar.txt

फ़ाइल: कुछ शर्तों के मुताबिक ज़रूरी है

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
service_id	आईडी	ज़रूरी है	एक या एक से ज़्यादा रूट के लिए सेवा मौजूद होने पर, खास तरीके से तारीखों के सेट की पहचान करता है. हर service_id वैल्यू, calendar.txt फ़ाइल में ज़्यादा से ज़्यादा एक बार दिख सकती है.
monday	Enum	ज़रूरी है	यह बताता है कि सेवा सभी सोमवार को काम करती है या नहीं. यह तारीख की उस सीमा में होना चाहिए जो start_date और end_date फ़ील्ड का इस्तेमाल करके डाली जाती है. ध्यान रखें कि खास तारीखों को calendar_dates.txt में अपवाद के तौर पर डाला जा सकता है. सही विकल्प हैं: 1 - तारीख की सीमा में आ रहे सभी सोमवार को सेवा उपलब्ध है. 0 - तारीख की सीमा में आ रहे सभी सोमवार को सेवा उपलब्ध नहीं है.
tuesday	Enum	ज़रूरी है	monday की तरह ही काम करता है. मंगलवार के दिन लागू नहीं होता
wednesday	Enum	ज़रूरी है	monday की तरह ही काम करता है. बुधवार के दिन लागू नहीं होता
thursday	Enum	ज़रूरी है	monday की तरह ही काम करता है. गुरुवार के दिन लागू नहीं होता
friday	Enum	ज़रूरी है	monday की तरह ही काम करता है. शुक्रवार के दिन लागू नहीं होता
saturday	Enum	ज़रूरी है	monday की तरह ही काम करता है. शनिवार के दिन लागू नहीं होता.
sunday	Enum	ज़रूरी है	monday की तरह ही काम करता है. रविवार के दिन लागू नहीं होता.
start_date	तारीख	ज़रूरी है	सेवा अंतराल के लिए सेवा के शुरू होने का दिन.
end_date	तारीख	ज़रूरी है	सेवा अंतराल के लिए सेवा के खत्म होने का दिन. सेवा का यह दिन, अंतराल में शामिल है.

calendar_dates.txt

फ़ाइल: कुछ शर्तों के मुताबिक ज़रूरी है

calendar_dates.txt टेबल से सेवा को तारीख के हिसाब से चालू या बंद कर सकते हैं. इसका इस्तेमाल दो तरह से किया जा सकता है.

• सुझाव: calendar_dates.txt का इस्तेमाल calendar.txt के साथ करें, ताकि calendar.txt में बताए गए तरीके के मुताबिक डिफ़ॉल्ट सेवा पैटर्न के लिए अपवाद बनाए जा सकें. अगर आपकी सेवा आम तौर पर नियमित रहती है, तो खास तारीखों में कुछ बदलाव करना (जैसे, खास कार्यक्रम सेवाओं या स्कूल शेड्यूल में फेरबदल करना) एक अच्छा तरीका है. इस मामले में calendar_dates.service_id एक आईडी है जो calendar.service_id का संदर्भ देता है.
• दूसरा तरीका: calendar.txt हटा दें और calendar_dates.txt में सेवा की हर तारीख दर्ज करें. इससे सेवा में ठीक-ठाक वैरायटी देने में मदद मिलती है और बिना सामान्य हफ़्ते के शेड्यूल के सेवा दी जा सकती है. इस मामले में service_id एक आईडी है.

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
service_id	calendar.service_id का संदर्भ देने वाला आईडी या आईडी	ज़रूरी है	एक या ज़्यादा रूट के लिए सेवा में किसी तरह के अपवाद शामिल होने पर, खास तरीके से तारीखों के सेट की पहचान करता है. अगर calendar.txt और calendar_dates.txt को एक साथ इस्तेमाल किया जा रहा है, तो हर (service_id, date) जोड़ा calendar_dates.txt में सिर्फ़ एक बार दिख सकता है. अगर service_id वैल्यू calendar.txt और calendar_dates.txt दोनों फ़ाइलों में दिखती है, तो calendar_dates.txt में मौजूद जानकारीcalendar.txt में बताई गई जानकारी में बदलाव कर देती है.
date	तारीख	ज़रूरी है	वह तारीख जब सेवा में किसी तरह का अपवाद शामिल होता है.
exception_type	Enum	ज़रूरी है	यह बताता है कि date फ़ील्ड में दर्ज तारीख पर सेवा उपलब्ध है या नहीं. सही विकल्प हैं: 1 - बताई गई तारीख के लिए सेवा जोड़ी गई है. 2 - बताई गई तारीख के लिए सेवा हटा दी गई है. उदाहरण: मान लीजिए कि छुट्टियों के दिनों में किसी खास रास्ते पर एक तरह की और बाकी सभी दिनों में दूसरे तरह की यात्राएं उपलब्ध हैं. एक service_id नियमित सेवा शेड्यूल से मेल खाने वाला हो सकता है और दूसरा service_id छुट्टियों वाले शेड्यूल से मेल खा सकता है. किसी खास छुट्टी के लिए, छुट्टी को छुट्टी service_id में जोड़ने और छुट्टी को नियमित service_id शेड्यूल से हटाने के लिए calendar_dates.txt फ़ाइल का इस्तेमाल किया जा सकता है.

fare_attributes.txt

फ़ाइल: ज़रूरी नहीं

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
fare_id	आईडी	ज़रूरी है	किराये की कैटगरी की पहचान करता है.
price	सकारात्मक फ़्लोट	ज़रूरी है	किराये की कैटगरी, currency_type की ओर से बताई गई इकाई में होती है.
currency_type	मुद्रा कोड	ज़रूरी है	किराया चुकाने के लिए इस्तेमाल की जाने वाली मुद्रा.
payment_method	Enum	ज़रूरी है	यह बताता है कि किराये के पैसे कब चुकाना ज़रूरी है. सही विकल्प हैं: 0 - वाहन में सवार होने पर किराया चुकाना होता है. 1 - वाहन पर सवार होने से पहले किराया चुकाना ज़रूरी है.
transfers	Enum	ज़रूरी है	इस किराये पर अनुमति वाले ट्रांसफ़र की संख्या दिखाता है. यह फ़ील्ड खाली छोड़ा जा सकता है. यह उस शर्त का अपवाद है, जिसमें कोई भी ज़रूरी फ़ील्ड खाली नहीं छोड़ा जा सकता. सही विकल्प हैं: 0 - इस किराये पर किसी ट्रांसफ़र की अनुमति नहीं है. 1 - यात्री एक बार ट्रांसफ़र कर सकते हैं. 2 - यात्री दो बार ट्रांसफ़र कर सकते हैं. खाली - अनलिमिटेड ट्रांसफ़र की अनुमति है.
agency_id	agency.agency_id का संदर्भ देने वाला आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	किराये के लिए उससे जुड़ी एजेंसी की पहचान करता है. यह फ़ील्ड एक से ज़्यादा एजेंसियों वाले डेटासेट के लिए ज़रूरी है, जो agency.txt में तय किए गए हैं. इसके अलावा, यह ज़रूरी नहीं है.
transfer_duration	सकारात्मक पूर्णांक	ज़रूरी नहीं	ट्रांसफ़र खत्म होने से पहले, सेकंड के हिसाब से बताया गया समय. जब transfers=0 होता है, तब इस फ़ील्ड का इस्तेमाल करके दिखाया जा सकता है कि टिकट कब तक मान्य है या उसे खाली छोड़ा जा सकता है.

fare_rules.txt

फ़ाइल: ज़रूरी नहीं

fare_rules.txt टेबल बताती है कि fare_attributes.txt में दिए गए किराये किसी यात्रा की योजना पर कैसे लागू होते हैं. ज़्यादातर किराये में नीचे बताए गए नियमों को मिले-जुले तौर पर इस्तेमाल किया जाता है:

• किराया, यात्रा शुरू करने या मंज़िल वाले स्टेशनों के हिसाब से तय होता है.
• किराया उन जगहों के हिसाब से भी तय होता है जो यात्रा के दौरान आते हैं.
• किराया, यात्रा के लिए इस्तेमाल किए जाने वाले रास्ते पर निर्भर करता है.

fare_rules.txt और fare_attributes.txt के साथ किराया दिखाने वाले उदाहरण देखने के लिए, GoogleTransitDataFeed open source project wiki में https://code.google.com/p/googletransitdatafeed/wiki/FareExamples पर जाएं.

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
fare_id	fare_attributes.fare_id का संदर्भ देने वाला आईडी	ज़रूरी है	किराये की कैटगरी की पहचान करता है.
route_id	routes.route_id का संदर्भ देने वाला आईडी	ज़रूरी नहीं	किराये की कैटगरी से जुड़े रास्ते की पहचान करता है. अगर एक जैसी किराये वाली विशेषताएं मौजूद हों, तो हर रूट के लिए fare_rules.txt में रिकॉर्ड बनाएं. उदाहरण: अगर किराये की कैटगरी "b", "TSW" और "TSE पर मान्य है तो इस किराये की कैटगरी के रिकॉर्ड fare_rules.txt" में मौजूद होंगे: fare_id,route_id b,TSW b,TSE
origin_id	stops.zone_id का संदर्भ देने वाला आईडी	ज़रूरी नहीं	उस जगह की पहचान करता है जहां से यात्रा शुरू होती है. अगर किसी किराये की कैटगरी के तहत यात्रा शुरू करने वाली कई जगहें आती हैं, तो fare_rules.txt में हर origin_id के लिए एक रिकॉर्ड बनाएं. उदाहरण: अगर किराया कैटगरी "b" उन सभी यात्राओं के लिए मान्य है जो क्षेत्र "2" या क्षेत्र "8" से शुरू होती हैं, तो fare_rules.txt फ़ाइल में किराये की कैटगरी के लिए ये रिकॉर्ड होंगे: fare_id,...,origin_id b,...,2 b,...,8
destination_id	stops.zone_id का संदर्भ देने वाला आईडी	ज़रूरी नहीं	यात्रा पूरी होने की जगह (मंज़िल) की पहचान करता है. अगर किराये की कैटगरी के तहत यात्रा पूरी होने की कई जगहें (मंज़िलें) आती हैं, तो fare_rules.txt में हर destination_id के लिए एक रिकॉर्ड बनाएं. उदाहरण: आप यह बताने के लिए origin_id और destination_id फ़ील्ड का एक साथ इस्तेमाल कर सकते हैं कि किराया कैटगरी "b", क्षेत्र 3 और 4 के बीच और क्षेत्र 3 और 5 के बीच यात्रा करने के लिए मान्य है. fare_rules.txtफ़ाइल में किराये की कैटगरी के लिए ये रिकॉर्ड होंगे: fare_id,...,origin_id,destination_id b,...,3,4 b,...,3,5
contains_id	stops.zone_id का संदर्भ देने वाला आईडी	ज़रूरी नहीं	उन जगहों की पहचान करता है जिनमें कोई यात्री दी गई किराया कैटगरी का इस्तेमाल करके अंदर आता है. कुछ सिस्टम में किराये की सही कैटगरी का हिसाब लगाने के लिए इस्तेमाल किया जाता है. उदाहरण: अगर किराये की कैटगरी "c" GRT रूट पर सभी यात्रा से जुड़ा है जो 5, 6, और 7 क्षेत्रों से गुज़रती है, तो fare_rules.txt फ़ाइल में ये रिकॉर्ड होंगे: fare_id,route_id,...,contains_id c,GRT,...,5 c,GRT,...,6 c,GRT,...,7 किराये को लागू करने के लिए सभी contains_id क्षेत्र मेल खाने चाहिए. इसलिए, वह यात्रा जो क्षेत्र 5 और 6 से गुज़रती है, लेकिन क्षेत्र 7 से नहीं गुजरती है उसकी किराया कैटगरी "c" नहीं होगी. ज़्यादा जानकारी के लिए, GoogleTransitDataFeed project wiki में https://code.google.com/p/googletransitdatafeed/wiki/FareExamples पर जाएं.

shapes.txt

फ़ाइल: ज़रूरी नहीं

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

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
shape_id	आईडी	ज़रूरी है	आकार की पहचान करता है.
shape_pt_lat	अक्षांश	ज़रूरी है	आकार बिंदु का अक्षांश. shapes.txt में मौजूद हर रिकॉर्ड एक आकार बिंदु दिखाता है. इसका इस्तेमाल आकार बताने के लिए किया जाता है.
shape_pt_lon	देशांतर	ज़रूरी है	आकार बिंदु का देशांतर.
shape_pt_sequence	सकारात्मक पूर्णांक	ज़रूरी है	वह क्रम, जिसमें आकार बनाने के लिए आकार बिंदु जुड़ते हैं. यात्रा के साथ वैल्यू बढ़नी चाहिए, लेकिन उनका क्रम के मुताबिक होना ज़रूरी नहीं है. उदाहरण: अगर "A_shp" आकार की परिभाषा में तीन बिंदु हैं, तो आकार को परिभाषित करने के लिए shapes.txt फ़ाइल में ये रिकॉर्ड हो सकते हैं: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence A_shp,37.61956,-122.48161,0 A_shp,37.64430,-122.41070,6 A_shp,37.65863,-122.30839,11
shape_dist_traveled	सकारात्मक फ़्लोट	ज़रूरी नहीं	दिए गए पहले आकार बिंदु से इस रिकॉर्ड में बताए गए बिंदु तक आकार के साथ तय की गई असल दूरी. इसका इस्तेमाल यात्रा की योजना बनाने वाले, नक्शे पर आकार का सही भाग दिखाने के लिए करते हैं. shape_pt_sequence के साथ वैल्यू बढ़नी चाहिए; इनका इस्तेमाल वापस आने के लिए की जाने वाली यात्रा को दिखाने के लिए नहीं किया जा सकता. दूरी की इकाइयां stop_times.txt में इस्तेमाल की गई इकाइयों के मुताबिक होनी चाहिए. उदाहरण: अगर कोई बस A_shp के लिए ऊपर बताए गए तीन बिंदुओं पर चलती है, तो अतिरिक्त shape_dist_traveled वैल्यू (किलोमीटर में दिखाई गई) ऐसी दिखेंगी: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled A_shp,37.61956,-122.48161,0,0 A_shp,37.64430,-122.41070,6,6.8310 A_shp,37.65863,-122.30839,11,15.8765

frequencies.txt

फ़ाइल: ज़रूरी नहीं

frequencies.txt से उन यात्राओं के बारे में जानकारी मिलती है जो नियमित हेडवे पर (यात्राओं के बीच के समय) पर होती हैं. इस फ़ाइल का इस्तेमाल दो अलग-अलग तरह की सेवाएं दिखाने के लिए किया जा सकता है.

• समय के अंतराल पर चलने वाली सेवा (exact_times=0) जिसमें सेवा पूरे दिन में किसी तय शेड्यूल के हिसाब से नहीं चलती है. इसके बजाय ऑपरेटर, यात्राओं के लिए पहले से तय किए गए हेडवे का सख्ती से पालन करने की कोशिश करते हैं.
• शेड्यूल के मुताबिक चलने वाली किसी सेवा का कंप्रेस किया गया वर्शन (exact_times=1) जिसमें तय समय के दौरान यात्राओं के लिए एक ही हेडवे होता है. शेड्यूल-आधारित सेवा में, ऑपरेटर सख्ती से शेड्यूल को पूरा करने की कोशिश करते हैं.

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
trip_id	trips.trip_id का संदर्भ देने वाला आईडी	ज़रूरी है	उस यात्रा की पहचान करता है जो सेवा के तय हेडवे पर लागू होती है.
start_time	समय	ज़रूरी है	वह समय जब पहला वाहन तय हेडवे पर यात्रा के पहले स्टॉप से निकलता है.
end_time	समय	ज़रूरी है	वह समय जब यात्रा के पहले स्टॉप से सेवा अलग हेडवे में बदल जाती है (या बंद हो जाती है).
headway_secs	सकारात्मक पूर्णांक	ज़रूरी है	start_time और end_time के दिए गए समय अंतराल के दौरान, उसी स्टॉप (हेडवे) से इस यात्रा के लिए जाने का समय सेकंड में. एक ही यात्रा के लिए कई हेडवे हो सकते हैं, लेकिन वे ओवरलैप नहीं होने चाहिए. नए हेडवे ठीक उसी समय शुरू हो सकते हैं जब पिछला हेडवे खत्म होता है.
exact_times	Enum	ज़रूरी नहीं	यात्रा के लिए उपलब्ध सेवा बताता है. ज़्यादा जानकारी के लिए फ़ाइल का ब्यौरा देखें. सही विकल्प हैं: 0 या खाली - समय अंतराल पर आधारित यात्राएं. 1 - शेड्यूल-आधारित यात्राएं जिनके लिए पूरे दिन में एक ही हेडवे है. इस मामले में end_time की वैल्यू पिछली यात्रा के start_time से ज़्यादा होना चाहिए, लेकिन पिछली यात्रा के start_time + headway_secs से कम होना चाहिए.

transfers.txt

फ़ाइल: ज़रूरी नहीं

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

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

pathways.txt

फ़ाइल: ज़रूरी नहीं

जीटीएफ़एस-पाथवे एक्सटेंशन, नोड (जगहें) और किनारों (रास्ते) के साथ सबवे या ट्रेन की जानकारी देने के लिए ग्राफ़ का इस्तेमाल करता है.

दरवाज़े (जो location_type=2 के साथ जगह के तौर पर दिखाया गया नोड है) से प्लैटफ़ॉर्म (जो location_type=0 के साथ जगह के तौर पर दिखाया गया नोड है) पर जाने के लिए यात्री को पैदल रास्तों, किराया चुकाने पर खुलने वाले दरवाज़ों, सीढ़ियों, और दूसरे रास्तों से जाना होगा (ये किनारे हैं जिन्हें रास्तों के तौर पर दिखाया जाता है). यह प्रस्ताव दूसरी तरह की जगह को भी जोड़ता है, जिसमें सामान्य को "जेनेरिक नोड" कहा जाता है. जैसे, पैदल रास्ते की वह क्रॉसिंग जहां से दूसरे पैदल रास्ते मिल सकते हैं.

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

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

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
pathway_id	आईडी	ज़रूरी है	pathway_id फ़ील्ड में एक आईडी होता है, जो किसी रास्ते की खास तौर पर पहचान करता है. pathway_id का इस्तेमाल सिस्टम की ओर से इस रिकॉर्ड (उदाहरण के लिए डेटाबेस की प्राथमिक कुंजी) के अंदरूनी पहचानकर्ता के तौर पर किया जाता है. इसलिए, pathway_id का डेटासेट खास होना चाहिए. अलग-अलग रास्ते एक ही from_stop_id से to_stop_id के लिए जा सकते हैं. उदाहरणः ऐसा तब होता है, जब अलग-अलग दिशा में जाने वाले दो एस्केलेटर अगल-बगल मौजूद होते हैं या जब एक सीढ़ी नज़दीक हो और सीढ़ी और लिफ़्ट दोनों एक ही जगह शुरू और खत्म होते हैं.
from_stop_id	stops.stop_id का संदर्भ देने वाला आईडी	ज़रूरी है	वह जगह जहां से रास्ता शुरू होता है. इसमें एक stop_id होता है, जो प्लैटफ़ॉर्म, आने/जाने के दरवाज़े, सामान्य नोड या बोर्डिंग की जगह की पहचान stops.txt फ़ाइल से करता है.
to_stop_id	stops.stop_id का संदर्भ देने वाला आईडी	ज़रूरी है	वह जगह जहां रास्ता खत्म होता है. इसमें एक stop_id होता है, जो प्लैटफ़ॉर्म, आने/जाने के दरवाज़े, सामान्य नोड या बोर्डिंग की जगह की पहचान stops.txt फ़ाइल से करता है.
pathway_mode	Enum	ज़रूरी है	बताई गई जोड़ी (from_stop_id, to_stop_id) के बीच, रास्ता किस तरह का है. इस फ़ील्ड के लिए सही वैल्यू हैं: • 1: पैदल रास्ता • 2: सीढ़ियां • 3: चलने वाला फ़ुटपाथ/ट्रैवलेटर • 4: एस्केलेटर • 5: लिफ़्ट • 6: किराया चुकाने वाला या (पैसे चुकाने पर खुलने वाला) गेट: वह रास्ता जो स्टेशन की जगह से गुज़रता है जहां पैसे चुकाने का सबूत देना ज़रूरी है (आम तौर पर पैसे चुकाने के दरवाज़े से). किराया चुकाने वाले (पैसे चुकाने पर खुलने वाले) गेट, स्टेशन में बिना पैसे चुकाए उपलब्ध जगहों से अलग हो सकते हैं या एक स्टेशन पर पैसे चुकाने के बाद जाने वाली अलग-अलग जगह हो सकती हैं जो एक-दूसरे से अलग हों. इस जानकारी की मदद से शॉर्टकट का इस्तेमाल करके यात्रियों को स्टेशन में से रूट करने से बचाया जा सकता है. रूट करने के लिए यात्रियों को गैर-ज़रूरी पैसे चुकाने पड़ते हैं. इसका उदाहरण है किसी यात्री को सबवे तक पहुंचने के लिए, सबवे प्लैटफ़ॉर्म से चलने के निर्देश देना. • 7: बाहर निकलने का दरवाज़ा: ऐसी जगह से बाहर निकलने का रास्ता बताता है जहां पैसे चुकाने का सबूत देना ज़रूरी हो और वहां से ऐसी जगह का रास्ता बताता है जहां पैसे चुकाने का सबूत देना ज़रूरी नहीं होता.
is_bidirectional	Enum	ज़रूरी है	बताता है कि किस दिशा में रास्ते का इस्तेमाल किया जा सकता है: • 0: एकतरफ़ा रास्ता, इसका इस्तेमाल सिर्फ़ from_stop_id से to_stop_id तक किया जा सकता है. • 1: दोतरफ़ा रास्ता, इसका इस्तेमाल दो दिशाओं में किया जा सकता है. किराया चुकाने पर खुलने वाले दरवाज़े (pathway_mode=6) और बाहर निकलने के दरवाज़े (pathway_mode=7) दोतरफ़ा नहीं हो सकते.
length	सकारात्मक फ़्लोट	ज़रूरी नहीं	मूल जगह से मंज़िल तक (from_stop_id के मुताबिक) के रास्ते की मीटर में लंबाई (to_stop_id के मुताबिक). पैदल चलने के रास्तों (pathway_mode=1), किराया चुकाने पर खुलने वाले रास्ते (pathway_mode=6), और बाहर निकलने के दरवाज़ों (pathway_mode=7) के लिए इस फ़ील्ड का सुझाव दिया जाता है.
traversal_time	धनात्मक पूर्णांक	ज़रूरी नहीं	शुरुआत की जगह (from_stop_id के मुताबिक) से मंज़िल (to_stop_id के मुताबिक) तक पैदल चलने के रास्ते को तय करने में सेकंड में लगने वाला औसत समय. अपने-आप चलने वाले फ़ुटपाथ (pathway_mode=3), एस्केलेटर (pathway_mode=4), और एलिवेटर (pathway_mode=5) के लिए इस फ़ील्ड का सुझाव दिया जाता है.
stair_count	नॉन-ज़ीरो पूर्णांक	ज़रूरी नहीं	रास्ते में सीढ़ियों की संख्या. सबसे सही तरीके: अनुमानित वैल्यू पाने के लिए 1 फ़्लोर = 15 सीढ़ियों के अनुमान का इस्तेमाल किया जा सकता है. पॉज़िटिव stair_count का मतलब है कि यात्री from_stop_id से ऊपर to_stop_id तक चलकर जाता है. एक नेगेटिव stair_count का मतलब है कि यात्री from_stop_id से नीचे to_stop_id तक पैदल उतरकर चला जाता है. सीढ़ियों (pathway_mode=2) के लिए इस फ़ील्ड का सुझाव दिया जाता है.
max_slope	फ़्लोट	ज़रूरी नहीं	रास्ते के ज़्यादा से ज़्यादा ढलान का अनुपात. इस फ़ील्ड के लिए सही वैल्यू हैं: • 0 या (खाली): कोई ढलान नहीं. • एक फ्लोट: रास्ते के ढलान का अनुपात, ऊपर की ओर सकारात्मक, नीचे की ओर नकारात्मक. इस फ़ील्ड का इस्तेमाल सिर्फ़ पैदल रास्तों (pathway_type=1) और अपने-आप चलने वाले फ़ुटपाथ (pathway_type=3) के लिए करना चाहिए. उदाहरण: अमेरिका में हाथ से चलने वाली व्हीलचेयर के लिए ज़्यादा से ज़्यादा ढलान अनुपात 0.083 (या 8.3%) है. इसका मतलब है हर एक मीटर के लिए 0.083 मी (या 8.3 सेमी).की बढ़ोतरी.
min_width	सकारात्मक फ़्लोट	ज़रूरी नहीं	मीटर में रास्ते की कम-से-कम चौड़ाई. अगर कम से कम चौड़ाई एक मीटर से कम है, तो इस फ़ील्ड का सुझाव दिया जाता है.
signposted_as	टेक्स्ट	ज़रूरी नहीं	साइनबोर्ड पर लिखे टेक्स्ट की स्ट्रिंग, जो परिवहन का इस्तेमाल करने वाले यात्रियों को दिखती है. स्ट्रिंग का इस्तेमाल उपयोगकर्ताओं को टेक्स्ट में दिशा-निर्देश देने के लिए किया जा सकता है, जैसे कि 'चिह्नों को फ़ॉलो करें '. इस फ़ील्ड में टेक्स्ट ठीक उसी तरह दिखना चाहिए जैसा कि साइनबोर्ड पर छपा हुआ है - इसका अनुवाद नहीं होना चाहिए.
reversed_signposted_as	टेक्स्ट	ज़रूरी नहीं	signposted_as फ़ील्ड की तरह है, लेकिन जब रास्ते का इस्तेमाल उल्टी दिशा में किया जाता है, जैसे to_stop_id से from_stop_id तक.

levels.txt

फ़ाइल: ज़रूरी नहीं

किसी स्टेशन के अलग-अलग लेवल के बारे में बताएं. यह ज़्यादातर तब काम आता है, जब pathways.txt के साथ इस्तेमाल किया जाता है. एलिवेटर (pathway_mode=5) के लिए यह ज़रूरी है कि वह उपयोगकर्ता से एलिवेटर को "मेज़ेनाइन" या "प्लैटफ़ॉर्म" लेवल पर ले जाने के लिए कहे.

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
level_id	आईडी	ज़रूरी है	उस लेवल का आईडी, जिसका संदर्भ stops.txt से लिया जा सकता है.
level_index	फ़्लोट	ज़रूरी है	लेवल का संख्या वाला इंडेक्स जो दूसरे लेवल के संबंध में इस लेवल की मिलती-जुलती स्थिति बताता है ( माना जाता है कि ज़्यादा इंडेक्स वाला लेवल, कम इंडेक्स वाले लेवल के ऊपर मौजूद रहता है). ज़मीनी लेवल का इंडेक्स 0 होना चाहिए. ज़मीन से ऊपर के लेवल सकारात्मक इंडेक्स से और नीचे के लेवल नकारात्मक इंडेक्स से बताए जाते हैं.
level_name	टेक्स्ट	ज़रूरी नहीं	लेवल का दूसरा नाम (जो इमारत या स्टेशन के अंदर इस्तेमाल किए जाने वाले लेवल के अक्षरों/नंबरों से मेल खाता हो). यह एलिवेटर को रूट करने के लिए उपयोगी है (उदाहरण के लिए, "एलिवेटर को "मेज़ेनाइन" या "प्लैटफ़ॉर्म" या -"1") पर ले जाएं.

feed_info.txt

फ़ाइल: कुछ शर्तों के मुताबिक ज़रूरी है

इस फ़ोन में, डेटासेट में बताई गई सेवाओं के बजाय डेटासेट के बारे में जानकारी होती है. कुछ मामलों में, डेटासेट का प्रकाशक एजेंसियों से अलग होता है. अगर translations.txt दिया गया है, तो यह फ़ाइल ज़रूरी है.

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
feed_publisher_name	टेक्स्ट	ज़रूरी है	संगठन का पूरा नाम, जो डेटासेट प्रकाशित करता है. यह agency.agency_name वैल्यू में से एक वैल्यू के जैसा ही हो सकता है.
feed_publisher_url	यूआरएल	ज़रूरी है	डेटासेट प्रकाशित करने वाले संगठन की वेबसाइट का यूआरएल. यह agency.agency_url वैल्यू में से एक वैल्यू के जैसा ही हो सकता है.
feed_lang	भाषा का कोड	ज़रूरी है	इस डेटासेट में टेक्स्ट के लिए डिफ़ॉल्ट भाषा. इस खाते से जीटीएफ़एस उपभोक्ताओं को डेटासेट के लिए कैपिटलाइज़ेशन नियम और किसी खास भाषा वाली सेटिंग चुनने में मदद मिलती है. दूसरी भाषा तय करने के लिए, language फ़ील्ड का इस्तेमाल करें, जो translations.txt. कई भाषाओं वाले डेटासेट में, मूल लेख के लिए कई भाषाओं के साथ एक डिफ़ॉल्ट भाषा हो सकती है. कुछ मामलों में, feed_lang फ़ील्ड में ISO 639-2 भाषा कोड mul का इस्तेमाल करें. translations.txt में डेटासेट में इस्तेमाल की जाने वाली हर भाषा के लिए अनुवाद मुहैया कराएं. अगर डेटासेट में मूल लेख उसी भाषा में है, तो mul का इस्तेमाल न करें. उदाहरण के लिए, स्विट्ज़रलैंड का कोई डेटासेट मूल stops.stop_name फ़ील्ड के लिए सेट हो सकता है और स्टॉप के नाम अलग-अलग भाषाओं में हो सकते हैं. हर स्टॉप नाम उस स्टॉप की जगह या देश में इस्तेमाल की जाने वाली प्रमुख भाषा के अनुसार लिखा गया है. स्टॉप के नामों में फ़्रेंच-भाषा इस्तेमाल करने वाले शहर जेनेवा के लिए जेनेव, जर्मन-भाषा इस्तेमाल करने वाले शहर ज़्यूरिख के लिए ज़ूरिख, और दो भाषाएं इस्तेमाल करने वाले बेल/बिएन शहर के लिए बील/बियेन शामिल हैं. feed_lang=mul सेट करें और translations.txt में नीचे बताए गए अनुवाद मुहैया कराएं: जर्मन: "जेनफ़," "ज़्यूरिख," और "बील" फ़्रेंच: "जेनेव" "ज़ूरिख," और "बियेन" इटैलियन: "जिनेव्रा," "ज़्यूरिगो," और "बियेना" अंग्रेज़ी: "जिनेवा," "ज़ूरिख," और "बील/बियेन"
default_lang	भाषा का कोड	ज़रूरी नहीं	डेटा उपभोक्ता अगर राइडर की भाषा नहीं जानता है, तो इस्तेमाल की जाने वाली भाषा तय करता है. इसे अक्सर en, अंग्रेज़ी में दिया जाता है.
feed_start_date	तारीख	ज़रूरी नहीं	यह डेटासेट feed_start_date दिन की शुरुआत से feed_end_date दिन खत्म होने तक चलने वाले सेवा के शेड्यूल की पूरी और सही जानकारी देता है. उपलब्ध न होने पर दोनों दिन खाली रह सकते हैं. अगर दोनों दिन दर्ज हैं, तो feed_end_date तारीख feed_start_date तारीख से पहले नहीं होनी चाहिए. भावी सेवा की सलाह देने के लिए डेटासेट देने वालों को इस अवधि से बाहर शेड्यूल डेटा देने के लिए प्रोत्साहित किया जाता है, लेकिन डेटासेट उपभोक्ताओं को इसकी गैर-आधिकारिक स्थिति के प्रति जागरूक होना चाहिए. अगर feed_start_date या feed_end_date calendar.txt और calendar_dates.txt में दी गई कैलेंडर तारीखों के बाद की होती है, तो डेटासेट यह बताता है कि feed_start_date या feed_end_date के तहत आने वाली तारीखों के लिए कोई सेवा मौजूद नहीं है, लेकिन कैलेंडर में दर्ज तारीखों में यह शामिल नहीं है.
feed_end_date	तारीख	ज़रूरी नहीं	इस टेबल में feed_start_date वाली लाइन देखें.
feed_version	टेक्स्ट	ज़रूरी नहीं	ऐसी स्ट्रिंग, जो उनके जीटीएफ़एस डेटासेट का मौजूदा वर्शन दिखाती है. जीटीएफ़एस का इस्तेमाल करने वाले ऐप्लिकेशन इस वैल्यू को दिखा सकते हैं. इससे डेटासेट के प्रकाशक यह तय कर सकते हैं कि सबसे नए वर्शन को शामिल किया गया है या नहीं.
feed_contact_email	ईमेल	ज़रूरी नहीं	जीटीएफ़एस डेटासेट और डेटा प्रकाशित करने के तरीकों के बारे में कोई जानकारी पाने के लिए ईमेल पता. जीटीएफ़एस इस्तेमाल करने वाले ऐप्लिकेशन के लिए, feed_contact_email तकनीकी संपर्क के तौर पर काम करता है. agency.txt इस्तेमाल करके ग्राहक सेवा से संपर्क करने की जानकारी दें.
feed_contact_url	यूआरएल	ज़रूरी नहीं	जीटीएफ़एस डेटासेट और डेटा प्रकाशित करने के तरीकों के बारे में जानकारी देने के लिए, टेलीफ़ोन नंबर, ईमेल, ऑफ़िस का पता, वेब फ़ॉर्म, सहायता डेस्क या संपर्क करने के लिए इस्तेमाल होने वाले दूसरे टूल का यूआरएल. जीटीएफ़एस इस्तेमाल करने वाले ऐप्लिकेशन के लिए, feed_contact_url तकनीकी संपर्क के तौर पर काम करता है. agency.txt इस्तेमाल करके ग्राहक सेवा से संपर्क करने की जानकारी दें.

translations.txt

फ़ाइल: ज़रूरी नहीं

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
table_name	Enum	ज़रूरी है	उस डेटासेट टेबल की जानकारी देता है जिसमें मौजूद किसी फ़ील्ड का अनुवाद किया जाना है. ये वैल्यू इस्तेमाल की जा सकती हैं: agency stops routes trips stop_times feed_info pathways levels attributions ध्यान दें: टेबल के नाम के बाद .txt फ़ाइल एक्सटेंशन न डालें.
field_name	टेक्स्ट	ज़रूरी है	इससे उस फ़ील्ड का नाम पता चलता है जिसका अनुवाद करना है. "टेक्स्ट" वाले फ़ील्ड का अनुवाद किया जा सकता है, जबकि यहां "यूआरएल," "ईमेल," और "फ़ोन नंबर" वाले फ़ील्ड शामिल किए जा सकते हैं, ताकि सही भाषा में उनकी जानकारी दी जा सके. ध्यान दें: दूसरे तरह के फ़ील्ड पर ध्यान नहीं दिया जाएगा और उनका अनुवाद नहीं किया जाएगा.
language	भाषा का कोड	ज़रूरी है	अनुवाद की भाषा के बारे में जानकारी मिलती है. अगर यह वही भाषा है जो feed_lang के feed_info.txt में है, तो फ़ील्ड की मूल वैल्यू ही डिफ़ॉल्ट वैल्यू होगी. भाषाओं में किसी खास अनुवाद के बिना इसी का इस्तेमाल किया जाएगा. उदाहरण के लिए, स्विट्ज़रलैंड में दो भाषाएं बोलने वाले कैंटन इलाके में एक शहर को आधिकारिक तौर पर "बील/बियेन" कहा जाता है, लेकिन इसे फ़्रेंच में "बियेन" और जर्मन में "बील" कहा जाएगा.
translation	टेक्स्ट, यूआरएल, ईमेल या फ़ोन नंबर	ज़रूरी है	बताए गए field_name के लिए अनुवाद की गई वैल्यू देता है.
record_id	आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	उस रिकॉर्ड के बारे में बताता है जो अनुवाद किए जाने वाले फ़ील्ड से मेल खाता है. record_id की वैल्यू, डेटासेट टेबल में मौजूद मुख्य आईडी होनी चाहिए, जैसा कि इस टेबल में दिखाया गया है: table_name record_id agency agency_id stops stop_id routes route_id trips trip_id stop_times trip_id pathways pathway_id levels level_id attributions attribution_id ये शर्तें तय करती हैं कि इस फ़ील्ड का इस्तेमाल कैसे किया जा सकता है: अगर table_name की वैल्यू feed_info के बराबर है, तो इसका इस्तेमाल न करें. अगर field_value की वैल्यू दी गई है, तो इसका इस्तेमाल न करें. अगर field_value की वैल्यू खाली है, तो इसका इस्तेमाल करना ज़रूरी है.
record_sub_id	आईडी	कुछ शर्तों के मुताबिक ज़रूरी है	जब record_id में मौजूद टेबल में विशेष आईडी नहीं होता, तब फ़ील्ड वाले रिकॉर्ड का आसानी से अनुवाद किया जा सकता है. record_sub_id में मौजूद वैल्यू, डेटासेट के टेबल का दूसरा आईडी है, जैसा कि इस टेबल में दिखाया गया है: table_name record_sub_id agency NONE stops NONE routes NONE trips NONE stop_times stop_sequence pathways NONE levels NONE attributions NONE ये शर्तें तय करती हैं कि इस फ़ील्ड का इस्तेमाल कैसे किया जा सकता है: अगर table_name की वैल्यू feed_info के बराबर है, तो इसका इस्तेमाल न करें. अगर field_value की वैल्यू दी गई है, तो इसका इस्तेमाल न करें. अगर table_name की वैल्यू stop_times के बराबर है और record_id दिया गया है, तो इसका इस्तेमाल करना ज़रूरी है.
field_value	टेक्स्ट, यूआरएल, ईमेल या फ़ोन नंबर	कुछ शर्तों के मुताबिक ज़रूरी है	कौनसे रिकॉर्ड का अनुवाद करना है, यह तय करने के लिए record_id और record_sub_id का इस्तेमाल करने के बजाय, field_value का इस्तेमाल करके अनुवाद करने वाली वैल्यू तय की जा सकती है. इसका इस्तेमाल करने पर, जब table_name और field_name वाले फ़ील्ड में बिल्कुल वही वैल्यू होती है जो field_value में दी गई है, तब अनुवाद लागू किया जाता है. field_value में दी गई वैल्यू से यह फ़ील्ड पूरी तरह मेल खाना चाहिए. अगर वैल्यू का सिर्फ़ एक ही सबसेट field_value से मेल खाता है, तो अनुवाद लागू नहीं होगा. अगर एक ही रिकॉर्ड से अनुवाद के दो नियम मेल खाते हैं, जैसे कि एक field_value के साथ और दूसरा record_id के साथ, तो record_id वाला नियम इस्तेमाल किया जाएगा. ये शर्तें तय करती हैं कि इस फ़ील्ड का इस्तेमाल कैसे किया जा सकता है: अगर table_name की वैल्यू feed_info के बराबर है, तो इसका इस्तेमाल न करें. अगर record_id की वैल्यू दी गई है, तो इसका इस्तेमाल न करें. अगर record_id की वैल्यू खाली है, तो इसका इस्तेमाल करना ज़रूरी है.

attributions.txt

फ़ाइल: ज़रूरी नहीं

फ़ील्ड का नाम	प्रकार	ज़रूरी है	ब्यौरा
attribution_id	आईडी	ज़रूरी नहीं	डेटासेट या इसके सबसेट के लिए किसी एट्रिब्यूशन की पहचान करता है. अनुवाद के लिए यह फ़ील्ड काम का है.
agency_id	आईडी का संदर्भ देना	ज़रूरी नहीं	वह एजेंसी जिस पर एट्रिब्यूशन लागू होता है. अगर एक agency_id, route_id या trip_id एट्रिब्यूशन को तय किया गया है, तो दूसरे फ़ील्ड खाली होने चाहिए. अगर एट्रिब्यूशन के लिए अलग से कुछ तय नहीं है, तो यह पूरे डेटासेट पर लागू होगा.
route_id	आईडी का संदर्भ देना	ज़रूरी नहीं	यह फ़ील्ड, agency_id की तरह ही काम करता है. बस इतना ही अंतर है कि एट्रिब्यूशन किसी रास्ते पर लागू होता है. एक ही रास्ते पर कई एट्रिब्यूशन लागू हो सकते हैं.
trip_id	आईडी का संदर्भ देना	ज़रूरी नहीं	यह फ़ील्ड, agency_id की तरह ही काम करता है. बस इतना अंतर है कि एट्रिब्यूशन किसी यात्रा पर लागू होता है. एक यात्रा पर कई एट्रिब्यूशन लागू हो सकते हैं.
organization_name	टेक्स्ट	ज़रूरी है	उस संगठन का नाम जिसे डेटासेट एट्रिब्यूट करता है.
is_producer	Enum	ज़रूरी नहीं	संगठन का काम भूमिका बनाने का है. इन वैल्यू को अनुमति दी गई है: • 0 या खाली : संगठन के पास यह काम नहीं है. • 1: संगठन के पास यह काम है. कम से कम एक फ़ील्ड, is_producer, is_operator या is_authority को 1 पर सेट किया जाना चाहिए.
is_operator	Enum	ज़रूरी नहीं	is_producer की तरह ही काम करता है. बस इतना ही अंतर है कि संगठन बतौर ऑपरेटर काम कर रहा है.
is_authority	Enum	ज़रूरी नहीं	is_producer की तरह ही काम करता है. बस इतना अंतर है कि संगठन के पास अनुमति देने का अधिकार है.
attribution_url	यूआरएल	ज़रूरी नहीं	संगठन का यूआरएल.
attribution_email	ईमेल	ज़रूरी नहीं	संगठन का ईमेल.
attribution_phone	फ़ोन नंबर	ज़रूरी नहीं	संगठन का फ़ोन नंबर.