GTFS Realtime 參考資料

GTFS Realtime 動態饋給可讓大眾運輸公司為消費者提供即時資訊，包括服務中斷情形 (例如車站封閉、路線停止營運、重大誤點等)、車輛所在地點，以及預計抵達時間。

這個網站會探討並記錄 2.0 版的動態饋給規格。

字詞定義

必要

在 GTFS Realtime 2.0 以上的版本中，「必要」欄位會指出製作者必須提供哪些欄位，才能讓大眾運輸資料有實用價值，並便於採用這些資料的應用程式辨識。

以下是「必要」欄位中使用的值：

  • 必要：GTFS Realtime 動態饋給製作者必須提供這個欄位。
  • 必要 (有條件)：在特定條件下 (請參閱「說明」欄位)，此為必要欄位。如果不符合這些條件，就是選用欄位。
  • 選用：此為選用欄位，製作者不一定需要導入。然而，如果基礎自動車輛定位系統有提供資料 (例如 VehiclePosition timestamp)，建議製作者盡可能提供這些選用欄位。

請注意，GTFS Realtime 1.0 版並未定義語意規定，因此 gtfs_realtime_version 為 1 的動態饋給可能不符合這些規定 (詳情請參閱語意規定提案)。

基數

「基數」代表可為特定欄位提供的元素數量，使用的值如下：

請務必對照「必要」和「說明」欄位，確認特定欄位為必要、必要 (有條件) 或選用。請參考 gtfs-realtime.proto 來瞭解通訊協定緩衝區基數。

通訊協定緩衝區資料類型

以下通訊協定緩衝區資料類型是用來描述動態饋給元素：

  • 訊息：複雜類型
  • 列舉：固定值清單

實驗性欄位

標示為實驗性的欄位可能會有變動，因此尚未正式納入規格中。我們日後可能會正式採用實驗性欄位。

元素索引

元素

FeedMessage (訊息)

動態饋給訊息的內容。系統會取得串流中的每則訊息，做為對相關 HTTP GET 要求的回應。Realtime 動態饋給一定是依照現有 GTFS 動態饋給定義。所有實體 ID 皆已根據 GTFS 動態饋給完成解析。

欄位

欄位名稱 類型 必要 基數 說明
header FeedHeader 必要 一個 關於這項動態饋給和動態饋給訊息的中繼資料。
entity FeedEntity 必要 (有條件) 多個 動態饋給的內容。如果有大眾運輸系統的即時資訊，就必須提供這個欄位。如果這個欄位空白，使用者會認定系統沒有即時資訊。

FeedHeader (訊息)

關於動態饋給的中繼資料 (包含在動態饋給訊息中)。

欄位

欄位名稱 類型 必要 基數 說明
gtfs_realtime_version string 必要 一個 動態饋給規格的版本。目前為 2.0 版。
incrementality Incrementality 必要 一個
timestamp uint64 必要 一個 時間戳記可識別這個動態饋給內容的建立時間 (伺服器時間)，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。為避免製作和使用即時資訊的不同系統之間出現時間偏移，強烈建議您從時間伺服器取得 timestamp。如果想使用 Stratum 3，甚至是更低階的 Strata 伺服器，也完全不成問題，因為數秒的時間誤差尚在接受範圍內。

Incrementality (列舉)

判斷目前擷取到的是否為遞增資料。

  • FULL_DATASET：這項動態饋給更新會覆寫動態饋給的所有先前即時資訊，因此應該要能提供所有已知即時資訊的完整數據匯報。
  • DIFFERENTIAL：目前不支援這個模式，且未指定使用這個模式的動態饋給行為。GTFS Realtime 郵寄清單上有些關於完全指定 DIFFERENTIAL 模式行為的討論，拍板定案後我們就會更新相關說明文件。

值

值
FULL_DATASET
DIFFERENTIAL

FeedEntity (訊息)

大眾運輸動態饋給中實體的定義 (或更新)。如果實體未遭刪除，則應在 trip_update、vehicle 和 alert 任一欄位中填入資料。

欄位

欄位名稱 類型 必要 基數 說明
id string 必要 一個 這個實體的動態饋給專屬 ID。這類 ID 只能用於提供遞增支援。動態饋給參照的實際實體必須由明確的選取器指定 (詳情請參閱下方的 EntitySelector)。
is_deleted bool 選用 一個 是否要刪除這個實體。只有 Incrementality 為 DIFFERENTIAL 的動態饋給才需要這個欄位；如果動態饋給的 Incrementality 為 FULL_DATASET，則不需要。
trip_update TripUpdate 必要 (有條件) 一個 去程時間誤點的即時資料。至少要提供 trip_update、vehicle 或 alert 其中一項，且這三個欄位皆不可空白。
vehicle VehiclePosition 必要 (有條件) 一個 車輛即時位置的相關資料。至少要提供 trip_update、vehicle 或 alert 其中一項，且這三個欄位皆不可空白。
alert Alert 必要 (有條件) 一個 即時快訊的相關資料。至少要提供 trip_update、vehicle 或 alert 其中一項，且這三個欄位皆不可空白。

TripUpdate (訊息)

行程中車輛進度的即時更新資訊。另請參閱行程更新實體的一般討論。

視 ScheduleRelationship 的值而定，TripUpdate 可以指定：

  • 依照時間表進行的行程。
  • 沿著路線進行，但沒有固定時間表的行程。
  • 已依照時間表新增或移除的行程。

您可以針對未來的事件、預計抵達/出發事件，或是過去已發生的事件進行更新。在大多數情況下，過往事件的相關資訊皆為已確定值，因此建議您將不確定度設為 0。當然凡事皆有例外，如遇此情況，也是可以將過去事件的不確定度設為 0 以外的值。如果更新資訊的不確定度不是 0，則可能為下列情況之一：更新資訊是針對未完成行程的概略預測結果、測量結果不精確、更新資訊是針對過往事件 (發生後未經驗證) 的預測結果。

請注意，更新資訊可描述已完成的行程。在這種情況下，只要針對行程的最後一個停靠站提供更新資訊即可。如果抵達最後一個停靠站的時間為過去時間，用戶端就會認為整趟行程的時間都是過去時間 (即使無關緊要，您還是可以一併提供前幾個停靠站的更新資訊)。提早完成但從時間表來看目前仍在進行中的行程，最適合使用這個選項。要是移除這趟行程的更新資訊，用戶端可能會認為行程仍在進行中。請注意，動態饋給供應商可以 (但不一定要) 清除過去的更新資訊，此時這個方法就非常實用。

欄位

欄位名稱 類型 必要 基數 說明
trip TripDescriptor 必要 一個 要套用這則訊息的行程。每趟實際行程最多只能有一個 TripUpdate 實體。如果沒有任何這類實體，就表示無法提供預測資訊。這「不」代表行程目前依照時間表進行。
vehicle VehicleDescriptor 選用 一個 提供這趟行程的車輛的其他相關資訊。
stop_time_update StopTimeUpdate 必要 (有條件) 多個 行程的 StopTimes 更新 (未來的停靠時間預測，有時是過去的停靠時間)。這些更新資訊必須依照 stop_sequence 排序，且適用於行程的所有後續停靠站，直到下一個指定的 stop_time_update 為止。除非 trip.schedule_relationship 是 CANCELED，否則必須為行程提供至少一個 stop_time_update；如果行程取消，則不用提供 stop_time_updates。
timestamp uint64 選用 一個 測量車輛即時進度的時間點，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。
delay int32 選用 一個 行程目前偏離時間表的幅度。只有在根據 GTFS 中部分現有時間表進行預測時，才需指定 delay。
delay (以秒為單位) 可以是正數 (表示車輛誤點) 或負數 (表示車輛超前進度)。如果 delay 為 0，則代表車輛準點。
StopTimeUpdates 中的誤點資訊優先於行程層級的誤點資訊，因此行程層級誤點資訊的效力只會維持到行程中指定 StopTimeUpdate delay 值的下一個停靠站為止。
我們強烈建議動態饋給供應商提供 TripUpdate.timestamp 值來表示上次更新 delay 的時間，以便評估資料的即時性。
注意：這個欄位仍在實驗階段，因此或許會有變更，但日後可能就會正式採用。

StopTimeEvent (訊息)

單一預測事件 (抵達或離開) 的時間資訊。時間包括誤點和/或預估時間，以及不確定度。

  • 只有在根據 GTFS 中部分現有時間表進行預測時，才需使用 delay。
  • 無論是否有預測時間表，都應指定 time。如果同時指定 time 和 delay，則 time 的優先度較高 (如果是已排定的行程，time 通常應等於 GTFS 中的排定時間加上誤點時間)。

不論是時間還是誤點，不確定度都適用。不確定度用來指出實際發生誤點時，預估的偏誤情形 (但請注意，我們尚未定義確切的統計意義)。不確定度可能是 0，例如由電腦控時驅動的火車。

欄位

欄位名稱 類型 必要 基數 說明
delay int32 必要 (有條件) 一個 delay 欄位 (以秒為單位) 可以是正數 (表示車輛誤點) 或負數 (表示車輛超前進度)。如果 delay 為 0，表示車輛準點。必須在 StopTimeEvent 內提供 delay 或 time，兩個欄位皆不可空白。
time int64 必要 (有條件) 一個 將事件視為絕對時間，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。必須在 StopTimeEvent 內提供 delay 或 time，兩個欄位皆不可空白。
uncertainty int32 選用 一個 如果省略不確定度，系統會將這項資訊視為不明。如要指定完全確定的預測結果，請將不確定度設為 0。

StopTimeUpdate (訊息)

行程中特定停靠站抵達和/或出發事件的即時更新資訊。另請參閱 TripDescriptor 和行程更新實體說明文件中，有關停靠時間更新的一般討論內容。

不論是過去還是未來的事件，您都能提供更新資訊。製作者可以 (但不一定要) 捨棄過去的事件。更新資訊會透過 stop_sequence 或 stop_id 連結至特定的停靠站，因此您必須設定其中一個欄位。如果在一趟行程中多次造訪同一個 stop_id，則必須針對該行程中該 stop_id 的所有 StopTimeUpdates 提供 stop_sequence。

欄位

欄位名稱 類型 必要 基數 說明
stop_sequence uint32 必要 (有條件) 一個 必須與對應 GTFS 動態饋給中 stop_times.txt 內的值相同。必須在 StopTimeUpdate 內提供 stop_sequence 或 stop_id (無論提供哪個欄位皆不可空白)。如果多趟行程中多次造訪同一個 stop_id (例如環狀路線)，則必須指定 stop_sequence，釐清預測結果適用於哪個停靠站。
stop_id string 必要 (有條件) 一個 必須與對應 GTFS 動態饋給中 stops.txt 內的值相同。必須在 StopTimeUpdate 內提供 stop_sequence 或 stop_id，兩個欄位皆不可空白。
arrival StopTimeEvent 必要 (有條件) 一個 如果 schedule_relationship 為空白或 SCHEDULED，就必須在 StopTimeUpdate 內提供 arrival 或 departure (無論提供哪個欄位皆不可空白)。如果 schedule_relationship 為 SKIPPED，arrival 和 departure 可以同時空白。如果 schedule_relationship 為 NO_DATA，則 arrival 和 departure 必須留空。
departure StopTimeEvent 必要 (有條件) 一個 如果 schedule_relationship 為空白或 SCHEDULED，就必須在 StopTimeUpdate 內提供 arrival 或 departure (無論提供哪個欄位皆不可空白)。如果 schedule_relationship 為 SKIPPED，arrival 和 departure 可以同時空白。如果 schedule_relationship 為 NO_DATA，則 arrival 和 departure 必須留空。
schedule_relationship ScheduleRelationship 選用 一個 預設的關係為 SCHEDULED。

ScheduleRelationship (列舉)

這個 StopTime 與靜態時間表之間的關係。

值

值 註解
SCHEDULED 車輛會按照停靠站的靜態時間表前進，但不一定會遵循表定時間。此為預設行為。至少須提供 arrival 或 departure 任一項。
SKIPPED 系統會略過該停靠站，也就是說，車輛不會停在這個停靠站。arrival 和 departure 為選用欄位。
NO_DATA 沒有提供這個停靠站的資料，也就表示無法提供即時資訊。如果設定此值，NO_DATA 會在後續停靠站生效，建議您透過這個方式指定從哪個停靠站開始沒有提供即時資訊。如果設定 NO_DATA，則不應提供 arrival 和 departure。

VehiclePosition (訊息)

特定車輛的即時定位資訊。

欄位

欄位名稱 類型 必要 基數 說明
trip TripDescriptor 選用 一個 這輛車提供的行程。如果無法以特定行程識別車輛，則可留空或填寫部分。
vehicle VehicleDescriptor 選用 一個 提供這趟行程的車輛的其他相關資訊。每個項目都必須有專屬的車輛 ID。
position Position 選用 一個 這輛車的目前位置。
current_stop_sequence uint32 選用 一個 目前停靠站的停靠順序索引。current_stop_sequence (亦即所指的停靠站) 的意義取決於 current_status。如果缺少 current_status，系統會假設使用的是 IN_TRANSIT_TO。
stop_id string 選用 一個 用於識別目前的停靠站。這個值必須與對應 GTFS 動態饋給中 stops.txt 內的值相同。
current_status VehicleStopStatus 選用 一個 與目前停靠站相關的車輛確切狀態。如果缺少 current_stop_sequence，則會略過。
timestamp uint64 選用 一個 測量車輛位置的時間點，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。
congestion_level CongestionLevel 選用 一個
occupancy_status OccupancyStatus 選用 一個 車輛載客情形。
注意：這個欄位仍為實驗階段，可能會有變動，但日後可能就會正式採用。

VehicleStopStatus (列舉)

值

值 註解
INCOMING_AT 車輛即將抵達停靠站 (車輛符號在停靠站顯示器上通常會閃爍)。
STOPPED_AT 車輛目前正在停靠站。
IN_TRANSIT_TO 車輛已離開前一個停靠站，目前行駛中。

CongestionLevel (列舉)

影響這輛車的壅塞程度。

值

值
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

OccupancyStatus (列舉)

車輛的乘客承載程度。

注意：這個欄位仍為實驗階段，可能會有變動，但日後可能就會正式採用。

值

值 註解
EMPTY 大多數測量方法都判定這是空車，而且車上幾乎沒有乘客，但仍可載客。
MANY_SEATS_AVAILABLE 車輛或車廂無人座位的比例偏高。至於空位要達到多少數量才算比例偏高，則由製作者酌情決定。
FEW_SEATS_AVAILABLE 車輛或車廂無人座位的比例偏低。至於空位要達到多少數量才算比例偏低，則由製作者酌情決定。
STANDING_ROOM_ONLY 車輛或車廂目前只有站位。
CRUSHED_STANDING_ROOM_ONLY 車輛或車廂目前只有站位，而且位置有限。
FULL 大多數測量方法都判定這輛車客滿，但可能仍可載客。
NOT_ACCEPTING_PASSENGERS 車輛或車廂不接受乘客。車輛或車廂通常會接受乘客上車。
NO_DATA_AVAILABLE 車輛或車廂目前沒有任何承載程度資料。
NOT_BOARDABLE 車輛或車廂不提供上車服務，且絕不接受乘客。適用於特殊車輛或車廂 (引擎、保養車廂等)。

Alert (訊息)

快訊，用於表示大眾運輸網路中的某種事件。

欄位

欄位名稱 類型 必要 基數 說明
active_period TimeRange 選用 多個 應向使用者顯示快訊的時間。就算缺少這項，只要該快訊仍存在於動態饋給就會顯示。如果指定多個時段，快訊就會在這些範圍內顯示。
informed_entity EntitySelector 必要 多個 應看到這則快訊的使用者所屬實體。必須提供至少一個 informed_entity。
cause Cause 選用 一個
effect Effect 選用 一個
url TranslatedString 選用 一個 提供快訊相關額外資訊的網址。
header_text TranslatedString 必要 一個 快訊的標題。這個純文字字串會醒目顯示，例如以粗體表示。
description_text TranslatedString 必要 一個 快訊的說明。這個純文字字串會使用快訊內文的格式 (或是在使用者明確要求「展開」時顯示)。說明中的資訊應加進標題資訊。

Cause (列舉)

發出這則快訊的原因。

值

值
UNKNOWN_CAUSE
OTHER_CAUSE
TECHNICAL_PROBLEM
STRIKE
DEMONSTRATION
ACCIDENT
HOLIDAY
WEATHER
MAINTENANCE
CONSTRUCTION
POLICE_ACTIVITY
MEDICAL_EMERGENCY

Effect (列舉)

這個問題對相關實體造成的影響。

值

值
NO_SERVICE
REDUCED_SERVICE
SIGNIFICANT_DELAYS
DETOUR
ADDITIONAL_SERVICE
MODIFIED_SERVICE
OTHER_EFFECT
UNKNOWN_EFFECT
STOP_MOVED

TimeRange (訊息)

時間間隔。如果 t 晚於或等於 start 時間，且早於 end 時間，則系統會將 t 視為該間隔的生效時間。

欄位

欄位名稱 類型 必要 基數 說明
start uint64 必要 (有條件) 一個 開始時間，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。如果缺少這個時間，間隔就會從負無限大開始。如果提供 TimeRange，則必須提供 start 或 end (無論提供哪個欄位皆不可空白)。
end uint64 必要 (有條件) 一個 結束時間，以 POSIX 時間表示 (亦即自世界標準時間 1970 年 1 月 1 日 00:00:00 起計算的秒數)。如果缺少這個時間，間隔就會以正無限大結束。如果提供 TimeRange，則必須提供 start 或 end (無論提供哪個欄位皆不可空白)。

Position (訊息)

車輛的地理位置。

欄位

欄位名稱 類型 必要 基數 說明
latitude float 必要 一個 往北的度數 (WGS-84 座標系統)。
longitude float 必要 一個 往東的度數 (WGS-84 座標系統)。
bearing float 選用 一個 方位角 (以度為單位，從正北順時針移動)，意即 0 為北方，90 為東方。這可以是指南針方位，也可以是指向下個停靠站或中繼點的方向。這不應根據先前位置順序 (用戶端可依據先前資料來計算) 進行推斷。
odometer double 選用 一個 里程表值 (以公尺為單位)。
speed float 選用 一個 車輛測量到的瞬時速度 (以公尺/秒為單位)。

TripDescriptor (訊息)

用於識別單趟 GTFS 行程的描述元。

在大多數情況下，單用 trip_id 就足以指定單趟行程。但在下列情況中，就必須要有額外資訊才能解析單趟行程：

  • 如果已在 frequencies.txt 中定義行程，則除了 trip_id 以外，還必須要有 start_date 和 start_time。
  • 如果行程持續超過 24 小時，或是因誤點而與隔天已排定的行程衝突，請同時提供 start_date 和 trip_id。
  • 如果無法提供 trip_id 欄位，則必須提供 route_id、direction_id、start_date 和 start_time 欄位。

不論如何，如果同時提供 route_id 和 trip_id，則 route_id 必須與 GTFS trips.txt 檔案中指派給特定行程的 route_id 欄位相符。

trip_id 欄位無法單獨或與其他 TripDescriptor 欄位搭配用來識別多趟行程。如果 TripDescriptor 解析為零或多趟 (而非單趟) 行程，就會視為發生錯誤。使用者可能會捨棄包含錯誤 TripDescriptor 的實體。

舉例來說，如果已在 GTFS frequencies.txt 中定義行程且 exact_times=0，TripDescriptor 就不得單獨指定 trip_id。這是因為如果解析的是在一天當中特定時間開始的單趟行程，您還必須提供 start_time。

請注意，如果 trip_id 不明，光是只有 TripUpdate 中的車站順序 ID 還不夠，必須一併提供 stop_id 欄位。此外，您也必須提供絕對抵達和出發時間。

欄位

欄位名稱 類型 必要 基數 說明
trip_id string 必要 (有條件) 一個 這個 trip_id 是來自選取器參照的 GTFS 動態饋給。trip_id 是否為必要欄位，取決於行程類型：
• 非以頻率為準的行程：單用 trip_id 欄位就能正確識別這類行程。請注意，非以頻率為準的行程不是在 GTFS frequencies.txt 中定義。
• 以頻率為準的行程：trip_id、start_time 和 start_date 都是必要欄位。以頻率為準的行程是在 GTFS frequencies.txt 中定義。
• 以時間表為準的行程：聯合 route_id、direction_id、start_time 和 start_date 這幾欄就能辨識某行程時，才能省略 trip_id 欄位。請注意，以頻率為準的行程不是在 GTFS frequencies.txt 中定義。
route_id string 必要 (有條件) 一個 這個 route_id 是來自選取器參照的 GTFS 動態饋給。如果省略 trip_id，則 route_id、direction_id、start_time 和 schedule_relationship=SCHEDULED 全部都要設定，才能識別特定一趟行程。
direction_id uint32 必要 (有條件) 一個 GTFS 動態饋給 trips.txt 檔案的 direction_id，用於表示行駛方向。如果省略 trip_id，就必須提供 direction_id。
注意：這個欄位仍為實驗階段，可能會有變動，但日後可能就會正式採用。
start_time string 必要 (有條件) 一個 這趟行程最初排定的開始時間。欄位類型 Time 定義這個欄位的格式，例如 11:15:35 或 25:15:35。start_time 是否為必要欄位，取決於行程類型：
• trip_id 對應到非以頻率為準的行程：start_time 欄位必須省略，或是等於 GTFS 動態饋給 stop_times.txt 檔案中 departure_time 的值。
• trip_id 對應到以頻率為準的行程：start_time 一律為必要欄位，且必須指定才能進行行程更新和車輛定位。以頻率為準的行程是在 GTFS frequencies.txt 中定義。
◦ 如果以頻率為準的行程對應到 exact_times=1 GTFS 記錄：start_time 欄位必須是 headway_secs 的倍數 (包含零在內)，且晚於對應時間範圍內的 frequencies.txt start_time。
◦ 如果以頻率為準的行程對應到 exact_times=0 GTFS 記錄：start_time 可以是任意值，原則上是行程的第一個班次。設定後，以頻率為準 exact_times=0 行程的 start_time 就無法改變，即使更改第一個班次的時間也一樣。如果之後時間上有任何異動，可以改用 StopTimeUpdate 訊息更新。
• 省略 trip_id：必須提供 start_time。
start_date string 必要 (有條件) 一個 這趟行程的開始日期，格式為 YYYYMMDD。start_date 是否為必要欄位，取決於行程類型：
• 已排定的行程：必須提供 start_date。如果有行程因誤點而與隔天已排定的行程衝突，這樣做有助於釐清。舉例來說，假設火車每天 8:00 和 20:00 發車。如果火車誤點 12 小時，就會有兩趟不同的行程安排在同一個時間。
注意：如果已排定的行程不會發生這種衝突，則此為選用欄位。舉例來說，如果服務是每小時提供一次，而誤點一小時的車輛就不會再視為表定班次，可能就會發生上述情況。
• 以頻率為準的行程：必須提供 start_date。請注意，以頻率為準的行程是在 GTFS frequencies.txt 檔案中定義，但已排定的行程不是。
• 省略 trip_id：必須提供 start_date。
schedule_relationship ScheduleRelationship 選用 一個 這個行程與靜態時間表之間的關係。如果在 Alert EntitySelector 中提供 TripDescriptor，則使用者在識別出相符的行程時，就會略過 schedule_relationship 欄位。

ScheduleRelationship (列舉)

這個行程與靜態時間表之間的關係。如果行程是依據臨時時間表 (未顯示於 GTFS) 完成，這個欄位就不應標示為 SCHEDULED，而應標示 ADDED。

值

值 註解
SCHEDULED 行程依 GTFS 時間表或是近似的時間表進行。
ADDED 在目前時間表以外追加的額外行程，例如用於取代故障車輛，或因應突然增加的載客量。
UNSCHEDULED 不按任何相關時間表進行的行程，這個值會用於識別 GTFS frequencies.txt 中定義且 exact_times = 0 的行程，不應用於描述 GTFS frequencies.txt 中未定義的行程，或是在 GTFS frequencies.txt 中且 exact_times = 1 的行程。
CANCELED 曾在時間表上但已遭移除的行程。

VehicleDescriptor (訊息)

提供行程的車輛識別資訊。

欄位

欄位名稱 類型 必要 基數 說明
id string 選用 一個 車輛的內部系統識別資訊。每輛車的這項資訊皆不得重複，且可用來在行駛期間透過系統追蹤車輛。請勿向使用者顯示這個 ID，如要顯示，請使用 label 欄位。
label string 選用 一個 使用者可見標籤，也就是必須向乘客顯示以便他們識別正確車輛的資訊。
license_plate string 選用 一個 車輛的車牌。

EntitySelector (訊息)

GTFS 動態饋給中的實體選取器。欄位值需對應至 GTFS 動態饋給中的適當欄位。必須提供至少一個指定碼。如果提供多個指定碼，則應解讀為由 AND 邏輯運算子結合。此外，指定碼的組合必須與 GTFS 動態饋給中的對應資訊相符。換言之，如果快訊要套用至 GTFS 中的實體，就必須與所有提供的 EntitySelector 欄位相符。舉例來說，包含 route_id: "5" 和 route_type: "3" 欄位的 EntitySelector 只會套用至 route_id: "5" 公車，不會套用至 route_type: "3" 的任何其他路線。如果製作者希望將快訊套用至 route_id: "5" 和 route_type: "3"，則應提供兩個獨立的 EntitySelector 欄位，一個參照 route_id: "5"，另一個則參照 route_type: "3"。

必須提供至少一個指定碼，EntitySelector 中的所有欄位皆不可空白。

欄位

欄位名稱 類型 必要 基數 說明
agency_id string 必要 (有條件) 一個 這個 agency_id 是來自選取器參照的 GTFS 動態饋給。
route_id string 必要 (有條件) 一個 這個 route_id 是來自選取器參照的 GTFS。如果提供 direction_id，則必須一併提供 route_id。
route_type int32 必要 (有條件) 一個 這個 route_type 是來自選取器參照的 GTFS。
direction_id uint32 必要 (有條件) 一個 GTFS 動態饋給 trips.txt 檔案的 direction_id，用於選取路線 (以 route_id 指定) 中其中一個方向的所有行程。如果提供 direction_id，則必須一併提供 route_id。
trip TripDescriptor 必要 (有條件) 一個 這個行程是來自選取器參照的 GTFS。這個 TripDescriptor 必須解析為 GTFS 資料中的單趟行程 (以 exact_times=0 行程為例，製作者不能只提供 trip_id)。如果這個 TripDescriptor 內的 ScheduleRelationship 欄位已填入值，則使用者試著識別 GTFS 行程時會略過這個欄位。
stop_id string 必要 (有條件) 一個 這個 stop_id 是來自選取器參照的 GTFS 動態饋給。

TranslatedString (訊息)

國際化訊息，內含各種語言版本的文字或網址片段。系統會挑選訊息中的任一字串。解析作業的進行方式如下：如果 UI 語言與翻譯的語言代碼相符，則挑選第一個相符的翻譯。如果預設 UI 語言 (例如英文) 與翻譯的語言代碼相符，則挑選第一個相符的翻譯。如果翻譯未指定語言代碼，系統就會挑選這個翻譯。

欄位

欄位名稱 類型 必要 基數 說明
translation Translation 必要 多個 必須提供至少一種翻譯。

Translation (訊息)

與某種語言對應的本地化字串。

欄位

欄位名稱 類型 必要 基數 說明
text string 必要 一個 包含訊息的 UTF-8 字串。
language string 必要 (有條件) 一個 BCP-47 語言代碼。如果語言不明，或是動態饋給完全沒有國際化，則可省略。最多只有一種翻譯能有未指定的語言標記，如有多種翻譯，則必須提供語言。