便の更新(trip updates)¶

便の更新(trip updates)は、時刻表の変動を表します。リアルタイム対応可能なすべての便(trip)について、便の更新を受け取ることが期待されます。これらの更新は、ルート・路線系統(route)に沿った停留所等(stop)での予測到着時刻または出発時刻を提供します。便の更新は、便の運休や追加、さらには経路変更といった、より複雑なシナリオにも対応することができます。

注意: GTFSにおいて、便(trip)とは、特定の時刻に発生する2つ以上の停留所等(stop)の並びを指します。

各便(trip)に対して、便の更新(trip update)は最大で1つであるべきです。もし便(trip)に対して便の更新(trip update)が存在しない場合、その便にはリアルタイムデータが利用できないと判断されます。データ利用者は、その便が定刻通りに運行していると仮定してはいけません。

1台の車両が同じブロック内で複数の便(trip)を運行している場合（便とブロックの詳細については GTFS trips.txt を参照してください）:

フィードには、現在その車両が運行している便(trip)の TripUpdate を含めるべきです。プロデューサーは、将来の便に対する予測の品質に自信がある場合、現在の便の後に続く1つ以上の便についても TripUpdate を含めることが推奨されます。同じ車両に対して複数の TripUpdate を含めることで、車両が便から便へ移行する際に予測が突然現れる（"pop-in"）のを避けることができ、また、後続の便に影響する遅延について乗客に事前に通知することができます（例: 既知の遅延が便間の計画された待機時間を超える場合）。
各 TripUpdate エンティティは、ブロック内で予定されている順序と同じ順序でフィードに追加する必要はありません。例えば、trip_ids が 1、2、3 の便が1つのブロックに属しており、車両が便1、便2、便3の順に運行する場合でも、trip_update エンティティは任意の順序で現れることができます。例えば、便2、便1、便3の順に追加することも可能です。

StopTimeUpdate¶

便の更新(trip update)は、車両の停車時刻(stop time)に対する1つ以上の更新で構成され、これらは StopTimeUpdates と呼ばれます。これらは過去および未来の停車時刻に対して提供することができます。GTFS 静的データに存在しない新規または代替の便でない限り、過去の停車時刻を削除することは許可されていますが、必須ではありません。ただし、ある便において、将来の予定到着時刻を持つ停留所等(stop)に関する過去の StopTimeUpdate を削除するべきではありません（つまり、車両が予定より早く停留所等を通過した場合）。そうしないと、その停留所等に関する更新が存在しないと解釈されてしまいます。

例えば、GTFS-rt フィードに以下のデータが含まれている場合:

停留所等 4 – 予測時刻 10:18am（予定時刻 10:20am – 2分早い）
停留所等 5 – 予測時刻 10:30am（予定時刻 10:30am – 定刻）

...停留所等 4 の予測は、バスが実際に 10:18am に通過したとしても、10:21am まではフィードから削除してはいけません。もし停留所等 4 の StopTimeUpdate が 10:18am または 10:19am にフィードから削除され、予定到着時刻が 10:20am であった場合、利用者はその時点で停留所等 4 に関するリアルタイム情報が存在しないと判断し、GTFS のスケジュールデータを使用することになります。

各 StopTimeUpdate は停留所等に関連付けられます。通常、これは GTFS の stop_sequence または stop_id を使用して行うことができます。ただし、GTFS の trip_id を持たない便に対して更新を提供する場合、stop_sequence には意味がないため、stop_id を指定しなければなりません。この stop_id は GTFS 内の stop_id を参照している必要があります。同じ stop_id が便内で複数回訪問される場合、その便におけるその stop_id のすべての StopTimeUpdate に stop_sequence を指定するべきです。

更新は、StopTimeUpdates 内で StopTimeEvent を使用して、停留所等での到着および/または出発の正確な時刻を提供することができます。これには絶対的な time または delay（予定時刻からの秒単位のオフセット）のいずれかを含めるべきです。delay は、便の更新が GTFS のスケジュール便を参照している場合にのみ使用できます（頻度ベースの便では使用できません）。この場合、time は「予定時刻 + delay」と等しくなければなりません。また、StopTimeEvent とともに予測の uncertainty を指定することもできます。これについては後述の Uncertainty セクションで詳しく説明されています。

各 StopTimeUpdate のデフォルトのスケジュール関係は scheduled です。（これは便のスケジュール関係とは異なる点に注意してください）。停留所等に停車しない場合は skipped に変更することができ、便の一部にしかリアルタイムデータがない場合は no data に変更することができます。

更新は stop_sequence の順序（または便内での stop_id の順序）で並べ替えるべきです。

便の途中で1つ以上の停留所等が欠落している場合、更新からの delay（または、更新で time のみが提供されている場合は、その time と GTFS の予定時刻を比較して算出された delay）がすべての後続の停留所等に伝播します。つまり、ある停留所等の停車時刻を更新すると、他の情報がない限り、すべての後続の停留所等の時刻が変更されることを意味します。なお、スケジュール関係が SKIPPED の更新は delay の伝播を止めませんが、スケジュール関係が SCHEDULED（スケジュール関係が指定されていない場合のデフォルト値）または NO_DATA の更新は delay の伝播を止めます。

例 1

20 停留所等の便において、現在の停留所等の stop_sequence に対して到着遅延および出発遅延が 0 の StopTimeUpdate（StopTimeEvents）がある場合、その便は完全に定刻通りであることを意味します。

例 2

同じ便に対して、3つの StopTimeUpdates が提供されます:

stop_sequence 3 に対して 300 秒の遅延
stop_sequence 8 に対して 60 秒の遅延
stop_sequence 10 に対して ScheduleRelationship が NO_DATA

これは次のように解釈されます:

stop_sequence 1,2 は遅延不明
stop_sequence 3,4,5,6,7 は 300 秒の遅延
stop_sequence 8,9 は 60 秒の遅延
stop_sequence 10,..,20 は遅延不明

TripDescriptor¶

TripDescriptor によって提供される情報は、更新対象の便(trip)のスケジュール関係に依存します。設定できるオプションはいくつかあります。

値	コメント
Scheduled	この便(trip)は GTFS スケジュールに従って運行しているか、または十分に近いためスケジュールに関連付けられています。
Added	この便(trip)はスケジュールされておらず、新たに追加されたものです。例えば、需要に対応するためや故障した車両を代替するために追加されます。
Unscheduled	この便(trip)は運行しているが、スケジュールに関連付けられることはありません。例えば、スケジュールが存在せず、バスがシャトルサービスとして運行している場合です。
Canceled	この便(trip)はスケジュールされていましたが、現在は削除されています。
Duplicated	この新しい便(trip)は、TripProperties で指定された運行開始日時を除き、静的 GTFS 内の既存の便(trip)のコピーです。新しい便(trip)は TripProperties で指定された運行日と時刻に運行されます。

ほとんどの場合、この更新が関連する GTFS 内のスケジュール済み便(trip)の trip_id を指定するべきです。

trip_id が繰り返されるシステム¶

frequencies.txt を使用してモデル化された便、すなわち頻度ベースの便のように、繰り返される trip_id を使用するシステムでは、trip_id 自体は単一の旅程(journey)を一意に識別するものではありません。これは特定の時間要素を欠いているためです。そのような便を TripDescriptor 内で一意に識別するためには、以下の3つの識別子の組み合わせを提供しなければなりません。

trip_id
start_time
start_date

start_time は最初に公開されるべきであり、その後のフィード更新では同じ旅程を参照する際に同じ start_time を使用しなければなりません。StopTimeUpdates を使用して調整を示すべきであり、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) として引き続き識別できますが、最初の停留所等(stop)からの出発を 10:13:00 とする StopTimeUpdate を提供することができます。

代替便の照合¶

頻度ベースではない便(trip)も、以下の組み合わせを含む TripDescriptor によって一意に識別することができます。

route_id
direction_id
start_time
start_date

ここで、start_time は静的スケジュールで定義された予定出発時刻であり、提供された ID の組み合わせが一意の便(trip)に解決される限り有効です。

不確実性¶

不確実性は、StopTimeUpdate の時刻と遅延値の両方に適用されます。不確実性は、真の遅延における予想誤差を秒単位の整数で大まかに指定します（ただし、正確な統計的意味はまだ定義されていません）。例えば、コンピュータによる時刻制御で運行される列車のように、不確実性が 0 となる場合もあります。

例として、長距離バスが次の停留所(stop)に到着する際、15分の遅延が見込まれており、その誤差が4分の範囲（+2分 / -2分）である場合、不確実性の値は 240 となります。