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

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

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

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

ज़रूरी

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

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

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

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

एलिमेंट की संख्या

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

कौनसी फ़ील्ड कब ज़रूरी है, कब शर्त के साथ ज़रूरी है या ज़रूरी नहीं है, यह जानने के लिए हमेशा ज़रूरी और ब्यौरा फ़ील्ड देखें. प्रोटोकॉल बफ़र के दौरान एलिमेंट की संख्या के लिए, कृपया gtfs-realtime.proto देखें.

प्रोटोकॉल बफ़र का डेटा कितने तरह का है

फ़ीड के एलिमेंट का ब्यौरा देने के लिए प्रोटोकॉल बफ़र के इस तरह के डेटा का इस्तेमाल किया जाता है:

  • message: कॉम्प्लेक्स टाइप
  • enum: तय किए गए मानों की सूची

एक्सपेरिमेंटल फ़ील्ड

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

एलिमेंट इंडेक्स

एलिमेंट

message FeedMessage

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

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
header FeedHeader ज़रूरी एक इस फ़ीड और फ़ीड मैसेज के बारे में मेटाडेटा.
entity FeedEntity शर्त के साथ ज़रूरी कई फ़ीड का कॉन्टेंट अगर सार्वजनिक परिवहन के सिस्टम के लिए रीयल-टाइम जानकारी उपलब्ध है, तो यह फ़ील्ड दिया जाना चाहिए. अगर यह फ़ील्ड खाली है, तो उपभोक्ताओं को यह मान लेना चाहिए कि सिस्टम के लिए कोई रीयल-टाइम जानकारी उपलब्ध नहीं है.

message FeedHeader

फ़ीड मैसेज में शामिल, फ़ीड के बारे में मेटाडेटा.

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
gtfs_realtime_version स्ट्रिंग ज़रूरी एक फ़ीड के वर्शन की खास बात. फ़िलहाल, वर्शन 2.0 चल रहा है.
incrementality Incrementality ज़रूरी एक
timestamp uint64 ज़रूरी एक यह टाइमस्टैंप उस पल की पहचान करता है, जब इस फ़ीड का कॉन्टेंट बनाया गया (सर्वर में दिए गए समय के मुताबिक). POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). रीयल टाइम जानकारी देने और इस्तेमाल करने वाले सिस्टम के बीच के समय का अंतर न रहे, इसके लिए ज़रूरी है कि टाइमस्टैंप को सर्वर के समय के हिसाब से निकाला जाए. Stratum 3 या इससे निचले स्तर के सर्वर का भी इस्तेमाल किया जा सकता है, क्योंकि कुछ सेकंड के समय के अंतर को नज़रअंदाज़ किया जा सकता है.

enum Incrementality

यह बताता है कि निकाली गई नई फ़ीड बढ़ने लायक है या नहीं.

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

मान

मान
FULL_DATASET
DIFFERENTIAL

message FeedEntity

सार्वजनिक परिवहन वाली फ़ीड में किसी इकाई की जानकारी (या अपडेट). अगर इकाई को मिटाया नहीं जा रहा है, तो 'trip_update', 'गाड़ी' और 'अलर्ट' फ़ील्ड में से कोई एक फ़ील्ड दिखेगी.

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
id स्ट्रिंग ज़रूरी एक इकाई की पहचान के लिए फ़ीड में खास पहचानकर्ता. आईडी का इस्तेमाल सिर्फ़ इसे बढ़ाने में मदद करने के लिए किया जाता है. जिन असल इकाईयों के बारे में फ़ीड में रेफ़रंस दिया गया है, उनके बारे में सिलेक्टर को खास तौर से बताना चाहिए (ज़्यादा जानकारी के लिए नीचे EntitySelector देखें).
is_deleted bool ज़रूरी नहीं एक क्या यह इकाई मिटाई जानी है. सिर्फ़ DIFFERENTIAL में बढ़ने लायक फ़ीड के लिए जानकारी दी जानी चाहिए - FULL_DATASET में बढ़ने लायक फ़ीड के लिए इस फ़ील्ड की जानकारी नहीं दी जानी चाहिए.
trip_update TripUpdate शर्त के साथ ज़रूरी एक किसी यात्रा पर जाने में हुई देरी का रीयल टाइम डेटा. trip_update, वाहन या अलर्ट में से किसी एक फ़ील्ड की जानकारी देना ज़रूरी है. सभी फ़ील्ड को खाली नहीं छोड़ा जा सकता.
vehicle VehiclePosition शर्त के साथ ज़रूरी एक वाहन की स्थिति के बारे में रीयल टाइम डेटा trip_update, वाहन या अलर्ट में से किसी एक फ़ील्ड की जानकारी देना ज़रूरी है. सभी फ़ील्ड को खाली नहीं छोड़ा जा सकता.
alert Alert शर्त के साथ ज़रूरी एक अलर्ट के बारे में रीयल टाइम डेटा. trip_update, वाहन या अलर्ट में से किसी एक फ़ील्ड की जानकारी देना ज़रूरी है. सभी फ़ील्ड को खाली नहीं छोड़ा जा सकता.

message TripUpdate

यात्रा के दौरान वाहन की ताज़ा स्थिति पर रीयल टाइम अपडेट. कृपया इकाइयों की यात्रा अपडेट को लेकर सामान्य चर्चा भी देखें.

ScheduleRelationship के मान के आधार पर, TripUpdate इन बातों की जानकारी देता है:

  • शेड्यूल के मुताबिक चलने वाली यात्रा.
  • किसी रूट पर बढ़ने वाली यात्रा जिसका कोई तय शेड्यूल न हो.
  • यात्रा जिसे शेड्यूल के हिसाब से जोड़ा या हटाया गया हो.

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

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

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
trip TripDescriptor ज़रूरी एक वह यात्रा जिस पर यह मैसेज लागू होता है. असल में हर एक यात्रा के लिए ज़्यादा से ज़्यादा एक TripUpdate इकाई हो सकती है. अगर कोई TripUpdate इकाई नहीं है, तो इसका मतलब है कि यात्रा के अनुमान को लेकर कोई जानकारी उपलब्ध नहीं है. इसका मतलब यह नहीं है कि यात्रा शेड्यूल के मुताबिक चल रही है
vehicle VehicleDescriptor ज़रूरी नहीं एक उस वाहन के बारे में अन्य जानकारी, जिससे यात्रा की जा रही है.
stop_time_update StopTimeUpdate शर्त के साथ ज़रूरी कई यात्रा के लिए StopTimes पर अपडेट (आगे की जानी वाली यात्राओं के लिए अनुमान और कुछ मामलों में पिछली यात्राओं के बारे में अपडेट). अपडेट को stop_sequence के हिसाब से क्रम में लगाना चाहिए. साथ ही, अपडेट को अगले बताए गए stop_time_update तक यात्रा के आगे के सभी स्टॉप के लिए लागू किया जाना चाहिए. trip.schedule_relationship को रद्द किए जाने तक यात्रा के लिए कम से कम एक stop_time_update दिया जाना चाहिए - अगर यात्रा रद्द कर दी जाती है, तो stop_time_updates दिए जाने की ज़रूरत नहीं है.
timestamp uint64 ज़रूरी नहीं एक यात्रा के दौरान वह पल जब वाहन की रीयल टाइम प्रगति मापी गई थी. POSIX समय में (यानी, 1 जनवरी 1970 से सेकंड की संख्या 00:00:00 UTC).
delay int32 ज़रूरी नहीं एक यात्रा के लिए मौजूदा शेड्यूल में किसी तरह का अंतर आना. देरी के बारे में तभी बताया जाना चाहिए जब जीटीएफ़एस में मौजूदा शेड्यूल के लिहाज़ से कोई अनुमान दिया गया हो.
देरी (सेकंड में) पॉज़िटिव (मतलब कि वाहन शेयूडल के हिसाब से पीछे चल रहा है) भी हो सकती है या निगेटिव (वाहन शेड्यूल के हिसाब से आगे चल रहा है) भी. जब देरी का मान शून्य हो, तो इसका मतलब है कि वाहन समय पर चल रहा है.
StopTimeUpdates में देरी की जानकारी, यात्रा-लेवल पर देरी की जानकारी से ली जाती है. यात्रा-लेवल पर देरी की जानकारी, यात्रा के दौरान StopTimeUpdate देरी मान के साथ अगले स्टॉप तक ही दिखाई जाती है.
फ़ीड देने वालों को TripUpdate टाइमस्टैंप देने के लिए प्रोत्साहित किया जाता है जो कि यह दिखाता है कि देरी के मान को पिछली बार कब अपडेट किया गया था. इससे यह पता चलता है कि डेटा कितना ताज़ा है.
चेतावनी: यह फ़ील्ड अभी भी एक्सपेरिमेंटल है और इसमें बदलाव हो सकते हैं. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है.

message StopTimeEvent

किसी यात्रा के लिए आने या जाने के समय को लेकर किया गया अनुमान. समय की जानकारी में देरी और/या अनुमानित समय, और किसी तरह की अनिश्चितता शामिल है.

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

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

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
delay int32 शर्त के साथ ज़रूरी एक देरी (सेकंड में) पॉज़िटिव (मतलब कि वाहन शेयूडल के हिसाब से पीछे चल रहा है) भी हो सकती है या निगेटिव (वाहन शेड्यूल के हिसाब से आगे चल रहा है) भी. देरी का मान अगर शून्य हो, तो इसका मतलब है कि वाहन शेड्यूल के हिसाब से समय पर है. StopTimeEvent के तहत देरी या समय की जानकारी दी जानी चाहिए - दोनों फ़ील्ड को खाली नहीं छोड़ा जा सकता.
time int64 शर्त के साथ ज़रूरी एक इवेंट का पूरा समय POSIX समय में (यानी, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). StopTimeEvent के तहत देरी या समय की जानकारी दी जानी चाहिए - दोनों फ़ील्ड को खाली नहीं छोड़ा जा सकता.
uncertainty int32 ज़रूरी नहीं एक अगर अनिश्चितता हटा दी जाती है, तो उसे अज्ञात माना जाता है. किसी अनुमान को निश्चित बताने के लिए, उसकी अनिश्चितता का मान शून्य पर सेट किया जाना चाहिए.

message 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 स्ट्रिंग शर्त के साथ ज़रूरी एक संबंधित GTFS फ़ीड में इसे stop.txt के जैसा होना चाहिए. StopTimeUpdate के तहत stop_sequence या stop_id दिया जाना चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते.
arrival StopTimeEvent शर्त के साथ ज़रूरी एक अगर schedule_relationship खाली होता है या शेड्यूल किया गया होता है, तो StopTimeUpdate के तहत आने या जाने की जानकारी दी जानी चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. schedule_relationship को छोड़ने पर आने और जाने, दोनों फ़ील्ड को खाली छोड़ा जा सकता है. अगर schedule_relationship, NO_DATA है, तो आने और जाने वाले फ़ील्ड, दोनों खाली होने चाहिए.
departure StopTimeEvent शर्त के साथ ज़रूरी एक अगर schedule_relationship खाली होता है या शेड्यूल किया गया होता है, तो StopTimeUpdate के तहत आने या जाने की जानकारी दी जानी चाहिए - दोनों फ़ील्ड खाली नहीं छोड़े जा सकते. schedule_relationship को छोड़ने पर आने और जाने, दोनों फ़ील्ड को खाली छोड़ा जा सकता है. अगर schedule_relationship, NO_DATA है, तो आने और जाने वाले फ़ील्ड, दोनों खाली होने चाहिए.
schedule_relationship ScheduleRelationship ज़रूरी नहीं एक डिफ़ॉल्ट रूप से ScheduleRelationship को शेड्यूल किया गया.

enum ScheduleRelationship

रूका हुआ शेड्यूल और StopTime के बीच संबंध.

मान

मान टिप्पणी
SCHEDULED वाहन, शेड्यूल में स्टॉप के लिए दी गई जानकारी के मुताबिक आगे बढ़ रहा है. हालांकि, यह ज़रूरी नहीं कि वाहन शेड्यूल में दिए गए समय के हिसाब से आगे बढ़े. यह डिफ़ॉल्ट व्यवहार है. आने और जाने दोनों के लिए, कम से कम एक जानकारी दी जानी चाहिए.
SKIPPED स्टॉप को छोड़ गया, यानी कि वाहन इस स्टॉप पर नहीं रुकेगा. आने और जाने की जानकारी ज़रूरी नहीं है.
NO_DATA इस स्टॉप के लिए कोई डेटा नहीं दिया गया है. इसका मतलब है कि कोई रीयल टाइम जानकारी उपलब्ध नहीं है. NO_DATA को आगे के दिए गए स्टॉप पर सेट करके यह जाना जा सकता है कि किस स्टॉप के लिए रीयल टाइम जानकारी उपलब्ध नहीं है. यह सुझाया गया तरीका है. NO_DATA सेट होने पर न तो आने और न ही जाने की जानकारी दी जाती है.

message VehiclePosition

किसी दिए गए वाहन की स्थिति के बारे में रीयल टाइम जानकारी.

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
trip TripDescriptor ज़रूरी नहीं एक वह यात्रा, जिसके लिए इस वाहन का इस्तेमाल किया जा रहा है. अगर किसी यात्रा के लिए वाहन की पहचान नहीं हो पाती है, तो यह फ़ील्ड खाली या अधूरा रह सकता है.
vehicle VehicleDescriptor ज़रूरी नहीं एक उस वाहन के बारे में अन्य जानकारी, जिससे यात्रा की जा रही है. हर एक एंट्री में वाहन के लिए खास आईडी दी जानी चाहिए.
position Position ज़रूरी नहीं एक फ़िलहाल वाहन कहां है, उसकी जानकारी.
current_stop_sequence uint32 ज़रूरी नहीं एक यात्रा के वर्तमान स्टॉप के लिए स्टॉप सिक्वेंस इंडेक्स. current_stop_sequence का मतलब (यानी कि वह स्टॉप जिसके बारे में बताया गया है) current_status से निकाला जाता है. अगर current_status मौजूद नहीं है, तो IN_TRANSIT_TO को मान लिया जाता है.
stop_id स्ट्रिंग ज़रूरी नहीं एक वर्तमान स्टॉप की पहचान करता है. संबंधित GTFS फ़ीड में मान stop.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 uint64 शर्त के साथ ज़रूरी एक शुरू होने का समय, POSIX समय में (यानि, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). अगर मौजूद नहीं है, तो अंतराल माइनस इन्फ़िनिटी पर शुरू होता है. अगर TimeRange दिया गया है, तो शुरू होने या खत्म होने में से किसी एक फ़ील्ड का दिया जाना ज़रूरी है.
end uint64 शर्त के साथ ज़रूरी एक खत्म होने का समय, POSIX समय में (यानि, 1 जनवरी, 1970 को 00:00:00 यूटीसी से सेकंड की संख्या). अगर मौजूद नहीं है, तो अंतराल प्लस इन्फिनिटी पर खत्म होता है. अगर TimeRange दिया गया है, तो शुरू होने या खत्म होने में से किसी एक फ़ील्ड का दिया जाना ज़रूरी है.

message Position

किसी वाहन की भौगोलिक स्थिति.

फ़ील्ड

फ़ील्ड का नाम प्रकार ज़रूरी एलिमेंट की संख्या ब्यौरा
latitude फ़्लोट ज़रूरी एक WGS-84 कॉर्डिनेट सिस्टम में, डिग्री नॉर्थ.
longitude फ़्लोट ज़रूरी एक WGS-84 कॉर्डिनेट सिस्टम में, डिग्री ईस्ट.
bearing फ़्लोट ज़रूरी नहीं एक बियरिंग, डिग्री में, उत्तर से घड़ी की दिशा में, मतलब, 0 उत्तर है और 90 पूर्व है. यह कम्पास बियरिंग हो सकता है, या अगले स्टॉप की दिशा या बीच का कोई लोकेशन. इसका नतीजा पिछली भौगोलिक स्थिति के क्रम के आधार पर नहीं निकाला जाना चाहिए, जिसकी गणना क्लाइंट पिछले डेटा से सकते हैं.
odometer डबल ज़रूरी नहीं एक मीटर में, ओडोमीटर का मान.
speed फ़्लोट ज़रूरी नहीं एक किसी दिए गए समय पर कुछ देर के लिए वाहन से मीटर प्रति सेकंड में मापी गई रफ़्तार.

message TripDescriptor

ऐसा डिस्क्रिप्टर जो जीटीएफ़एस यात्रा के सिंगल इंस्टेंस की पहचान करता है.

किसी सिंगल ट्रिप इंस्टेंस की पहचान के लिए, trip_id कई मामलों में खुद सही तरीके से काम करता है. हालांकि, नीचे दिए गए मामलों में सिंगल ट्रिप इंस्टेंस को सुलझाने के लिए ज़्यादा जानकारी की ज़रूरत होती है:

  • अगर यात्रा की जानकारी frequencies.txt में दी गई है, तो start_date और start_time को trip_id में जोड़ना होगा.
  • अगर यात्रा 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 स्ट्रिंग शर्त के साथ ज़रूरी एक जीटीएफ़एस फ़ीड से लिया गया वह 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 स्ट्रिंग शर्त के साथ ज़रूरी एक जीटीएफ़एस फ़ीड से लिया गया वह route_id, जिसके बारे में इस सिलेक्टर ने बताया है. अगर trip_id को छोड़ा जाता है, तो यात्रा के इंस्टेंस की पहचान के लिए route_id, direction_id, start_time, और schedule_relationship=SCHEDULED ज़रूर दिए जाने चाहिए.
direction_id uint32 शर्त के साथ ज़रूरी एक जीटीएफ़एस फ़ीड की trips.txt फ़ाइल का direction_id, यात्रा की दिशा के बारे में बताता है. अगर trip_id को छोड़ा जाता है, तो direction_id का दिया जाना ज़रूरी है.
चेतावनी: यह फ़ील्ड अब भी एक्सपेरिमेंटल है और इसमें बदलाव हो सकते हैं. इसे आने वाले समय में औपचारिक तौर पर अपनाया जा सकता है.
start_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 स्ट्रिंग शर्त के साथ ज़रूरी एक इस यात्रा इंस्टेंस के शुरू होने की तारीख YYYYMMDD फ़ॉर्मैट में है. यात्रा किस तरह की है, इस पर निर्भर करता है कि start_date की ज़रूरत है या नही:
शेड्यूल की गई यात्राएं: start_date ज़रूर दी जानी चाहिए. बहुत देर से शुरू होने वाली यात्राओं में अंतर करने के लिए ऐसा किया जाता है, ताकि अगले दिन शेड्यूल की गई यात्रा से वे यात्राएं टकरा न जाएं. उदाहरण के लिए, मान लें कि हर दिन एक ट्रेन 8:00 और 20:00 बजे चलती है. अगर ट्रेन 12 घंटे लेट है, तो एक ही समय पर दो अलग-अलग यात्राएं शेड्यूल हो जाएंगी.
ध्यान दें: यह फ़ील्ड उन शेड्यूल की गई यात्राओं के लिए वैकल्पिक है जिनमें इस तरह के टकराव संभव नहीं हैं. उदाहरण के लिए, ऐसा तब हो सकता है जब कोई सेवा हर घंटे के शेड्यूल पर चलती है और एक घंटा देरी से चलने वाले वाहन को शेड्यूल से जुड़ा नहीं माना जाता.
फ़्रीक्वेंसी पर-आधारित यात्राएं: start_date ज़रूर दी जानी चाहिए. ध्यान रखें कि फ़्रीक्वेंसी पर आधारित यात्राएं, जीटीएफ़एस frequencies.txt फ़ाइल में बताई गई हैं, जबकि शेड्यूल की गई यात्राएं नहीं.
trip_id छोड़ दिया गया है: start_date ज़रूर दी जानी चाहिए.
schedule_relationship ScheduleRelationship ज़रूरी नहीं एक तय किया हुआ शेड्यूल और इस यात्रा के बीच संबंध. अगर EntitySelector में TripDescriptor, Alert दिया गया है, तो मेल खाने वाली यात्रा के इंस्टेंस की पहचान होने पर ग्राहकों को schedule_relationship फ़ील्ड को नज़रअंदाज़ करना चाहिए.

enum ScheduleRelationship

तय किया हुआ शेड्यूल और इस यात्रा के बीच संबंध. अगर यह यात्रा, जीटीएफ़एस में नहीं दिखाए गए अस्थायी शेड्यूल के मुताबिक की जाती है, तो उसे 'शेड्यूल की गई' के रूप में चिह्नित न करके 'जोड़ी गई' के रूप में चिह्नित किया जाना चाहिए.

मान

मान टिप्पणी
SCHEDULED वह यात्रा, जो अपने जीटीएफ़एस शेड्यूल के अनुसार चल रही हो या उससे जोड़े जाने वाली शेड्यूल की गई यात्रा के करीब हो.
ADDED चल रहे शेड्यूल के साथ एक अन्य यात्रा को जोड़ना. जैसे कि एक खराब वाहन को बदलने के लिए या अचानक बढ़े यात्री भार की वजह से अतिरिक्त यात्रा जोड़ना.
UNSCHEDULED एक चल रही यात्रा, जिसके साथ कोई शेड्यूल संबद्ध नहीं है - इस मान का उपयोग GTFS frequencies.txt में परिभाषित exact_times = 0 वाली यात्राओं की पहचान करने के लिए किया जाता है. इसका उपयोग GTFS frequencies.txt में परिभाषित न की गई यात्राओं या GTFS frequencies.txt में exact_times = 1 वाली यात्राओं को वर्णित करने के लिए नहीं किया जाना चाहिए.
CANCELED यात्रा जो शेड्यूल में मौजूद थी, लेकिन हटा दी गई थी.

message VehicleDescriptor

यात्रा के लिए इस्तेमाल किए जा रहे वाहन की पहचान से जुड़ी जानकारी.

फ़ील्ड

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

message EntitySelector

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

फ़ील्ड

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

message TranslatedString

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

फ़ील्ड

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

message Translation

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

फ़ील्ड

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