यात्रा के अपडेट

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

रिमाइंडर:जीटीएफ़एसमें, कोई भी यात्रा दो या उससे ज़्यादा स्टॉप का एक क्रम है जो किसी खास समय पर होते हैं.

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

स्टॉप समय के अपडेट

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

उदाहरण के लिए, अगर GTFS-rt फ़ीड में नीचे दिया गया डेटा दिखता है:

  • स्टॉप 4 - सुबह 10:18 बजे का पूर्वानुमान है (सुबह 10:20 बजे पर शेड्यूल किया गया है - 2 मिनट पहले)
  • स्टॉप 5 - सुबह 10:30 बजे का पूर्वानुमान है (सुबह 10:30 बजे पर शेड्यूल किया गया है - समय पर)

...स्टॉप 4 के पूर्वानुमान को सुबह 10:21 बजे के पहले फ़ीड से हटाया नहीं जा सकता, भले ही बस ने स्टॉप को सुबह 10:18 बजे ही पार कर लिया हो. अगर स्टॉप 4 के लिए StopTimeUpdate को सुबह 10:18 बजे या सुबह 10:19 बजे पर फ़ीड से निकाल दिया गया था और शेड्यूल किया गया पहुंचने का समय सुबह 10:20 बजे है, तो उपभोक्ता को यह मानना चाहिए कि उस समय स्टॉप 4 के लिए कोई रीयल टाइम जानकारी मौजूद नहीं है. साथ ही, जीटीएफ़एस से शेड्यूल डेटा का इस्तेमाल किया जाना चाहिए.

हर StopTimeUpdate को स्टॉप से लिंक किया गया है. आम तौर पर, जीटीएफ़एस stop_sequence या जीटीएफ़एस stop_id का इस्तेमाल करके ऐसा किया जा सकता है. हालांकि, अगर आप बिना जीटीएफ़एस trip_id वाली यात्रा के लिए अपडेट दे रहे हैं, तो आपको stop_id बताना होगा क्योंकि stop_sequence का कोई मान नहीं है. stop_id को अब भी जीटीएफ़एस में stop_id का संदर्भ देना होगा. अगर किसी यात्रा में एक ही stop_id को एक से ज़्यादा बार देखा गया है, तो उस यात्रा के दौरान उस stop_id के लिए सभी StopTimeUpdate मैसेज में stop_sequence दिया जाना चाहिए.

StopTimeUpdate में StopTimeEvent इस्तेमाल करके यह अपडेट, arrival और/या departure के किसी स्टॉप पर आने का सही समय दे सकता है. इसमें या तो एक पूरा time या delay समय (यानी सेकंड के हिसाब से शेड्यूल किए गए समय का ऑफ़सेट) होना चाहिए. delay फ़ील्ड का इस्तेमाल सिर्फ़ तब किया जा सकता है जब यात्रा अपडेट, फ़्रीक्वेंसी पर आधारित यात्रा के बजाय शेड्यूल की गई किसी जीटीएफ़एस यात्रा का संदर्भ देता है. इस स्थिति में समय, शेड्यूल किए गए समय + देरी के बराबर होना चाहिए. आप StopTimeEvent के साथ अनुमान वाले uncertainty के बारे में बता सकते हैं. इसका ब्यौरा इसी पेज पर थोड़ा नीचे तय नहीं हैं सेक्शन में दिया गया है.

हर StopTimeUpdate के लिए, डिफ़ॉल्ट शेड्यूल का संबंध scheduled से है. (ध्यान दें कि यह यात्रा के शेड्यूल संबंध से अलग है.) अगर स्टॉप पर रोका नहीं जाएगा, तो आप इसे skipped में बदल सकते हैं या अगर आपके पास यात्रा के कुछ हिस्से का सिर्फ़ रीयल टाइम डेटा है, तो आप इसे no data में बदल सकते हैं.

अपडेट, stop_sequence के हिसाब से क्रम में लगाए जाने चाहिए (या stop_ids के हिसाब से उसी क्रम में लगाए जाने चाहिए जिस क्रम में वे यात्रा के दौरान होते हैं).

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

पहला उदाहरण

अगर किसी यात्रा में 20 स्टॉप हैं, तो मौजूदा स्टॉप के stop_sequence के लिए StopTimeUpdate के आने में देरी और जाने में देरी (StopTimeEvent) का 0 होने का मतलब है कि यात्रा बिल्कुल सही समय पर चल रही है.

दूसरा उदाहरण

एक ही यात्रा इंस्टेंस के लिए, तीन StopTimeUpdate मैसेज दिए गए हैं:

  • stop_sequence 3 के लिए 300 सेकंड की देरी
  • stop_sequence 8 के लिए 60 सेकंड की देरी
  • stop_sequence 10 के लिए की देरी, जिसकी अवधि तय नहीं है

इसे ऐसे समझा जा सकता है:

  • stop_sequence मैसेज 1,2 में ऐसी देरी है जिसकी अवधि तय नहीं है.
  • stop_sequence मैसेज 3,4,5,6,7 में 300 सेकंड की देरी है.
  • stop_sequence मैसेज 8,9 में 60 सेकंड की देरी है.
  • stop_sequence मैसेज 10,..,20 में ऐसी देरी है जिसकी अवधि तय नहीं है.

यात्रा का ब्यौरा

यात्रा के ब्यौरे में दी गई जानकारी उस यात्रा के शेड्यूल संबंध पर निर्भर करती है जिसे आप अपडेट कर रहे हैं. आपके पास इसे सेट करने के कई विकल्प हैं:

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

ज़्यादातर मामलों में, आपको इस अपडेट से संबंधित जीटीएफ़एस में शेड्यूल की गई यात्रा का trip_id देना होगा.

वे सिस्टम जिनमें trip_id के मान बार-बार आते हैं

दोहराए गए trip_id का इस्तेमाल करने वाले सिस्टम के लिए: उदहारण के लिए frequencies.txt का इस्तेमाल करके तैयार की गई ऐसी यात्राएं जो फ़्रीक्वेंसी यात्राएं होती हैं, जिनके लिए trip_id किसी एक यात्रा का खास पहचानकर्ता नहीं होता है. ऐसा इसलिए होता है क्योंकि इसमें कोई खास समय कॉम्पोनेंट नहीं होता. किसी TripDescriptor में खास तौर पर इस तरह की यात्राओं को पहचानने के लिए तीन पहचानकर्ता दिए जाने चाहिए:

  • trip_id
  • start_time
  • start_date

सबसे पहले start_time प्रकाशित किया जाना चाहिए और उसी यात्रा का संदर्भ देते समय इसके बाद आने वाले सभी फ़ीड अपडेट के लिए उसी start_time का इस्तेमाल किया जाना चाहिए. StopTimeUpdateका इस्तेमाल अडजस्टमेंट दिखाने के लिए किया जाना चाहिए; start_time का पहले स्टेशन से जाने वाले समय के हूबहू होना ज़रूरी नहीं है, हालांकि वह उस समय के आस-पास का होना चाहिए.

उदाहरण के लिए, मान लीजिए कि हम 25 मई, 2015 को 10:00 बजे तय करते हैं कि trip_id=T के साथ यात्रा start_time=10:10:00 पर शुरू होगी और यह जानकारी, रीयल टाइम फ़ीड से 10:01 पर दी जाएगी. 10:05 पर हमें अचानक पता चलता है कि यात्रा 10:10 की जगह 10:13 पर शुरू होगी. हमारी नई रीयल टाइम फ़ीड में, हम अब भी इस यात्रा की पहचान (T, 2015-05-25, 10:10:00) के रूप में कर सकते हैं, लेकिन 10:13:00 पर पहले स्टॉप से जाने के समय के साथ StopTimeUpdate अपडेट दें.

वैकल्पिक यात्रा मिलान

ऐसी यात्राएं जो फ़्रीक्वेंसी आधारित नहीं हैं, को भी एक TripDescriptor से खास तौर पर पहचाना जा सकता है जिसमें ये सभी शामिल हैं:

  • route_id
  • direction_id
  • start_time
  • start_date

यहां start_time शेड्यूल किया गया शुरुआत का वह समय है जो कि स्टैटिक शेड्यूल में निर्धारित किया गया है. ऐसा तब तक होगा, जब तक कि आईडी के दिए गए संयोजन एक खास यात्रा बनाते हैं.

अनिश्चितता

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

उदाहरण के लिए, एक लंबी दूरी की यात्रा करने वाली बस जिसके अगले स्टॉप पर पहुंचने की अनुमानित देरी 15 मिनट है. इसमें चार मिनट की गड़बड़ी होने की वजह से (+2 मिनट या -2 मिनट) उसका uncertainty मान 240 होगा.