旅程の更新¶

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

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

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

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

フィードには、車両が現在担当している旅程のTripUpdateを含める必要があります。プロデューサーは、将来の旅程の予測の品質に自信がある場合は、この車両のブロック内の現在の旅程の後の 1 つ以上の旅程の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdate を含めると、車両が 1 つの旅程から別の旅程に移行する際に予測が突然表示されるのを回避できるほか、下流の旅程に影響する遅延 (例: 既知の遅延が旅程間の予定の乗り継ぎ時間を超える場合) を事前に乗客に通知できます。
それぞれのTripUpdateエンティティは、ブロック内でスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、1 つのブロックに属するtrip_ids 1、2、3 のルートがあり、車両がルート 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 – 定刻通り）

...バスが実際には午前 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 を参照する必要があります。 1 つの旅程で同じ stop_id に複数回訪問する場合は、その旅程のその stop_id のすべての StopTimeUpdates でstop_sequenceを指定する必要があります。

更新では、StopTimeUpdates で StopTimeEvent を使用して、停車地でのarrivaldeparture/または出発の正確なタイミングを提供できます。これには、絶対timeまたはdelay (つまり、予定時刻からの秒単位のオフセット) のいずれかを含める必要があります。遅延は、旅程更新が、頻度ベースの旅程ではなく、スケジュールされた GTFS 旅程を参照する場合にのみ使用できます。この場合、時間は予定時刻 + 遅延と等しくなります。 StopTimeEvent とともに予測のuncertaintyを指定することもできます。これについては、ページの下にある不確実性のセクションで詳しく説明します。

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

更新はstop_sequence (またはルートで発生する順序の stop_id) で並べ替える必要があります。

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

例 1

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

例 2

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

stop_sequence 3 の遅延は 300 秒
stop_sequence 8 の遅延は 60 秒
ScheduleRelationship がstop_sequence 10 の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によって提供される情報は、更新する旅行のスケジュール関係によって異なります。設定できるオプションは多数あります:¶

値	コメント
スケジュール済み	この旅程はGTFS scheduleに従って運行中であるか、またはそれと関連付けられるほど近い状態です。
追加済み	この旅程はスケジュールされておらず、追加されました。たとえば、需要に対応するため、または故障した車両を交換するためです。
未スケジュール	この旅程は運行中であり、スケジュールに関連付けられることはありません。たとえば、スケジュールがなく、バスがシャトルサービスで運行されている場合などです。
キャンセル済み	この旅程はスケジュールされていましたが、現在は削除されています。
重複	この新しい旅程は、サービスの開始dateを除き、静的 GTFS の既存の旅程のコピーです。新しい旅程は、 TripPropertiesで指定されたサービスのdateで運行されます。

ほとんどの場合、この更新が関係する 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 になります。