行程更新

行程更新代表時刻表有變動。凡是您已排定且能即時反映現況的行程,應該都要有行程更新。這些更新可提供沿途停靠站的到達和出發預測時間。行程更新也能反映更複雜的情境,例如有行程取消或加進時間表,甚至是改變路線。

貼心小提醒:GTFS 中,行程是指在特定時間內由兩個以上的停靠站所組成的序列。

每個排定的行程最多只能有 1 次更新。如果排定的行程沒有任何更新,就表示該行程沒有任何即時資料。資料使用者應假定行程絕對準時。

停靠時間更新

行程更新包含一或多次車輛停靠時間更新,稱為 StopTimeUpdate 訊息。不論是過去還是未來的停靠時間,都可以提供這類更新。您可以 (但不一定要) 捨棄過去的停靠時間。如果 StopTimeUpdate 是指特定行程中到達時間排定在未來的停靠站 (意即車輛提早通過停靠站),製作者就不應予以捨棄,否則就表示該停靠站沒有任何更新。

舉例來說,如果 GTFS-rt 資訊提供中顯示以下資料:

  • 第 4 站 - 預測時間為上午 10:18 (原定時間為上午 10:20 - 提早 2 分鐘)
  • 第 5 站 - 預測時間為上午 10:30 (原定時間為上午 10:30 - 準點)

即使公車實際在上午 10:18 通過第 4 站,該停靠站的預測結果在上午 10:21 之前還是無法從動態饋給中捨棄。如果在上午 10:18 或 10:19 就從動態饋給中捨棄第 4 站的 StopTimeUpdate,而排定的抵達時間是上午 10:20,使用者就會假設第 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 於所有 StopTimeUpdate 訊息中提供 stop_sequence

您可以透過更新的方式,使用 StopTimeEventStopTimeUpdate 中提供某停靠站 arrival 和/或 departure 的確切時間。更新資訊應包含絕對的 timedelay (也就是與排定時間的差距,以秒為單位)。只有在行程更新涉及已排定的 GTFS 行程時,才能使用 delay 欄位,如果是以頻率為準的行程則無法。在這種情況下,時間應等於排定時間加上延遲時間。此外,您還可以指定預測結果的 uncertainty 以及 StopTimeEvent,詳情請參閱本頁下方的「不確定度」部分。

每個 StopTimeUpdate 的預設時間表關係皆為 scheduled (請注意,這與行程的時間表關係不同)。如果停靠站不會有車輛停靠,您可以將該值變更為 skipped;如果只有部分行程的即時資料,則可變更為 no data

更新資訊應按照 stop_sequence 排序 (或是依照 stop_ids 在行程中發生的順序)。

如果行程缺少一或多個停靠站,更新資訊就會套用至所有後續的停靠站。也就是說,如果更新某個停靠站的停靠時間,在缺少任何其他資訊的情況下,所有後續停靠站的停靠時間也會跟著改變。

範例 1

如果行程包含 20 個停靠站,針對目前停靠站的 stop_sequence,如果 StopTimeUpdate 中的抵達和出發延遲時間為 0 (StopTimeEvent),就表示行程準點。

範例 2:

在同一趟行程中,系統提供三則 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 這趟行程依照 GTFS 時間表或是極為相似的時間表運作。
Added 這趟行程沒有排定,為額外追加,例如為了解決額外載客需求或更換故障車輛。
Unscheduled 這趟行程正在進行中,且與時間表毫無關聯。舉例來說,沒有時間表的公車提供接駁服務。
Canceled 這趟行程曾排定,但現已移除。

在大多數情況下,您應提供 GTFS 中與這項更新相關的排定行程的 trip_id

包含重複 trip_id 值的系統

如果是使用重複 trip_id 值的系統 (例如使用 frequencies.txt 模擬的行程,也就是以頻率為準的行程),trip_id 缺少特定時間元件,因此本身並非單一旅程的專屬 ID。為了在 TripDescriptor 內正確識別這類行程,您必須提供三組 ID:

  • trip_id
  • start_time
  • start_date

start_time 必須先發布,如果與同一個旅程相關,則所有後續的動態饋給更新則應使用相同的 start_timeStopTimeUpdate 必須用於表示調整;start_time 不一定要與第一個車站的出發時間完全相同,但應該要十分貼近。

舉例來說,假設我們在 2015 年 5 月 25 日 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),但會提供 StopTimeUpdate,指出第一個停靠站的出發為 10:13:00。

其他行程比對方式

非以頻率為準的行程也可以使用 TripDescriptor 來正確識別,包含以下組合:

  • route_id
  • direction_id
  • start_time
  • start_date

其中 start_time 是指靜態時間表中定義的預定開始時間,前提是提供的 ID 組合可解析為不重複的行程。

不確定度

不確定度會同時套用至 StopTimeUpdate 的時間和誤點值。不確定度會大致指出在真實誤點狀況下預期會發生的偏誤,以整數秒為單位 (但是請注意,確切的統計意義尚未定義)。不確定度可能是 0,例如由電腦控制時間來驅動的火車。

舉例來說,如果一輛長程公車預估誤點 15 分鐘,但會在 4 分鐘 (亦即 +2/-2 分鐘) 的偏誤範圍內抵達下一個停靠站,uncertainty 的值就會是 240