行程更新

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

貼心小提醒：在 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。

您可以透過更新的方式，使用 StopTimeEvent 在 StopTimeUpdate 中提供某停靠站 arrival 和/或 departure 的確切時間。更新資訊應包含絕對的 time 或 delay (也就是與排定時間的差距，以秒為單位)。只有在行程更新涉及已排定的 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_time。StopTimeUpdate 必須用於表示調整。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。