रेफ़रंस

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

विषय-सूची

शब्दों के मतलब
फ़ील्ड टाइप
डेटासेट वाली फ़ाइलें
फ़ाइल की ज़रूरतें
फ़ील्ड के मतलब

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

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

डेटासेट - ऐसी फ़ाइलों का पूरा सेट जिनके बारे में इस स्पेसिफ़िकेशन के तहत बताया गया है. डेटासेट में बदलाव करने पर, डेटासेट का नया वर्शन तैयार हो जाता है. डेटासेट को एक सार्वजनिक और हमेशा मौजूद रहने वाले यूआरएल पर पब्लिश करना चाहिए. इसमें 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.
ईमेल - एक ईमेल पता.
उदाहरण: example@example.com
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`	फ़ोन नंबर	ज़रूरी नहीं	संगठन का फ़ोन नंबर.