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

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

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

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

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

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

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

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

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

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

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

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

अपडेट को stop_sequence से क्रम में लगाना चाहिए (या यात्रा में उनके आने के क्रम में stop_id में).

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

उदाहरण 1

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

उदाहरण 2

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

  • stop_sequence 3 के लिए 300 सेकंड की देरी
  • stop_sequence 8 के लिए 60 सेकंड की देरी
  • stop_sequence 10 के लिए अज्ञात अवधि की देरी

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

  • stop_sequences 1,2 में देरी अज्ञात है.
  • stop_sequences 3,4,5,6,7 में 300 सेकंड की देरी है.
  • stop_sequences 8,9 में 60 सेकंड की देरी है.
  • stop_sequences 10,..,20 में देरी अज्ञात है.

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

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

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

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

सिस्टम, जिनमें trip_id दोहराए गए हैं

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

  • trip_id
  • start_time
  • start_date

सबसे पहले start_time प्रकाशित किया जाना चाहिए, और उसी यात्रा का संदर्भ देते समय इसके बाद आने वाले सभी फ़ीड अपडेट के लिए उसी start_time का इस्तेमाल किया जाना चाहिए. StopTimeUpdates का इस्तेमाल समायोजन दिखाने के लिए किया जाना चाहिए; 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 शेड्यूल किया गया शुरुआत का समय है जैसा कि स्टैटिक शेड्यूल में निर्धारित किया गया है, जब तक कि ids के दिए गए संयोजन एक खास यात्रा बनाते हैं.

अनिश्चितता

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

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