旅程の更新¶

旅程の更新は時刻表の変動を表します。リアルタイム対応のスケジュールされたすべての便の更新を受け取ることを期待しています。これらの更新は、ルート上の停留所等の到着または出発の予想時刻を示します。旅程の更新は、便がキャンセルされたり、スケジュールに追加されたり、さらにはルートが変更されたりする、より複雑なシナリオにも対応できます。

注意:GTFS では、旅程とは特定の時間に発生する 2 つ以上の停留所等のシーケンスです。

スケジュールされた旅程ごとに、最大1 つの旅程更新がするべきである。スケジュールされた旅程に旅程の更新がない場合は、その旅程のリアルタイムデータは利用できないと判断されます。データ利用者は、旅程が時間どおりに運行されていると想定してはするべきであるん。

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

フィードには、車両が現在提供している便の TripUpdate を含める必要があります。プロデューサーは、将来の便の予測の品質に自信がある場合は、この車両のブロックに現在の便の後の 1 つ以上の便の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdate を含めると、車両が 1 つの便から別の便に移行する際に乗客に予測が「突然表示される」のを回避でき、また、下流の便に影響する遅延 (既知の遅延が便間の予定の乗り継ぎ時間を超える場合など) を乗客に事前に通知できます。
それぞれの TripUpdate エンティティは、ブロックでスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、trip_ids が 1、2、3 で、すべて 1 つのブロックに属する便があり、車両が便 1、便 2、便 3 の順に移動する場合は、trip_update エンティティは任意の順序で表示できます。たとえば、便 2、便 1、便 3 の順で追加できます。

StopTimeUpdate¶

ルート更新は、車両の停車時刻に対する 1 つ以上の更新で構成されます。これは StopTimeUpdates と呼ばれます。これらは、過去および将来の停車時刻に対して指定できます。過去の停車時刻を削除できますが、削除は必須ではありません。プロデューサーは、過去のStopTimeUpdateが、特定の旅程で予定到着時刻が未来の停留所を参照している場合（つまり、車両が予定より早く停留所を通過している場合）、それを削除するべきではない。削除すると、この停留所には更新がないと判断されます。

たとえば、GTFS-rt フィードに次のデータが表示される場合:

停留所 4 – 予測時刻は午前 10:18（予定時刻は午前 10:20 – 2 分早い）
停留所 5 – 予測時刻は午前 10:30（予定時刻は午前 10:30 – 定刻通り）

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

各 StopTimeUpdate は停留所にリンクされています。通常、これは GTFS stop_sequence または GTFS stop_id を使用して行うことができます。ただし、GTFS trip_id のない便の更新を提供する場合は、stop_sequence に値がないため、stop_id を指定する必要があります。stop_id は GTFS の stop_id を参照する必要があります。便中に同じ stop_id を複数回訪問する場合は、その便のその stop_id のすべての StopTimeUpdates で stop_sequence を指定する必要があります。

更新では、StopTimeEvent を使用して、StopTimeUpdates の停留所での到着および/または出発の正確なタイミングを提供できます。これには絶対的な時間または遅延（つまり、予定時刻からの秒単位のオフセット）のいずれかを含める必要があります。遅延は、運行更新が定期運行の GTFS 運行を参照する場合にのみ使用できます。頻度ベースの運行ではありません。この場合、時間は予定時刻 + 遅延に等しくする必要があります。StopTimeEvent とともに予測の不確実性 を指定することもできます。これについては、ページの下の不確実性セクションで詳しく説明します。

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

更新は stop_sequence (または、旅程内での stop_id の順序) で並べ替える必要があります。

旅程中に 1 つ以上の停留所がない場合、更新の delay (または、更新で time のみが指定されている場合は、time と GTFS スケジュール時間を比較して計算された遅延) が、後続のすべての停留所に伝播されます。つまり、特定の停留所の停留所時間を更新すると、他の情報がない場合、後続のすべての停留所が変更されます。スケジュール関係が SKIPPED の更新では遅延の伝播が停止されませんが、スケジュール関係が SCHEDULED (スケジュール関係が指定されていない場合のデフォルト値) または NO_DATA の更新では遅延の伝播が停止されることに注意してください。

例 1

20 の停留所がある便の場合、現在の停留所の stop_sequence の StopTimeUpdate で到着遅延と出発遅延が 0 (StopTimeEvents) の場合、便は正確に時間どおりであることを意味します。

例 2

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

stop_sequence 3 の遅延は300秒
stop_sequence 8 の遅延は60秒
stop_sequence 10 の ScheduleRelationship は NO_DATA

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

stop_sequences 1、2 の遅延は不明です。
stop_sequences 3、4、5、6、7 の遅延は 300 秒です。
stop_sequences 8、9 の遅延は 60 秒です。
stop_sequences 10、..、20 の遅延は不明です。

TripDescriptor¶

TripDescriptor によって提供される情報は、更新する便のスケジュール関係によって異なります。設定できるオプションは多数あります:

値	コメント
Scheduled	この便は GTFS スケジュールに従って実行されているか、またはそれと関連付けられるほど近いです。
Added	この便はスケジュールされておらず、追加されました。たとえば、需要に対応するため、または故障した車両を交換するためです。
Unscheduled	この便は実行されており、スケジュールに関連付けられることはありません。たとえば、スケジュールがなく、バスがシャトルサービスで実行される場合などです。
Canceled	この便はスケジュールされていましたが、現在は削除されています。
Duplicated	この新しい旅程は、サービス開始日時を除いて、静的 GTFS の既存の旅程のコピーです。新しい旅程は、TripProperties で指定されたサービス日時で実行されます。

ほとんどの場合、この更新に関連する GTFS のスケジュールされた旅程の trip_id を指定する必要があります。

trip_id が重複するシステム¶

trip_id が重複するシステム (たとえば、frequencies.txt を使用してモデル化された旅程、つまり頻度ベースの旅程) の場合、trip_id 自体は特定の時間コンポーネントがないため、単一の旅程の一意の識別子ではありません。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) として識別できますが、最初の停留所からの出発時刻を 10:13:00 とする StopTimeUpdate を提供します。

代替の便マッチング¶

頻度ベースではない便は、次の組み合わせを含む TripDescriptor によって一意に識別される場合もあります:

route_id
direction_id
start_time
start_date

start_time は、静的スケジュールで定義されている予定の開始時刻です。ただし、提供された ID の組み合わせによって一意の便が解決される限りです。

不確実性¶

不確実性は、StopTimeUpdate の時間と遅延値の両方に適用されます。不確実性は、実際の遅延の予想される誤差を秒単位の整数として大まかに指定します (ただし、正確な統計的意味はまだ定義されていないことに注意してください)。たとえば、コンピューターのタイミング制御下で運転される列車の場合、不確実性が0になることがあります。

たとえば、長距離バスが次の停留所に4分間の誤差 (つまり+2/-2分) 以内で到着すると予測される遅延が15分の場合、不確実性の値は240になります。