जीटीएफ़एस रीयल टाइम रेफ़रंस

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

फ़ीड के वर्शन 2.0 की खास बातों के बारे में इस साइट पर चर्चा की गई है. साथ ही, इससे जुड़े दस्तावेज़ भी यहां मौजूद हैं.

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

ज़रूरी

जीटीएफ़एस-रीयल टाइम v2.0 और इसके ऊपर के वर्शन में, ज़रूरी कॉलम में बताया गया है कि निर्माता को किन फ़ील्ड की जानकारी देनी चाहिए, ताकि सार्वजनिक परिवहन का डेटा मान्य हो और जीटीएफ़एस का इस्तेमाल करने वाले ऐप्लिकेशन के काम का हो.

ज़रूरी फ़ील्ड में इन वैल्यू का इस्तेमाल किया जाता है:

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

ध्यान दें कि जीटीएफ़एस रीयल टाइम के वर्शन 1.0 में सिमैंटिक ज़रूरतों के बारे में नहीं बताया गया था. इसलिए, हो सकता है कि 1 के gtfs_realtime_version वाले फ़ीड इन ज़रूरतों को पूरा न करें (ज़्यादा जानकारी के लिए, सिमेंटिक ज़रूरतों के लिए सुझाव देखें).

घटकों की संख्या

घटकों की संख्या किसी एक फ़ील्ड के लिए एलिमेंट की संख्या को बताता है, जिनके लिए इन वैल्यू का इस्तेमाल करके जानकारी दी जा सकती है:

कौनसी फ़ील्ड कब ज़रूरी है, कब शर्त के साथ ज़रूरी है या ज़रूरी नहीं है, यह जानने के लिए हमेशा ज़रूरी और ब्यौरा फ़ील्ड देखें. प्रोटोकॉल बफ़र के दौरान घटकों की संख्या के लिए, कृपया 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 वाहन में और यात्री नहीं आ सकते.

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

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

फ़ील्ड

फ़ील्ड का नाम टाइप ज़रूरी घटकों की संख्या ब्यौरा
agency_id string कुछ शर्तों के मुताबिक ज़रूरी है एक कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.
route_id string कुछ शर्तों के मुताबिक ज़रूरी है एक कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.
route_type int32 कुछ शर्तों के मुताबिक ज़रूरी है एक कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.
trip TripDescriptor कुछ शर्तों के मुताबिक ज़रूरी है एक कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.
stop_id string कुछ शर्तों के मुताबिक ज़रूरी है एक कम से कम एक फ़ील्ड के लिए खास जानकारी दी जानी चाहिए - EntitySelector में सभी फ़ील्ड खाली नहीं छोड़े जा सकते.

मैसेज TranslatedString

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

फ़ील्ड

फ़ील्ड का नाम टाइप ज़रूरी घटकों की संख्या ब्यौरा
translation Translation ज़रूरी कई कम से कम एक अनुवाद दिया जाना चाहिए.

message Translation

स्थानीय भाषा में लिखे गए स्ट्रिंग को किसी भाषा पर मैप करना.

फ़ील्ड

फ़ील्ड का नाम टाइप ज़रूरी घटकों की संख्या ब्यौरा
text string ज़रूरी एक एक UTF-8 स्ट्रिंग जिसमें मैसेज है.
language string कुछ शर्तों के मुताबिक ज़रूरी है एक BCP-47 भाषा कोड. अगर भाषा के बारे में पता नहीं है या फ़ीड के लिए किसी भी तरह का अंतरराष्ट्रीयकरण नहीं किया गया है, तो छोड़ा जा सकता है. बिना बताई हुई भाषा के टैग वाले ज़्यादा से ज़्यादा एक अनुवाद की मंज़ूरी है - एक से ज़्यादा अनुवाद मौजूद होने पर, भाषा बताई जानी चाहिए.