ルート更新情報

ルート更新情報を使って時刻表の変動を表します。運行スケジュールが作成されていてリアルタイム対応が可能なすべてのルートについて、ルート更新情報を Google に提供していただくことになります。これらの更新情報で、経路上の停留所での予想到着 / 発車時刻を提示します。また、ルートの運休または運行スケジュールへの追加、さらには経路変更など、より複雑な状況にも対応できます。

注: GTFS では、一定の時間に 2 回以上の停車を伴う移動行程をルートといいます。

運行スケジュールがある各ルートについて、ルート更新情報は多くても 1 つしか存在しません。運行スケジュールがあるルートにルート更新情報がない場合、そのルートにはリアルタイム データが存在しないこと以上の意味はなく、データ利用者はそのルートが定刻どおり運行されているものと思い込んではいけません。

停車時刻の更新情報

ルート更新情報は、車両の停車時刻の更新情報（複数可）で構成されます。この更新情報を StopTimeUpdate メッセージといいます。過去と未来の停車時刻を提供できますが、過去の停車時刻については省略することもできます（省略しなくてもかまいません）。ただし、過去の StopTimeUpdate が参照している停留所の運行スケジュールの到着時刻が未来の場合は（車両が予定より早く停留所を通過した場合など）、その情報を省略しないでください。そうしないと、この停留所の更新情報はひとつもない、ということになります。

たとえば、GTFS-rt フィードに次のデータが表示されたとします。

  • 停車地 4 - 午前 10 時 18 分と予測（時刻表では午前 10 時 20 分 - 2 分早め）
  • 停留所 5 - 午前 10 時 30 分と予測（運行スケジュールでは午前 10 時 30 分 - 定刻どおり）

... バスが実際に停留所 4 を通過した時刻が午前 10 時 18 分だった場合でも、午前 10 時 21 分まで、この停留所に関する予測をフィードから省略することはできません。午前 10 時 18 分または午前 10 時 19 分にフィードから停留所 4 の StopTimeUpdate が省略され、運行スケジュールの到着時刻が午前 10 時 20 分の場合、利用者は、その時点では停留所 4 に関するリアルタイムの情報がないものと見なして、GTFS の運行スケジュールのデータを使用することになります。

各 StopTimeUpdate は停留所と 1 対 1 で関連しています。通常は、GTFS の stop_sequence または GTFS の stop_id を使用して関連を設定できます。ただし、GTFS の trip_id を使用しないでルートの更新情報を提供する場合は、stop_sequence の値がないので必ず stop_id を指定してください。この stop_id は、GTFS の stop_id を参照する必要があります。1 つのルートで同じ stop_id に複数回停留する場合、そのルートのその stop_id について、すべての StopTimeUpdate メッセージに stop_sequence を指定する必要があります。

この更新情報では、StopTimeUpdate で StopTimeEvent を使用して、停留所の arrival または departure（あるいはその両方）について正確に時刻を提供することができます。その際、time（絶対時間）または delay（運行スケジュールの時刻との時間差（秒単位））を含める必要があります。delay フィールドを使用できるのは、ルート更新情報が参照する対象が、運転時隔ベースのルートではなく運行スケジュール ベースの GTFS のルートである場合に限ります。この場合の時刻は、運行スケジュールの時刻に遅延時間を足した値と等しくなります。さらに StopTimeEvent では、予測の不確かさを示す uncertainty を指定することもできます。詳しくは、このページの下の方にある不確実度のセクションをご覧ください。

どの StopTimeUpdate も、運行スケジュールとの関係のデフォルト値は scheduled です（これはルートについての運行スケジュールとの関係とは異なります）。この値は、停留所に停車しない場合は skipped に、ルートの一部にしかリアルタイム データがない場合は no data に変更できます。

更新情報は stop_sequence 順（またはルートでの出現順である stop_ids 順）に並べ替える必要があります。

ルートの 1 つ以上の停留所で StopTimeUpdate メッセージが欠落している場合も、更新情報は後続のすべての停留所に反映されます。つまり、ある停留所の停車時刻が更新されると、他の情報が欠落していても、後続のすべての停留所の停車時刻が同様に更新されます。

例 1

停留所が 20 か所あるルートについて、現在の停留所に関する StopTimeUpdate の stop_sequence で到着と発車の遅延時間（StopTimeEvent）が 0 の場合、定刻どおりに運行されていることを意味します。

例 2

上記と同じルートで、次の 3 つの StopTimeUpdate メッセージが指定されているとします。

  • stop_sequence 3 に対し 300 秒の遅延
  • stop_sequence 8 に対し 60 秒の遅延
  • stop_sequence 10 に対し遅延時間の指定なし

この指定は次のように解釈されます。

  • stop_sequence メッセージ 1、2 の遅延時間は不明である。
  • stop_sequence メッセージ 3、4、5、6、7 は 300 秒の遅延が発生している。
  • stop_sequence メッセージ 8、9 は 60 秒の遅延が発生している。
  • stop_sequence メッセージ 10〜20 の遅延時間は不明である。

ルート記述子

ルート記述子により提供される情報は、更新対象となるルートの運行スケジュールとの関係によって変わります。次に示すように、設定できるオプションはいくつかあります。

値 説明
Scheduled このルートは GTFS の運行スケジュール（またはそれとほぼ同じスケジュール）で進行しています。
Added このルートは元々予定されておらず追加されたものです。たとえば、需要に対応するためや、故障した車両の代わりとして、などの場合があります。
Unscheduled このルートは運行中ですが運行スケジュールはありません。たとえば、運行スケジュールのないシャトルバスの場合などです。
Canceled このルートには運行スケジュールがありましたが、現在は削除されています。

ほとんどの場合、この更新情報が関連する、運行スケジュールのある GTFS のルートの trip_id を指定する必要があります。

同じ trip_id 値を繰り返し使用するシステム

たとえば frequencies.txt を使用してモデル化するルート（運転時隔ベースのルート）など、同じ trip_id の値を繰り返し使用しているシステムの場合、trip_id に時間コンポーネントが欠けているため、それだけでは特定のルートの一意の識別子にはなりません。TripDescriptor でそうしたルートを一意に識別するには、次の 3 つ一組の識別子を使用する必要があります。

  • trip_id
  • start_time
  • start_date

start_time は最初に公開したものを継続して使用し、その後のフィードの更新情報で同じルートを参照する場合は、必ず同じ start_time を使用する必要があります。時刻の調整には StopTimeUpdate を使用します。start_time は最初の停留所からの発車時刻に正確に合わせる必要はありませんが、ずれは最小限に抑える必要があります。

たとえば、trip_id=T のルートを start_time=10:10:00 に出発することを 2015 年 5 月 25 日の 10 時に決定し、この情報をリアルタイム フィードで 10 時 1 分に送信するとします。そして、10 時 5 分の段階で、このルートの出発が 10 時 10 分ではなく 10 時 13 分に変わることが急に判明します。最新のリアルタイム フィードでは、このルートはまだ (T, 2015-05-25, 10:10:00) となっていますが、StopTimeUpdate を使用すれば、最初の駅からの発車が 10 時 13 分になることを通知できます。

代替ルートのマッチング

運転時隔ベースではないルートは、以下の組み合わせを含む TripDescriptor で一意に識別することもできます。

  • route_id
  • direction_id
  • start_time
  • start_date

ここでは、指定された ID の組み合わせでルートが識別される限り、start_time は静的な運行スケジュールで定義されている予定出発時刻です。

不確実度

不確実度は、StopTimeUpdate の時刻（time）と遅延時間（delay）のどちらの値にも適用されます。不確実度では、実際の遅延時間で予想される誤差を秒単位の整数で大まかに指定します（正確な統計的意味はまだ定義されていません）。コンピュータによる時間制御の下で運転されている列車の場合など、不確実度を 0 にすることも可能です。

一例として、ある長距離バスが次の停留所に 15 分遅れで到着すると予測され、その誤差が 4 分（つまりプラスマイナス 2 分）だとします。この場合の uncertainty の値は 240 となります。