जीटीएफ़एस रीयल टाइम फ़ीड की मदद से सार्वजनिक परिवहन एजेंसियां, उपभोक्ताओं को सेवा में किसी तरह की रुकावट (जैसे कि स्टेशन का बंद होना, किसी लाइन का काम नहीं करना, और कोई महत्वपूर्ण देरी वगैरह), गाड़ियों की लोकेशन, और पहुंचने के अनुमानित समय की रीयल टाइम जानकारी देती हैं.
फ़ीड के वर्शन 2.0 की खास बातों के बारे में इस साइट पर चर्चा की गई है. साथ ही, इससे जुड़े दस्तावेज़ भी यहां मौजूद हैं.
शब्दों के मतलब
ज़रूरी
जीटीएफ़एस-रीयल टाइम v2.0 और इसके ऊपर के वर्शन में, ज़रूरी कॉलम में बताया गया है कि निर्माता को किन फ़ील्ड की जानकारी देनी चाहिए, ताकि सार्वजनिक परिवहन का डेटा मान्य हो और जीटीएफ़एस का इस्तेमाल करने वाले ऐप्लिकेशन के काम का हो.
ज़रूरी फ़ील्ड में इन वैल्यू का इस्तेमाल किया जाता है:
- ज़रूरी: जीटीएफ़एस-रीयल टाइम फ़ीड निर्माता को इस फ़ील्ड की जानकारी देनी होगी.
- शर्त के साथ ज़रूरी: इस फ़ील्ड की जानकरी कुछ शर्तों के तहत ज़रूरी है. इन शर्तों के बारे में ब्यौरा फ़ील्ड में बताया गया है. इन शर्तों के बाहर, इस फ़ील्ड की जानकारी ज़रूरी नहीं है.
- ज़रूरी नहीं: यह फ़ील्ड ज़रूरी नहीं है. फ़ीड निर्माता के लिए इसकी जानकारी देना ज़रूरी नहीं है. हालांकि, वाहन की जगह के बारे में अपने-आप बताने वाले सिस्टम में अगर डेटा उपलब्ध है (जैसे,
VehiclePositiontimestamp), तो जब भी मुमकिन हो, फ़ीड निर्माता को इन वैकल्पिक फ़ील्ड की जानकारी देनी चाहिए.
ध्यान दें कि जीटीएफ़एस रीयल टाइम के वर्शन 1.0 में सिमैंटिक ज़रूरतों के बारे में नहीं बताया गया था. इसलिए, हो सकता है कि 1 के gtfs_realtime_version वाले फ़ीड इन ज़रूरतों को पूरा न करें (ज़्यादा जानकारी के लिए, सिमेंटिक ज़रूरतों के लिए सुझाव देखें).
घटकों की संख्या
घटकों की संख्या किसी एक फ़ील्ड के लिए एलिमेंट की संख्या को बताता है, जिनके लिए इन वैल्यू का इस्तेमाल करके जानकारी दी जा सकती है:
- एक - इस फ़ील्ड के लिए सिर्फ़ एक एलिमेंट की जानकारी दी जा सकती है. यह ज़रूरी प्रोटोकॉल बफ़र और वैकल्पिक घटकों की संख्या को मैप करता है.
- कई - इस फ़ील्ड के लिए कई एलिमेंट (0, 1 या ज़्यादा) की जानकारी दी जा सकती है. यह प्रोटोकॉल बफ़र दोहराए गए घटकों की संख्या के लिए मैप करता है.
कौनसी फ़ील्ड कब ज़रूरी है, कब शर्त के साथ ज़रूरी है या ज़रूरी नहीं है, यह जानने के लिए हमेशा ज़रूरी और ब्यौरा फ़ील्ड देखें. प्रोटोकॉल बफ़र के दौरान घटकों की संख्या के लिए, कृपया gtfs-realtime.proto देखें.
प्रोटोकॉल बफ़र का डेटा कितनी तरह का है
फ़ीड के एलिमेंट का ब्यौरा देने के लिए, प्रोटोकॉल बफ़र के इस तरह के डेटा का इस्तेमाल किया जाता है:
- मैसेज: कॉम्प्लेक्स टाइप
- enum: तय की गई वैल्यू की सूची
एक्सपेरिमेंटल फ़ील्ड
एक्सपेरिमेंटल माने जाने वाले फ़ील्ड में बदलाव हो सकते हैं. इसलिए, उन्हें औपचारिक तौर पर ब्यौरे में शामिल नहीं किया गया है. एक्सपेरिमेंटल फ़ील्ड को आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है.
एलिमेंट इंडेक्स
एलिमेंट
message FeedMessage
फ़ीड मैसेज का कॉन्टेंट. स्ट्रीम का हर एक मैसेज, सही एचटीटीपी GET अनुरोध के जवाब के तौर पर मिलता है. रीयल टाइम फ़ीड, हमेशा मौजूदा जीटीएफ़एस फ़ीड के लिहाज़ से तय किया जाता है. सभी इकाई आईडी का समाधान, जीटीएफ़एस फ़ीड के हिसाब से किया जाता है.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
header |
FeedHeader |
ज़रूरी है | एक | इस फ़ीड और फ़ीड मैसेज के बारे में मेटाडेटा. |
entity |
FeedEntity |
कुछ शर्तों के मुताबिक ज़रूरी है | कई | फ़ीड का कॉन्टेंट अगर सार्वजनिक परिवहन सिस्टम के लिए रीयल-टाइम जानकारी उपलब्ध है, तो यह फ़ील्ड दिया जाना चाहिए. अगर यह फ़ील्ड खाली है, तो उपभोक्ताओं को यह मान लेना चाहिए कि सिस्टम के लिए कोई रीयल-टाइम जानकारी उपलब्ध नहीं है. |
message FeedHeader
फ़ीड मैसेज में शामिल एक फ़ीड के बारे में मेटाडेटा.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
gtfs_realtime_version |
string |
ज़रूरी है | एक | फ़ीड के वर्शन की खास बात. फ़िलहाल, वर्शन 2.0 चल रहा है. |
incrementality |
Incrementality |
ज़रूरी है | एक | |
timestamp |
uint64 |
ज़रूरी है | एक | यह टाइमस्टैंप उस क्षण की पहचान करता है, जब इस फ़ीड का कॉन्टेंट बनाया गया (सर्वर में दिए गए समय के मुताबिक). POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). रीयल टाइम जानकारी देने और इस्तेमाल करने वाले सिस्टम के बीच समय का अंतर न रहे, इसके लिए ज़रूरी है कि timestamp को सर्वर के समय के हिसाब से निकाला जाए. Stratum 3 या इससे निचले स्तर के सर्वर का भी इस्तेमाल किया जा सकता है, क्योंकि कुछ सेकंड के समय के अंतर को नज़रअंदाज़ किया जा सकता है. |
enum Incrementality
यह बताता है कि निकाला गया नया फ़ीड बढ़ने लायक है या नहीं.
FULL_DATASET: यह फ़ीड अपडेट, फ़ीड के लिए सभी पिछली रीयल टाइम जानकारी ओवरराइट कर देगा. इसलिए, उम्मीद की जाती है कि यह फ़ीड अपडेट सभी रीयल टाइम जानकारी का पूरा स्नैपशॉट दे.DIFFERENTIAL: फ़िलहाल, यह मोड काम नहीं करता और इस मोड का इस्तेमाल करने वाले फ़ीड के लिए व्यवहार तय नहीं है.DIFFERENTIALमोड के काम करने के तरीके को लेकर जीटीएफ़एस रीयल टाइम जानकारी पाने वाले लोगों के बीच ईमेल से चर्चा चल रही है. इसके किसी नतीजे पर पहुंचने पर इससे जुड़े दस्तावेज़ को अपडेट कर दिया जाएगा.
वैल्यू
| वैल्यू |
|---|
FULL_DATASET |
DIFFERENTIAL |
मैसेज FeedEntity
सार्वजनिक परिवहन वाली फ़ीड में किसी इकाई की जानकारी (या अपडेट). अगर इकाई को मिटाया नहीं जा रहा, तो trip_update, vehicle और alert फ़ील्ड में से कोई एक फ़ील्ड दिखेगा.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
id |
string |
ज़रूरी है | एक | इकाई की पहचान के लिए फ़ीड में खास पहचानकर्ता. आईडी का इस्तेमाल सिर्फ़ इसे बढ़ाने में मदद करने के लिए किया जाता है. सिलेक्टर को उन असल इकाइयों के बारे में खास तौर से बताना चाहिए जिनके बारे में फ़ीड में बताया गया है (ज़्यादा जानकारी के लिए नीचे EntitySelector देखें). |
is_deleted |
bool |
ज़रूरी नहीं | एक | यह इकाई मिटाई जानी है या नहीं. सिर्फ़ DIFFERENTIAL के Incrementality वाले फ़ीड के लिए ही दिया जाना चाहिए - यह फ़ील्ड FULL_DATASET के Incrementality वाले फ़ीड के लिए नहीं दिया जाना चाहिए. |
trip_update |
TripUpdate |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | किसी यात्रा पर जाने में हुई देरी का रीयल टाइम डेटा. trip_update, vehicle या alert में से कम से कम एक फ़ील्ड दिया जाना चाहिए - ये सभी फ़ील्ड खाली नहीं हो सकते. |
vehicle |
VehiclePosition |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | वाहन की स्थिति के बारे में रीयल टाइम डेटा. trip_update, vehicle या alert में से कम से कम एक फ़ील्ड दिया जाना चाहिए - ये सभी फ़ील्ड खाली नहीं हो सकते. |
alert |
Alert |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | रीयल टाइम अलर्ट के बारे में डेटा. trip_update, vehicle या alert में से कम से कम एक फ़ील्ड दिया जाना चाहिए - ये सभी फ़ील्ड खाली नहीं हो सकते. |
मैसेज TripUpdate
यात्रा के दौरान वाहन की स्थिति पर रीयल टाइम अपडेट. कृपया यात्रा अपडेट इकाइयों को लेकर सामान्य चर्चा भी देखें.
ScheduleRelationship के वैल्यू के आधार पर, TripUpdate ये चीज़ें दिखा सकता है:
- शेड्यूल के मुताबिक चलने वाली यात्रा.
- किसी रूट पर बढ़ने वाली यात्रा, जिसका कोई तय शेड्यूल न हो.
- यात्रा, जिसे शेड्यूल के हिसाब से जोड़ा या हटाया गया हो.
ये अपडेट आगे की यात्राओं को लेकर हो सकते हैं, जैसे कि यात्रा से जुड़े आने/जाने के समय को लेकर या पिछली यात्राओं से जुड़े अपडेट. ज़्यादातर मामलों में, बीते इवेंट की जानकारी के लिए एक तय वैल्यू होती है, इसलिए इसके लिए तय नहीं की जाने वाली वैल्यू को 0 माना जाता है. हालांकि, कुछ मामलों में ऐसा नहीं भी होता, इसलिए किसी बीते इवेंट के लिए तय नहीं की जाने वाली वैल्यू 0 से अलग भी हो सकती है. अगर किसी अपडेट की तय नहीं की जाने वाली वैल्यू 0 नहीं है, तो यह ऐसी किसी यात्रा को लेकर करीब-करीब सही अनुमान है जो अभी जारी है या माप सही नहीं है या यह अपडेट किसी ऐसी पिछली यात्रा का अनुमान है जिसकी पुष्टि नहीं की गई है.
ध्यान दें कि अपडेट, ऐसी किसी यात्रा का ब्यौरा दे सकता है जो पूरी हो चुकी है. इसके लिए, यात्रा के आखिरी स्टॉप का अपडेट देना काफ़ी है. अगर यात्रा के आखिरी स्टॉप पर पहुंचने का समय पहले का है, तो क्लाइंट यह समझ जाएगा कि यह यात्रा बीते समय में की गई है (यहां यात्रा के पिछले स्टॉप के बारे में अपडेट देने का कोई मतलब नहीं बनता. हालांकि, ऐसा करना संभव है). यह विकल्प उस यात्रा के लिए सबसे सही है, जो शेड्यूल से पहले पूरी हो गई, जबकि शेड्यूल के मुताबिक, मौजूदा समय में यात्रा जारी है. इस यात्रा के लिए अपडेट को हटाने से क्लाइंट को यही लगेगा कि यात्रा अब भी जारी है. ध्यान दें कि फ़ीड देने वाले को पिछले अपडेट को हटाने की अनुमति है, लेकिन ऐसा करना ज़रूरी नहीं है - हालांकि, यह एक ऐसा मामला है जहां ऐसा करना उपयोगी होगा.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
trip |
TripDescriptor |
ज़रूरी है | एक | वह यात्रा जिस पर यह मैसेज लागू होता है. असल में हर एक यात्रा के लिए ज़्यादा से ज़्यादा एक TripUpdate इकाई हो सकती है. अगर कोई इकाई नहीं है, तो इसका मतलब है कि यात्रा के अनुमान को लेकर कोई जानकारी उपलब्ध नहीं है. इसका मतलब यह नहीं है कि यात्रा शेड्यूल के मुताबिक चल रही है. |
vehicle |
VehicleDescriptor |
ज़रूरी नहीं | एक | उस वाहन के बारे में अतिरिक्त जानकारी जिससे यात्रा की जा रही है. |
stop_time_update |
StopTimeUpdate |
कुछ शर्तों के मुताबिक ज़रूरी है | कई | यात्रा के लिए StopTimes पर अपडेट (आगे की जानी वाली यात्राओं के लिए अनुमान और कुछ मामलों में पिछली यात्राओं के बारे में अपडेट). अपडेट को stop_sequence के हिसाब से क्रम में लगाना चाहिए. साथ ही, अपडेट को अगले बताए गए stop_time_update तक, यात्रा के आगे के सभी स्टॉप के लिए लागू किया जाना चाहिए. अगर trip.schedule_relationship, CANCELED नहीं है, तो यात्रा के लिए कम से कम एक stop_time_update दिया जाना चाहिए - अगर यात्रा रद्द कर दी जाती है, तो stop_time_updates दिए जाने की ज़रूरत नहीं है. |
timestamp |
uint64 |
ज़रूरी नहीं | एक | यात्रा का वह क्षण जब वाहन की रीयल टाइम प्रगति मापी गई थी. POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). |
delay |
int32 |
ज़रूरी नहीं | एक | यात्रा के लिए मौजूदा शेड्यूल में किसी तरह का अंतर आना. delay के बारे में तभी बताया जाना चाहिए जब जीटीएफ़एस में मौजूदा शेड्यूल के लिहाज़ से कोई अनुमान दिया गया हो. delay (सेकंड के हिसाब से) पॉज़िटिव (मतलब कि वाहन शेड्यूल के हिसाब से पीछे चल रहा है) भी हो सकती है या नेगेटिव (वाहन शेड्यूल के हिसाब से आगे चल रहा है) भी. 0 का delay होने का मतलब है कि वाहन समय पर चल रहा है. StopTimeUpdates में देरी की जानकारी, यात्रा-लेवल पर देरी की जानकारी से ली जाती है. यात्रा-लेवल पर देरी की जानकारी, यात्रा के दौरान StopTimeUpdate delay देरी वैल्यू के साथ अगले स्टॉप तक ही दिखाई जाती है. फ़ीड देने वालों को TripUpdate.timestamp वैल्यू देने के लिए बढ़ावा दिया जाता है जो कि यह दिखाता है कि delay वैल्यू को पिछली बार कब अपडेट किया गया था. इससे यह पता चलता है कि डेटा कितना ताज़ा है. चेतावनी: यह फ़ील्ड अब भी एक्सपेरिमेंटल है और इसमें बदलाव किए जा सकते हैं. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है. |
message StopTimeEvent
किसी यात्रा के लिए आने या जाने के समय को लेकर किया गया अनुमान. समय की जानकारी में देरी और/या अनुमानित समय और किसी तरह की अनिश्चितता शामिल है.
delayका इस्तेमाल तभी किया जाना चाहिए, जब जीटीएफ़एस में किसी मौजूदा शेड्यूल के हिसाब से अनुमान दिया गया हो.timeदिया जाना चाहिए, भले ही अनुमानित शेड्यूल हो या नहीं. अगरtimeऔरdelay, दोनों के बारे में बताया गया है, तोtimeकी अहमियत बढ़ जाएगी (हालांकि, आम तौर पर, अगर शेड्यूल की गई यात्रा के लिएtimeदिया गया होता है, तो इसे जीटीएफ़एस में शेड्यूल किए गए समय + देरी के बराबर होना चाहिए).
समय और देरी पर अनिश्चितता एक तरह से लागू होती है. अनिश्चितता, असल में हुई देरी में हो सकने वाली गड़बड़ी को बताती है (लेकिन ध्यान दें, इसे सही से आंकड़ों में बता पाना फ़िलहाल मुमकिन नहीं है). अनिश्चितता के लिए दी गई वैल्यू 0 हो सकता है. जैसे, वे ट्रेन जिनके टाइम टेबल को कंप्यूटर नियंत्रित करता है.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
delay |
int32 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | delay फ़ील्ड (सेकंड में) पॉज़िटिव (मतलब कि वाहन शेड्यूल के हिसाब से पीछे चल रहा है) भी हो सकती है या नेगेटिव (वाहन शेड्यूल के हिसाब से आगे चल रहा है) भी. 0 के delay होने का मतलब है कि वाहन शेड्यूल के हिसाब से समय पर है. StopTimeEvent के अंदर, delay या time दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. |
time |
int64 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | इवेंट का पूरा समय POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). StopTimeEvent के अंदर, delay या time दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. |
uncertainty |
int32 |
ज़रूरी नहीं | एक | अगर अनिश्चितता हटा दी जाती है, तो उसे अज्ञात माना जाता है. किसी अनुमान को निश्चित बताने के लिए, उसकी अनिश्चितता की वैल्यू 0 पर सेट की जानी चाहिए. |
मैसेज StopTimeUpdate
किसी यात्रा के लिए बताए गए स्टॉप पर पहुंचने और/या वहां से निकलने के बारे में रीयल टाइम अपडेट. TripDescriptor और यात्रा अपडेट इकाइयां दस्तावेज़ में स्टॉप समय अपडेट की सामान्य चर्चा भी देखें.
पिछले और आने वाले इवेंट, दोनों के लिए अपडेट दिए जा सकते हैं. निर्माता को पिछले इवेंट को छोड़ने की अनुमति है. हालांकि, यह ज़रूरी नहीं है.
अपडेट को stop_sequence या stop_id की मदद से बताए गए स्टॉप से लिंक किया जाता है. इसलिए, ज़रूरी है कि दोनों में से एक फ़ील्ड को सेट किया गया हो. अगर किसी यात्रा में एक ही stop_id को एक से ज़्यादा बार देखा गया है, तो उस यात्रा के दौरान उस stop_id के लिए सभी StopTimeUpdates में stop_sequence दिया जाना चाहिए.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
stop_sequence |
uint32 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | इससे जुड़े जीटीएफ़एस फ़ीड में इसे stop_times.txt के जैसा होना चाहिए. StopTimeUpdate के अंदर, stop_sequence या stop_id दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. stop_sequence उन यात्राओं के लिए ज़रूरी है जो एक ही stop_id पर एक से ज़्यादा बार जाते हैं (जैसे कि लूप). इससे साफ़ तौर पर पता चल सकेगा कि अनुमान किस स्टॉप के लिए है. |
stop_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | इससे जुड़े जीटीएफ़एस फ़ीड में इसे stops.txt के जैसा होना चाहिए. StopTimeUpdate के अंदर, stop_sequence या stop_id दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. |
arrival |
StopTimeEvent |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | अगर schedule_relationship खाली या SCHEDULED है, तो StopTimeUpdate के अंदर arrival या departure दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं हो सकते. जब schedule_relationship SKIPPED हो, तो arrival और departure, दोनों खाली हो सकते हैं. अगर schedule_relationship NO_DATA है, तो arrival और departure खाली होने चाहिए. |
departure |
StopTimeEvent |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | अगर schedule_relationship खाली या SCHEDULED है, तो StopTimeUpdate के अंदर arrival या departure दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं हो सकते. जब schedule_relationship SKIPPED हो, तो arrival और departure, दोनों खाली हो सकते हैं. अगर schedule_relationship NO_DATA है, तो arrival और departure खाली होने चाहिए. |
schedule_relationship |
ScheduleRelationship |
ज़रूरी नहीं | एक | डिफ़ॉल्ट संबंध SCHEDULED है. |
enum ScheduleRelationship
तय किया हुआ शेड्यूल और इस StopTime के बीच संबंध.
वैल्यू
| वैल्यू | टिप्पणी |
|---|---|
SCHEDULED |
वाहन, शेड्यूल में स्टॉप के लिए दी गई जानकारी के मुताबिक आगे बढ़ रहा है. हालांकि, यह ज़रूरी नहीं कि वाहन शेड्यूल में दिए गए समय के हिसाब से आगे बढ़े. यह डिफ़ॉल्ट व्यवहार है. कम से कम एक arrival और departure देना ज़रूरी है. |
SKIPPED |
स्टॉप को छोड़ा गया, यानी कि वाहन इस स्टॉप पर नहीं रुकेगा. arrival और departure फ़ील्ड ज़रूरी नहीं हैं. |
NO_DATA |
इस स्टॉप के लिए कोई डेटा नहीं दिया गया है. इसका मतलब है कि कोई रीयल टाइम जानकारी उपलब्ध नहीं है. NO_DATA को आगे के दिए गए स्टॉप पर सेट करके यह जान सकते हैं कि किस स्टॉप के लिए रीयल टाइम जानकारी उपलब्ध नहीं है. यह सुझाया गया तरीका है. जब NO_DATA सेट किया गया हो, तब arrival और departure नहीं दिए जाने चाहिए. |
message VehiclePosition
किसी दिए गए वाहन की स्थिति के बारे में रीयल टाइम जानकारी.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
trip |
TripDescriptor |
ज़रूरी नहीं | एक | वह यात्रा, जिसके लिए इस वाहन का इस्तेमाल किया जा रहा है. अगर किसी यात्रा के लिए वाहन की पहचान नहीं हो पाती है, तो यह फ़ील्ड खाली या अधूरा रह सकता है. |
vehicle |
VehicleDescriptor |
ज़रूरी नहीं | एक | उस वाहन के बारे में अतिरिक्त जानकारी जिससे यात्रा की जा रही है. हर एंट्री में वाहन के लिए खास आईडी दिया जाना चाहिए. |
position |
Position |
ज़रूरी नहीं | एक | फ़िलहाल वाहन कहां है, उसकी जानकारी. |
current_stop_sequence |
uint32 |
ज़रूरी नहीं | एक | यात्रा के मौजूदा स्टॉप के लिए स्टॉप सीक्वेंस इंडेक्स. current_stop_sequence का मतलब (यानी कि वह स्टॉप जिसके बारे में बताया गया है) current_status से निकाला जाता है अगर current_status मौजूद नहीं है, तो IN_TRANSIT_TO का अंदाज़ा लगाया जाता है. |
stop_id |
string |
ज़रूरी नहीं | एक | मौजूदा स्टॉप की पहचान करता है. जो वैल्यू stops.txt में है वही वैल्यू इससे जुड़े जीटीएफ़एस फ़ीड में होनी चाहिए. |
current_status |
VehicleStopStatus |
ज़रूरी नहीं | एक | मौजूदा स्टॉप के हिसाब से वाहन की जगह की सटीक जानकारी. अगर current_stop_sequence मौजूद नहीं है, तो इस पर ध्यान न दें. |
timestamp |
uint64 |
ज़रूरी नहीं | एक | वह क्षण, जब वाहन की स्थिति को मापा गया था. POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). |
congestion_level |
CongestionLevel |
ज़रूरी नहीं | एक | |
occupancy_status |
OccupancyStatus |
ज़रूरी नहीं | एक | वाहन में यात्रियों की संख्या. चेतावनी: यह फ़ील्ड अब भी एक्सपेरिमेंटल है, और इसमें बदलाव हो सकता है. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है. |
enum VehicleStopStatus
वैल्यू
| वैल्यू | टिप्पणी |
|---|---|
INCOMING_AT |
वाहन, स्टॉप पर पहुंचने वाला है (स्टॉप डिस्प्ले पर, वाहन का निशान दिखने लगता है). |
STOPPED_AT |
वाहन, स्टॉप पर खड़ा है. |
IN_TRANSIT_TO |
वाहन, पिछले स्टॉप से चल चुका है और रास्ते में है. |
enum CongestionLevel
वाहन में कितनी भीड़ है और इससे वाहन पर कितना असर हो रहा है.
वैल्यू
| वैल्यू |
|---|
UNKNOWN_CONGESTION_LEVEL |
RUNNING_SMOOTHLY |
STOP_AND_GO |
CONGESTION |
SEVERE_CONGESTION |
enum OccupancyStatus
वाहन में यात्रियों की संख्या.
चेतावनी: यह फ़ील्ड अब भी एक्सपेरिमेंटल है और इसमें बदलाव हो सकता है. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है.
वैल्यू
| वैल्यू | टिप्पणी |
|---|---|
EMPTY |
वाहन ज़्यादातर मामलों में खाली है और उसमें कोई भी यात्री नहीं है या कुछ यात्री हैं. अब भी उसमें और यात्री बैठ सकते हैं. |
MANY_SEATS_AVAILABLE |
गाड़ी या डिब्बे में बड़ी संख्या में सीट मौजूद हैं. कुल सीटों में से कितनी मुफ़्त सीट उपलब्ध हैं, यह तय करना मालिक के फ़ैसले पर निर्भर करता है. |
FEW_SEATS_AVAILABLE |
वाहन या डिब्बे में कुछ प्रतिशत खाली सीटें हैं. कुल सीटों में से कितनी सीटें मुफ़्त में मानी जा सकती हैं, यह पूरी तरह से निर्माता के फ़ैसले पर निर्भर करता है. |
STANDING_ROOM_ONLY |
फ़िलहाल, गाड़ी या डिब्बे में सिर्फ़ वही लोग आ सकते हैं जो खड़े रहकर यात्रा कर सकते हैं. |
CRUSHED_STANDING_ROOM_ONLY |
फ़िलहाल, गाड़ी या डिब्बे में सिर्फ़ वही लोग आ सकते हैं जो खड़े रहकर यात्रा कर सकते हैं. उनके लिए भी जगह कम है. |
FULL |
वाहन को करीब-करीब भरा माना जा रहा है, लेकिन अब भी उसमें और यात्री आ सकते हैं. |
NOT_ACCEPTING_PASSENGERS |
वाहन या डिब्बा, यात्रियों को स्वीकार नहीं कर रहे हैं. गाड़ी या डिब्बे में यात्री आम तौर पर चढ़ सकते हैं. |
NO_DATA_AVAILABLE |
फ़िलहाल, गाड़ी या गाड़ी के लिए, व्यस्तता की दर से जुड़ा कोई डेटा उपलब्ध नहीं है. |
NOT_BOARDABLE |
वाहन या केबिन में बोर्डिंग नहीं की जा सकती और कभी भी यात्रियों को स्वीकार नहीं किया जाता है. खास वाहनों या डिब्बों (इंजन, रखरखाव के डिब्बे वगैरह) के लिए उपयोगी. |
message Alert
एक अलर्ट, जो सार्वजनिक परिवहन के नेटवर्क में किसी घटना का संकेत दे रहा है.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
active_period |
TimeRange |
ज़रूरी नहीं | कई | वह समय जब उपयोगकर्ताओं को अलर्ट दिखाया जाना चाहिए. अगर कोई समय नहीं दिया गया है, तो अलर्ट तब तक दिखाया जाएगा, जब तक वह फ़ीड में रहेगा. अगर एक से ज़्यादा टाइम रेंज दिए गए हैं, तो अलर्ट उन सभी के दौरान दिखाया जाएगा. |
informed_entity |
EntitySelector |
ज़रूरी है | कई | वे इकाइयां जिनके उपयोगकर्ताओं को हमें इस अलर्ट के बारे में सूचना देनी चाहिए. कम से कम एक informed_entity दिया जाना चाहिए. |
cause |
Cause |
ज़रूरी नहीं | एक | |
effect |
Effect |
ज़रूरी नहीं | एक | |
url |
TranslatedString |
ज़रूरी नहीं | एक | वह यूआरएल जो अलर्ट के बारे में और जानकारी देता है. |
header_text |
TranslatedString |
ज़रूरी | एक | अलर्ट के लिए हेडर. इस सादे लेख के स्ट्रिंग को हाइलाइट किया जाएगा, जैसे कि बोल्डफ़ेस में. |
description_text |
TranslatedString |
ज़रूरी है | एक | अलर्ट का ब्यौरा इस सादे लेख के स्ट्रिंग को अलर्ट मैसेज की बॉडी के रूप में फ़ॉर्मैट किया जाएगा (या उपयोगकर्ता के साफ़ तौर पर "बड़ा करने" के अनुरोध पर दिखाया जाएगा). ब्यौरे में, हेडर की जानकारी से ज़्यादा जानकारी होनी चाहिए. |
enum Cause
इस अलर्ट की वजह.
वैल्यू
| वैल्यू |
|---|
UNKNOWN_CAUSE |
OTHER_CAUSE |
TECHNICAL_PROBLEM |
STRIKE |
DEMONSTRATION |
ACCIDENT |
HOLIDAY |
WEATHER |
MAINTENANCE |
CONSTRUCTION |
POLICE_ACTIVITY |
MEDICAL_EMERGENCY |
enum असर
प्रभावित इकाई पर इस समस्या का असर.
वैल्यू
| वैल्यू |
|---|
NO_SERVICE |
REDUCED_SERVICE |
SIGNIFICANT_DELAYS |
DETOUR |
ADDITIONAL_SERVICE |
MODIFIED_SERVICE |
OTHER_EFFECT |
UNKNOWN_EFFECT |
STOP_MOVED |
message TimeRange
समय का अंतराल. अंतराल को t समय पर चालू माना जाता है, अगर t start समय से ज़्यादा या उसके बराबर है और end समय से कम है.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
start |
uint64 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | शुरू होने का समय, POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). अगर मौजूद नहीं है, तो अंतराल माइनस इन्फ़िनिटी पर शुरू होता है. अगर TimeRange दिया गया है, तो start या end देना ज़रूरी है - दोनों फ़ील्ड खाली नहीं होने चाहिए. |
end |
uint64 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | खत्म होने का समय, POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). अगर मौजूद नहीं है, तो अंतराल प्लस इनफ़िनिटी पर खत्म होता है. अगर TimeRange दिया गया है, तो start या end देना ज़रूरी है - दोनों फ़ील्ड खाली नहीं होने चाहिए. |
message स्थिति
किसी वाहन की भौगोलिक स्थिति.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
latitude |
float |
ज़रूरी है | एक | WGS-84 कॉर्डिनेट सिस्टम में, डिग्री नॉर्थ. |
longitude |
float |
ज़रूरी | एक | WGS-84 कॉर्डिनेट सिस्टम में, डिग्री ईस्ट. |
bearing |
float |
ज़रूरी नहीं | एक | बियरिंग, डिग्री में, उत्तर से घड़ी की दिशा में, यानी, 0 उत्तर है और 90 पूर्व है. यह कंपास बियरिंग हो सकता है या अगले स्टॉप की दिशा या बीच का कोई लोकेशन. इसका नतीजा पिछली भौगोलिक स्थिति के क्रम के आधार पर नहीं निकाला जाना चाहिए, जिसकी गणना क्लाइंट पिछले डेटा से कर सकते हैं. |
odometer |
double |
ज़रूरी नहीं | एक | मीटर में, ओडोमीटर की वैल्यू. |
speed |
float |
ज़रूरी नहीं | एक | किसी दिए गए समय पर कुछ देर के लिए वाहन से मीटर प्रति सेकंड में मापी गई रफ़्तार. |
message TripDescriptor
ऐसा डिस्क्रिप्टर जो जीटीएफ़एस यात्रा के सिंगल इंस्टेंस की पहचान करता है.
किसी सिंगल ट्रिप इंस्टेंस की पहचान के लिए, trip_id कई मामलों में खुद सही तरीके से काम करता है.
हालांकि, नीचे दिए गए मामलों में सिंगल ट्रिप इंस्टेंस को सुलझाने के लिए
ज़्यादा जानकारी की ज़रूरत होती है:
- अगर यात्रा की जानकारी
frequencies.txtमें दी गई है, तोtrip_idके अलावा,start_dateऔरstart_timeकी भी ज़रूरत होगी. - अगर यात्रा 24 घंटे से ज़्यादा की है या अगले दिन, शेड्यूल की गई यात्रा के साथ टकराने
की वजह से यात्रा में देरी की संभावना है, तो
start_dateऔरtrip_id, दोनों की जानकारी दें. - अगर
trip_idफ़ील्ड की जानकारी नहीं है, तो आपकोroute_id,direction_id,start_date, औरstart_timeफ़ील्ड की जानकारी ज़रूर देनी होगी.
सभी मामलों में, अगर route_id और trip_id दोनों दिए गए हैं, तो route_id
जीटीएफ़एस trips.txt फ़ाइल में दी गई यात्रा के route_id फ़ील्ड से ज़रूर मेल खाना चाहिए.
trip_id फ़ील्ड, खुद या किसी दूसरे TripDescriptor
फ़ील्ड के साथ मिलाकर, एक से ज़्यादा यात्रा के इंस्टेंस की पहचान करने में इस्तेमाल नहीं किया जा सकता. अगर TripDescriptor
के नतीजे, शून्य या एक से ज़्यादा यात्रा के इंस्टेंस आते हैं, तो इसे
गलती माना जाएगा. जिस इकाई में गलती वाला TripDescriptor है
उसे ग्राहक खारिज कर सकते हैं.
उदाहरण के लिए, जब कोई यात्रा जीटीएफ़एस frequencies.txt में exact_times=0 के साथ बताई जाती है,
तो TripDescriptor, trip_id अपने-आप नहीं बताता. इसलिए, दिन के किसी खास समय पर
शुरू होने वाली किसी एक यात्रा के इंस्टेंस को सुलझाते समय
आपको start_time बताना होगा.
ध्यान रखें कि अगर trip_id नहीं पता, तो TripUpdate
में स्टेशन के क्रम के आईडी होना काफ़ी नहीं है. साथ ही, stop_id फ़ील्ड में भी जानकारी ज़रूर भरी होनी चाहिए. इसके साथ ही,
आने और जाने का ठीक समय भी बताना होगा.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
trip_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड से लिया गया वह trip_id जिसके बारे में इस सिलेक्टर ने बताया है. trip_id ज़रूरी है या नहीं, यह इस पर निर्भर करता है कि यात्रा किस तरह की है: • बिना फ़्रीक्वेंसी आधारित यात्राएं: ऐसी यात्राओं की पहचान के लिए सिर्फ़ trip_id फ़ील्ड ही काफ़ी है. ध्यान रखें कि जो यात्राएं, फ़्रीक्वेंसी पर आधारित नहीं हैं उनके बारे में जीटीएफ़एस frequencies.txt में नहीं बताया गया है. • फ़्रीक्वेंसी पर आधारित यात्राएं: trip_id, start_time, और start_date का फ़ील्ड भरना ज़रूरी है. फ़्रीक्वेंसी पर आधारित यात्राएं जीटीएफ़एस frequencies.txt में बताई गई हैं. • शेड्यूल पर आधारित यात्राएं: trip_id फ़ील्ड को सिर्फ़ तभी खाली छोड़ा जा सकता है जब यात्रा की पहचान, दिए गए route_id, direction_id, start_time, और start_date फ़ील्ड को मिलाकर की जा सकती हो. ध्यान रखें कि शेड्यूल पर आधारित यात्राएं जीटीएफ़एस frequencies.txt में नहीं बताई गई हैं. |
route_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड से लिया गया वह route_id जिसके बारे में इस सिलेक्टर ने बताया है. अगर trip_id को हटाया जाता है, तो यात्रा के इंस्टेंस की पहचान के लिए route_id, direction_id, start_time, और schedule_relationship=SCHEDULED ज़रूर दिए जाने चाहिए. |
direction_id |
uint32 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड की direction_id फ़ाइल का trips.txt, यात्रा की दिशा के बारे में बताता है. अगर trip_id हटाया गया है, तो direction_id दिया जाना चाहिए. चेतावनी: यह फ़ील्ड अब भी एक्सपेरिमेंटल है और इसमें बदलाव हो सकते हैं. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है. |
start_time |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | इस यात्रा के लिए शुरुआत में शेड्यूल किया गया स्टार्ट टाइम. फ़ील्ड टाइप Time, इस फ़ील्ड का फ़ॉर्मैट बताता है. उदाहरण के लिए, 11:15:35 या 25:15:35. start_time फ़ील्ड भरना ज़रूरी है या नहीं, यह इस पर निर्भर करता है कि यात्रा किस तरह की है: • trip_id बिना फ़्रीक्वेंसी पर आधारित यात्रा की जानकारी देता है: start_time फ़ील्ड या तो छोड़ देना चाहिए या जीटीएफ़एस फ़ीड की stop_times.txt फ़ाइल में, departure_time की वैल्यू के बराबर होना चाहिए. • trip_id ऐसी यात्रा से मेल खाता है जो फ़्रीक्वेंसी पर आधारित है: start_time की हमेशा ज़रूरत होती है और यह यात्रा के अपडेट और वाहन की स्थिति के लिए बताया जाना ज़रूरी होता है. फ़्रीक्वेंसी पर आधारित यात्राएं जीटीएफ़एस frequencies.txt में बताई गई हैं. ◦ अगर फ़्रीक्वेंसी पर आधारित यात्रा, exact_times=1 जीटीएफ़एस रिकॉर्ड से मेल खाती है: start_time फ़ील्ड में, समयावधि के हिसाब से एक से ज़्यादा frequencies.txt start_time के बाद के headway_secs दिए हुए होंगे, जिसमें ज़ीरो भी शामिल होगा. ◦ अगर फ़्रीक्वेंसी पर आधारित यात्रा, exact_times=0 जीटीएफ़एस रिकॉर्ड से मेल खाती है: start_time मनमुताबिक हो सकता है और इसे यात्रा के लिए पहला डिपार्चर माना जा सकता है. एक बार स्थापित होने के बाद, फ़्रीक्वेंसी पर आधारित इस exact_times=0 यात्रा के start_time को बदला नहीं जा सकता. पहला डिपार्चर का समय बदलने की स्थिति में भी इसे बदला नहीं जा सकेगा. समय में किए गए बदलाव इसके बजाय शायद StopTimeUpdate मैसेज में दिखें. • trip_id हटाया गया: start_time दिया जाना चाहिए. |
start_date |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | इस यात्रा के लिए, शुरू होने की तारीख YYYYMMDD फ़ॉर्मैट में दी जा सकती है. start_date की ज़रूरत है या नहीं, यह इस पर निर्भर करता है कि यात्रा किस तरह की है: • शेड्यूल की गई यात्राएं: start_date ज़रूर दिया जाना चाहिए. बहुत देर से शुरू होने वाली यात्राओं में अंतर करने के लिए ऐसा किया जाता है, ताकि अगले दिन शेड्यूल की गई यात्रा से वे यात्राएं टकरा न जाएं. उदाहरण के लिए, मान लें कि हर दिन एक ट्रेन 8:00 और 20:00 बजे चलती है. अगर ट्रेन 12 घंटे लेट है, तो एक ही समय पर दो अलग-अलग यात्राएं शेड्यूल हो जाएंगी. ध्यान दें: यह फ़ील्ड उन शेड्यूल की गई यात्राओं के लिए वैकल्पिक है जिनमें इस तरह के टकराव मुमकिन नहीं हैं. उदाहरण के लिए, ऐसा तब हो सकता है, जब कोई सेवा हर घंटे के शेड्यूल पर चलती है और एक घंटा देरी से चलने वाले वाहन को शेड्यूल से जुड़ा नहीं माना जाता. • फ़्रीक्वेंसी पर-आधारित यात्राएं: start_date ज़रूर दिया जाना चाहिए. ध्यान रखें कि फ़्रीक्वेंसी पर आधारित यात्राएं, जीटीएफ़एस frequencies.txt फ़ाइल में बताई गई हैं, जबकि शेड्यूल की गई यात्राएं नहीं. • trip_id हटाया गया: start_date दिया जाना चाहिए. |
schedule_relationship |
ScheduleRelationship |
ज़रूरी नहीं | एक | स्टैटिक शेड्यूल और इस यात्रा के बीच संबंध. अगर TripDescriptor, Alert EntitySelector में दिया गया है, तो मेल खाने वाली यात्रा के इंस्टेंस की पहचान होने पर ग्राहकों को schedule_relationship फ़ील्ड को नज़रअंदाज़ करना चाहिए. |
enum ScheduleRelationship
स्टैटिक शेड्यूल और इस यात्रा के बीच संबंध. अगर यह यात्रा, जीटीएफ़एस में नहीं दिखाए गए अस्थायी शेड्यूल के मुताबिक की जाती है, तो इसे SCHEDULED के तौर पर मार्क करने के बजाय ADDED के तौर पर मार्क करना चाहिए.
वैल्यू
| वैल्यू | टिप्पणी |
|---|---|
SCHEDULED |
वह यात्रा, जो अपने जीटीएफ़एस शेड्यूल के अनुसार चल रही हो या उससे जोड़े जाने वाली शेड्यूल की गई यात्रा के करीब हो. |
ADDED |
चल रहे शेड्यूल के साथ दूसरी यात्रा को जोड़ना. जैसे कि एक खराब वाहन को बदलने के लिए या अचानक बढ़े यात्रियों के भार की वजह से दूसरी यात्रा जोड़ना. |
UNSCHEDULED |
एक चल रही यात्रा, जिसके साथ कोई शेड्यूल जुड़ा नहीं है - इस वैल्यू का इस्तेमाल जीटीएफ़एस frequencies.txt में परिभाषित exact_times = 0 वाली यात्राओं की पहचान करने के लिए किया जाता है. इसका इस्तेमाल जीटीएफ़एस frequencies.txt में परिभाषित न की गई यात्राओं या जीटीएफ़एस frequencies.txt में exact_times = 1 वाली यात्राओं के बारे में बताने के लिए नहीं किया जाना चाहिए. |
CANCELED |
यात्रा जो शेड्यूल में मौजूद थी, लेकिन हटा दी गई थी. |
message VehicleDescriptor
यात्रा के लिए इस्तेमाल किए जा रहे वाहन की पहचान से जुड़ी जानकारी.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
id |
string |
ज़रूरी नहीं | एक | वाहन की पहचान बताने वाला अंदरूनी सिस्टम. यह हर एक वाहन के लिए खास होना चाहिए. जैसे-जैसे वाहन आगे बढ़ता है, इसका इस्तेमाल उसे ट्रैक करने के लिए किया जाता है. यह आईडी असली उपयोगकर्ता को नहीं दिखना चाहिए. इसके लिए label फ़ील्ड का इस्तेमाल करें. |
label |
string |
ज़रूरी नहीं | एक | उपयोगकर्ता को दिखने वाला लेबल, यानी कि ऐसी कोई चीज़ जो उपयोगकर्ता को दिखानी चाहिए, ताकि वह सही वाहन की पहचान कर सके. |
license_plate |
string |
ज़रूरी नहीं | एक | वाहन की लाइसेंस प्लेट. |
message EntitySelector
जीटीएफ़एस फ़ीड में किसी इकाई के लिए सिलेक्टर. फ़ील्ड की वैल्यू को जीटीएफ़एस फ़ीड में मौजूद सही फ़ील्ड के मुताबिक होना चाहिए. कम से कम एक फ़ील्ड की खास बात की जानकारी दी जानी चाहिए. अगर कई ऑपरेटर दिए गए हैं, तो उनकी गिनती लॉजिकल ऑपरेटर AND से जुड़ने के तौर पर की जानी चाहिए. इसके अलावा, खास जानकारी के कॉम्बिनेशन को जीटीएफ़एस फ़ीड में मौजूद जानकारी से मैच करना चाहिए. दूसरे शब्दों में, किसी चेतावनी को जीटीएफ़एस में लागू करने के लिए, उसे दिए गए सभी EntitySelector फ़ील्ड से मेल खाना चाहिए. उदाहरण के लिए, route_id: "5" और route_type: "3" फ़ील्ड वाली EntitySelector सिर्फ़ route_id: "5" बस पर लागू होती है, route_type: "3" के किसी भी दूसरे रास्ते पर लागू नहीं होती. अगर किसी प्रोड्यूसर को route_id: "5" के साथ-साथ route_type: "3" पर लागू होने की चेतावनी चाहिए, तो उसे दो अलग-अलग EntitySelector फ़ील्ड देने चाहिए, जिनमें से एक route_id: "5" और route_type: "3" का रेफ़रंस देने वाला फ़ील्ड हो.
कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
agency_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड से लिया गया वह agency_id जिसके बारे में इस सिलेक्टर ने बताया है. |
route_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस में से route_id का नाम, जिसके बारे में इस सिलेक्टर ने बताया है. अगर direction_id दिया गया है, तो route_id भी दिया जाना चाहिए. |
route_type |
int32 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस में से route_type का नाम, जिसके बारे में इस सिलेक्टर ने बताया है. |
direction_id |
uint32 |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड की trips.txt फ़ाइल का direction_id, route_id की ओर से बताए गए किसी रास्ते के लिए सभी यात्राओं को एक ही जगह पर चुनता है. अगर direction_id दिया गया है, तो route_id भी दिया जाना चाहिए. |
trip |
TripDescriptor |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस यात्रा से जुड़ा वह इंस्टेंस जिसके बारे में इस सिलेक्टर ने बताया है. TripDescriptor को जीटीएफ़एस डेटा में सिंगल ट्रिप इंस्टेंस का समाधान करना चाहिए (उदाहरण के लिए, एक प्रोड्यूसर exact_times=0 यात्राओं के लिए सिर्फ़ trip_id नहीं दे सकता). अगर इस TripDescriptor के अंदर ScheduleRelationship फ़ील्ड में जानकारी अपने-आप भरी जाती है, तो उपभोक्ता जीटीएफ़एस यात्रा की पहचान करने की कोशिश करते समय इसे नज़रअंदाज़ कर देंगे. |
stop_id |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | जीटीएफ़एस फ़ीड से लिया गया वह stop_id जिसके बारे में इस सिलेक्टर ने बताया है. |
मैसेज TranslatedString
एक अंतरराष्ट्रीय मैसेज, जिसमें टेक्स्ट या URL के स्निपेट के लिए भाषा के अनुसार वर्शन शामिल हैं. मैसेज में से एक स्ट्रिंग को चुना जाएगा. समाधान ऐसे होता है: अगर यूज़र इंटरफ़ेस (यूआई) भाषा, अनुवाद के भाषा कोड से मेल खाती है, तो पहला मिलता-जुलता अनुवाद चुना जाता है. अगर एक डिफ़ॉल्ट यूआई भाषा (जैसे, अंग्रेज़ी) किसी अनुवाद के भाषा कोड से मेल खाती है, तो पहला मिलता-जुलता अनुवाद चुना जाता है. अगर किसी अनुवाद में भाषा कोड के बारे में साफ़-साफ़ पता नहीं है, तो वह अनुवाद चुना जाता है.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
translation |
Translation |
ज़रूरी है | कई | कम से कम एक अनुवाद दिया जाना चाहिए. |
message Translation
स्थानीय भाषा में लिखे गए स्ट्रिंग को किसी भाषा पर मैप करना.
फ़ील्ड
| फ़ील्ड का नाम | टाइप | ज़रूरी | घटकों की संख्या | ब्यौरा |
|---|---|---|---|---|
text |
string |
ज़रूरी है | एक | एक UTF-8 स्ट्रिंग जिसमें मैसेज है. |
language |
string |
कुछ शर्तों के मुताबिक ज़रूरी है | एक | BCP-47 भाषा कोड. अगर भाषा के बारे में पता नहीं है या फ़ीड के लिए किसी भी तरह का अंतरराष्ट्रीयकरण नहीं किया गया है, तो छोड़ा जा सकता है. बिना बताई हुई भाषा के टैग वाले ज़्यादा से ज़्यादा एक अनुवाद की मंज़ूरी है - एक से ज़्यादा अनुवाद मौजूद होने पर, भाषा बताई जानी चाहिए. |