Trip Updates¶

Trip updatesは時刻表の変動を表します。私たちは、あなたがスケジュールしたリアルタイムに対応するすべてのトリップについて、トリップアップデートを受け取ることを期待します。これらの更新は、ルート上の停留所への到着または出発の予測時刻を提供します。トリップアップデートはまた、トリップがキャンセルされたり、スケジュールに追加されたり、あるいはルートが変更されたりする、より複雑なシナリオを提供することができます。

注意事項 GTFSでは、トリップとは、特定の時刻に発生する2つ以上の停車駅の連続を指します。

各スケジュールされたトリップに対して、最大で1つのトリップアップデートがあるべきである。スケジュールされたトリップに対してトリップアップデートがない場合、そのトリップに対してリアルタイムのデータが利用できないと判断される。データ消費者は、トリップが時間通りに運行されていると仮定してはならない。

車両が同じブロック内で複数のトリップを提供している場合（トリップとブロックの詳細については、GTFS trips.txtを参照してください）。

フィードには、その車両現在担当している旅行 TripUpdateを含める必要があります。生産者は、この車両ブロックの現在の旅行後に、1つ以上のトリップのTripUpdateを含めることが推奨されます（生産者が将来の旅行予測の品質に自信を持っている場合）。同じ車両複数のTripUpdateを含めることで、車両ある旅行別の旅行に移行する際に利用者が予測の「ポップイン」を避けることができ、また、下流の旅行に影響を与える遅延を利用者に事前に知らせることができます（例：既知の遅れ旅行間の計画された待ち時間を超える場合など）。
の場合、それぞれのTripUpdateエンティティは、ブロック内で予定されるのと同じ順序でフィードに追加したされる必要はない。たとえば、trip_id が 1、2、3 ですべて 1 つのブロックに属するトリップがあり、車両旅行1、旅行2、旅行3 の順に移動する場合、trip_updateエンティティは任意の順序で表示できます。たとえば、旅行2、旅行1、旅行3 と追加してもよいことになっています。

StopTimeUpdate¶

トリップの更新は、StopTimeUpdatesと呼ばれる車両の停車時間に対する1つ以上の更新から構成される。これらは、過去および将来の停車時間について提供することができる。過去の停車時間を削除することは可能であるが、必須ではない。プロデューサーは、過去のStopTimeUpdateが、与えられたトリップの将来の到着予定時刻を持つ停留所（すなわち、車両が予定より早くその停留所を通過した）を参照している場合、その停留所の更新がないと判断されるため、ドロップしてはならない。

例えば、GTFS-rtのフィードに以下のようなデータが表示された場合。

停車駅4 - 午前10時18分に予測（午前10時20分に予定 - 2分早い）。
停車駅5 - 10:30amの予測（10:30amの予定-定刻通り）

...バスが実際に10時18分に停留所を通過しても、10時21分まで停留所4の予測はフィードから削除できません。停留所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 を 1 つのトリップで複数回訪れる場合は、そのトリップのその stop_id のすべての StopTimeUpdate で stop_sequence を提供する必要があります。

更新では、StopTimeEventを使用して、StopTimeUpdatesに停留所へのarrivalよび／またはdeparture正確なタイミングを提供することができます。これには、絶対timeまたはdelay（つまり、予定時間からのオフセット（秒単位））が含まれるべきです。遅延は、トリップの更新が、頻度ベースのトリップとは対照的に、スケジュールされたGTFSトリップを参照する場合にのみ使用することができます。この場合、時間は予定時刻 + 遅延に等しくなければなりません。また、StopTimeEventと一緒に予測のuncertainty指定することもできます。これについては、このページの下の方にあるUncertainty性のセクションで詳しく説明します。

それぞれのStopTimeUpdate、に対してデフォルトのスケジュール関係がscheduledされます。(これは旅行のスケジュール関係とは異なることに注意してください)。停留所に停車しない場合はskipped、トリップの一部のリアルタイムのデータしかない場合はデーno dataに変更することができます。

更新は、stop_sequence（またはトリップに含まれるstop_idの順番）でソートされる必要がある。

トリップ中に1つ以上の停留所がない場合、更新によるdelay（または、更新にtime提供されている場合、GTFSのスケジュールtime比較して計算された遅延）は、後続のすべての停留所に伝搬されます。つまり、ある停車駅の停車時刻を更新すると、他の情報がない場合、それ以降のすべての停車駅が変更されます。スケジュール関係SKIPPEDの更新は遅延の伝播を止めませんが、スケジュール関係SCHEDULED（スケジュール関係が提供されない場合のデフォルト値）またはNO_DATAの更新は停止することに注意してください。

例1

20の停留所があるトリップでは、現在の停留所のstop_sequenceの到着遅延と出発遅延が0（StopTimeEvents）のStopTimeUpdate、はトリップが正確に時間通りであることを意味します。

例2

同じトリップインスタンスに対して、3つのStopTimeUpdateが提供されます。

stop_sequence3に対して300秒の遅延。
stop_sequence 8の遅延時間は60秒です。
stop_sequence 10のScheduleRelationshipofNO_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は特定の時間要素を持たないため、それ自体が1つの旅を識別するユニークなものではありません。TripDescriptor 内でこのようなトリップを一意に識別するためには、識別子のトリプルを提供する必要がある。

trip_id
start_time
start_date

start_time は最初に公開されるべきもので、それ以降のフィードの更新では、同じ旅を参照するときに同じ start_time を使用する必要があります。StopTimeUpdatesは、調整を示すために使用されるべきである。start_timeは、最初の駅からの出発時刻を正確に示す必要はないが、その時刻にかなり近いものであるべきである。

例えば、2015年5月25日10時にtrip_id=Tのトリップをstart_time=10:10:00に開始すると決定し、10時1分にリアルタイムフィードでその情報を提供したとします。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の組み合わせが一意のトリップに解決する限り、次の組み合わせを含むTripDescriptorによって一意に識別されます。

Uncertainty¶

Uncertaintyは、StopTimeUpdateの時刻と遅延値の両方に適用されます。Uncertaintyは、秒単位の整数として、真の遅延の予想誤差をおおまかに指定します（ただし、正確な統計的意味はまだ定義されていないことに注意してください）。コンピュータのタイミング制御で運転される列車などでは、uncertaintyが0になることもあり得ます。

例として、長距離バスの遅延が15分で、4分の誤差（つまり+2分/-2分）以内に次の停留所に到着すると予測される場合、uncertaintyの値は240となります。