timeサーバから取得することを強く推奨します。3またはそれ以下の階層のサーバーを使用することは全く問題ない。現在のフェッチがインクリメンタルであるかどうかを判断する。このフィードの更新は、それまでのフィードのリアルタイム情報をすべて上書きする。したがって、この更新はすべての既知のリアルタイム情報のFULLスナップショットを提供することが期待されます。現在、このモードはサポートされておらず、このモードを使用するフィードの動作は指定されていません。メーリングリストでは、DIFFERENTIALモードの挙動について議論されており、その議論がまとまった時点でドキュメントが更新される予定です。FeedEntity¶トランジットフィードにおけるentity定義(または更新)。フィールドのうち、ちょうど1つが入力されている必要があります。このentityフィード固有識別子。Incrementalityサポートを提供するためにのみ使用されます。(INFO、以下のEntitySelectorを参照ください)。このentity削除されるかどうか。DIFFERENTIALのIncrementality持つフィードに対してのみ指定する必要があります。Incrementality持つフィードに対しては、このフィールドを指定してはいけません。tripリアルタイムのdeparture遅延に関するデータ。これらすべてのフィールドをEMPTYすることはできない。vehicleリアルタイムのPositionデータ。これらすべてのフィールドをEMPTYすることはできない。リアルタイムのAlertデータ。これらすべてのフィールドをEMPTYすることはできない。DETOURようなリアルタイムのADDED形状に関するデータ。これらすべてのフィールドをEMPTYすることはできません。実験的であり、変更される可能性があります。将来、正式に採用される可能性がある。TripUpdate¶trip中のvehicle進行状況をリアルタイムに表示します。trip-updates">trip一般的な議論も参照してください。ScheduleRelationship値に応じて、TripUpdate指定することができます。スケジュールに沿って進行するtrip。スケジュールに沿って進行するtrip。スケジュールに関してADDEDまたは削除されたtrip。静的なGTFSある既存のtripコピーである新しいtrip。TripProperties指定された運行time運行されます。更新は、将来予測されるarrivalイベント、またはすでに発生した過去のイベントに対して行うことができます。多くの場合、過去のイベントに関する情報は測定値であるため、そのuncertainty値は0であることが推奨されます。ない場合もあるため、過去のイベントのuncertainty値が0と異なることは許容されます。更新のuncertainty性が0でない場合、その更新は完了していないtripおおよその予測であるか、測定が正確でないか、またはイベント発生後に検証されていない過去の予測であるかのいずれかである。trips.txt参照してください)。TripUpdateを含める必要があります。生産者は、このvehicleブロックの現在のtrip後に、1つ以上のトリップのTripUpdateを含めることが推奨されます(生産者が将来のtrip予測の品質に自信を持っている場合)。同じvehicle複数のTripUpdateを含めることで、vehicleあるtrip別の旅行に移行する際に利用者が予測の「ポップイン」を避けることができ、また、下流の旅行に影響を与える遅延を利用者に事前に知らせることができます(例:既知のdelay旅行間の計画された待ち時間を超える場合など)。場合、それぞれのTripUpdateエンティティは、ブロック内でSCHEDULEDされるのと同じ順序でフィードにADDEDされる必要はない。順に移動する場合、trip_updateエンティティは任意の順序で表示できます。追加してもよいことになっています。更新は、すでに終了したtrip記述できることに注意する。time過去のものである場合、クライアントはtrip全体が過去のものであると判断する(重要ではないが、以前の目的地の更新も提供することは可能である)。よると、trip現在のtime進行中である。みなされる可能性がある。フィードプロバイダーは、過去の更新を削除することができるが、必須ではないことに注意。このmessage適用されるtrip。entity存在することができる。1つもない場合は、利用可能な予測情報がないことを意味します。_ない_tripスケジュール通りに進行していることを意味する。このtripサービスを提供しているvehicle追加情報。tripStopTimeの更新(未来のもの、つまり予測、場合によっては過去のもの、つまりすでに起こったものの両方)。tripすべての次の停留所に適用される必要がある。CANCELEDまたはDUPLICATEDでない限り、そのtrip提供されなければなりません。DUPLICATED場合、stop_time_updatesは新しいtripリアルタイム情報を示すために提供されるかもしれません。将来のStopTimesを推定するために、vehicleリアルタイム進捗を測定した直近の瞬間。提供される場合、arrival時刻はこの値より早いかもしれない。delay、GTFS既存のスケジュールとの相対的な予測を行う場合にのみ指定する必要があります。delay(秒)は、正(vehicleいることを意味する)または負(vehicle予定より進んでいることを意味する)とすることができる。delay値が0であれば、車両は時間通りであることを意味します。delay情報よりも優先されます。フィード・プロバイダーは、データの鮮度を評価するために、delay値が最後に更新された日時を示すTripUpdate.timestamp値を提供することが強く推奨される。実験的であり、変更される可能性がある。将来、正式に採用されるかもしれない。trip更新されたプロパティを提供する。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。単一の予測されたイベント(arrivalまたはdepartureいずれか)のためのタイミング情報。タイミングは、delay推定time、およびuncertaintyなる。既存のスケジュールと関連して与えられる場合に使用されるべきである。timeは、予測されるスケジュールがあるなしにかかわらず、指定されるべきものです。time+delay等しくなるはずです)。delay両方に等しく適用される。uncertainty性は、真のdelay予想誤差をおおまかに特定します(ただし、その正確な統計的意味はまだ定義されていません)。コンピュータのタイミング制御の下で運転される列車では、uncertaintyさが0になることもあり得ます。delay(秒)は、正の値(vehicleいることを意味する)と負の値(vehicle予定より進んでいることを意味する)がある。timeどちらかをStopTimeEvent内で指定する必要があり、両方のフィールドをEMPTYすることはできません。絶対timeイベント。POSIXtime(すなわち、1970年1月1日午前0時00分00秒UTCからの秒数)。uncertainty省略された場合、unknownとして解釈されます。完全に確実な予測を指定するには、そのuncertainty性を0に設定します。StopTimeUpdate¶trip所定の停留所のarrival/またはdepartureイベントに関するリアルタイム更新。更新は過去と未来の両方のイベントに対して供給することができる。プロデューサは、必須ではありませんが、過去のイベントを削除することができます。更新はstop_sequenceまたはstop_id特定のストップにリンクされるので、これらのフィールドのいずれかが必ず設定されなければならない。stop_sequenceが提供される必要があります。対応するGTFSフィードのstop_times.txt同じである必要があります。stop_sequence、同じstop_id2回以上訪れるトリップ(例:ループ)において、どの停留所の予測なのかを曖昧にしないために必要とされます。stop_sequenceは入力されていなければならない。対応するGTFSフィードのstops.txt同じである必要があります。StopTimeUpdateでは、stop_sequenceとstop_idのどちらかを指定する必要があります。StopTimeProperties.assigned_stop_idが入力されている場合は、省略することが望ましい。stop_idのみを使用します。stop_idと一致しなければなりません。両フィールドをEMPTYすることはできません。departure両方ともEMPTYなる可能性があります。EMPTYでなければなりません。両フィールドともEMPTYすることはできません。departure両方ともEMPTYすることができます。EMPTYでなければなりません。指定された停留所からdepartureした直後のvehicle予測される乗客の占有状況。提供する場合、stop_sequenceを指定する必要がある。リアルタイムのarrivalまたはdeparture予測を提供せずにdeparture_occupancy_status提供するために、このフィールドを入力し、StopTimeUpdate設定します。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。デフォルトの関係はSCHEDULEDである。stop_times.txt内で定義された特定のプロパティに対するリアルタイム更新。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。ScheduleRelationship¶このStopTimeと静的スケジュールとの関係。vehicle静的な停車スケジュールに従って進行しているが、必ずしもスケジュールの時間通りに進行している必要はない。デフォルトの動作である。departure少なくとも一方は提供されなければならない。0)はSCHEDULED値を持つべきではなく、UNSCHEDULEDを代わりに使用する必要がある。この停留所はSKIPPEDであり、vehicleこの停留所には停車しない。SKIPPEDを持たない限り、delay停車駅に停車する)。_する_を越えて伝搬する。SKIPPEDとなる。SKIPPEDが設定されていない場合、その上流の予測は、その停車駅の後の停車駅に伝搬されます。SKIPPEDが設定されるまで、その停留所以降の停留所に伝搬される。stop_time_updateが設定されるまで、その停車駅の上流にある予測は、その停車駅の次の停車駅に伝播します。この停留所のデータは与えられていない。これは、利用可能なリアルタイムのタイミング情報がないことを示す。設定すると、後続の停留所に伝搬されるので、どの停留所からリアルタイムのタイミング情報がないかを指定する方法として推奨される。departureどちらも指定してはならない。トリップには、この値を使用してはならない。UNSCHEDULEDは、TripDescriptorも設定する必要があります。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。stop_times.txt内で定義された特定のプロパティに対するリアルタイム更新。注意:このmessageまだ実験的なものであり、変更される可能性がある。将来、正式に採用される可能性がある。リアルタイムの停止位置の割り当てをサポートします。assigned_stop_idは、endユーザーのtrip体験を大きく変えるものであってはならない。このフィールドは、プラットフォーム割り当てのために、次のようなものを使用することを意図している。stop_times.txt.リアルタイムのarrivalまたはdeparture予測を提供せずに停留所を割り当てるには、このフィールドに値を入力し、.NETを設定します。StopTimeUpdate.stop_idは入力してはならない。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。TripProperties¶trip更新されたプロパティを定義する注意:このmessageまだ実験的なものであり、変更される可能性がある。将来は正式に採用されるかもしれない。startする新しいtrip識別子を定義する。TripProperties.start_time).の定義をご参照ください。trips.trip_idの定義を参照してください。使用されている値とは異なるものでなければならない。場合、このフィールドは必須である。DUPLICATEDそれ以外の場合,このフィールドは入力してはならず,コンシューマはこのフィールドを無視します。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。trip実行されるサービス日。形式で提供されなければならない。このフィールドは以下の場合に必要である。DUPLICATEDそれ以外の場合、このフィールドは入力されてはならず、消費者によって無視される。実験的将来、正式に採用されるかもしれないし、変更されるかもしれない。それは将来、正式に採用されるかもしれない。