From 49ec0b6c32d7b451b12c19d6de786bb28f620121 Mon Sep 17 00:00:00 2001 From: Sergio Delgado Rodriguez Date: Fri, 30 Aug 2024 10:22:45 -0400 Subject: [PATCH] Translate Technical Documentation section --- docs/ja/documentation/overview.md | 30 + .../change_history/recent_additions.md | 103 ++ .../change_history/revision_history.md | 118 ++ .../realtime/examples/migration-duplicated.md | 103 ++ .../realtime/examples/service-alerts.md | 80 ++ .../realtime/examples/trip-updates.md | 78 ++ .../realtime/feed_entities/overview.md | 52 + .../realtime/feed_entities/service-alerts.md | 64 + .../feed_entities/trip-modifications.md | 55 + .../realtime/feed_entities/trip-updates.md | 95 ++ .../feed_entities/vehicle-positions.md | 60 + .../realtime/gtfs-realtime.proto | 1191 +++++++++++++++++ .../realtime/language-bindings/dotnet.md | 28 + .../realtime/language-bindings/golang.md | 67 + .../realtime/language-bindings/java.md | 65 + .../realtime/language-bindings/nodejs.md | 62 + .../realtime/language-bindings/overview.md | 32 + .../realtime/language-bindings/php.md | 55 + .../realtime/language-bindings/python.md | 32 + .../realtime/language-bindings/ruby.md | 41 + docs/ja/documentation/realtime/proto.md | 1050 +++++++++++++++ .../realtime/realtime_best_practices.md | 157 +++ docs/ja/documentation/realtime/reference.md | 691 ++++++++++ .../change_history/recent_additions.md | 110 ++ .../change_history/revision_history.md | 323 +++++ .../schedule/examples/attributions.md | 26 + .../schedule/examples/continuous-stops.md | 68 + .../schedule/examples/fares-v1.md | 71 + .../schedule/examples/fares-v2.md | 422 ++++++ .../schedule/examples/feed-info.md | 21 + .../documentation/schedule/examples/flex.md | 343 +++++ .../schedule/examples/frequencies.md | 19 + .../schedule/examples/pathways.md | 137 ++ .../schedule/examples/routes-stops-trips.md | 139 ++ .../schedule/examples/text-to-speech.md | 48 + .../schedule/examples/transfers.md | 43 + .../schedule/examples/translations.md | 52 + docs/ja/documentation/schedule/reference.md | 861 ++++++++++++ .../schedule/schedule_best_practices.md | 321 +++++ 39 files changed, 7313 insertions(+) create mode 100644 docs/ja/documentation/overview.md create mode 100644 docs/ja/documentation/realtime/change_history/recent_additions.md create mode 100644 docs/ja/documentation/realtime/change_history/revision_history.md create mode 100644 docs/ja/documentation/realtime/examples/migration-duplicated.md create mode 100644 docs/ja/documentation/realtime/examples/service-alerts.md create mode 100644 docs/ja/documentation/realtime/examples/trip-updates.md create mode 100644 docs/ja/documentation/realtime/feed_entities/overview.md create mode 100644 docs/ja/documentation/realtime/feed_entities/service-alerts.md create mode 100644 docs/ja/documentation/realtime/feed_entities/trip-modifications.md create mode 100644 docs/ja/documentation/realtime/feed_entities/trip-updates.md create mode 100644 docs/ja/documentation/realtime/feed_entities/vehicle-positions.md create mode 100644 docs/ja/documentation/realtime/gtfs-realtime.proto create mode 100644 docs/ja/documentation/realtime/language-bindings/dotnet.md create mode 100644 docs/ja/documentation/realtime/language-bindings/golang.md create mode 100644 docs/ja/documentation/realtime/language-bindings/java.md create mode 100644 docs/ja/documentation/realtime/language-bindings/nodejs.md create mode 100644 docs/ja/documentation/realtime/language-bindings/overview.md create mode 100644 docs/ja/documentation/realtime/language-bindings/php.md create mode 100644 docs/ja/documentation/realtime/language-bindings/python.md create mode 100644 docs/ja/documentation/realtime/language-bindings/ruby.md create mode 100644 docs/ja/documentation/realtime/proto.md create mode 100644 docs/ja/documentation/realtime/realtime_best_practices.md create mode 100644 docs/ja/documentation/realtime/reference.md create mode 100644 docs/ja/documentation/schedule/change_history/recent_additions.md create mode 100644 docs/ja/documentation/schedule/change_history/revision_history.md create mode 100644 docs/ja/documentation/schedule/examples/attributions.md create mode 100644 docs/ja/documentation/schedule/examples/continuous-stops.md create mode 100644 docs/ja/documentation/schedule/examples/fares-v1.md create mode 100644 docs/ja/documentation/schedule/examples/fares-v2.md create mode 100644 docs/ja/documentation/schedule/examples/feed-info.md create mode 100644 docs/ja/documentation/schedule/examples/flex.md create mode 100644 docs/ja/documentation/schedule/examples/frequencies.md create mode 100644 docs/ja/documentation/schedule/examples/pathways.md create mode 100644 docs/ja/documentation/schedule/examples/routes-stops-trips.md create mode 100644 docs/ja/documentation/schedule/examples/text-to-speech.md create mode 100644 docs/ja/documentation/schedule/examples/transfers.md create mode 100644 docs/ja/documentation/schedule/examples/translations.md create mode 100644 docs/ja/documentation/schedule/reference.md create mode 100644 docs/ja/documentation/schedule/schedule_best_practices.md diff --git a/docs/ja/documentation/overview.md b/docs/ja/documentation/overview.md new file mode 100644 index 000000000..1fea3f0d3 --- /dev/null +++ b/docs/ja/documentation/overview.md @@ -0,0 +1,30 @@ +#General Transit Feed Specification(GTFS) + +General Transit Feed Specification(GTFS) は、交通システムに関する関連情報を乗客に配信するために使用される [オープン スタンダード](https:) です。これにより、公共交通事業者は、さまざまなソフトウェア アプリケーションで使用できる形式で交通データを公開できます。 + +GTFS は、[GTFS Schedule](../schedule/reference) と [GTFS Realtime](../realtime/reference) という 2 つの主要な部分で構成されています。 + +## [GTFS Schedule](../schedule/reference) + + GTFS Scheduleは、静的な公共交通機関情報の共通形式を定義するフィード仕様です。これは、単一の ZIP ファイルに含まれる、ほとんどがテキスト ファイル (.txt) である単純なファイルのコレクションで構成されています。 + +各ファイルは、停留所、ルート、旅行などの交通情報の特定の側面を記述します。最も基本的な形式では、 GTFS Scheduleデータセットは 7 つのファイルで構成されます: `agency.txt`、 `routes.txt`、 `trips.txt`、 `stops.txt`、 `stop_times.txt`、 `calendar.txt` 、および`calendar_dates.txt`ル` セットに加えて、追加の (オプションの) ファイルをグループ化して、運賃、翻訳、乗り換え、駅構内経路などの他のサービス要素の情報を提供することもできます。現在、GTFS の基本要素を拡張する 15 を超えるオプション ファイルがあり、その中には、地理的領域を表すために使用できるテキスト ファイル ( .txt ) 以外の新しい形式を導入したlocations.geojsonも含まれます。 + +すべてのGTFS Scheduleファイルの信頼できる情報源は、公式の [GTFS Scheduleリファレンス](../schedule/reference) です。このリファレンスには、 GTFS Scheduleデータセットを構成する各ファイルのすべての情報要素の要件に関する詳細情報が記載されています。 + + +## [GTFS Realtime](../realtime/reference) + + GTFS Realtimeは、公共交通機関が現在の到着時刻と出発時刻、サービス アラート、車両の位置に関する最新情報を提供できるようにするフィード仕様であり、ユーザーはスムーズに旅行を計画できます。 + +この仕様では現在、次の種類の情報がサポートされています。 + +- 旅行の更新 - 遅延、キャンセル、ルート変更 +- サービス アラート - 停留所の移動、駅、ルート、またはネットワーク全体に影響を及ぼす予期しないイベント +- 車両の位置 - 場所や混雑レベルなどの車両に関する情報 + +詳細については、[フィード エンティティ](../realtime/feed_entities/overview) セクションをご覧ください。 + + GTFS Realtimeは、実装の容易さ、優れたGTFS の相互運用性と乗客情報への重点。これは、[初期の Live Transit Updates](https://developers.google.com/transit/google-transit#LiveTransitUpdates) パートナー機関、多数の交通機関開発者、および Google のパートナーシップを通じて実現しました。仕様は [Apache 2.0 ライセンス](http://www.apache.org/licenses/LICENSE-2.0.html) に基づいて公開されています。 + +GTFSGTFS Realtimeデータ交換形式は [Protocol Buffers](https://developers.google.com/protocol-buffers/) に基づいています。これは、構造化データをシリアル化するための言語およびプラットフォームに依存しないメカニズムです (XML のようなものですが、より小さく、より高速で、よりシンプルです)。 GTFS Scheduleと同様に、[GTFS Realtimeリファレンス](../realtime/reference) は、あらゆるGTFS Realtimeフィードのルールと要件を確立する信頼できる情報源であり、[gtfs-realtime.proto](../realtime/proto) ファイルは、使用される要素の階層とそのタイプ定義を定義します。 diff --git a/docs/ja/documentation/realtime/change_history/recent_additions.md b/docs/ja/documentation/realtime/change_history/recent_additions.md new file mode 100644 index 000000000..17f145551 --- /dev/null +++ b/docs/ja/documentation/realtime/change_history/recent_additions.md @@ -0,0 +1,103 @@ +# GTFS Realtimeの変更 + +GTFSGTFS Realtimeリファレンスは固定されたものではありません。 GTFS Realtimeを使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。 GTFS Realtimeデータのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されていますGTFS Realtimeに貢献するには、[GTFS Realtime修正プロセス](../../../../community/governance/gtfs_realtime_amendment_process)を読み、GTFS Github リポジトリ ( google/transit ) の未解決の問題とプル リクエストでの議論に従ってください。 ![](../../../assets/mark-github.svg) + + + + + +## 最近採択された提案 + +最近統合された提案は、[公式GTFS Realtimeリファレンス](../../reference) の機能になりました。詳細については、完全な [改訂履歴](../revision_history) を参照してください。 + + +
+
+

旅行の変更を追加する

+

gcampによる#332 は 2024 年 3 月 11 日にマージされました

+
+
+
    +
  • 一連の旅行に影響する迂回路を説明するために使用される旅行変更を実験的な機能として追加します。
    • +
  • 旅行の変更により、特定の停車地をキャンセルしたり、旅行のタイミングを調整したり、旅行の新しい形を提供したり、途中の一時的な停車地の場所を提供したりすることができます。
    • +
+
+
+ +
+
+

schedule_relationship に DELETED 列挙型を追加します。

+

mads14による#332 は 2022 年 11 月 30 日に統合されました

+
+
+
    +
  • 新しい実験的なDELETED旅行スケジュール関係列挙型を追加します
    • +
  • これは、交通機関のプロバイダーが、公共向けアプリケーションから旅行を完全に消すことを意図していることを伝えるために使用できます。
    • +
+
+
+ +
+
+

アラートに cause_detail と effect_detail を追加する

+

mckenzie-maidl-ibigroupによる#332 は 2022 年 6 月 26 日にマージされました

+
+
+
    +
  • アラートの原因と影響の説明を追加します
    • +
+
+
+ +
+
+

GTFS-rt: 車椅子アクセスのアップデート

+

#340 by flaktackは 2022 年 7 月 25 日に統合されました

+
+
+
    +
  • 旅行のアクセシビリティに関するリアルタイム情報を追加
    • +
  • 指定されている場合、 GTFS Scheduleデータセットのtrips.wheelchair_accessibleを上書きします。
    • +
+
+
+ +
+
+

アラート内の機能/画像

+

gcampによる#283 は 2021 年 11 月 26 日にマージされました

+
+
+
    +
  • アプリのサービスアラートに表示される画像（写真や地図など）へのURLリンクのフィールドを追加し、アラートの理解度を高めます。
    • +
  • 変更内容: 画像のサイズ制限の強制、アラートごとに 1 つの画像、画像の内容や言語が変更された場合の URL の変更の保証
    • +
+
+
+ +
+
+

GTFS-NewShapes を実験的に追加

+

#272 by ericouyangは2021年8月30日に統合されました

+
+
+
    +
  • 迂回ルートを反映するためにルート形状をリアルタイムで更新する機能
    • +
  • ルートの更新は、既存のshape_id参照するか、エンコードされたポリラインとして新しいシェイプをリアルタイムで定義することによって反映されます。
    • +
+
+
+ +
diff --git a/docs/ja/documentation/realtime/change_history/revision_history.md b/docs/ja/documentation/realtime/change_history/revision_history.md new file mode 100644 index 000000000..b956cb1b2 --- /dev/null +++ b/docs/ja/documentation/realtime/change_history/revision_history.md @@ -0,0 +1,118 @@ +# GTFS Realtime### 改訂履歴 + +#### 2024 年 3 月 + +* 旅程変更を採用しました。[ディスカッション](https://github.com/google/transit/pull/403) を参照してください。 + +#### 2022 年 11 月 + +* 削除された旅程のサポートを追加しました。[ディスカッション](https://github.com/google/transit/pull/352) を参照してください。 + +#### 2022 年 7 月 + +* cause_detail と effect_detail を追加しました。[ディスカッション](https://github.com/google/transit/pull/332) を参照してください。 +* TripUpdate. VehicleDescriptorで wheels_accessible 値を指定できるようになりました。 [ディスカッション](https://github.com/google/transit/pull/340) を参照してください。 + +#### 2021 年 9 月 + +* アラートの機能/画像。[ディスカッション](https://github.com/google/transit/pull/283) を参照してください。 + +#### 2021 年 8 月 + +* GTFS-NewShapes を試験的に追加。[ディスカッション](https://github.com/google/transit/pull/272) を参照してください。 + +#### 2021 年 4 月 + +* TripUpdateに department_occupancy_status を追加します。[ディスカッション](https://github.com/google/transit/pull/260) を参照してください。 + +#### 2021 年 2 月 + +* GTFS Realtimeの乗車率の説明を明確化。 [ディスカッション](https:](https://github.com/google/transit/pull/237) を参照してください。 + +#### 2020 年 4 月 + +* 停留所の割り当てに対応しました。[ディスカッション](https://github.com/google/transit/pull/219) を参照してください。 + +#### 2020 年 7 月 + +* 重複した旅行に対応しました。[ディスカッション](https://github.com/google/transit/pull/221) を参照してください。 +* アラート tts_header_text、tts_description_text は試験運用ではなくなりました。 [ディスカッション](https://github.com/google/transit/pull/229) を参照してください。 +* GTFS-RT ADDED の旅行を、完全に指定されていないものとしてラベル付けします。[ディスカッション](https://github.com/google/transit/pull/230) を参照してください。 + +#### 2020 年 4 月 + +* SeverityLevel をfinal としてマークします。[ディスカッション](https://github.com/google/transit/pull/214) を参照してください。 +* occupancy_percentage を追加します。[ディスカッション](https://github.com/google/transit/pull/213) を参照してください。 + +#### 2020 年 3 月 12 日 + +* ブロック内の次の旅行についてTripUpdate予測を提供することを推奨します。 [ディスカッション](https://github.com/google/transit/pull/206) を参照してください。 + +#### 2019 年 8 月 + +* trip_updates はフィード内でブロック順に発生する必要がないことを文書化しました。[ディスカッション](https://github.com/google/transit/pull/176) を参照してください。 +* StopTimeUpdate. ScheduleRelationship UNSCHEDULED 値を追加します。[ディスカッション](https://github.com/google/transit/pull/173) を参照してください。 + +#### 2019 年 5 月 + +* アクセシビリティの問題アラート効果を追加します。[ディスカッション](https://github.com/google/transit/pull/164) を参照してください。 + +#### 2019 年 2 月 + +* GTFS リアルタイム サービス アラートに NO_EFFECT 効果オプションを追加します。 [ディスカッション](https://github.com/google/transit/pull/137) を参照してください。 +* Service Alerts フィードに新しいオプション フィールドSeverityLevelを追加します。[ディスカッション](https://github.com/google/transit/pull/136) を参照してください。 +* Service Alerts フィードにテキスト読み上げ機能用の新しいオプション フィールドを追加します。[ディスカッション](https://github.com/google/transit/pull/135) を参照してください。 + +#### 2018 年 4 月 + +* SCHEDULED ルートの stop_time_update 到着と出発の要件を削除します。[ディスカッション](https://github.com/google/transit/pull/165) を参照してください。 + +#### 2017 年 8 月 + +* GTFS リアルタイム フィールドのセマンティック カーディナリティを定義します。 [ディスカッション](https://github.com/google/transit/pull/64) を参照してください。 + +#### 2015 年 1 月 30 日 + +* 残りのすべての GTFS リアルタイム メッセージに Protocol Buffer 拡張名前空間を追加しました ( `FeedMessage`や`FeedEntity`など)。 + +#### 2015 年 1 月 28 日 + +* `TripUpdate`に試験的なフィールド`delay`を追加しました ([ディスカッション](https://groups.google.com/forum/#!topic/gtfs-realtime/NsTIRQdMNN8))。 + +#### 2015 年 1 月 16 日 + +* `TripDescriptor.start_time`の説明を更新しました。 + +#### 2015 年 1 月 8 日 + +* 試験的な列挙型`OccupancyStatus`を定義しました。 +* 試験的なフィールドを追加しました`occupancy_status`を`VehiclePosition`に変更しました ([ディスカッション](https://groups.google.com/forum/#!topic/gtfs-realtime/_HtNTGp5LxM))。 + +#### 2014 年 5 月 22 日 + +* `StopTimeUpdate`messageの`ScheduleRelationship`列挙型の説明を更新しました ([ディスカッション](https://groups.google.com/forum/#!topic/gtfs-realtime/77c3WZrGBnI))。 +* `TripDescriptor`messageの`ScheduleRelationship`ら` REPLACEMENT を削除しました ([ディスカッション](https://groups.google.com/forum/#!topic/gtfs-realtime/77c3WZrGBnI))。 + +#### 2014 年 10 月 12 日2012 + +* `TripUpdate`プ` フィールドを追加しました。 + +#### 2012 年 5 月 30 日 + +* 仕様に拡張機能に関する具体的な詳細を追加しました。 + +#### 2011 年 11 月 30 日 + +* 仕様の拡張機能の記述を容易にするため、主要な GTFS リアルタイム メッセージに Protocol Buffer 拡張名前空間を追加しました。 + +#### 2011 年 10 月 25 日 + +* `alert`、 `header_text` 、 `description_text`ン` テキスト値であることを明確化するためにドキュメントを更新しました。 + +#### 2011 年 8 月 20 日 + +* `TimeRange`messageのセマンティクスを明確にするためにドキュメントを更新しました。 + +#### 2011 年 8 月 22 日 + +* 初期バージョン。 \ No newline at end of file diff --git a/docs/ja/documentation/realtime/examples/migration-duplicated.md b/docs/ja/documentation/realtime/examples/migration-duplicated.md new file mode 100644 index 000000000..65d6df828 --- /dev/null +++ b/docs/ja/documentation/realtime/examples/migration-duplicated.md @@ -0,0 +1,103 @@ +## 移行ガイド - ADDED から DUPLICATED の旅行への移行 + +GTFS リアルタイムの `trip.schedule_relationship` の`DUPLICATED`は、サービス開始dateを除いて既存のスケジュールされた旅行と同じ新しい旅行を表します。 + +この移行ガイドでは、重複した旅行を表すために`ADDED`列挙を使用していた既存のプロデューサーとコンシューマーが`DUPLICATED`列挙に移行する方法を定義します。目標は、移行中にプロデューサーとコンシューマーの混乱を最小限に抑えることです。 + +*重複した旅行を記述するために`ADDED`列挙を **使用していない** プロデューサーまたはコンシューマーの場合、アクションは必要ありません。`ADDED` エンティティを生成/消費することなく、 `ADDED` `DUPLICATED`旅行を生成/消費できます。* + +`DUPLICATED` 列挙の完全な履歴については、[GitHub の`DUPLICATED` `DUPLICATED`提案](https://github.com/google/transit/pull/221) を参照してください。 + +### 同じフィードでの ADDED エンティティと DUPLICATED エンティティの使用 + +#### プロデューサー + +重複した旅行に`ADDED`列挙を使用しているプロデューサーの場合、既存のコンシューマーの混乱を避けるため、これらの旅行に対して`ADDED`エンティティを生成し続けながら、同じ旅行に対して`DUPLICATED`エンティティも追加することをおすすめします。 + +ただし、ユーザーが誤って同じ旅行を 2 回追加するのを防ぐために、同じ旅行を参照するエンティティは同じ`trip_id`を使用してリンクされている必要があります。2 つのエンティティは、次の 2 つの方法のいずれかでリンクできます。 + + 1.両方のエンティティの `trip.trip_id` が同じである必要があります。または + 2. `ADDED`旅行の `trip.trip_id ` は、 `DUPLICATED`旅行の `trip_properties.trip_id` と同じである必要があります。 + +以下は、GTFS `d` 1` を `trip.trip_id ` で複製する最初のオプション (1) の例です。 `ADDED`および`DUPLICATED`エンティティのtrip_id ` の一致: + +~~~ +entity { + id: "ei0" + trip_update { + trip: { + trip_id: "1"//<-- 静的 GTFS からのtrip_idをコピー + schedule_relationship: ADDED + start_date: "20200821"//<-- 新しい旅行date + start_time: "11:30:00"//<-- 新しい旅行時刻 + } + stop_time_update { +... + } + } +} + +entity { + id: "ei10" + trip_update { + trip: { + trip_id: "1"//<-- 静的 GTFS からのtrip_idをコピー + schedule_relationship: DUPLICATED + } + trip_properties { + trip_id: "NewTripId987"//<-- この旅行に固有の新しいtrip_id : "20200821"//<-- 新しい旅行date + start_time: "11:30:00"//<-- 新しい旅行時刻 + } + stop_time_update { +... + } + } +} +~~~ + +以下は、GTFS `d` 1` を複製する 2 番目のオプション (2) の例です。`ADDED` 旅行の `trip.trip_idは、 `ADDED` `DUPLICATED`旅行の `s`. と一致します。 trip_id`: + +~~~ +entity { + id: "ei0" + trip_update { + trip: { + trip_id: "NewTripId987"//<-- このtrip_idに固有の新しい trip_id + schedule_relationship: ADDED + start_date: "20200821"//<-- 新しい旅行date + start_time: "11:30:00"//<-- 新しい旅行時刻 + } + stop_time_update { +... + } + } +} + +entity { + id: "ei10" + trip_update { + trip: { + trip_id: "1"//<-- コピーする静的 GTFS のtrip_id : DUPLICATED + } + trip_properties { + trip_id: "NewTripId987"//<-- ADDED の旅行と一致します。 trip_id + start_date: "20200821"//<-- 新しい旅行date + start_time: "11:30:00"//<-- 新しい旅行時刻 + } + stop_time_update { +... + } + } +} +~~~ + +重複した旅行に対する`ADDED`の使用は設定された期限までに廃止されるため、代わりに`DUPLICATED` の旅行を使用するように既存の消費者に通知することをお勧めします (開発者のメーリング リストなどを通じて) `ADDED`と`DUPLICATED`の旅行エンティティを一致させるために使用されている上記の戦略についても言及し、この移行ガイドへのリンクを含める必要があります。期限が過ぎると、フィードから`ADDED` `ADDED`エンティティを削除し、重複した旅行の`DUPLICATED`エンティティのみを公開できます。 + +#### コンシューマー + +前述のように、プロデューサーは、エンティティ間の ID を一致させるために上記の 2 つのオプションのいずれかを使用して、最初に各重複旅行の 2 つのエンティティを公開することにより、 `ADDED`列挙から ` `DUPLICATED`列挙に移行します。 + +したがって、コンシューマーが`DUPLICATED`旅行のサポートを実装する場合、コンシューマーが次の点に注意することが重要です。 + + 1. `DUPLICATED`旅行 `trip.trip_id ` + 1. `DUPLICATED`旅行 `trip_properties.trip_id `を持つ`ADDED`旅行を無視します。 \ No newline at end of file diff --git a/docs/ja/documentation/realtime/examples/service-alerts.md b/docs/ja/documentation/realtime/examples/service-alerts.md new file mode 100644 index 000000000..5701ce6bb --- /dev/null +++ b/docs/ja/documentation/realtime/examples/service-alerts.md @@ -0,0 +1,80 @@ +# サービスアラート + +次の例は、アラートフィードの ASCII 表現です。 + +```python#ヘッダー情報 +header { +# 速度仕様のバージョン。現在は`2.0`です。有効なバージョンは`2.0`、`1.0`です。 + gtfs_realtime_version: `2.0` + +# データセットが増分か完全かを決定します + incrementality: FULL_DATASET#このデータセットがサーバー上で生成された時刻 +# アラート フィードのシーケンスを決定するためのもの + timestamp: 1284457468 +} +# フィードには複数のエンティティを含めることができます +entity { +# エンティティの一意の識別子 + id: `0` + +# エンティティの`タイプ` + alert { + # アラートがアクティブな場合は複数の期間を定義できます + active_period { + # POSIX エポック形式の開始時刻 + start: 1284457468#POSIX エポック形式の終了時刻 + end: 1284468072 + } + # 影響を受ける GTFS エンティティを選択します + informed_entity { + # 有効なパラメータ: + # agency_id、 route_id、route_type、stop_id、trip ( TripDescriptorを参照) + route_id: "219" + } + # 1 つのアラート エンティティに複数のセレクター (informed_entity) を含めることができます + informed_entity { + stop_id: "16230" + } + # 1 つの informed_entity に複数のフィールドを含めることができます + informed_entity { + stop_id: "16299" + route_id: "100" + # この例では、ルート 100 のストップ 16299 を意味します。 + # これは、ルート 100 の他のストップやストップ 16299 の他のルートには適用されません。 + } + + # アラートの原因 - 有効な値については gtfs-realtime.proto を参照してください + cause: CONSTRUCTION#アラートの影響 - を参照してください有効な値については gtfs-realtime.proto を参照してください + effect: DETOUR#指定された URL は追加情報を提供します + url { + # 複数の言語/翻訳がサポートされています + translation { + # Google の外部でホストされているページ（プロバイダ/代理店など） + text: "http://www.sometransitagency/alerts" + language: "en" + } + } + + # アラートのヘッダーが強調表示されます + header_text { + # 複数の言語/翻訳がサポートされています + translation { + text: "Stop at Elm street is closed, temporary stop at Oak street" + language: "en" + } + } + + # アラートの説明。ヘッダーテキストへの追加情報 + description_text { + # 複数の言語/翻訳がサポートされています + translation { + text: "エルム ストリートの工事のため、停留所は閉鎖されています。臨時停留所は、300 メートル北のオーク ストリートにあります" + language: "en" + } + } + } +} +``` + + + diff --git a/docs/ja/documentation/realtime/examples/trip-updates.md b/docs/ja/documentation/realtime/examples/trip-updates.md new file mode 100644 index 000000000..eb3da5800 --- /dev/null +++ b/docs/ja/documentation/realtime/examples/trip-updates.md @@ -0,0 +1,78 @@ +# 旅行更新 + +次の例は、完全なデータセットの旅行更新フィードを表す ASCII 表現です。 + +```python#ヘッダー情報 +header { +# 速度仕様のバージョン。現在は`2.0`です。有効なバージョンは`2.0`、`1.0`です。 + gtfs_realtime_version: `2.0` +# データセットが増分か完全かを決定します + incrementality: FULL_DATASET#このデータセットがサーバー上で生成された時刻 + timestamp: 1284457468 +} + +# フィードには複数のエンティティを含めることができます +entity { +# エンティティの一意の識別子 + id: `simple-trip` + +# エンティティの`タイプ` + trip_update { + trip { + # 影響を受ける GTFS エンティティ (旅行) を選択します + trip_id: `trip-1` + } + # スケジュール情報の更新 + stop_time_update { + # 影響を受ける停留所を選択します + stop_sequence : 3#車両の到着時間 + arrival { + # 5 秒遅延します + delay: 5 + } + } + #...この車両の遅延は、後続の停車駅に伝播します。 + + # 車両のスケジュールに関する次の情報更新 + stop_sequence { + # stop_sequenceによって選択されます。車両の元の (予定) 到着時刻が + arrival { + # 1 秒の遅延で更新されます。 + delay: 1 + } + } + #...同様に、遅延は後続の停車駅に伝播します。 + + # 車両のスケジュールに関する次の情報更新 + stop_time_update { + # stop_sequenceによって選択されます。車両の到着時刻 + stop_sequence: 10#をデフォルトの遅延 0 (定刻) で更新し、この更新を車両の残りの停車地に伝播します + } + } +} + +# 別の旅行の更新情報を含む 2 番目のエンティティ +entity { + id: "3" + trip_update { + trip { + # 頻度ベースの旅行は、GTFS のtrip_idによって定義され + trip_id: "frequency-expanded-trip" + # start_time + start_time: "11:15:35" + } + stop_time_update { + stop_sequence: 1 + arrival { + # 負の遅延は、車両がスケジュールより 2 秒進んでいることを意味します + delay: -2 + } + } + stop_time_update { + stop_sequence: 9 + } + } +} +``` + + diff --git a/docs/ja/documentation/realtime/feed_entities/overview.md b/docs/ja/documentation/realtime/feed_entities/overview.md new file mode 100644 index 000000000..b87d7adca --- /dev/null +++ b/docs/ja/documentation/realtime/feed_entities/overview.md @@ -0,0 +1,52 @@ +# フィード エンティティ + + GTFS Realtimeは、単一のリアルタイム フィードに組み合わせることができる 4 つの異なるタイプのリアルタイム データをサポートしています。概要は以下に記載されており、詳細なドキュメントは関連セクションに記載されています。 + +## ルート更新 + +#### `ス` X は 5 分遅れています` + +ルート更新は時刻表の変動を表します。スケジュールされているルートのうちリアルタイム対応のルート更新はすべて受信されるものと想定されます。これらの更新により、ルート上の停留所の到着または出発が予測されます。 +トリップ更新では、トリップがキャンセルされたり、スケジュールに追加されたり、ルートが変更されたりするような、より複雑なシナリオにも対応できます。 + +[トリップ更新の詳細...](../trip-updates) + +## サービス アラート + +#### `駅` Y は工事のため閉鎖されています` + +サービス アラートは、特定のエンティティに関する高レベルの問題を表し、通常は混乱のテキスト説明の形式です。 + +次の問題を表すことができます: + +* 駅 +* 路線 +* ネットワーク全体 +* など。 + +サービス アラートは通常、問題を説明するテキストで構成され、詳細情報の URL や、このサービス アラートが誰に影響するかを理解するのに役立つより構造化された情報も使用できます。 + +[サービス アラートの詳細...](../service-alerts) + +## 車両の位置 + +#### `刻` Y に位置 X にいる" + +車両の位置は、ネットワーク上の特定の車両に関するいくつかの基本的な情報を表します。 + +最も重要なのは、車両が現在いる緯度と経度ですが、車両の現在の速度とオドメーターの読み取り値のデータも使用できます。 + +[車両Positionの更新の詳細...](../vehicle-positions) + +## ルートの変更 + +#### `これらのルートは、特定の日に迂回によって影響を受けます` + +ルートの変更は、一連のルートに影響する迂回を説明するために使用されます。 + +ルートの変更により、特定の停車地をキャンセルしたり、ルートのタイミングを調整したり、ルートの新しい形状を提供したり、途中の一時的な停車地の場所を提供したりできます。 + +[ルートの変更の詳細...](../trip-modifications) + +## フィード タイプに関する過去のコメントGTFS Realtime仕様の初期のバージョンでは、各フィードに 1 種類のエンティティのみを含める必要がありました。マージされたスキーマから +feed-per-type スキーマに変換するサンプル ツールは、Bliksem Labs [gtfsrt-examples](https:) GitHub リポジトリにあります。 \ No newline at end of file diff --git a/docs/ja/documentation/realtime/feed_entities/service-alerts.md b/docs/ja/documentation/realtime/feed_entities/service-alerts.md new file mode 100644 index 000000000..33fa48fa8 --- /dev/null +++ b/docs/ja/documentation/realtime/feed_entities/service-alerts.md @@ -0,0 +1,64 @@ +# サービスアラート + +サービスアラートを使用すると、ネットワークに混乱が生じたときに更新情報を提供できます。個々の旅行の遅延やキャンセルは、通常、[旅行の更新情報](../trip-updates)を使用して通信する必要があります。 + +次の情報を提供するオプションがあります: + +* URL- アラートの詳細を説明するサイトへのリンク +* ヘッダーテキスト - アラートの概要 +* 説明 - アラートの完全な説明。常にヘッダーと一緒に表示されます (この情報を繰り返さないでください)。 + +##TimeRange + +アラートは、指定された時間範囲内の適切な場所に表示されます。この範囲は、乗客がアラートを確認するのに役立つ時間全体をカバーする必要があります。 + +時間が指定されていない場合は、フィードにある限りアラートが表示されます。複数の範囲が指定されている場合は、それらすべての期間にわたって表示されます。 + +## EntitySelector + +エンティティ セレクタを使用すると、このアラートがネットワークのどの部分に影響するかを正確に指定できるため、ユーザーに最も適切なアラートのみを表示できます。複数のエンティティに影響するアラートには、複数のエンティティ セレクタを含めることができます。 + +エンティティは GTFS 識別子を使用して選択され、次のいずれかを選択できます。 + +* 事業者 - ネットワーク全体に影響します +* Route- ルート全体に影響します +* Route type- このタイプのすべてのルートに影響します。例: すべての地下鉄。 +* Trip- 特定の旅行に影響します +* Stop- 特定の停留所に影響します + +1 つの`informed_entity`に上記のフィールドを複数含めることができます。1 つの`informed_entity`に複数のフィールドを含める場合は、 `AND`論理演算子で結合されていると解釈する必要があります。つまり、アラートは、 `informed_entity`で提供されるすべてのフィールドを満たすコンテキストでのみ適用する必要があります。たとえば、 `route_id: "1"`と`stop_id: "5"`が` 1 つの`informed_entity`に含まれている場合、アラートはルート 1 の停留所5.にのみ適用されます。ルート 1 の他の停留所には適用しないでください。また、停留所5.の他のルートにも適用しないでください。 + +複数のエンティティに影響するアラートを表現する場合 (例: ルート 1 と停留所 5 の両方に対するアラート) は、 `alert`に複数の`informed_entity`を追加し、それぞれが影響を受けるエンティティに適用されます (例: ルート 1 を含む`informed_entity`と、停留所 5 を含む別の`informed_entity` )。 + +## 原因 + +このアラートの原因は何ですか?次のいずれかを指定できます: + +* 原因不明 +* その他の原因(これらのオプションのいずれにも該当しない) +* 技術的な問題 +* ストライキ +* デモ +* 事故 +* 休日 +* 天候 +* メンテナンス +* 工事 +* 警察活動 +* 医療上の緊急事態 + +## 影響 + +この問題は指定されたエンティティにどのような影響を与えますか? 次のいずれかを指定できます: + +* サービスなし +* サービス削減 +* 大幅な遅延(軽微な遅延は[旅程の更新](../trip-updates)を通じてのみ提供されます)。 +* 迂回 +* 追加サービス +* サービス変更: 運行は、乗客が通常期待するものとは異なります。一例として、その曜日の通常のサービスとは異なる今後の休日スケジュールを乗客に通知するアラートが挙げられます。 +* 停留所の移動 +* その他の影響（これらのオプションのいずれにも該当しない） +* 影響不明 +* 影響なし: アラートは乗客に情報を提供しますが、運営には影響しません。例としては、公開会議の宣伝やアンケートによるフィードバックの募集などがあります。 +* アクセシビリティの問題: アラートは、段差のないアクセスに影響するアクセシビリティの問題に関する情報を提供します。例としては、使用できないエレベーターや可動式スロープなどがあります。 diff --git a/docs/ja/documentation/realtime/feed_entities/trip-modifications.md b/docs/ja/documentation/realtime/feed_entities/trip-modifications.md new file mode 100644 index 000000000..b0cd1db77 --- /dev/null +++ b/docs/ja/documentation/realtime/feed_entities/trip-modifications.md @@ -0,0 +1,55 @@ +# 旅行の変更`TripModifications`messageは、迂回などの特定の変更の影響を受ける (CSV) GTFS からの類似の`trip_ids`のリストを識別します。 + +

**注意:**このエンティティはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +## SLO: サービス レベル目標 + +データ更新の頻度は、約 1 時間ごと (1 日あたり約 24 回) になると予想されます。取り込み時間は、影響を受ける旅行の合計数によって異なる場合があります。コンシューマーは、1 つの TripModification を 5 分以内に、数百の迂回を含むフィードを 20 分以内に取り込むことが期待されます。 + +## TripModifications `TripModifications` は、フィードから削除されるまで、リストされているすべての service\_dates で有効です。特定のサービスdateでは、旅行を複数の`TripModifications`オブジェクトに割り当てるしてはいけない。 + +特定の停車パターンには、複数の`TripModifications` が存在するしてもよいます。迂回中に `propagated_modification_delay` が大幅に変更される場合など、旅程を複数の変更に分割することが望ましい場合があります。 + +GTFS- TripModificationsを通じて作成された旅程は、指定された各`trip_id`を変更して置き換え、コピーや追加の運行は作成しません。変更は、静的な GTFS (CSV) が変更された場合と同様に、スケジュール情報に適用されます。 + +各代替旅程の予定停車時刻は、変更にリストされている変更を実行することで、影響を受ける旅程の予定停車時刻から作成されます。すべての停車時刻の`stop_sequence` は、最初の stop_time の 1 から始まり、旅程内の停車ごとに 1 ずつ増加する、 1 ～ nの新しい値に置き換えられます。代替旅程のリアルタイムの到着/出発時刻を公開するには、 `TripUpdate`messageを提供する必要があります。 + + +## TripUpdates へのリンク + +* TripUpdateは、TripUpdate の`TripDescriptor`内の `ModifiedTripSelector` を使用して提供するするべきである。 + * TripUpdateが代替旅程を参照する場合、コンシューマーは、静的 GTFS がTripModifications (代替停車地の`arrival_time`、 `departure_time`、 `stop_sequence`、 `stop_id`など) で変更されたかのように動作する必要があります。 + * `ModifiedTripSelector` を提供する場合、 `TripDescriptor`の他のフィールドは空のままにして、`ModifiedTripSelector` 値を探していないコンシューマーによる混乱を避けるしなければならない。 + * `ModifiedTripSelector` で更新情報を提供するTripUpdateフィードには、 TripModificationsをサポートしていないクライアントを対象とするTripUpdateも含めるするべきである。つまり、2 つの TripUpdate が必要です。1 つは変更された旅程を持つクライアント用 ( `TripModifications`あり)、もう 1 つは元の変更されていない GTFS を持つクライアント用 ( `TripModifications`なし) です。 + * `ModifiedTripSelector` でTripUpdateを提供することが、代替の停車地で予測を作成する唯一の方法です。 +* このようなTripUpdateが見つからない場合は、元の`trip_id`の` TripUpdate が変更された旅程に適用されます。 + * この場合、使用される静的 GTFS 情報は、 TripModificationsが適用される前の静的 GTFS からのものである必要があります。 + * 前の旅程と新しい変更された旅程の共通の停車地では、リアルタイムの情報を利用できます。ただし、代替の停車地では到着予定時刻は利用できません。 + +##Modification + +`Modification`messageは、`start_stop_selector` から始まる、影響を受ける各旅行への変更を説明します。`Modification` によって置き換えられる停車時間は、0、1、または 1 個以上である可能性があります。変更の範囲は重複してはなりません。範囲は連続していてはしなければならないません。この場合、2 つの変更は 1 つにマージされるしなければならない。これらの停車時刻は、 `replacement_stops` によって記述される代替の停車地ごとに新しい停車時間に置き換えられます。 + +`replacement_stops` のシーケンスは任意の長さにすることができます。たとえば、状況に応じて、3 つの停車地を 2 つ、4 つ、または 0 つの停車地に置き換えることができます。 + +![](/../assets/trip_modification.png) + +特定の旅行に対する変更の効果を示す例。この変更は、他の複数の旅行にも適用される場合があります。_ + +![](/../assets/propagated_delay.png) + +伝播された迂回遅延は、変更の終了後にすべての停車地に影響します。旅行に複数の変更がある場合、遅延は累積されます。_ + +## ReplacementStop + +各`ReplacementStop``ReplacementStop`は、旅行で訪問する停車地を定義し、オプションで停車地までの推定移動時間を指定します。`ReplacementStop`messageは、停車地のスケジュールされた`stop_time`を作成するために使用されます。 + +`travel_time_to_stop` が指定されている場合、 `arrival_time`は元の旅行の参照停車地から計算され、`travel_time_to_stop` のオフセットが加算されます。それ以外の場合は、元の旅程の変更の合計所要時間に基づいて`arrival_time`を補間できます。 + +`departure_time`は常に`arrival_time`と同じです。 + +(CSV) GTFS 仕様の [`stop_times.txt`](../../../schedule/reference/#stop_timestxt) のオプション フィールドはすべてデフォルト値に設定されています。 + +![](/../assets/first_stop_reference.png) + +変更が旅程の最初の停車地に影響する場合、その停車地は変更の参照停車地としても機能します。_ diff --git a/docs/ja/documentation/realtime/feed_entities/trip-updates.md b/docs/ja/documentation/realtime/feed_entities/trip-updates.md new file mode 100644 index 000000000..dcbb85696 --- /dev/null +++ b/docs/ja/documentation/realtime/feed_entities/trip-updates.md @@ -0,0 +1,95 @@ +# 旅程の更新 + +旅程の更新は時刻表の変動を表します。リアルタイム対応のスケジュールされたすべての旅程の更新を受け取ることを期待しています。これらの更新は、ルート上の停車地の到着または出発の予想時刻を提供します。旅程の更新は、旅程がキャンセルされたり、スケジュールに追加されたり、さらにはルートが変更されたりする、より複雑なシナリオにも対応できます。 + +**注意:** [GTFS](../../../schedule/reference) では、旅程とは特定の時間に発生する 2 つ以上の停車地のシーケンスです。 + +スケジュールされた旅程ごとに、**最大** 1 つの旅程更新が必要です。スケジュールされた旅程に旅程の更新がない場合は、その旅程のリアルタイム データは利用できないと判断されます。データ利用者は、旅程が時間どおりに運行されていると**想定してはなりません**。 + +車両が同じブロック内で複数の旅程を担当している場合 (旅程とブロックの詳細については、[GTFS trips.txt](../../../schedule/reference/#tripstxt) を参照してください): + +* フィードには、車両が現在担当している旅程のTripUpdateを含める必要があります。プロデューサーは、将来の旅程の予測の品質に自信がある場合は、この車両のブロック内の現在の旅程の後の 1 つ以上の旅程の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdate を含めると、車両が 1 つの旅程から別の旅程に移行する際に予測が突然表示されるのを回避できるほか、下流の旅程に影響する遅延 (例: 既知の遅延が旅程間の予定の乗り継ぎ時間を超える場合) を事前に乗客に通知できます。 +* それぞれのTripUpdateエンティティは、ブロック内でスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、1 つのブロックに属する`trip_ids` 1、2、3 のルートがあり、車両がルート 1、ルート 2、ルート 3 の順に走行する場合、 `trip_update`エンティティは任意の順序で表示できます。たとえば、ルート 2、ルート 1、ルート 3 の順で追加できます。 + +## StopTimeUpdate + +ルート更新は、車両の停車時刻に対する 1 つ以上の更新で構成されます。これは [StopTimeUpdates](../../reference/#message-stoptimeupdate) と呼ばれます。これらは、過去および将来の停車時刻に対して指定できます。過去の停車時刻を削除できますが、必須ではありません。プロデューサーは、過去の`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](../../reference/#message-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](../../reference/#message-stoptimeupdate) で [StopTimeEvent](../../reference/#message-stoptimeevent) を使用して、停車地での**arrival****departure**/または **出発** の正確なタイミングを提供できます。これには、絶対**time**または**delay** (つまり、予定時刻からの秒単位のオフセット) のいずれかを含める必要があります。遅延は、旅程更新が、頻度ベースの旅程ではなく、スケジュールされた GTFS 旅程を参照する場合にのみ使用できます。この場合、時間は予定時刻 + 遅延と等しくなります。 [StopTimeEvent](../../reference/#message-stoptimeevent) とともに予測の**uncertainty**を指定することもできます。これについては、ページの下にある [不確実性](#uncertainty) のセクションで詳しく説明します。 + +各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) について、デフォルトのスケジュール関係は **scheduled** です。(これは、旅行のスケジュール関係とは異なることに注意してください)。停車地で停車しない場合はこれを **スキップ** に変更できます。また、一部のルートにリアルタイム データしかない場合は **データなし** に変更できます。 + +**更新はstop_sequence** (またはルートで発生する順序の stop_id) で並べ替える必要があります。 + +ルートで 1 つ以上の停車地が欠落している場合は、更新による`delay` (または、更新で`time`のみが指定されている場合は、 `time`S` schedule時間を比較して計算された遅延) が、後続のすべての停車地に適用されます。つまり、特定の停車地の停車時刻を更新すると、他の情報がない場合、後続のすべての停車地が変更されます。スケジュール関係が`SKIPPED`の更新では遅延の伝播が停止されませんが、スケジュール関係が`SCHEDULED` (スケジュール関係が指定されていない場合のデフォルト値) または`NO_DATA` の更新では遅延の伝播が停止されることに注意してください。 + +**例 1** + +20 の停車地がある旅行の場合、現在のStopTimeUpdateのstop_sequenceに対して到着遅延と出発遅延が 0 ([StopTimeEvents](../../reference/#message-stoptimeevent)) である [StopTimeUpdate](../../reference/#message-stoptimeupdate) は、旅行が正確に時間どおりであることを意味します。 + +**例 2** + +同じ旅行インスタンスに対して、3 つの [StopTimeUpdates](../../reference/#message-stoptimeupdate) が提供されます: + +* stop_sequence 3 の遅延は 300 秒 +* stop_sequence 8 の遅延は 60 秒 +* [ScheduleRelationship](../../reference/#enum-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](../../reference/#message-stoptimeupdate) の時間と遅延値の両方に不確実性が適用されます。不確実性は、実際の遅延の予測誤差を秒単位の整数で大まかに指定します (ただし、正確な統計的意味はまだ定義されていません)。たとえば、コンピューターのタイミング制御で運転される列車の場合、不確実性が 0 になることがあります。 + +例として、次の停留所に 4 分間の誤差 (つまり +2/-2 分) 内で到着すると推定される遅延時間が 15 分の長距離バスの場合、不確実性の値は 240 になります。 diff --git a/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md b/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md new file mode 100644 index 000000000..567b19c4a --- /dev/null +++ b/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md @@ -0,0 +1,60 @@ +# 車両の位置 + +車両の位置は、車載 GPS デバイスなどから自動的に生成された車両の位置情報を提供するために使用されます。位置を提供できるすべての車両に対して、1 つの車両の位置を提供する必要があります。 + +車両が現在提供している旅程は、[TripDescriptor](../../reference/#message-tripdescriptor) で提供する必要があります。また、[VehicleDescriptor](../../reference/#message-vehicledescriptor) を提供して、更新情報を提供する正確な物理的な車両を指定することもできます。ドキュメントは以下にあります。 + +位置の読み取りが行われた時間を示す**timestamp**を提供できます。これは、サーバーによってこのmessageが生成された時間であるフィード ヘッダーのタイムスタンプとは異なることに注意してください。 + +**現在の通路** も提供できます ( `stop_sequence`または`stop_id`として)。これは、車両が向かっている、またはすでに停止している停止場所への参照です。 + +##Position + +Positionには、車両のPosition内の位置データが含まれます。緯度と経度は必須で、他のフィールドはオプションです。これらのデータの種類は次のとおりです。 + +* **緯度** - WGS-84 座標系での北度 +* **経度** - WGS-84 座標系での東度 +* **方位** - 車両が向いている方向 +* **走行距離計** - 車両が移動した距離 +* **速度** - 車両が測定した瞬間速度 (メートル/秒) + +##CongestionLevel + +車両の位置により、機関は車両が現在経験している混雑レベルを指定することもできます。混雑は、次のカテゴリに分類できます: + +* 混雑レベル不明 +* 順調に走行 +* ストップ アンド ゴー +* 混雑 +* 深刻な混雑 + +各タイプの混雑をどのように分類するかは、機関次第です。私たちのガイダンスでは、深刻な混雑は、交通が混雑しすぎて人々が車から降りる状況でのみ使用されます。 + +##OccupancyStatus + +車両の位置により、機関は車両の乗客の占有度を指定することもできます。占有状況は、次のカテゴリに分類できます: + +* 空席多数 +* 空席わずか +* 立ち見のみ +* 立ち見のみ混雑 +* 満席 +* 乗客を受け入れていません + +このフィールドはまだ**実験的**であり、変更される可能性があります。将来、正式に採用される可能性があります。 + +## VehicleStopStatus + +車両停止ステータスは、現在近づいている、または現在いる停止に関連して、車両のステータスにさらに意味を与えます。次のいずれかの値に設定できます。 + +* **Incoming at** - 車両は参照された停止に到着しようとしています +* **Stopped at** - 車両は参照された停止で停止しています +* **In transit to** - 参照された停止は車両の次の停止です - **default** + +## VehicleDescriptor + + VehicleDescriptor は正確な物理車両を記述し、次の属性のいずれかを含めることができます: + +* **ID** - 車両を識別するための内部システム。車両に一意である必要があります +* **Label** - ユーザーに表示されるラベル - たとえば、列車の名前 +* **License plate** - 車両の実際のナンバー プレート diff --git a/docs/ja/documentation/realtime/gtfs-realtime.proto b/docs/ja/documentation/realtime/gtfs-realtime.proto new file mode 100644 index 000000000..d3cfe5294 --- /dev/null +++ b/docs/ja/documentation/realtime/gtfs-realtime.proto @@ -0,0 +1,1191 @@ +// Copyright 2015 The GTFS Specifications Authors. +// +// Licensed under the Apache License, Version 2.0 (the "License"); +// you may not use this file except in compliance with the License. +// You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. + +// Protocol definition file for GTFS Realtime. +// +// GTFS Realtime lets transit agencies provide consumers with realtime +// information about disruptions to their service (stations closed, lines not +// operating, important delays etc), location of their vehicles and expected +// arrival times. +// +// This protocol is published at: +// https://github.com/google/transit/tree/master/gtfs-realtime + +syntax = "proto2"; +option java_package = "com.google.transit.realtime"; +package transit_realtime; + +// The contents of a feed message. +// A feed is a continuous stream of feed messages. Each message in the stream is +// obtained as a response to an appropriate HTTP GET request. +// A realtime feed is always defined with relation to an existing GTFS feed. +// All the entity ids are resolved with respect to the GTFS feed. +// Note that "required" and "optional" as stated in this file refer to Protocol +// Buffer cardinality, not semantic cardinality. See reference.md at +// https://github.com/google/transit/tree/master/gtfs-realtime for field +// semantic cardinality. +message FeedMessage { + // Metadata about this feed and feed message. + required FeedHeader header = 1; + + // Contents of the feed. + repeated FeedEntity entity = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// Metadata about a feed, included in feed messages. +message FeedHeader { + // Version of the feed specification. + // The current version is 2.0. Valid versions are "2.0", "1.0". + required string gtfs_realtime_version = 1; + + // Determines whether the current fetch is incremental. Currently, + // DIFFERENTIAL mode is unsupported and behavior is unspecified for feeds + // that use this mode. There are discussions on the GTFS Realtime mailing + // list around fully specifying the behavior of DIFFERENTIAL mode and the + // documentation will be updated when those discussions are finalized. + enum Incrementality { + FULL_DATASET = 0; + DIFFERENTIAL = 1; + } + optional Incrementality incrementality = 2 [default = FULL_DATASET]; + + // This timestamp identifies the moment when the content of this feed has been + // created (in server time). In POSIX time (i.e., number of seconds since + // January 1st 1970 00:00:00 UTC). + optional uint64 timestamp = 3; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// A definition (or update) of an entity in the transit feed. +message FeedEntity { + // The ids are used only to provide incrementality support. The id should be + // unique within a FeedMessage. Consequent FeedMessages may contain + // FeedEntities with the same id. In case of a DIFFERENTIAL update the new + // FeedEntity with some id will replace the old FeedEntity with the same id + // (or delete it - see is_deleted below). + // The actual GTFS entities (e.g. stations, routes, trips) referenced by the + // feed must be specified by explicit selectors (see EntitySelector below for + // more info). + required string id = 1; + + // Whether this entity is to be deleted. Relevant only for incremental + // fetches. + optional bool is_deleted = 2 [default = false]; + + // Data about the entity itself. Exactly one of the following fields must be + // present (unless the entity is being deleted). + optional TripUpdate trip_update = 3; + optional VehiclePosition vehicle = 4; + optional Alert alert = 5; + + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional Shape shape = 6; + optional Stop stop = 7; + optional TripModifications trip_modifications = 8; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// +// Entities used in the feed. +// + +// Realtime update of the progress of a vehicle along a trip. +// Depending on the value of ScheduleRelationship, a TripUpdate can specify: +// - A trip that proceeds along the schedule. +// - A trip that proceeds along a route but has no fixed schedule. +// - A trip that have been added or removed with regard to schedule. +// +// The updates can be for future, predicted arrival/departure events, or for +// past events that already occurred. +// Normally, updates should get more precise and more certain (see +// uncertainty below) as the events gets closer to current time. +// Even if that is not possible, the information for past events should be +// precise and certain. In particular, if an update points to time in the past +// but its update's uncertainty is not 0, the client should conclude that the +// update is a (wrong) prediction and that the trip has not completed yet. +// +// Note that the update can describe a trip that is already completed. +// To this end, it is enough to provide an update for the last stop of the trip. +// If the time of that is in the past, the client will conclude from that that +// the whole trip is in the past (it is possible, although inconsequential, to +// also provide updates for preceding stops). +// This option is most relevant for a trip that has completed ahead of schedule, +// but according to the schedule, the trip is still proceeding at the current +// time. Removing the updates for this trip could make the client assume +// that the trip is still proceeding. +// Note that the feed provider is allowed, but not required, to purge past +// updates - this is one case where this would be practically useful. +message TripUpdate { + // The Trip that this message applies to. There can be at most one + // TripUpdate entity for each actual trip instance. + // If there is none, that means there is no prediction information available. + // It does *not* mean that the trip is progressing according to schedule. + required TripDescriptor trip = 1; + + // Additional information on the vehicle that is serving this trip. + optional VehicleDescriptor vehicle = 3; + + // Timing information for a single predicted event (either arrival or + // departure). + // Timing consists of delay and/or estimated time, and uncertainty. + // - delay should be used when the prediction is given relative to some + // existing schedule in GTFS. + // - time should be given whether there is a predicted schedule or not. If + // both time and delay are specified, time will take precedence + // (although normally, time, if given for a scheduled trip, should be + // equal to scheduled time in GTFS + delay). + // + // Uncertainty applies equally to both time and delay. + // The uncertainty roughly specifies the expected error in true delay (but + // note, we don't yet define its precise statistical meaning). It's possible + // for the uncertainty to be 0, for example for trains that are driven under + // computer timing control. + message StopTimeEvent { + // Delay (in seconds) can be positive (meaning that the vehicle is late) or + // negative (meaning that the vehicle is ahead of schedule). Delay of 0 + // means that the vehicle is exactly on time. + optional int32 delay = 1; + + // Event as absolute time. + // In Unix time (i.e., number of seconds since January 1st 1970 00:00:00 + // UTC). + optional int64 time = 2; + + // If uncertainty is omitted, it is interpreted as unknown. + // If the prediction is unknown or too uncertain, the delay (or time) field + // should be empty. In such case, the uncertainty field is ignored. + // To specify a completely certain prediction, set its uncertainty to 0. + optional int32 uncertainty = 3; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features + // and modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + + // Realtime update for arrival and/or departure events for a given stop on a + // trip. Updates can be supplied for both past and future events. + // The producer is allowed, although not required, to drop past events. + message StopTimeUpdate { + // The update is linked to a specific stop either through stop_sequence or + // stop_id, so one of the fields below must necessarily be set. + // See the documentation in TripDescriptor for more information. + + // Must be the same as in stop_times.txt in the corresponding GTFS feed. + optional uint32 stop_sequence = 1; + // Must be the same as in stops.txt in the corresponding GTFS feed. + optional string stop_id = 4; + + optional StopTimeEvent arrival = 2; + optional StopTimeEvent departure = 3; + + // Expected occupancy after departure from the given stop. + // Should be provided only for future stops. + // In order to provide departure_occupancy_status without either arrival or + // departure StopTimeEvents, ScheduleRelationship should be set to NO_DATA. + optional VehiclePosition.OccupancyStatus departure_occupancy_status = 7; + + // The relation between the StopTimeEvents and the static schedule. + enum ScheduleRelationship { + // The vehicle is proceeding in accordance with its static schedule of + // stops, although not necessarily according to the times of the schedule. + // At least one of arrival and departure must be provided. If the schedule + // for this stop contains both arrival and departure times then so must + // this update. Frequency-based trips (GTFS frequencies.txt with exact_times = 0) + // should not have a SCHEDULED value and should use UNSCHEDULED instead. + SCHEDULED = 0; + + // The stop is skipped, i.e., the vehicle will not stop at this stop. + // Arrival and departure are optional. + SKIPPED = 1; + + // No StopTimeEvents are given for this stop. + // The main intention for this value is to give time predictions only for + // part of a trip, i.e., if the last update for a trip has a NO_DATA + // specifier, then StopTimeEvents for the rest of the stops in the trip + // are considered to be unspecified as well. + // Neither arrival nor departure should be supplied. + NO_DATA = 2; + + // The vehicle is operating a trip defined in GTFS frequencies.txt with exact_times = 0. + // This value should not be used for trips that are not defined in GTFS frequencies.txt, + // or trips in GTFS frequencies.txt with exact_times = 1. Trips containing StopTimeUpdates + // with ScheduleRelationship=UNSCHEDULED must also set TripDescriptor.ScheduleRelationship=UNSCHEDULED. + // NOTE: This field is still experimental, and subject to change. It may be + // formally adopted in the future. + UNSCHEDULED = 3; + } + optional ScheduleRelationship schedule_relationship = 5 + [default = SCHEDULED]; + + // Provides the updated values for the stop time. + // NOTE: This message is still experimental, and subject to change. It may be formally adopted in the future. + message StopTimeProperties { + // Supports real-time stop assignments. Refers to a stop_id defined in the GTFS stops.txt. + // The new assigned_stop_id should not result in a significantly different trip experience for the end user than + // the stop_id defined in GTFS stop_times.txt. In other words, the end user should not view this new stop_id as an + // "unusual change" if the new stop was presented within an app without any additional context. + // For example, this field is intended to be used for platform assignments by using a stop_id that belongs to the + // same station as the stop originally defined in GTFS stop_times.txt. + // To assign a stop without providing any real-time arrival or departure predictions, populate this field and set + // StopTimeUpdate.schedule_relationship = NO_DATA. + // If this field is populated, it is preferred to omit `StopTimeUpdate.stop_id` and use only `StopTimeUpdate.stop_sequence`. If + // `StopTimeProperties.assigned_stop_id` and `StopTimeUpdate.stop_id` are populated, `StopTimeUpdate.stop_id` must match `assigned_stop_id`. + // Platform assignments should be reflected in other GTFS-realtime fields as well + // (e.g., `VehiclePosition.stop_id`). + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string assigned_stop_id = 1; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features + // and modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + + // Realtime updates for certain properties defined within GTFS stop_times.txt + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional StopTimeProperties stop_time_properties = 6; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features + // and modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + + // Updates to StopTimes for the trip (both future, i.e., predictions, and in + // some cases, past ones, i.e., those that already happened). + // The updates must be sorted by stop_sequence, and apply for all the + // following stops of the trip up to the next specified one. + // + // Example 1: + // For a trip with 20 stops, a StopTimeUpdate with arrival delay and departure + // delay of 0 for stop_sequence of the current stop means that the trip is + // exactly on time. + // + // Example 2: + // For the same trip instance, 3 StopTimeUpdates are provided: + // - delay of 5 min for stop_sequence 3 + // - delay of 1 min for stop_sequence 8 + // - delay of unspecified duration for stop_sequence 10 + // This will be interpreted as: + // - stop_sequences 3,4,5,6,7 have delay of 5 min. + // - stop_sequences 8,9 have delay of 1 min. + // - stop_sequences 10,... have unknown delay. + repeated StopTimeUpdate stop_time_update = 2; + + // The most recent moment at which the vehicle's real-time progress was measured + // to estimate StopTimes in the future. When StopTimes in the past are provided, + // arrival/departure times may be earlier than this value. In POSIX + // time (i.e., the number of seconds since January 1st 1970 00:00:00 UTC). + optional uint64 timestamp = 4; + + // The current schedule deviation for the trip. Delay should only be + // specified when the prediction is given relative to some existing schedule + // in GTFS. + // + // Delay (in seconds) can be positive (meaning that the vehicle is late) or + // negative (meaning that the vehicle is ahead of schedule). Delay of 0 + // means that the vehicle is exactly on time. + // + // Delay information in StopTimeUpdates take precedent of trip-level delay + // information, such that trip-level delay is only propagated until the next + // stop along the trip with a StopTimeUpdate delay value specified. + // + // Feed providers are strongly encouraged to provide a TripUpdate.timestamp + // value indicating when the delay value was last updated, in order to + // evaluate the freshness of the data. + // + // NOTE: This field is still experimental, and subject to change. It may be + // formally adopted in the future. + optional int32 delay = 5; + + // Defines updated properties of the trip, such as a new shape_id when there is a detour. Or defines the + // trip_id, start_date, and start_time of a DUPLICATED trip. + // NOTE: This message is still experimental, and subject to change. It may be formally adopted in the future. + message TripProperties { + // Defines the identifier of a new trip that is a duplicate of an existing trip defined in (CSV) GTFS trips.txt + // but will start at a different service date and/or time (defined using the TripProperties.start_date and + // TripProperties.start_time fields). See definition of trips.trip_id in (CSV) GTFS. Its value must be different + // than the ones used in the (CSV) GTFS. Required if schedule_relationship=DUPLICATED, otherwise this field must not + // be populated and will be ignored by consumers. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string trip_id = 1; + // Service date on which the DUPLICATED trip will be run, in YYYYMMDD format. Required if + // schedule_relationship=DUPLICATED, otherwise this field must not be populated and will be ignored by consumers. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string start_date = 2; + // Defines the departure start time of the trip when it’s duplicated. See definition of stop_times.departure_time + // in (CSV) GTFS. Scheduled arrival and departure times for the duplicated trip are calculated based on the offset + // between the original trip departure_time and this field. For example, if a GTFS trip has stop A with a + // departure_time of 10:00:00 and stop B with departure_time of 10:01:00, and this field is populated with the value + // of 10:30:00, stop B on the duplicated trip will have a scheduled departure_time of 10:31:00. Real-time prediction + // delay values are applied to this calculated schedule time to determine the predicted time. For example, if a + // departure delay of 30 is provided for stop B, then the predicted departure time is 10:31:30. Real-time + // prediction time values do not have any offset applied to them and indicate the predicted time as provided. + // For example, if a departure time representing 10:31:30 is provided for stop B, then the predicted departure time + // is 10:31:30. This field is required if schedule_relationship is DUPLICATED, otherwise this field must not be + // populated and will be ignored by consumers. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string start_time = 3; + // Specifies the shape of the vehicle travel path when the trip shape differs from the shape specified in + // (CSV) GTFS or to specify it in real-time when it's not provided by (CSV) GTFS, such as a vehicle that takes differing + // paths based on rider demand. See definition of trips.shape_id in (CSV) GTFS. If a shape is neither defined in (CSV) GTFS + // nor in real-time, the shape is considered unknown. This field can refer to a shape defined in the (CSV) GTFS in shapes.txt + // or a Shape in the (protobuf) real-time feed. The order of stops (stop sequences) for this trip must remain the same as + // (CSV) GTFS. Stops that are a part of the original trip but will no longer be made, such as when a detour occurs, should + // be marked as schedule_relationship=SKIPPED. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string shape_id = 4; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features + // and modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + optional TripProperties trip_properties = 6; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// Realtime positioning information for a given vehicle. +message VehiclePosition { + // The Trip that this vehicle is serving. + // Can be empty or partial if the vehicle can not be identified with a given + // trip instance. + optional TripDescriptor trip = 1; + + // Additional information on the vehicle that is serving this trip. + optional VehicleDescriptor vehicle = 8; + + // Current position of this vehicle. + optional Position position = 2; + + // The stop sequence index of the current stop. The meaning of + // current_stop_sequence (i.e., the stop that it refers to) is determined by + // current_status. + // If current_status is missing IN_TRANSIT_TO is assumed. + optional uint32 current_stop_sequence = 3; + // Identifies the current stop. The value must be the same as in stops.txt in + // the corresponding GTFS feed. + optional string stop_id = 7; + + enum VehicleStopStatus { + // The vehicle is just about to arrive at the stop (on a stop + // display, the vehicle symbol typically flashes). + INCOMING_AT = 0; + + // The vehicle is standing at the stop. + STOPPED_AT = 1; + + // The vehicle has departed and is in transit to the next stop. + IN_TRANSIT_TO = 2; + } + // The exact status of the vehicle with respect to the current stop. + // Ignored if current_stop_sequence is missing. + optional VehicleStopStatus current_status = 4 [default = IN_TRANSIT_TO]; + + // Moment at which the vehicle's position was measured. In POSIX time + // (i.e., number of seconds since January 1st 1970 00:00:00 UTC). + optional uint64 timestamp = 5; + + // Congestion level that is affecting this vehicle. + enum CongestionLevel { + UNKNOWN_CONGESTION_LEVEL = 0; + RUNNING_SMOOTHLY = 1; + STOP_AND_GO = 2; + CONGESTION = 3; + SEVERE_CONGESTION = 4; // People leaving their cars. + } + optional CongestionLevel congestion_level = 6; + + // The state of passenger occupancy for the vehicle or carriage. + // Individual producers may not publish all OccupancyStatus values. Therefore, consumers + // must not assume that the OccupancyStatus values follow a linear scale. + // Consumers should represent OccupancyStatus values as the state indicated + // and intended by the producer. Likewise, producers must use OccupancyStatus values that + // correspond to actual vehicle occupancy states. + // For describing passenger occupancy levels on a linear scale, see `occupancy_percentage`. + // This field is still experimental, and subject to change. It may be formally adopted in the future. + enum OccupancyStatus { + // The vehicle or carriage is considered empty by most measures, and has few or no + // passengers onboard, but is still accepting passengers. + EMPTY = 0; + + // The vehicle or carriage has a large number of seats available. + // The amount of free seats out of the total seats available to be + // considered large enough to fall into this category is determined at the + // discretion of the producer. + MANY_SEATS_AVAILABLE = 1; + + // The vehicle or carriage has a relatively small number of seats available. + // The amount of free seats out of the total seats available to be + // considered small enough to fall into this category is determined at the + // discretion of the feed producer. + FEW_SEATS_AVAILABLE = 2; + + // The vehicle or carriage can currently accommodate only standing passengers. + STANDING_ROOM_ONLY = 3; + + // The vehicle or carriage can currently accommodate only standing passengers + // and has limited space for them. + CRUSHED_STANDING_ROOM_ONLY = 4; + + // The vehicle or carriage is considered full by most measures, but may still be + // allowing passengers to board. + FULL = 5; + + // The vehicle or carriage is not accepting passengers, but usually accepts passengers for boarding. + NOT_ACCEPTING_PASSENGERS = 6; + + // The vehicle or carriage doesn't have any occupancy data available at that time. + NO_DATA_AVAILABLE = 7; + + // The vehicle or carriage is not boardable and never accepts passengers. + // Useful for special vehicles or carriages (engine, maintenance carriage, etc…). + NOT_BOARDABLE = 8; + + } + // If multi_carriage_status is populated with per-carriage OccupancyStatus, + // then this field should describe the entire vehicle with all carriages accepting passengers considered. + optional OccupancyStatus occupancy_status = 9; + + // A percentage value indicating the degree of passenger occupancy in the vehicle. + // The values are represented as an integer without decimals. 0 means 0% and 100 means 100%. + // The value 100 should represent the total maximum occupancy the vehicle was designed for, + // including both seated and standing capacity, and current operating regulations allow. + // The value may exceed 100 if there are more passengers than the maximum designed capacity. + // The precision of occupancy_percentage should be low enough that individual passengers cannot be tracked boarding or alighting the vehicle. + // If multi_carriage_status is populated with per-carriage occupancy_percentage, + // then this field should describe the entire vehicle with all carriages accepting passengers considered. + // This field is still experimental, and subject to change. It may be formally adopted in the future. + optional uint32 occupancy_percentage = 10; + + // Carriage specific details, used for vehicles composed of several carriages + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + message CarriageDetails { + + // Identification of the carriage. Should be unique per vehicle. + optional string id = 1; + + // User visible label that may be shown to the passenger to help identify + // the carriage. Example: "7712", "Car ABC-32", etc... + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + optional string label = 2; + + // Occupancy status for this given carriage, in this vehicle + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + optional OccupancyStatus occupancy_status = 3 [default = NO_DATA_AVAILABLE]; + + // Occupancy percentage for this given carriage, in this vehicle. + // Follows the same rules as "VehiclePosition.occupancy_percentage" + // -1 in case data is not available for this given carriage (as protobuf defaults to 0 otherwise) + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + optional int32 occupancy_percentage = 4 [default = -1]; + + // Identifies the order of this carriage with respect to the other + // carriages in the vehicle's list of CarriageDetails. + // The first carriage in the direction of travel must have a value of 1. + // The second value corresponds to the second carriage in the direction + // of travel and must have a value of 2, and so forth. + // For example, the first carriage in the direction of travel has a value of 1. + // If the second carriage in the direction of travel has a value of 3, + // consumers will discard data for all carriages (i.e., the multi_carriage_details field). + // Carriages without data must be represented with a valid carriage_sequence number and the fields + // without data should be omitted (alternately, those fields could also be included and set to the "no data" values). + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + optional uint32 carriage_sequence = 5; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + + // Details of the multiple carriages of this given vehicle. + // The first occurrence represents the first carriage of the vehicle, + // given the current direction of travel. + // The number of occurrences of the multi_carriage_details + // field represents the number of carriages of the vehicle. + // It also includes non boardable carriages, + // like engines, maintenance carriages, etc… as they provide valuable + // information to passengers about where to stand on a platform. + // This message/field is still experimental, and subject to change. It may be formally adopted in the future. + repeated CarriageDetails multi_carriage_details = 11; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// An alert, indicating some sort of incident in the public transit network. +message Alert { + // Time when the alert should be shown to the user. If missing, the + // alert will be shown as long as it appears in the feed. + // If multiple ranges are given, the alert will be shown during all of them. + repeated TimeRange active_period = 1; + + // Entities whose users we should notify of this alert. + repeated EntitySelector informed_entity = 5; + + // Cause of this alert. If cause_detail is included, then Cause must also be included. + enum Cause { + UNKNOWN_CAUSE = 1; + OTHER_CAUSE = 2; // Not machine-representable. + TECHNICAL_PROBLEM = 3; + STRIKE = 4; // Public transit agency employees stopped working. + DEMONSTRATION = 5; // People are blocking the streets. + ACCIDENT = 6; + HOLIDAY = 7; + WEATHER = 8; + MAINTENANCE = 9; + CONSTRUCTION = 10; + POLICE_ACTIVITY = 11; + MEDICAL_EMERGENCY = 12; + } + optional Cause cause = 6 [default = UNKNOWN_CAUSE]; + + // What is the effect of this problem on the affected entity. If effect_detail is included, then Effect must also be included. + enum Effect { + NO_SERVICE = 1; + REDUCED_SERVICE = 2; + + // We don't care about INsignificant delays: they are hard to detect, have + // little impact on the user, and would clutter the results as they are too + // frequent. + SIGNIFICANT_DELAYS = 3; + + DETOUR = 4; + ADDITIONAL_SERVICE = 5; + MODIFIED_SERVICE = 6; + OTHER_EFFECT = 7; + UNKNOWN_EFFECT = 8; + STOP_MOVED = 9; + NO_EFFECT = 10; + ACCESSIBILITY_ISSUE = 11; + } + optional Effect effect = 7 [default = UNKNOWN_EFFECT]; + + // The URL which provides additional information about the alert. + optional TranslatedString url = 8; + + // Alert header. Contains a short summary of the alert text as plain-text. + optional TranslatedString header_text = 10; + + // Full description for the alert as plain-text. The information in the + // description should add to the information of the header. + optional TranslatedString description_text = 11; + + // Text for alert header to be used in text-to-speech implementations. This field is the text-to-speech version of header_text. + optional TranslatedString tts_header_text = 12; + + // Text for full description for the alert to be used in text-to-speech implementations. This field is the text-to-speech version of description_text. + optional TranslatedString tts_description_text = 13; + + // Severity of this alert. + enum SeverityLevel { + UNKNOWN_SEVERITY = 1; + INFO = 2; + WARNING = 3; + SEVERE = 4; + } + + optional SeverityLevel severity_level = 14 [default = UNKNOWN_SEVERITY]; + + // TranslatedImage to be displayed along the alert text. Used to explain visually the alert effect of a detour, station closure, etc. The image must enhance the understanding of the alert. Any essential information communicated within the image must also be contained in the alert text. + // The following types of images are discouraged : image containing mainly text, marketing or branded images that add no additional information. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional TranslatedImage image = 15; + + // Text describing the appearance of the linked image in the `image` field (e.g., in case the image can't be displayed + // or the user can't see the image for accessibility reasons). See the HTML spec for alt image text - https://html.spec.whatwg.org/#alt. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional TranslatedString image_alternative_text = 16; + + + // Description of the cause of the alert that allows for agency-specific language; more specific than the Cause. If cause_detail is included, then Cause must also be included. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional TranslatedString cause_detail = 17; + + // Description of the effect of the alert that allows for agency-specific language; more specific than the Effect. If effect_detail is included, then Effect must also be included. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional TranslatedString effect_detail = 18; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features + // and modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// +// Low level data structures used above. +// + +// A time interval. The interval is considered active at time 't' if 't' is +// greater than or equal to the start time and less than the end time. +message TimeRange { + // Start time, in POSIX time (i.e., number of seconds since January 1st 1970 + // 00:00:00 UTC). + // If missing, the interval starts at minus infinity. + optional uint64 start = 1; + + // End time, in POSIX time (i.e., number of seconds since January 1st 1970 + // 00:00:00 UTC). + // If missing, the interval ends at plus infinity. + optional uint64 end = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// A position. +message Position { + // Degrees North, in the WGS-84 coordinate system. + required float latitude = 1; + + // Degrees East, in the WGS-84 coordinate system. + required float longitude = 2; + + // Bearing, in degrees, clockwise from North, i.e., 0 is North and 90 is East. + // This can be the compass bearing, or the direction towards the next stop + // or intermediate location. + // This should not be direction deduced from the sequence of previous + // positions, which can be computed from previous data. + optional float bearing = 3; + + // Odometer value, in meters. + optional double odometer = 4; + // Momentary speed measured by the vehicle, in meters per second. + optional float speed = 5; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// A descriptor that identifies an instance of a GTFS trip, or all instances of +// a trip along a route. +// - To specify a single trip instance, the trip_id (and if necessary, +// start_time) is set. If route_id is also set, then it should be same as one +// that the given trip corresponds to. +// - To specify all the trips along a given route, only the route_id should be +// set. Note that if the trip_id is not known, then stop sequence ids in +// TripUpdate are not sufficient, and stop_ids must be provided as well. In +// addition, absolute arrival/departure times must be provided. +message TripDescriptor { + // The trip_id from the GTFS feed that this selector refers to. + // For non frequency-based trips, this field is enough to uniquely identify + // the trip. For frequency-based trip, start_time and start_date might also be + // necessary. When schedule_relationship is DUPLICATED within a TripUpdate, the trip_id identifies the trip from + // static GTFS to be duplicated. When schedule_relationship is DUPLICATED within a VehiclePosition, the trip_id + // identifies the new duplicate trip and must contain the value for the corresponding TripUpdate.TripProperties.trip_id. + optional string trip_id = 1; + + // The route_id from the GTFS that this selector refers to. + optional string route_id = 5; + + // The direction_id from the GTFS feed trips.txt file, indicating the + // direction of travel for trips this selector refers to. + optional uint32 direction_id = 6; + + // The initially scheduled start time of this trip instance. + // When the trip_id corresponds to a non-frequency-based trip, this field + // should either be omitted or be equal to the value in the GTFS feed. When + // the trip_id correponds to a frequency-based trip, the start_time must be + // specified for trip updates and vehicle positions. If the trip corresponds + // to exact_times=1 GTFS record, then start_time must be some multiple + // (including zero) of headway_secs later than frequencies.txt start_time for + // the corresponding time period. If the trip corresponds to exact_times=0, + // then its start_time may be arbitrary, and is initially expected to be the + // first departure of the trip. Once established, the start_time of this + // frequency-based trip should be considered immutable, even if the first + // departure time changes -- that time change may instead be reflected in a + // StopTimeUpdate. + // Format and semantics of the field is same as that of + // GTFS/frequencies.txt/start_time, e.g., 11:15:35 or 25:15:35. + optional string start_time = 2; + // The scheduled start date of this trip instance. + // Must be provided to disambiguate trips that are so late as to collide with + // a scheduled trip on a next day. For example, for a train that departs 8:00 + // and 20:00 every day, and is 12 hours late, there would be two distinct + // trips on the same time. + // This field can be provided but is not mandatory for schedules in which such + // collisions are impossible - for example, a service running on hourly + // schedule where a vehicle that is one hour late is not considered to be + // related to schedule anymore. + // In YYYYMMDD format. + optional string start_date = 3; + + // The relation between this trip and the static schedule. If a trip is done + // in accordance with temporary schedule, not reflected in GTFS, then it + // shouldn't be marked as SCHEDULED, but likely as ADDED. + enum ScheduleRelationship { + // Trip that is running in accordance with its GTFS schedule, or is close + // enough to the scheduled trip to be associated with it. + SCHEDULED = 0; + + // An extra trip that was added in addition to a running schedule, for + // example, to replace a broken vehicle or to respond to sudden passenger + // load. + // NOTE: Currently, behavior is unspecified for feeds that use this mode. There are discussions on the GTFS GitHub + // [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221) + // [(3)](https://github.com/google/transit/pull/219) around fully specifying or deprecating ADDED trips and the + // documentation will be updated when those discussions are finalized. + ADDED = 1; + + // A trip that is running with no schedule associated to it (GTFS frequencies.txt exact_times=0). + // Trips with ScheduleRelationship=UNSCHEDULED must also set all StopTimeUpdates.ScheduleRelationship=UNSCHEDULED. + UNSCHEDULED = 2; + + // A trip that existed in the schedule but was removed. + CANCELED = 3; + + // Should not be used - for backwards-compatibility only. + REPLACEMENT = 5 [deprecated=true]; + + // An extra trip that was added in addition to a running schedule, for example, to replace a broken vehicle or to + // respond to sudden passenger load. Used with TripUpdate.TripProperties.trip_id, TripUpdate.TripProperties.start_date, + // and TripUpdate.TripProperties.start_time to copy an existing trip from static GTFS but start at a different service + // date and/or time. Duplicating a trip is allowed if the service related to the original trip in (CSV) GTFS + // (in calendar.txt or calendar_dates.txt) is operating within the next 30 days. The trip to be duplicated is + // identified via TripUpdate.TripDescriptor.trip_id. This enumeration does not modify the existing trip referenced by + // TripUpdate.TripDescriptor.trip_id - if a producer wants to cancel the original trip, it must publish a separate + // TripUpdate with the value of CANCELED or DELETED. Trips defined in GTFS frequencies.txt with exact_times that is + // empty or equal to 0 cannot be duplicated. The VehiclePosition.TripDescriptor.trip_id for the new trip must contain + // the matching value from TripUpdate.TripProperties.trip_id and VehiclePosition.TripDescriptor.ScheduleRelationship + // must also be set to DUPLICATED. + // Existing producers and consumers that were using the ADDED enumeration to represent duplicated trips must follow + // the migration guide (https://github.com/google/transit/tree/master/gtfs-realtime/spec/en/examples/migration-duplicated.md) + // to transition to the DUPLICATED enumeration. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + DUPLICATED = 6; + + + // A trip that existed in the schedule but was removed and must not be shown to users. + // DELETED should be used instead of CANCELED to indicate that a transit provider would like to entirely remove + // information about the corresponding trip from consuming applications, so the trip is not shown as cancelled to + // riders, e.g. a trip that is entirely being replaced by another trip. + // This designation becomes particularly important if several trips are cancelled and replaced with substitute service. + // If consumers were to show explicit information about the cancellations it would distract from the more important + // real-time predictions. + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + DELETED = 7; + } + optional ScheduleRelationship schedule_relationship = 4; + + message ModifiedTripSelector { + // The 'id' from the FeedEntity in which the contained TripModifications object affects this trip. + optional string modifications_id = 1; + + // The trip_id from the GTFS feed that is modified by the modifications_id + optional string affected_trip_id = 2; + } + optional ModifiedTripSelector modified_trip = 7; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// Identification information for the vehicle performing the trip. +message VehicleDescriptor { + // Internal system identification of the vehicle. Should be unique per + // vehicle, and can be used for tracking the vehicle as it proceeds through + // the system. + optional string id = 1; + + // User visible label, i.e., something that must be shown to the passenger to + // help identify the correct vehicle. + optional string label = 2; + + // The license plate of the vehicle. + optional string license_plate = 3; + + enum WheelchairAccessible { + // The trip doesn't have information about wheelchair accessibility. + // This is the **default** behavior. If the static GTFS contains a + // _wheelchair_accessible_ value, it won't be overwritten. + NO_VALUE = 0; + + // The trip has no accessibility value present. + // This value will overwrite the value from the GTFS. + UNKNOWN = 1; + + // The trip is wheelchair accessible. + // This value will overwrite the value from the GTFS. + WHEELCHAIR_ACCESSIBLE = 2; + + // The trip is **not** wheelchair accessible. + // This value will overwrite the value from the GTFS. + WHEELCHAIR_INACCESSIBLE = 3; + } + optional WheelchairAccessible wheelchair_accessible = 4 [default = NO_VALUE]; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// A selector for an entity in a GTFS feed. +message EntitySelector { + // The values of the fields should correspond to the appropriate fields in the + // GTFS feed. + // At least one specifier must be given. If several are given, then the + // matching has to apply to all the given specifiers. + optional string agency_id = 1; + optional string route_id = 2; + // corresponds to route_type in GTFS. + optional int32 route_type = 3; + optional TripDescriptor trip = 4; + optional string stop_id = 5; + // Corresponds to trip direction_id in GTFS trips.txt. If provided the + // route_id must also be provided. + optional uint32 direction_id = 6; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// An internationalized message containing per-language versions of a snippet of +// text or a URL. +// One of the strings from a message will be picked up. The resolution proceeds +// as follows: +// 1. If the UI language matches the language code of a translation, +// the first matching translation is picked. +// 2. If a default UI language (e.g., English) matches the language code of a +// translation, the first matching translation is picked. +// 3. If some translation has an unspecified language code, that translation is +// picked. +message TranslatedString { + message Translation { + // A UTF-8 string containing the message. + required string text = 1; + // BCP-47 language code. Can be omitted if the language is unknown or if + // no i18n is done at all for the feed. At most one translation is + // allowed to have an unspecified language tag. + optional string language = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + // At least one translation must be provided. + repeated Translation translation = 1; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// An internationalized image containing per-language versions of a URL linking to an image +// along with meta information +// Only one of the images from a message will be retained by consumers. The resolution proceeds +// as follows: +// 1. If the UI language matches the language code of a translation, +// the first matching translation is picked. +// 2. If a default UI language (e.g., English) matches the language code of a +// translation, the first matching translation is picked. +// 3. If some translation has an unspecified language code, that translation is +// picked. +// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. +message TranslatedImage { + message LocalizedImage { + // String containing an URL linking to an image + // The image linked must be less than 2MB. + // If an image changes in a significant enough way that an update is required on the consumer side, the producer must update the URL to a new one. + // The URL should be a fully qualified URL that includes http:// or https://, and any special characters in the URL must be correctly escaped. See the following http://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a description of how to create fully qualified URL values. + required string url = 1; + + // IANA media type as to specify the type of image to be displayed. + // The type must start with "image/" + required string media_type = 2; + + // BCP-47 language code. Can be omitted if the language is unknown or if + // no i18n is done at all for the feed. At most one translation is + // allowed to have an unspecified language tag. + optional string language = 3; + + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + // At least one localized image must be provided. + repeated LocalizedImage localized_image = 1; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// Describes the physical path that a vehicle takes when it's not part of the (CSV) GTFS, +// such as for a detour. Shapes belong to Trips, and consist of a sequence of shape points. +// Tracing the points in order provides the path of the vehicle. Shapes do not need to intercept +// the location of Stops exactly, but all Stops on a trip should lie within a small distance of +// the shape for that trip, i.e. close to straight line segments connecting the shape points +// NOTE: This message is still experimental, and subject to change. It may be formally adopted in the future. +message Shape { + // Identifier of the shape. Must be different than any shape_id defined in the (CSV) GTFS. + // This field is required as per reference.md, but needs to be specified here optional because "Required is Forever" + // See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string shape_id = 1; + + // Encoded polyline representation of the shape. This polyline must contain at least two points. + // For more information about encoded polylines, see https://developers.google.com/maps/documentation/utilities/polylinealgorithm + // This field is required as per reference.md, but needs to be specified here optional because "Required is Forever" + // See https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules + // NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. + optional string encoded_polyline = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// Describes a stop which is served by trips. All fields are as described in the GTFS-Static specification. +// NOTE: This message is still experimental, and subject to change. It may be formally adopted in the future. +message Stop { + enum WheelchairBoarding { + UNKNOWN = 0; + AVAILABLE = 1; + NOT_AVAILABLE = 2; + } + + optional string stop_id = 1; + optional TranslatedString stop_code = 2; + optional TranslatedString stop_name = 3; + optional TranslatedString tts_stop_name = 4; + optional TranslatedString stop_desc = 5; + optional float stop_lat = 6; + optional float stop_lon = 7; + optional string zone_id = 8; + optional TranslatedString stop_url = 9; + optional string parent_station = 11; + optional string stop_timezone = 12; + optional WheelchairBoarding wheelchair_boarding = 13 [default = UNKNOWN]; + optional string level_id = 14; + optional TranslatedString platform_code = 15; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. +message TripModifications { + // A `Modification` message replaces a span of n stop times from each affected trip starting at `start_stop_selector`. + message Modification { + // The stop selector of the first stop_time of the original trip that is to be affected by this modification. + // Used in conjuction with `end_stop_selector`. + // `start_stop_selector` is required and is used to define the reference stop used with `travel_time_to_stop`. + optional StopSelector start_stop_selector = 1; + + // The stop selector of the last stop of the original trip that is to be affected by this modification. + // The selection is inclusive, so if only one stop_time is replaced by that modification, `start_stop_selector` and `end_stop_selector` must be equivalent. + // If no stop_time is replaced, `end_stop_selector` must not be provided. It's otherwise required. + optional StopSelector end_stop_selector = 2; + + // The number of seconds of delay to add to all departure and arrival times following the end of this modification. + // If multiple modifications apply to the same trip, the delays accumulate as the trip advances. + optional int32 propagated_modification_delay = 3 [default = 0]; + + // A list of replacement stops, replacing those of the original trip. + // The length of the new stop times may be less, the same, or greater than the number of replaced stop times. + repeated ReplacementStop replacement_stops = 4; + + // An `id` value from the `FeedEntity` message that contains the `Alert` describing this Modification for user-facing communication. + optional string service_alert_id = 5; + + // This timestamp identifies the moment when the modification has last been changed. + // In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). + optional uint64 last_modified_time = 6; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; + } + + message SelectedTrips { + // A list of trips affected with this replacement that all have the same new `shape_id`. + repeated string trip_ids = 1; + // The ID of the new shape for the modified trips in this SelectedTrips. + // May refer to a new shape added using a GTFS-RT Shape message, or to an existing shape defined in the GTFS-Static feed’s shapes.txt. + optional string shape_id = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + + // A list of selected trips affected by this TripModifications. + repeated SelectedTrips selected_trips = 1; + + // A list of start times in the real-time trip descriptor for the trip_id defined in trip_ids. + // Useful to target multiple departures of a trip_id in a frequency-based trip. + repeated string start_times = 2; + + // Dates on which the modifications occurs, in the YYYYMMDD format. Producers SHOULD only transmit detours occurring within the next week. + // The dates provided should not be used as user-facing information, if a user-facing start and end date needs to be provided, they can be provided in the linked service alert with `service_alert_id` + repeated string service_dates = 3; + + // A list of modifications to apply to the affected trips. + repeated Modification modifications = 4; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. +// Select a stop by stop sequence or by stop_id. At least one of the two values must be provided. +message StopSelector { + // Must be the same as in stop_times.txt in the corresponding GTFS feed. + optional uint32 stop_sequence = 1; + // Must be the same as in stops.txt in the corresponding GTFS feed. + optional string stop_id = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} + +// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future. +message ReplacementStop { + // The difference in seconds between the arrival time at this stop and the arrival time at the reference stop. The reference stop is the stop prior to start_stop_selector. If the modification begins at the first stop of the trip, then the first stop of the trip is the reference stop. + // This value MUST be monotonically increasing and may only be a negative number if the first stop of the original trip is the reference stop. + optional int32 travel_time_to_stop = 1; + + // The replacement stop ID which will now be visited by the trip. May refer to a new stop added using a GTFS-RT Stop message, or to an existing stop defined in the GTFS-Static feed’s stops.txt. The stop MUST have location_type=0 (routable stops). + optional string stop_id = 2; + + // The extensions namespace allows 3rd-party developers to extend the + // GTFS Realtime Specification in order to add and evaluate new features and + // modifications to the spec. + extensions 1000 to 1999; + + // The following extension IDs are reserved for private use by any organization. + extensions 9000 to 9999; +} \ No newline at end of file diff --git a/docs/ja/documentation/realtime/language-bindings/dotnet.md b/docs/ja/documentation/realtime/language-bindings/dotnet.md new file mode 100644 index 000000000..819a652d1 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/dotnet.md @@ -0,0 +1,28 @@ +# .NET GTFS-realtime 言語バインディング + +[![NuGet バージョン](https://badge.fury.io/nu/GtfsRealtimeBindings.svg)](http://badge.fury.io/nu/GtfsRealtimeBindings) + +[GTFS-realtime](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された.NETクラスを提供します。これらのクラスを使用すると、バイナリ プロトコル バッファ GTFS リアルタイム データ フィードを C#オブジェクトに解析できます。 + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`クラスを使用するには、まず [NuGet リポジトリ](https://www.nuget.org/packages/GtfsRealtimeBindings/) からモジュールをインストールする必要があります。 + +``` +Install-Package GtfsRealtimeBindings +``` + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果を反復処理する方法を示しています。 + +```p` using System.Net; +using ProtoBuf; +using TransitRealtime; + +WebRequest req = HttpWebRequest.Create("URL OF YOUR GTFS-REALTIMEソースはここに記述します"); + FeedMessage feed = Serializer.Deserialize (req.GetResponse().GetResponseStream()); +foreach ( feed.Entities 内のFeedEntityエンティティ) { +... +} +``` diff --git a/docs/ja/documentation/realtime/language-bindings/golang.md b/docs/ja/documentation/realtime/language-bindings/golang.md new file mode 100644 index 000000000..1cde852d2 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/golang.md @@ -0,0 +1,67 @@ +# Golang GTFS-realtime 言語バインディング + +[GTFS-realtime](https:) プロトコル バッファ仕様から生成された Golang 構造体を提供します。これらの構造体を使用すると、バイナリ Protocol Buffer GTFS リアルタイム データ フィードを Golang オブジェクトに解析できます。 + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`構造体を使用するには、まず次のコマンドでこのライブラリをインストールする必要があります: + +``` +go get github.com/MobilityData/gtfs-realtime-bindings/golang/gtfs +``` + +そして次のコマンドで golang protobuf ライブラリ依存関係をインストールします: +``` +go get google.golang.org/protobuf/proto +``` + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果を反復処理する方法を示しています。 + +```g` package main + +import ( + "fmt" + "google.golang.org/protobuf/proto" + "github.com/MobilityData/gtfs-realtime-bindings/golang/gtfs" + "io/ioutil" + "log" + "net/http" +) + +func main() { + var ( + username = "YOUR_ACCESS_KEY" + password = "YOUR_SECRET_KEY" + ) + + client := &http.Client{} + req, err := http.NewRequest("GET", "URL OF YOUR GTFS-REALTIME SOURCE GOES HERE", nil) + req.SetBasicAuth(username, password) + resp, err := client.Do(req) + defer resp.Body.Close() + if err != nil { + log.Fatal(err) + } + body, err := ioutil.ReadAll(resp.Body) + if err != nil { + log.Fatal(err) + } + + feed := gtfs. FeedMessage{} + err = proto.Unmarshal(body, &feed) + if err != nil { + log.Fatal(err) + } + + for _, entity := range feed.Entity { + tripUpdate := entity.GetTripUpdate() + trip := tripUpdate.GetTrip() + tripId := trip.GetTripId() + fmt.Printf("Trip ID: %s\n", tripId) + } +} +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される Golang 構造体の命名規則の詳細については、[Golang 生成コード](https:詳細は、Protocol Buffers 開発者サイトの (//developers.google.com/protocol-buffers/docs/reference/go-generated) セクションをご覧ください。 diff --git a/docs/ja/documentation/realtime/language-bindings/java.md b/docs/ja/documentation/realtime/language-bindings/java.md new file mode 100644 index 000000000..9c1bb7fab --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/java.md @@ -0,0 +1,65 @@ +# Java GTFS-realtime 言語バインディング + +![Maven Central バージョン](https://img.shields.io/maven-central/v/org.mobilitydata/gtfs-realtime-bindings.svg) + +[GTFS-realtime](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された Java クラスを提供します。これらのクラスを使用すると、バイナリ プロトコル バッファ GTFS-realtime データ フィードを Java オブジェクトに解析できます。 + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`クラスを使用するには、適切な依存関係を追加する必要があります。私たちのモジュールは [Maven Central Repository](http://search.maven.org/) に公開されており、Maven、Ivy、Gradle などの Java ビルド ツールで簡単に参照できます。 + +[Maven](http://maven.apache.org/) の場合は、 `pom.xml` の依存関係セクションに以下を追加します: + +```xml + + org.mobilitydata + gtfs リアルタイムバインディング + 0.0.8 + +``` + +[Gradle](https:) の場合は、 `build.gradle` の依存関係セクションに以下を追加します。 + +``` +実装グループ: ’org.mobilitydata’、名前: ’gtfs-realtime-bindings’、バージョン: ’0.0.8’ +``` + +プロジェクトで Maven 中央リポジトリが参照されていることを確認します。 + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析して、結果を反復処理する方法を示しています。 + +```a` import java.net.URL; + +import com.google.transit.realtime.GtfsRealtime. FeedEntity; +import com.google.transit.realtime.GtfsRealtime. FeedMessage; + +public class GtfsRealtimeExample { + public static void main(String[] args) throws Exception { + URL url = new URL("GTFS-REALTIME ソースの URL をここに記述してください"); + FeedMessage feed = FeedMessage.parseFrom(url.openStream()); + for (FeedEntity entity : feed.getEntityList()) { + if (entity.hasTripUpdate()) { + System.out.println(entity.getTripUpdate()); + } + } + } +} +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される Java クラスの命名規則の詳細については、[Java 生成コード](https://developers.google.com/protocol-buffers/docs/reference/java-generated) セクションの Protocol Buffers 開発者向けセクションをご覧ください。 + +## プロジェクト履歴 + +### `0.0.4` 以下 +このプロジェクトは元々 Google によって作成されました。バージョン `0.0.4` およびそれ以前のバージョンは、グループID `com.google.transit` [Maven Central のこちら](https:)からダウンロードできます。 + +### `0.0.5` +MobilityData は 2019 年の初めにプロジェクトの保守を開始し、当初は JCenter 経由でリリース成果物を公開しました。バージョン `0.0.5` は、グループID `io.mobilitydata.transit` [Maven Central のこちら](https:) からダウンロードできます。 + +### `0.0.6` および `0.0.7` +JCenter [は 2021 年にシャットダウン](https: )。シャットダウン前は、同期の問題によりバージョン `0.0.6` および `0.0.7` が JCenter から Maven Central に同期されなかったため、現在これらのバージョンでは直接アーティファクトをダウンロードすることはできません。ただし、コマンド`n` package`を使用して [tags](https: ) から自分でコンパイルすることができます。 + +### `0.0.8` 以上 +2022 年に、MobilityData は、グループID `org.mobilitydata`で` Maven Central に成果物を直接公開するように切り替えました。バージョン 0.0.8 以上はここで公開されます。 diff --git a/docs/ja/documentation/realtime/language-bindings/nodejs.md b/docs/ja/documentation/realtime/language-bindings/nodejs.md new file mode 100644 index 000000000..0b0db2727 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/nodejs.md @@ -0,0 +1,62 @@ +# JavaScript GTFS-realtime 言語バインディング + +[![npm バージョン](https://badge.fury.io/js/gtfs-realtime-bindings.svg)](http://badge.fury.io/js/gtfs-realtime-bindings) + +[GTFS-realtime](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された JavaScript クラスとそれに関連する型を提供します。これらのクラスを使用すると、バイナリ プロトコル バッファ GTFS リアルタイム データ フィードを JavaScript オブジェクトに解析できます。 + +これらのバインディングは [Node.js](http://nodejs.org/) 環境で使用するように設計されていますが、少し努力すれば、他の JavaScript 環境でも使用できる可能性があります。 + +JavaScript プロトコル バッファのサポートには [ProtoBuf.js](https://github.com/dcodeIO/ProtoBuf.js) ライブラリを使用します。 + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`クラスを使用するには、まず [Node.js npm パッケージ](https://www.npmjs.com/package/gtfs-realtime-bindings) をインストールする必要があります。 + +``` +npm install gtfs-realtime-bindings +``` + +## サンプル コード + +次の Node.js コード スニペットは、GTFS リアルタイム データ フィードのダウンロードを示しています。特定の URL からデータ フィードを取得し、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果を反復処理します。 + +この例を機能させるには、まず NPM で`node-fetch`をインストールする必要があります。 + +注: この例は ES モジュール (`import`/`export`構文) を使用しており、CommonJS (`require`構文) とは互換性がありません。`import`を`require`に変換し、 `node-fetch@2`で` CommonJS を使用できます。ES モジュールの詳細については、[こちら](https://nodejs.org/api/esm.html) を参照してください。_ + +```t` import GtfsRealtimeBindings from "gtfs-realtime-bindings"; +import fetch from "node-fetch"; + +(async () => { + try { + const response = await fetch(" "、{ + ヘッダー: { + "x-api-key": " ", + //GTFS リアルタイム ソースの認証トークンに置き換えます + //たとえば、x-api-key は NY の MTA GTFS API に使用されるヘッダー値です + }, + }); + if (!response.ok) { + const error = new Error(`${response.url}: ${response.status} ${response.statusText}`); + error.response = response; + throw error; + process.exit(1); + } + const buffer = await response.arrayBuffer(); + const feed = GtfsRealtimeBindings.transit_realtime. FeedMessage.decode( + new Uint8Array(buffer) + ); + feed.entity.forEach((entity) => { + if (entity.tripUpdate) { + console.log(entity.tripUpdate); + } + }); + } + catch (error) { + console.log(error); + process.exit(1); + } +})(); +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される JavaScript クラスの命名規則の詳細については、Protocol Buffer のシリアル化を処理するために使用する [ProtoBuf.js プロジェクト](https://github.com/dcodeIO/ProtoBuf.js/wiki) をご覧ください。 diff --git a/docs/ja/documentation/realtime/language-bindings/overview.md b/docs/ja/documentation/realtime/language-bindings/overview.md new file mode 100644 index 000000000..28112f640 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/overview.md @@ -0,0 +1,32 @@ +# GTFS Realtimeバインディング + +## はじめに + +[GTFS Realtime](https://github.com/google/transit/tree/master/gtfs-realtime) は、公共交通機関に関するリアルタイム情報を通信するためのデータ形式です。GTFSGTFS Realtimeデータは、[プロトコル バッファ](https://developers.google.com/protocol-buffers/) を使用してエンコードおよびデコードされます。これは、高速かつ効率的な処理のために設計されたコンパクトなバイナリ表現です。データ スキーマ自体は [gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) で定義されていますGTFS Realtimeデータを操作するには、開発者は通常、 `gtfs-realtime.proto`スキーマを使用して、任意のプログラミング言語でクラスを生成します。これらのクラスは、GTFS リアルタイム データ モデル オブジェクトを構築してバイナリ データとしてシリアル化したり、逆にバイナリ データをデータ モデル オブジェクトに解析したりするために使用できます。 + +`gtfs `gtfs-realtime.proto`S` Realtimeデータ モデル クラスを生成することは非常に一般的なタスクですが、初心者の開発者にとっては混乱を招くこともあるため、このプロジェクトでは、最も人気のあるプログラミング言語のいくつかに対して、事前に生成されたGTFS Realtime言語バインディングを提供することを目指しています。可能な場合は、これらの言語バインディングはパッケージとして公開され、他のプロジェクトでの使用が容易になります。 + +## サポートされている言語 + +* [.NET](dotnet.md) +* [Java](java.md) +* [JavaScript/TypeScript/Node.js](nodejs.md) +* [Python](python.md) +* [Golang](golang.md) +* ~~[Ruby](ruby.md)~~ *(2019 年初頭に非推奨)* +* ~~[PHP](php.md)~~ *(2019 年初頭に非推奨)* + +## その他の言語 + +C++ 用の生成コードは提供していません。そのためには公式の protoc コンパイラを使用してください ([こちら](https://developers.google.com/protocol-buffers/docs/downloads) または [こちら](https://github.com/google/protobuf)) + +お気に入りの言語が不足していませんか？貢献することを検討してください。 + + 1. [CONTRIBUTING.md](https://github.com/MobilityData/gtfs-realtime-bindings/blob/master/CONTRIBUTING.md) をお読みください。 + 2.選択した言語でpull requestを開きます。更新手順 (できればスクリプト) を含めてください。また、言語エコシステムに適したパッケージングも提供してください。 + +## プロジェクト履歴 + +このプロジェクトはもともと Google によって作成されました。MobilityData は 2019 年初頭にプロジェクトの保守を開始しました。 + +バインディング ライブラリの古いバージョンは、引き続き Google の名前で公開されています。Google によって公開された最新バージョンを見つけるには、各言語のドキュメントを [こちら](https://github.com/MobilityData/gtfs-realtime-bindings/tree/final-google-version) で参照してください。 diff --git a/docs/ja/documentation/realtime/language-bindings/php.md b/docs/ja/documentation/realtime/language-bindings/php.md new file mode 100644 index 000000000..904915544 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/php.md @@ -0,0 +1,55 @@ + + + + +# PHP GTFS-realtime 言語バインディング + +[![PHP バージョン](https://badge.fury.io/ph/google%2Fgtfs-realtime-bindings.svg)](https://badge.fury.io/ph/google%2Fgtfs-realtime-bindings) + +[GTFS-realtime](](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された PHP クラスを提供します。これらのクラスを使用すると、バイナリ プロトコル バッファ GTFS-realtime データ フィードを PHP オブジェクトに解析できます。 + +他の言語のバインディングについては、[gtfs-realtime-bindings](https://github.com/google/gtfs-realtime-bindings) プロジェクトをご覧ください。 + +!!! fail "非推奨" + + *2019 年 2 月現在、公式の`google-protobuf` Google プロトコル ツールは [proto2 ファイルをサポートしていません](https://github.com/protocolbuffers/protobuf/issues/3623)。そのため、proto2 ファイルの公式サポートが Google プロトコル バッファ ツールに実装されるまで、PHP バインディングは非推奨となります。* + +## 依存関係を追加する + +独自のプロジェクトで`gtfs-realtime-bindings-php`クラスを使用するには、まず [Packagist Composer パッケージ](https://packagist.org/packages/google/gtfs-realtime-bindings) をインストールする必要があります。これを行うには、 `composer.json`ファイルに依存関係を追加します: + +``` +"require": { + "google/gtfs-realtime-bindings": "xyz" +} +``` + +`xyz` は最新のリリース バージョンです: + +[![PHP バージョン](https://badge.fury.io/ph/google%2Fgtfs-realtime-bindings.svg)](https://badge.fury.io/ph/google%2Fgtfs-realtime-bindings) + +次に、Composer の依存関係を更新します: + +``` +composer update +``` + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果。 + +```p` require_once ’vendor/autoload.php’; + +use transit_realtime\ FeedMessage; + +$data = file_get_contents("GTFS-REALTIME ソースの URL をここに入力します"); +$feed = new FeedMessage(); +$feed->parse($data); +foreach ($feed->getEntityList() as $entity) { + if ($entity->hasTripUpdate()) { + error_log("trip: ". $entity->getId()); + } +} +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される PHP クラスの命名規則の詳細については、[gtfs-realtime.php ソース ファイル](https: \ No newline at end of file diff --git a/docs/ja/documentation/realtime/language-bindings/python.md b/docs/ja/documentation/realtime/language-bindings/python.md new file mode 100644 index 000000000..7b7351af6 --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/python.md @@ -0,0 +1,32 @@ +# Python GTFS-realtime 言語バインディング + +[![PyPI バージョン](https://badge.fury.io/py/gtfs-realtime-bindings.svg)](http://badge.fury.io/py/gtfs-realtime-bindings) + +[GTFS-realtime](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された Python クラスを提供します。これらのクラスを使用すると、バイナリ Protocol Buffer GTFS リアルタイム データ フィードを Python オブジェクトに解析できます。 + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`クラスを使用するには、まず [PyPI リポジトリ](https://pypi.python.org/pypi/gtfs-realtime-bindings) からモジュールをインストールする必要があります。 + +``` +# easy_install の使用 +easy_install--upgrade gtfs-realtime-bindings#pip の使用 +pip install--upgrade gtfs-realtime-bindings +``` + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果を反復処理する方法を示しています。 + +```n` from google.transit import gtfs_realtime_pb2 +import request + +feed = gtfs_realtime_pb2. FeedMessage() +response = request.get(’GTFS-REALTIME ソースの URL をここに記述します’) +feed.ParseFromString(response.content) +for entity in feed.entity: + if entity.HasField(’trip_update’): + print(entity.trip_update) +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される Python クラスの命名規則の詳細については、Protocol Buffers 開発者サイトの [Python 生成コード](https://developers.google.com/protocol-buffers/docs/reference/python-generated) セクションをご覧ください。 diff --git a/docs/ja/documentation/realtime/language-bindings/ruby.md b/docs/ja/documentation/realtime/language-bindings/ruby.md new file mode 100644 index 000000000..820f2632f --- /dev/null +++ b/docs/ja/documentation/realtime/language-bindings/ruby.md @@ -0,0 +1,41 @@ + + + + +# Ruby GTFS-realtime 言語バインディング + +[![Gem バージョン](https://badge.fury.io/rb/gtfs-realtime-bindings.svg)](https://badge.fury.io/rb/gtfs-realtime-bindings) + +[GTFS-realtime](](https://github.com/google/transit/tree/master/gtfs-realtime) プロトコル バッファ仕様から生成された Ruby クラスを提供します。これらのクラスを使用すると、バイナリ プロトコル バッファ GTFS-realtime データ フィードを Ruby オブジェクトに解析できます。 + +!!! fail "非推奨" + + *2019年2月現在、公式の`google-protobuf` Google protoc ツールは、proto2 ファイルの [拡張機能](https:) をサポートしていません。サードパーティ ツールの [ruby-protocol-buffers](https:) は、 `m` install ruby-protocol-buffers`を使用してインストールできますが、単体テストが失敗するため、Ruby GTFS-rt バインディングの既存の構造と一致していないようです。そのため、proto2 ファイルの公式サポートが Google プロトコル バッファ ツールに実装されるまで、Ruby バインディングは非推奨となります。* + +## 依存関係の追加 + +独自のプロジェクトで`gtfs-realtime-bindings`クラスを使用するには、まず [Ruby gem](https://rubygems.org/gems/gtfs-realtime-bindings) をインストールする必要があります。 + +``` +gem install gtfs-realtime-bindings +``` + +## サンプル コード + +次のコード スニペットは、特定の URL から GTFS リアルタイム データ フィードをダウンロードし、それをFeedMessage (GTFS リアルタイム スキーマのルート タイプ) として解析し、結果を反復処理する方法を示しています。 + +```y` require ’protobuf’ +require ’google/transit/gtfs-realtime.pb’ +require ’net/http’ +require ’uri’ + +data = Net::HTTP.get(URI.parse("GTFS-REALTIME ソースの URL をここに入力します")) +feed = Transit_realtime:: FeedMessage.decode(data) +for entity in feed.entity do + if entity.field?(:trip_update) + p entity.trip_update + end +end +``` + +[gtfs-realtime.proto](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) から生成される Ruby クラスの命名規則の詳細については、[gtfs-realtime.pb.rb ソース ファイル](https://github.com/MobilityData/gtfs-realtime-bindings/blob/master/ruby/lib/google/transit/gtfs-realtime.pb.rb) を参照してください。 diff --git a/docs/ja/documentation/realtime/proto.md b/docs/ja/documentation/realtime/proto.md new file mode 100644 index 000000000..81ea02014 --- /dev/null +++ b/docs/ja/documentation/realtime/proto.md @@ -0,0 +1,1050 @@ +# GTFS Realtime Protobuf +[gtfs-realtime.proto](gtfs-realtime.proto) ファイルをダウンロードし、それを使用して GTFS-realtime フィードをコンパイルします。ファイルの内容は、以下にインラインで示されています。 +protobufs の使用の詳細については、[Protocol Buffers Developer Guide](https://developers.google.com/protocol-buffers/docs/overview) をご覧ください。 +```protobuf +//Copyright 2015 The GTFS Specifications Authors. +// +//Apache License、バージョン 2.0 (以下`ライセンス`) に基づいてライセンス供与されます。 +//ライセンスに準拠しない限り、このファイルを使用することはできません。 +//ライセンスのコピーは、 +// +// http://www.apache.org/licenses/LICENSE-2.0 から入手できます。 +// +//適用法で義務付けられている場合、または書面で同意されている場合を除き、ライセンスに基づいて配布されるソフトウェアは、 +//`現状のまま`で配布され、 +//明示的または黙示的ないかなる種類の保証または条件もありません。 +//特定の言語については、ライセンスをご覧ください。ライセンスに基づく権限および +//制限を規定します。 + +//GTFSGTFS Realtimeのプロトコル定義ファイル。 +// +//GTFS Realtimeを使用すると、交通機関は消費者に対して、サービスへの混乱 (駅の閉鎖、路線の運行停止、重大な遅延など)、車両の場所、到着予定時刻に関するリアルタイムの +//情報を提供できます。 +// +//このプロトコルは、次の場所で公開されています: +//https://github.com/google/transit/tree/master/gtfs-realtime + +syntax = "proto2"; +option java_package = "com.google.transit.realtime"; +package transit_realtime; + +//フィードmessageの内容。 +//フィードは、フィード メッセージの連続ストリームです。ストリーム内の各messageは、 +//適切な HTTP GET リクエストへの応答として取得されます。 +//リアルタイム フィードは常に、既存の GTFS フィードとの関連で定義されます。 +//すべてのエンティティ ID は、GTFS フィードを基準にして解決されます。 +//このファイルに記載されている`必須`および`オプション`は、セマンティック カーディナリティではなく、プロトコル +//バッファ カーディナリティを参照することに注意してください。フィールド +//セマンティック カーディナリティについては、https://github.com/google/transit/tree/master/gtfs-realtime の reference.md をご覧くださいmessage FeedMessage { +//このフィードとフィードmessageに関するメタデータ。 + required FeedHeader header = 1; + +//フィードの内容。 + repeat FeedEntity entity = 2; + +//拡張機能の名前空間により、サードパーティ デベロッパーは +//GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 to 1999; + +//次の拡張機能 ID は、組織によるプライベート使用のために予約されています。 + extensions 9000 to 9999; +} + +//フィード メッセージに含まれる、フィードに関するメタデータ。 + message FeedHeader { +//フィード仕様のバージョン。 +//現在のバージョンは 2.0 です。有効なバージョンは`2.0`、`1.0`です。 + 必須string gtfs_realtime_version = 1; + +//現在のフェッチが増分かどうかを判断します。現在、 +//DIFFERENTIAL モードはサポートされておらず、このモードを使用するフィードの動作は未指定です。GTFS GTFS Realtimeメーリング リスト +//で DIFFERENTIAL モードの動作を完全に指定することについて議論されており、 +//議論が確定するとドキュメントが更新されます。 + enum Incrementality { + FULL_DATASET = 0; + DIFFERENTIAL = 1; + } + オプションIncrementality incrementality = 2 [default = FULL_DATASET]; + +//このタイムスタンプは、このフィードのコンテンツが作成された時刻 (サーバー時間) を識別します。 POSIX 時間（つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数）。 + オプションのuint64 timestamp = 3; + +//extensions 名前空間により、サードパーティの開発者はGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//交通フィード内のエンティティの定義（または更新）。 + message FeedEntity { +//ID は増分サポートを提供するためだけに使用されます。ID はFeedMessage内で一意である必要があります。後続の FeedMessage には、同じ ID の FeedEntities を含めることができます。差分更新の場合、何らかの ID を持つ新しいFeedEntityが、同じ ID を持つ古いFeedEntityを置き換えます (または削除します - 下記の is_deleted を参照してください)。 +//フィードによって参照される実際の G​​TFS エンティティ (駅、ルート、旅行など) は、明示的なセレクタによって指定する必要があります (詳細については、下記のEntitySelectorを参照してください)。 + 必須string id = 1; + +//このエンティティを削除するかどうか。増分フェッチにのみ関連します。 + オプションbool is_deleted = 2 [default = false]; + +//エンティティ自体に関するデータ。次のフィールドの 1 つが必ず存在する必要があります (エンティティが削除される場合を除く)。 + オプションTripUpdate trip_update = 3; + オプションVehiclePosition automobile = 4; + オプション Alert alert = 5; + +//注: このフィールドはまだ試験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプション Shape shape = 6; + オプション Stop stop = 7; + オプションTripModifications trip_modifications = 8; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張機能 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +// +//フィードで使用されるエンティティ。 +// + +//旅程に沿った車両の進行状況のリアルタイム更新。 +//ScheduleRelationshipの値に応じて、 TripUpdateでは以下を指定できます。 +//- スケジュールに沿って進む旅程。 +//- ルートに沿って進むが、固定スケジュールがない旅程。 +//- スケジュールに関して追加または削除された旅程。 +// +//更新は将来予測される到着/出発イベント、またはすでに発生した過去のイベントについてです。 +//通常、イベントが現在の時間に近づくにつれて、更新はより正確で確実になります (以下の不確実性を参照)。 +//それが不可能な場合でも、過去のイベントの情報は +//正確で確実である必要があります。特に、更新が過去の時間を指し示していても、その更新の不確実性が 0 でない場合、クライアントは更新が (間違った) 予測であり、旅行がまだ完了していないと結論付ける必要があります。 +// +//更新は、すでに完了した旅行を記述する場合があることに注意してください。 +//このためには、旅行の最後の停止の更新を提供すれば十分です。 +//その時間が過去である場合、クライアントはそれから旅行全体が過去であると結論付けます (重要ではありませんが、前の停止の更新も提供できます)。 +//このオプションは、スケジュールより早く完了した旅行に最も関連していますが、スケジュールによると、旅行は現在の時間でまだ進行中です。この旅程の更新を削除すると、クライアントは旅程がまだ進行中であると想定する可能性があります。 +//フィード プロバイダーは過去の更新を削除することが許可されていますが、必須ではありません。これは、これが実際に役立つ場合の 1 つです。 + message TripUpdate { +//このmessageが適用される旅程。実際の旅程インスタンスごとに、最大で 1 つのTripUpdateエンティティを指定できます。 +//ない場合は、予測情報がないことを意味します。 +//旅程がスケジュールどおりに進んでいることを意味するわけではありません。 + required TripDescriptor trip = 1; + +//この旅程を運行している車両に関する追加情報。 + optimal VehicleDescriptor automobile = 3; + +//予測される単一のイベント (到着または出発) のタイミング情報。 +//タイミングは、遅延および/または推定時刻、および不確実性で構成されます。 +//- 予測が GTFS 内の既存のスケジュールと比較して提供される場合は、遅延を使用する必要があります。 +//- 予測スケジュールがあるかどうかに関係なく、時間を指定する必要があります。 +// 時間と遅延の両方が指定されている場合は、時間が優先されます +// (ただし、通常、スケジュールされた旅行に対して時間が指定されている場合は、 +// GTFS のスケジュールされた時間 + 遅延に等しくする必要があります)。 +// +//不確実性は、時間と遅延の両方に等しく適用されます。 +//不確実性は、実際の遅延の予想される誤差を大まかに指定します (ただし、 +//正確な統計的意味はまだ定義していないことに注意してください)。 +//コンピューターのタイミング制御下で運転される列車など、不確実性が 0 になる可能性もありますmessage StopTimeEvent { + //遅延 (秒単位) は、正 (車両が遅れていることを意味する) または + //負 (車両がスケジュールより進んでいることを意味する) になります。遅延が 0 + の場合、車両は時間どおりに到着していることを意味します。 + オプションのint32 delay = 1; + + //イベントは絶対時間として表されます。 + //Unix 時間 (つまり、1970 年 1 月 1 日 00:00:00 + //UTC からの秒数)。 + オプションのint64 time = 2; + + //不確実性が省略されている場合は、不明と解釈されます。 + //予測が不明または不確実すぎる場合は、遅延 (または時間) フィールド + //は空にする必要があります。このような場合、不確実性フィールドは無視されます。 + //完全に確実な予測を指定するには、その不確実性を 0 に設定します。 + オプションint32不確実性 = 3; + + //拡張機能の名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + 拡張機能 1000 ～ 1999; + + //次の拡張機能 ID は、組織によるプライベート使用のために予約されています。 + 拡張機能 9000 ～ 9999; + } + +//旅行中の特定の停車地の到着イベントや出発イベントのリアルタイム更新。更新は、過去のイベントと将来のイベントの両方に提供できます。 +//プロデューサーは、過去のイベントを削除することが許可されていますが、必須ではありません。 + message StopTimeUpdate { + //更新はstop_sequenceまたは + //stop_id のいずれかを介して特定の停車地にリンクされるため、以下のフィールドのいずれかが必ず設定されている必要があります。 + //詳細については、 TripDescriptorのドキュメントを参照してください。 + + //対応する GTFS フィードのstop_times.txtと同じであるしなければならないがあります。 + オプション uint32 stop_sequence = 1; + //対応する GTFS フィードのstops.txtと同じである必要がありしなければならない。 + オプションstring stop_id = 4; + + オプションStopTimeEvent arrive = 2; + オプションStopTimeEvent departure = 3; + + //指定された停車地からの出発後の予想乗車率。 + //将来の停車地に対してのみ提供する必要があります。 + //到着または + //出発の StopTimeEvent なしで destination_occupancy_status を提供するには、 ScheduleRelationshipをNO_DATA に設定します。 + オプションのVehiclePosition. OccupancyStatus destination_occupancy_status = 7; + + //StopTimeEvents と静的スケジュールの関係。 + enum ScheduleRelationship { + //車両は、必ずしもスケジュールの時間に従っているわけではありませんが、静的なスケジュールに従って停車します。 + //到着と出発の少なくとも 1 つを指定する必要があります。この停車場のスケジュールに到着時間と出発時間の両方が含まれている場合は、この更新にも両方が含まれている必要があります。頻度ベースの旅程 (exact_times = 0 の GTFS frequencies.txt ) + //には SCHEDULED 値を指定せず、代わりに UNSCHEDULED を使用する必要があります。 + SCHEDULED = 0; + + //停車地はスキップされます。つまり、車両はこの停車地には停車しません。 + //到着と出発はオプションです。 + SKIPPED = 1; + + //この停車地には StopTimeEvents が指定されていません。 + //この値の主な目的は、旅程の一部についてのみ時間予測を提供することです。つまり、旅程の最後の更新に NO_DATA + //指定子が含まれている場合、旅程の残りの停車地の StopTimeEvents も指定されていないと見なされます。 + //到着も出発も指定しないでください。 + NO_DATA = 2; + + //車両は GTFS で定義された旅程を運行していますfrequencies.txtで exact_times = 0と設定します。 + //この値は、GTFS frequencies.txtで定義されていない旅程、または GTFS frequencies.txtで exact_times = 1.と設定されている旅程には使用しないでください。ScheduleRelationship =UNSCHEDULED とScheduleRelationshipされた StopTimeUpdates + //を含む便では、 TripDescriptorも設定する必要があります。ScheduleRelationship =UNSCHEDULED. + //注: このフィールドはまだ試験段階であり、変更される可能性があります。将来的には正式に採用される可能性があります。 + UNSCHEDULED = 3; + } + オプションのScheduleRelationship schedule_relationship = 5 + [default = SCHEDULED]; + + //停止時刻の更新された値を提供します。 + //注: このmessageはまだ試験段階であり、変更される可能性があります。将来的には正式に採用される可能性があります。 + message StopTimeProperties { + //リアルタイムの停車地割り当てをサポートします。 GTFS のstops.txtで定義された stop_id を参照します。 + //新しい assignment_stop_id によって、エンド ユーザーの旅行体験が GTFS のstop_times.txtで定義された stop_id と比べて大幅に異なることはあってはなりません。つまり、新しい停留所が追加のコンテキストなしでアプリ内に表示された場合は、エンド ユーザーはこの新しい stop_id を`異常な変更`と見なすべきではありません。 + //たとえば、このフィールドは、GTFS stop_times.txtで最初に定義された停留所と同じ駅に属する stop_id を使用して、プラットフォームの割り当てに使用することを目的としています。 + //リアルタイムの到着または出発の予測を提供せずに停留所を割り当てるには、このフィールドに値を入力して、 StopTimeUpdate.schedule_relationship = NO_DATA を設定します。 + //このフィールドに値を入力する場合は、 `StopTimeUpdate.stop_id` を省略し、 `StopTimeUpdate.stop_sequence`のみを使用することをお勧めします。 + //`StopTimeProperties.assigned_stop_id`と`StopTimeUpdate.stop_id` が設定されている場合、 `StopTimeUpdate.stop_id` は`assigned_stop_id`と一致する必要があります。 + //プラットフォームの割り当ては、他の GTFS リアルタイム フィールドにも反映される必要があります + //(例: `VehiclePosition.stop_id`)。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + optional string assignment_stop_id = 1; + + //extensions 名前空間により、サードパーティの開発者はGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 ～ 1999; + + //次の拡張 ID は、組織によるプライベート使用のために予約されています。 + extensions 9000 ～ 9999; + } + + //GTFS stop_times.txt内で定義されている特定のプロパティのリアルタイム更新 + //注: このフィールドはまだ試験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのStopTimeProperties stop_time_properties = 6; + + //extensions 名前空間により、サードパーティの開発者はGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + + //以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; + } + +//旅行の StopTimes への更新 (将来の予測と、場合によっては過去の予測、つまりすでに発生したものの両方)。 +//更新はstop_sequenceで並べ替え、次に指定された停車地までの旅行のすべての停車地に適用する必要があります。 +// +//例 1: +//停車地が 20 か所ある旅行の場合、到着遅延と出発遅延が 0 のStopTimeUpdate が現在の停車地のstop_sequence は、旅行が +//正確に時間通りであることを意味します。 +// +//例 2: +//同じ旅行インスタンスに対して、3 つの StopTimeUpdate が提供されます: +//- stop_sequence 3 の遅延は 5 分 +//- stop_sequence 8 の遅延は 1 分 +//- stop_sequence 10 の遅延時間は未指定 +//これは次のように解釈されます: +//- stop_sequences 3、4、5、6、7 の遅延は 5 分です。 +//- stop_sequences 8、9 の遅延は 1 分です。 +//- stop_sequences 10、...の遅延は不明です。 + StopTimeUpdateが繰り返されます stop_time_update = 2; + +//車両のリアルタイムの進行状況が測定された最新の瞬間 +//将来の StopTimes を推定します。過去の StopTimes が提供される場合、 +//到着/出発時刻はこの値よりも早くなる可能性があります。 POSIX +//時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 + オプションのuint64 timestamp = 4; + +//旅行の現在のスケジュール偏差。遅延は +//GTFS の既存のスケジュール +//を基準に予測が与えられる場合にのみ指定する必要があります。 +// +//遅延 (秒単位) は正 (車両が遅れていることを意味する) または +//負 (車両がスケジュールより進んでいることを意味する) になります。遅延が 0 +//の場合、車両は時間どおりであることを意味します。 +// +//StopTimeUpdates の遅延情報は、旅行レベルの遅延 +//情報よりも優先されます。そのため、旅行レベルの遅延は、 StopTimeUpdate遅延値が指定された次の +//停車地までしか伝播されません。 +// +//フィード プロバイダーは、データの鮮度を評価するために、遅延値が最後に更新された日時を示すTripUpdate.timestamp +//値を提供することを強くお勧めします。 +// +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来 +//正式に採用される可能性があります。 + オプションのint32 delay = 5; + +//迂回がある場合の新しい shape_id など、旅行の更新されたプロパティを定義します。または、重複した旅行のtrip_id、 start_date、および start_time を定義します。 +//注: このmessageはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性がありますmessage TripProperties { + //(CSV) GTFS trips.txt + で定義されている既存の旅行の複製であるが、異なるサービスdateおよび/または時刻 ( TripProperties.start_date フィールドと + //TripProperties.start_time フィールドを使用して定義) に開始する新しい旅行の識別子を定義します。trips の定義を参照してください。(CSV) GTFS のtrip_id 。その値は、(CSV) GTFS で使用される値と異なる必要があります + //。schedule_relationship=DUPLICATED の場合は必須。それ以外の場合は、このフィールドに値を入力してはならず、コンシューマーによって無視されます。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのstring trip_id = 1; + //DUPLICATED 旅行が実行されるサービスdate(YYYYMMDD 形式)。 + //schedule_relationship=DUPLICATED の場合は必須。それ以外の場合は、このフィールドに値を入力してはならず、コンシューマーによって無視されます。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのstringstart_date = 2; + //複製された旅行の出発開始時刻を定義します。(CSV) GTFS の stop_times.departure_time + //の定義を参照してください。複製された旅行の予定到着時刻と出発時刻は、元の旅行の出発時刻とこのフィールド間のオフセット + //に基づいて計算されます。たとえば、GTFS 旅行の停留所 A の出発時刻が 10:00:00、停留所 B の出発時刻が 10:01:00 で、このフィールドに値 + //10:30:00 が設定されている場合、複製された旅行の停留所 B の予定出発時刻は 10:31:00 になります。リアルタイム予測 + //遅延値は、予測時間を決定するために、計算されたスケジュール時間に適用されます。たとえば、停留所 B の出発遅延が 30 の場合、予測される出発時間は 10:31:30 です。リアルタイム予測時間値にはオフセットが適用されず、提供された予測時間を示します。 + //たとえば、停留所 B の出発時間が 10:31:30 の場合、予測される出発時間は 10:31:30 です。このフィールドは、schedule_relationship が DUPLICATED の場合に必須です。それ以外の場合は、このフィールドに値を入力してはならず、コンシューマーによって無視されます。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのstringstart_time = 3; + //旅行の形状が + //(CSV) GTFS で指定された形状と異なる場合に車両の移動経路の形状を指定します。または、乗客の需要に基づいて異なる経路を取る車両など、(CSV) GTFS によって提供されていない場合にリアルタイムで指定します。(CSV) GTFS の trips.shape_id の定義を参照してください。形状が (CSV) GTFS + //でもリアルタイムでも定義されていない場合、形状は不明であると見なされます。このフィールドは、(CSV) GTFS のshapes.txt + //で定義された形状、または (protobuf) リアルタイム フィードの Shape を参照できます。この旅行の停車順序 (停車シーケンス) は + //(CSV) GTFS と同じである必要があります。迂回が発生した場合など、元の旅行の一部であるが、今後は行かなくなる停留所等は、schedule_relationship=SKIPPED としてマークする必要があります。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + オプションのstring shape_id = 4; + + //extensions 名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + + //以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; + } + オプションのTripProperties trip_properties = 6; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//特定の車両のリアルタイム位置情報。 + message VehiclePosition { +//この Trip が使用する Trip車両がサービスを提供している。 +//特定の +//旅行インスタンスで車両を識別できない場合は、空または一部になることがあります。 + オプションのTripDescriptor trip = 1; + +//この旅行を提供している車両に関する追加情報。 + オプションのVehicleDescriptor Vehicle = 8; + +//この車両の現在位置。 + オプションのPosition position = 2; + +//現在の停車地の停車シーケンス インデックス。 +//current_stop_sequence (つまり、それが参照する停車地) の意味は +//current_status によって決まります。 +//current_status がない場合、IN_TRANSIT_TO が想定されます。 + オプションの uint32 current_stop_sequence = 3; +//現在の停車地を識別します。値は、 +//対応する GTFS フィード内のstops.txtと同じである必要があります。 + オプションのstring stop_id = 7; + + enum VehicleStopStatus { + //車両が停車地に到着しようとしています (停車表示 + //では通常、車両のシンボルが点滅します)。 + INCOMING_AT = 0; + + //車両が停車地に停止しています。 + STOPPED_AT = 1; + + //車両が出発し、次の停車地に向かっています。 + IN_TRANSIT_TO = 2; + } +//現在の停車地に関する車両の正確なステータス。 +//current_stop_sequence が指定されていない場合は無視されます。 + オプションのVehicleStopStatus current_status = 4 [default = IN_TRANSIT_TO]; + +//車両の位置が測定された瞬間。 POSIX 時間 +//(つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 + オプションのuint64 timestamp = 5; + +//この車両に影響を与えている混雑レベル。 + enum CongestionLevel { + UNKNOWN_CONGESTION_LEVEL = 0; + RUNNING_SMOOTHLY = 1; + STOP_AND_GO = 2; + CONGESTION = 3; + SEVERE_CONGESTION = 4;//車を離れる人々。 + } + オプションのCongestionLevel concentration_level = 6; + +//車両または客車の乗客占有状態。 +//個々のプロデューサーは、すべてのOccupancyStatus値を公開することはできません。したがって、コンシューマー +//は、 OccupancyStatusOccupancyStatusを表す必要があります。同様に、プロデューサーは、実際の車両の乗車状態に対応するOccupancyStatus値を使用する必要があります。 +//乗客の乗車レベルを線形スケールで記述するには、 `occupancy_percentage`を参照してください。 +//このフィールドはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + enum OccupancyStatus { + //車両または客車はほとんどの基準で空であると見なされ、乗客はほとんどまたはまったくいませんが、乗客はまだ受け入れています。 + EMPTY = 0; + + //車両または客車には多数の座席があります。 + //このカテゴリに該当するほど十分に大きいと見なされる利用可能な座席の総数に対する空席の数は、フィード プロデューサーの裁量で決定されます。 + MANY_SEATS_AVAILABLE = 1; + + //車両または客車には比較的少ない座席があります。 + //このカテゴリに該当するほど十分に小さいと見なされる利用可能な座席の総数に対する空席の数は、フィード プロデューサーの裁量で決定されます。 + FEW_SEATS_AVAILABLE = 2; + + //車両または客車は現在、立っている乗客のみを収容できます。 + STANDING_ROOM_ONLY = 3; + + //車両または客車は現在、立っている乗客のみを収容でき + //スペースが限られています。 + CRUSHED_STANDING_ROOM_ONLY = 4; + + //車両または客車はほとんどの基準で満員と見なされますが、 + //乗客の乗車を許可している可能性があります。 + FULL = 5; + + //車両または客車は乗客を受け入れていませんが、通常は乗客の乗車を受け入れます。 + NOT_ACCEPTING_PASSENGERS = 6; + + //車両または客車には現在利用可能な占有データがありません。 + NO_DATA_AVAILABLE = 7; + + //車両または客車は乗車できず、乗客を受け入れることはありません。 + //特別な車両または客車（機関車、保守車両など）に役立ちます。 + NOT_BOARDABLE = 8; + + } +//multi_carriage_status に客車ごとのOccupancyStatusが設定されている場合、 +//このフィールドは車両全体を記述する必要があります。乗客を受け入れるすべての車両を考慮します。 + オプションのOccupancyStatus occupancy_status = 9; + +//車両内の乗客の占有率を示すパーセンテージ値。 +//値は小数点なしの整数で表されます。0 は 0%、100 は 100% を意味します。 +//値 100 は、座席と立席の両方の定員を含み、現在の運行規則で許可されている、車両が設計された最大占有率を表します。 +//設計された最大定員よりも多くの乗客がいる場合、値は 100 を超えることがあります。 +//occupancy_percentage の精度は、個々の乗客が車両に乗り降りするのを追跡できないほど低くする必要があります。 +//multi_carriage_status に車両ごとの occupancy_percentage が設定されている場合、 +//このフィールドは、乗客を受け入れるすべての車両を考慮した車両全体を記述する必要があります。 +//このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプション uint32 occupancy_percentage = 10; + +//複数の客車で構成されている車両に使用される、客車固有の詳細 +//このmessage/フィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + message CarriageDetails { + + //客車の識別。車両ごとに一意である必要があります。 + オプションのstringid = 1; + + //客車を識別するために乗客に表示される、ユーザーに表示されるラベル。例: "7712"、"Car ABC-32" など... + //このmessage/フィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのstringlabel = 2; + + //この車両のこの客車の占有状況 + //このmessage/フィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのOccupancyStatus occupancy_status = 3 [default = NO_DATA_AVAILABLE]; + + //この車両のこの特定の車両の占有率。 + //`VehiclePosition.occupancy_percentage`と同じルールに従います + //この特定の車両のデータが利用できない場合は -1 (それ以外の場合は protobuf のデフォルトが 0 になるため) + //このmessage/フィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションint32 occupancy_percentage = 4 [default = -1]; + + //車両のCarriageDetailsリスト内の他の車両に対するこの車両の順序を識別します。 + //移動方向の最初の車両の値は1.である必要があります。 + //2 番目の値は移動方向の 2 番目の車両に対応し、値 2 である必要があります。以下同様です。 + //たとえば、移動方向の最初の車両の値は1.です。 + //移動方向の 2 番目の車両の値が 3 の場合、 + //コンシューマーはすべての車両のデータ (つまり、multi_carriage_details フィールド) を破棄します。 + //データのない車両は、有効な carrier_sequence 番号で表す必要があり、データのないフィールドは省略する必要があります (または、それらのフィールドを含めて`データなし`に設定することもできます)。値)。 + //このmessage/フィールドはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + オプション uint32 キャリッジ シーケンス = 5; + + //拡張機能の名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + 拡張機能 1000 ～ 1999; + + //次の拡張機能 ID は、組織による私的使用のために予約されています。 + 拡張機能 9000 ～ 9999; + } + +//この車両の複数の車両の詳細。 +//最初の出現は、最初の車両を表します。 + + +//現在の移動方向に基づいて、車両の車両を特定します。 +//multi_carriage_details +//フィールドの出現回数は、車両の車両数を表します。 +//これには、機関車や保守車両などの乗車不可の車両も含まれます。これらは、プラットフォームのどこに立つべきかについて乗客に貴重な情報を提供するためです。 +//このmessageフィールドはまだ実験的なものであり、変更される可能性があります。将来、正式に採用される可能性があります。 + repeat CarriageDetails multi_carriage_details = 11; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張機能 ID は、組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//公共交通機関ネットワークで何らかのインシデントが発生したことを示すアラート。 + message Alert { +//アラートをユーザーに示す時刻。指定されていない場合は、 +//アラートはフィードに表示される限り表示されます。 +//複数の範囲が指定されている場合は、そのすべての範囲でアラートが表示されます。 + repeat TimeRange active_period = 1; + +//このアラートをユーザーに通知する必要があるエンティティ。 + repeat EntitySelector inform_entity = 5; + +//このアラートの原因。 cause_detail が含まれている場合は、Cause も含める必要があります。 + enum Cause { + UNKNOWN_CAUSE = 1; + OTHER_CAUSE = 2; //機械で表現できません。 + TECHNICAL_PROBLEM = 3; + STRIKE = 4; //公共交通機関の従業員が仕事を停止しました。 + DEMONSTRATION = 5; //人々が道路を封鎖しています。 + ACCIDENT = 6; + HOLIDAY = 7; + WEATHER = 8; + MAINTENANCE = 9; + CONSTRUCTION = 10; + POLICE_ACTIVITY = 11; + MEDICAL_EMERGENCY = 12; + } + オプションの Cause cause = 6 [default = UNKNOWN_CAUSE]; + +//この問題が影響を受けるエンティティに与える影響はどのようなものですか。 effect_detail が含まれている場合は、Effect も含める必要があります。 + enum Effect { + NO_SERVICE = 1; + REDUCED_SERVICE = 2; + + //重大な遅延は考慮しません。検出が難しく、ユーザーへの影響が小さく、頻度が高すぎるため、結果が乱雑になります。 + SIGNIFICANT_DELAYS = 3; + + DETOUR = 4; + ADDITIONAL_SERVICE = 5; + MODIFIED_SERVICE = 6; + OTHER_EFFECT = 7; + UNKNOWN_EFFECT = 8; + STOP_MOVED = 9; + NO_EFFECT = 10; + ACCESSIBILITY_ISSUE = 11; + } + オプションの Effect effect = 7 [default = UNKNOWN_EFFECT]; + +//パフォーマンスに関する追加情報を提供する URL alert. + オプションのTranslatedString url = 8; + +//アラート ヘッダー。アラート テキストの短い要約がプレーン テキストとして含まれています。 + オプションのTranslatedString header_text = 10; + +//アラートの完全な説明がプレーン テキストとして含まれています。 +//説明の情報は、ヘッダーの情報に追加する必要があります。 + オプションのTranslatedString description_text = 11; + +//テキスト読み上げの実装で使用されるアラート ヘッダーのText。このフィールドは、header_text のテキスト読み上げバージョンです。 + オプションのTranslatedString tts_header_text = 12; + +//テキスト読み上げの実装で使用されるアラートの完全な説明のText。このフィールドは、description_text の音声合成バージョンです。 + オプションのTranslatedString tts_description_text = 13; + +//このアラートの重大度。 + enum SeverityLevel { + UNKNOWN_SEVERITY = 1; + INFO = 2; + WARNING = 3; + SEVERE = 4; + } + + オプションのSeverityLevel severity_level = 14 [default = UNKNOWN_SEVERITY]; + +//アラート テキストとともに表示されるTranslatedImage 。迂回、駅の閉鎖などのアラート効果を視覚的に説明するために使用されます。画像はアラートの理解を深めるものでなければなりません。画像内で伝えられる重要な情報は、アラート テキストにも含まれている必要があります。 +//次の種類の画像は推奨されません : 主にテキストを含む画像、追加情報を含まないマーケティングまたはブランド画像。 +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのTranslatedImage image = 15; + +//`image`フィールドでリンクされた画像の外観を説明するText(例: 画像を表示できない場合 +//またはアクセシビリティ上の理由でユーザーが画像を見ることができない場合)。画像の代替テキストについては、HTML 仕様を参照してください - https://html.spec.whatwg.org/#alt. +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのTranslatedString image_alternative_text = 16; + + +//アラートの原因の説明。Cause よりも具体的な機関固有の言語を使用できます。cause_detail が含まれている場合は、Cause も含める必要があります。 +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのTranslatedString cause_detail = 17; + +//アラートの効果の説明。Effect よりも具体的な機関固有の言語を使用できます。 effect_detail が含まれる場合、Effect も含まれている必要があります。 +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのTranslatedString effect_detail = 18; + +//extensions 名前空間により、サードパーティの開発者はGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張機能 ID は、あらゆる組織によるプライベート使用のために予約されています。 + extensions 9000 から 9999; +} + +// +//上記で使用されている低レベルのデータ構造。 +// + +//時間間隔。 ’t’ が開始時刻以上で終了時刻未満の場合、その間隔は時刻 ’t’ にアクティブであるとみなされます。 + message TimeRange { +//開始時刻、POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 +//指定がない場合、間隔はマイナス無限大で始まります。 + 省略可能なuint64 start = 1; + +//終了時刻、POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 +//指定がない場合、間隔はプラス無限大で終了します。 + 省略可能なuint64 end = 2; + +//拡張機能の名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + 拡張機能 1000 から 1999; + +//次の拡張機能 ID はプライベート用に予約されていますあらゆる組織で使用できます。 + extensions 9000 to 9999; +} + +//位置。 + message Position { +//WGS-84 座標系での北度。 + required float latitude = 1; + +//WGS-84 座標系での東度。 + required float longitude = 2; + +//方位 (度単位、北から時計回り、つまり 0 が北、90 が東)。 +//これはコンパス方位、または次の停車地または中間地点への方向になります。 +//これは、以前の位置のシーケンスから推測される方向であってはなりません。これは、以前のデータから計算できます。 + オプションfloat bearing = 3; + +//走行距離計の値 (メートル単位)。 + オプション double odometer = 4; +//車両によって測定された瞬間速度 (メートル/秒単位)。 + オプションfloat speed = 5; + +//extensions 名前空間により、サードパーティ デベロッパーはGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価します。 + 拡張機能 1000 から 1999; + +//以下の拡張機能 ID は、あらゆる組織による私的使用のために予約されています。 + 拡張機能 9000 から 9999; +} + +//GTFS 旅行のインスタンス、またはルートに沿った旅行のすべてのインスタンスを識別する記述子。 +//- 単一の旅行インスタンスを指定するには、 trip_id (および必要な場合はstart_time) を設定します。route_id も設定する場合は、特定の旅行に対応するものと同じにする必要がありますroute_id//- 特定のルートに沿ったすべての旅行を指定するには、 route_idのみを設定します。trip_idが不明な場合は、 TripUpdateの停止シーケンス ID では不十分であり、stop_id も提供する必要があることに注意してください。 +// 加えて、絶対的な到着/出発時刻も提供する必要があります。 + message TripDescriptor { +//このセレクタが参照する GTFS フィードからのtrip_id//頻度ベースでない旅行の場合、このフィールドは旅行を一意に識別するのに十分です。頻度ベースの旅行の場合、start_time と start_date も +//必要になることがあります。schedule_relationship がTripUpdate内で DUPLICATED される場合、 trip_id は複製される +//静的 GTFS からの旅行を識別します。schedule_relationship がVehiclePosition内で DUPLICATED される場合、 trip_idは新しい複製旅行を識別し、対応するTripUpdateの値を含める必要があります。TripProperties。 trip_id. + オプションのstringtrip_id = 1; + +//このセレクタが参照する GTFS のroute_idオプションのstringroute_id = 5; + +//GTFS フィードtrips.txtファイルの direction_id。 +//このセレクタが参照する旅行の移動方向を示します。 + オプションの uint32 direction_id = 6; + +//この旅行インスタンスの当初の予定開始時刻。 +//trip_id が非頻度ベースの旅行に対応する場合、このフィールド +//は省略するか、GTFS フィードの値と同じにする必要があります。 +//trip_id が頻度ベースの旅行に対応する場合、旅行の更新と車両の位置に対して start_time を指定する必要があります。旅行が exact_times=1 の GTFS レコードに対応する場合、start_time は対応する期間のfrequencies.txtの start_time より headway_secs の倍数 +//(0 を含む) 後でなければなりません。旅行が exact_times=0 に該当する場合、start_time は任意で、当初は旅行の最初の出発時刻と想定されます。いったん確立されると、この頻度ベースの旅行の start_time は、最初の出発時刻が変更された場合でも不変と見なされます。その時間変更は、代わりにStopTimeUpdateに反映されます。 +//フィールドの形式とセマンティクスは、GTFS/frequencies.txt/start_time と同じです (例: 11:15:35 または 25:15:35)。 + オプションのstringstart_time = 2; +//この旅行インスタンスの予定開始date。 +//翌日の予定旅行と重なるほど遅れている旅行を明確にするために指定するしなければならない。たとえば、毎日 8:00 +//と 20:00 に出発し、12 時間遅れている列車の場合、同じ時間に 2 つの異なる +//旅行が存在することになります。 +//このフィールドは提供できますが、そのような +//衝突が不可能なスケジュールでは必須ではありません。たとえば、1 時間遅れの車両はスケジュールとは関係がないと見なされる、1 時間ごとの +//スケジュールで実行されるサービスなどです。 +//YYYYMMDD 形式です。 + オプションのstringstart_date = 3; + +//この旅行と静的スケジュールの関係。旅程が +//一時的なスケジュールに従って行われ、GTFS に反映されていない場合は、 +//SCHEDULED としてマークするのではなく、おそらく ADDED としてマークします。 + enum ScheduleRelationship { + //GTFS scheduleに従って実行されている旅程、または関連付けられるほどスケジュールされた旅程に近い + //旅程。 + SCHEDULED = 0; + + //故障した車両の交換や突然の乗客の増加に対応するためなど、実行スケジュールに加えて追加された旅程。 + //注: 現在、このモードを使用するフィードの動作は指定されていません。 GTFS GitHub + //[(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221) + //[(3)](https://github.com/google/transit/pull/219) では、ADDED の旅程を完全に指定するか廃止するかについて議論されており、 + //議論が確定した時点でドキュメントが更新されます。 + ADDED = 1; + + //スケジュールが関連付けられていない状態で運行されている旅程 (GTFS frequencies.txt exact_times=0)。 + //ScheduleRelationship =UNSCHEDULED の便では、すべての StopTimeUpdates も設定する必要があります。 ScheduleRelationship=UNSCHEDULED. + UNSCHEDULED = 2; + + //スケジュールには存在していたが削除された旅程。 + CANCELED = 3; + + //使用しないでください。後方互換性のためだけに使用します。 + REPLACEMENT = 5 [deprecated=true]; + + //故障した車両の交換や突然の乗客の増加に対応するためなど、TripPropertiesTripUpdateに加えて追加された旅程。TripUpdate.TripProperties.trip_id、 TripUpdate, + //およびTripUpdateとともに使用して、静的 GTFS から既存の旅程をコピーしますが、開始日は別のサービスdateTripProperties/または時刻にtrip_idます。(CSV) GTFS + //( TripPropertiesまたはcalendar_dates.txt内) の元の旅程に関連するサービスが今後 30 日以内に運行される場合、旅程の複製が許可されます。複製する旅程は、 TripUpdateによって識別trip_idれます。この列挙体は、 TripDescriptorによって参照される既存の旅程を変更しtrip_idん。プロデューサーが元の旅程をキャンセルする場合は、CANCELED または DELETED の値をTripUpdate別のTripUpdateを公開する必要があります。GTFS frequencies.txtで定義され、exact_times が空または 0 にTripDescriptor便は複製できません。新しい旅程のVehiclePositionには、 TripUpdateとtrip_idVehiclePositionの一致する値が含まれている必要があります。 ScheduleRelationship + //も DUPLICATED に設定する必要があります。 + //重複した旅行を表すために ADDED 列挙を使用していた既存のプロデューサーとコンシューマーは、 + //移行ガイド (https://github.com/google/transit/tree/master/gtfs-realtime/spec/en/examples/migration-duplicated.md) + //に従って DUPLICATED 列挙に移行する必要があります。 + //注: このフィールドはまだ試験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + DUPLICATED = 6; + + + //スケジュールには存在していたが削除された旅行で、ユーザーには表示してはならない。 + //交通機関プロバイダーが、対応する旅行に関する情報を消費アプリケーションから完全に削除し、乗客に旅行がキャンセルされたと表示されないようにするには、CANCELED ではなく DELETED を使用する必要があります。たとえば、旅行が完全に別の旅行に置き換えられる場合などです。 + //この指定は、複数の旅行がキャンセルされ、代替サービスに置き換えられる場合に特に重要になります。 + //キャンセルに関する明示的な情報を消費者に示すと、より重要なリアルタイム予測が妨げられます。 + //注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + DELETED = 7; + } + オプションScheduleRelationship schedule_relationship = 4; + + message ModifiedTripSelector { + //含まれるTripModificationsオブジェクトがこの旅行に影響を与えるFeedEntityの ’id’。 + オプションstring modifications_id = 1; + + //modifications_id によって変更される GTFS フィードのtrip_idオプションstring affected_trip_id = 2; + } + オプション ModifiedTripSelector modified_trip = 7; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//実行中の車両の識別情報旅行。 + message VehicleDescriptor { +//車両の内部システム ID。車両ごとに一意である必要があり、システム内を移動する際に車両を追跡するために使用できます。 + オプションのstringid = 1; + +//ユーザーに表示されるラベル。つまり、正しい車両を識別するために乗客に表示する必要があるもの。 + オプションのstringlabel = 2; + +//車両のナンバー プレート。 + オプションのstringlicense_plate = 3; + + enum WheelchairAccessible { + //旅行には車椅子でのアクセシビリティに関する情報がありません。 + //これは **デフォルト** の動作です。静的 GTFS に + //_wheelchair_accessible_ 値が含まれている場合、上書きされません。 + NO_VALUE = 0; + + //旅行にアクセシビリティ値がありません。 + //この値により、GTFS の値が上書きされます。 + UNKNOWN = 1; + + //旅行に車椅子でアクセスできます。 + //この値により、GTFS の値が上書きされます。 + WHEELCHAIR_ACCESSIBLE = 2; + + //旅行に車椅子でアクセスできません。 + //この値により、GTFS の値が上書きされます。 + WHEELCHAIR_INACCESSIBLE = 3; + } + オプションWheelchairAccessible wheels_accessible = 4 [default = NO_VALUE]; + +//拡張機能の名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + 拡張機能1000 から 1999; + +//次の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + 拡張 9000 から 9999; +} + +//GTFS フィード内のエンティティのセレクターmessage EntitySelector { +//フィールドの値は、 +//GTFS フィード内の適切なフィールドに対応している必要があります。 +//少なくとも 1 つの指定子を指定する必要があります。複数指定した場合は、 +//一致は指定されたすべての指定子に適用する必要があります。 + オプションのstringagency_id = 1; + オプションのstringroute_id = 2; +//GTFS の route_type に対応します。 + オプションのint32 route_type = 3; + オプションのTripDescriptor trip = 4; + オプションのstringstop_id = 5; +//GTFS trips.txtの trip direction_id に対応します。指定されている場合は、 +//route_idも指定する必要があります。 + オプション uint32 direction_id = 6; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張 ID は、組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//テキストまたは URL のスニペットの言語ごとのバージョンを含む国際化message。 +//messageから文字列の 1 つが取得されます。解決は次のように進行します: +//1. UI 言語が翻訳の言語コードと一致する場合、 +// 最初に一致する翻訳が選択されます。 +//2.デフォルトの UI 言語 (例: 英語) が翻訳の言語コードと一致する場合、 +// 最初に一致する翻訳が選択されます。 +//3.翻訳に言語コードが指定されていない場合は、その翻訳が選択されます。 + message TranslatedString { + message Translation { + //messageを含む UTF-8string。 + required string text = 1; + //BCP-47 言語コード。言語が不明な場合、またはフィードに対して i18n がまったく行われない場合は省略できます。最大 1 つの翻訳に、未指定の言語タグを付けることができます。 + オプションのstringlanguage = 2; + + //extensions 名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + + //以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; + } +//少なくとも 1 つの翻訳を指定する必要があります。 + 繰り返し Translation translation = 1; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//国際化された画像には、画像にリンクする URL の言語別バージョン +//およびメタ情報 +//messageの画像のうち 1 つだけがコンシューマーによって保持されます。解決は次のように行われます +//: +//1. UI 言語が翻訳の言語コードと一致する場合 +// 最初に一致する翻訳が選択されます。 +//2.デフォルトの UI 言語 (例: 英語) が翻訳の言語コードと一致する場合 +// 最初に一致する翻訳が選択されます。 +//3.翻訳に未指定の言語コードがある場合、その翻訳が選択されます +// 注: このフィールドはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + message TranslatedImage { + message LocalizedImage { + //画像にリンクする URL を含む文字列 + //リンクされる画像は 2MB 未満である必要があります。 + //画像が大幅に変更され、コンシューマー側で更新が必要になる場合、プロデューサーは URL を新しいものに更新する必要があります。 + //URL は http://または https://を含む完全修飾 URL である必要があり、URL 内のすべての特殊文字は正しくエスケープする必要があります。完全修飾 URL 値の作成方法については、次の http://www.w3.org/Addressing/URL/4_URI_Recommentations.html を参照してください。 + 必須のstringurl = 1; + + //表示する画像のタイプを指定するための IANA メディア タイプ。 + //タイプは "image/" で始まる必要があります + 必須のstringmedia_type = 2; + + //BCP-47 言語コード。言語が不明な場合、またはフィードに対して i18n がまったく行われない場合は省略できます。最大で 1 つの翻訳に、未指定の言語タグを付けることができます。 + オプションのstringlanguage = 3; + + + //extensions 名前空間により、サードパーティ デベロッパーは + //GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + + //以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; + } +//ローカライズされた画像を少なくとも 1 つ提供する必要があります。 + repeat LocalizedImage localized_image = 1; + +//extensions 名前空間により、サードパーティ デベロッパーは +//GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から9999; +} + +//迂回など、車両が (CSV) GTFS の一部ではない場合に車両がたどる物理的な経路を記述します。ルート形状は便に属し、一連のシェイプ ポイントで構成されます。 +//ポイントを順番にトレースすると、車両の経路が提供されます。ルート形状は停留所等の位置を正確に横切る必要はありませんが、旅行のすべての停留所等 は、その旅行のシェイプからわずかな距離内、つまりシェイプ ポイントを接続する直線セグメントの近くに配置する必要があります。 +//注: このmessageはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + message Shape { +//シェイプの識別子。 (CSV) GTFS で定義されている shape_id と異なるしなければならない。 +//このフィールドは reference.md に従って必須ですが、"必須は永久に有効" であるため、ここではオプションとして指定する必要があります。 +//https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules を参照してください。 +//注: このフィールドはまだ試験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 + オプションのstringshape_id = 1; + +//シェイプのエンコードされたポリライン表現。このポリラインには少なくとも 2 つのポイントが含まれている必要があります。 +//エンコードされたポリラインの詳細については、https://developers.google.com/maps/documentation/utilities/polylinealgorithm を参照してください +//このフィールドは reference.md に従って必須ですが、`必須は永久に有効`であるため、ここではオプションとして指定する必要があります +//https://developers.google.com/protocol-buffers/docs/proto#specifying_field_rules を参照してください +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + オプションのstringencoding_polyline = 2; + +//extensions 名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//旅行が運行される停留所を記述します。すべてのフィールドは、GTFS-Static 仕様で説明されているとおりです。 +//注: このmessageはまだ試験段階であり、変更される可能性があります。将来的には正式に採用される可能性があります。 + message Stop { + enum WheelchairBoarding { + UNKNOWN = 0; + AVAILABLE = 1; + NOT_AVAILABLE = 2; + } + + オプションのstringstop_id = 1; + オプションのTranslatedString stop_code = 2; + オプションのTranslatedString stop_name = 3; + オプションのTranslatedString tts_stop_name = 4; + オプションのTranslatedString stop_desc = 5; + オプションのfloat stop_lat = 6; + オプションのfloat stop_lon = 7; + オプションのstringzone_id = 8; + オプションのTranslatedString stop_url = 9; + オプションのstringparent_station = 11; + オプションのstringstop_timezone = 12; + オプションのWheelchairBoarding wheels_boarding = 13 [default = UNKNOWN]; + オプションのstringlevel_id = 14; + オプションのTranslatedString platform_code = 15; + +//extensions 名前空間を使用すると、サードパーティの開発者が +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//以下の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//注: このフィールドはまだ試験段階であり、変更される可能性があります。将来、正式に採用される可能性があります。 + message TripModifications { +//`Modification`messageは、`start_stop_selector` から始まる、影響を受ける各旅程の n 個の停車時刻の範囲を置き換えます。 + message Modification { + //この変更の影響を受ける元の旅程の最初の stop_time の停車セレクター。 + //`end_stop_selector` と組み合わせて使用​​します。 + //`start_stop_selector` は必須であり、`travel_time_to_stop` で使用される参照停車地を定義するために使用されます。 + オプションのStopSelector start_stop_selector = 1; + + //この変更によって影響を受ける元の旅行の最後の停車地の停車地セレクター。 + //選択は包括的であるため、その変更によって 1 つの stop_time のみが置き換えられる場合は、`start_stop_selector` と `end_stop_selector` は同等である必要があります。 + //stop_time が置き換えられない場合は、`end_stop_selector` を指定しないでください。それ以外の場合は必須です。 + オプションのStopSelector end_stop_selector = 2; + + //この変更の終了後にすべての出発時刻と到着時刻に追加する遅延の秒数。 + //同じ旅行に複数の変更が適用されると、旅行が進むにつれて遅延が累積します。 + オプションint32 propagated_modification_delay = 3 [デフォルト = 0]; + + //元の旅行の停留所を置き換える代替停留所のリスト。 + //新しい停車時刻の長さは、置き換えられた停車時刻の数より短くなったり、同じになったり、長くなったりする場合があります。 + 繰り返しReplacementStop replacement_stops = 4; + + //ユーザー向けのコミュニケーション用にこのModificationを説明する`Alert`を含む`FeedEntity`messageの`id`値。 + オプションのstringservice_alert_id = 5; + + //このタイムスタンプは、変更が最後に変更された瞬間を識別します。 + //POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 + オプションのuint64 last_modified_time = 6; + + //拡張機能の名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や + //仕様の変更を追加および評価できます。 + 拡張機能 1000 から 1999; + + //次の拡張機能 ID は、あらゆる組織によるプライベート使用のために予約されています。 + 拡張機能 9000 から 9999; + } + +message SelectedTrips { + //この置換の影響を受ける、新しい`shape_id`がすべて同じである旅行のリスト。 + 繰り返しstringtrip_ids = 1; + //このSelectedTrips内の変更された旅行の新しいシェイプのID//GTFS-RT Shapemessageを使用して追加された新しいシェイプ、または GTFS-Static フィードのshapes.txtで定義されている既存のシェイプを参照する場合があります。 + オプションのstringshape_id = 2; + + //extensions 名前空間により、サードパーティの開発者は + //GTFS Realtime仕様を拡張して、新機能や + //仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + + //次の拡張 ID は、あらゆる組織によるプライベート使用のために予約されています。 + extensions 9000 から 9999; +} + + //このTripModificationsの影響を受ける選択された旅行のリスト。 + 繰り返しSelectedTrips selected_trips = 1; + +//trip_ids で定義されたtrip_idのリアルタイム旅行記述子の開始時刻のリスト。 +//頻度ベースの旅行でtrip_idの複数の出発をターゲットにするのに便利です。 + repeated string start_times = 2; + +//変更が発生する日付 (YYYYMMDD 形式)。プロデューサーは、今後 1 週間以内に発生する迂回のみを送信するするべきである。 +//提供された日付はユーザー向けの情報として使用しないでください。ユーザー向けの開始日と終了dateを提供する必要がある場合は、リンクされたサービス アラートで `service_alert_id` を使用して提供できます。 + repeated string service_dates = 3; + +//影響を受ける旅行に適用する変更のリスト。 + repeated Modification modifications = 4; + +//拡張機能の名前空間により、サードパーティの開発者は +//GTFS Realtime仕様を拡張して、新機能や +//仕様の変更を追加および評価できます。 + 拡張機能 1000 から 1999; + +//以下の拡張機能 ID は、 + +あらゆる組織による私的使用のために提供されます。 + 拡張子 9000 から 9999; +} + +//注: このフィールドはまだ実験段階であり、変更される可能性があります。将来正式に採用される可能性があります。 +//停留所シーケンスまたは stop_id で停留所を選択します。 2 つの値のうち少なくとも 1 つは指定する必要があります。 + message StopSelector { +//対応する GTFS フィードのstop_times.txtと同じであるしなければならない。 + オプションの uint32 stop_sequence = 1; +//対応する GTFS フィードのstops.txtと同じであるしなければならない。 + オプションのstring stop_id = 2; + +//extensions 名前空間により、サードパーティのデベロッパーは +//GTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張 ID は、あらゆる組織による私的使用のために予約されています。 + extensions 9000 から 9999; +} + +//注: このフィールドはまだ試験段階であり、変更される可能性があります。将来正式に採用される可能性がありますmessage ReplacementStop { +//この停留所への到着時刻と参照停留所への到着時刻の差 (秒単位)。参照停留所は、start_stop_selector の前の停留所です。変更が旅程の最初の停車地から始まる場合、旅程の最初の停車地が参照停車地になります。 +//この値は単調に増加するしなければならないがあり、元の旅程の最初の停車地が参照停車地である場合は負の数のみにすることができます。 + オプションint32 travel_time_to_stop = 1; + +//旅程で訪問される代替の停車地ID-RT Stopmessageを使用して追加された新しい停車地、または GTFS-Static フィードのstops.txtで定義されている既存の停車地を参照する場合があります。停留所には location_type=0 (ルート可能な停留所)がしなければならない。 + オプションのstringstop_id = 2; + +//extensions 名前空間により、サードパーティの開発者はGTFS Realtime仕様を拡張して、新機能や仕様の変更を追加および評価できます。 + extensions 1000 から 1999; + +//次の拡張 ID は、あらゆる組織によるプライベート使用のために予約されています。 + extensions 9000 から 9999; +} +``` + diff --git a/docs/ja/documentation/realtime/realtime_best_practices.md b/docs/ja/documentation/realtime/realtime_best_practices.md new file mode 100644 index 000000000..6f5bae02e --- /dev/null +++ b/docs/ja/documentation/realtime/realtime_best_practices.md @@ -0,0 +1,157 @@ +# GTFS Realtimeのベスト プラクティス + +## はじめに + +これらは、[GTFS Realtime](../reference) データ形式でリアルタイムの公共交通機関情報を記述するための推奨プラクティスです。 + +### ドキュメントの構造 + +推奨プラクティスは、2 つの主要なセクションに分かれています + +* __[メッセージ別にまとめたプラクティス推奨事項](#practice-recommendations-organized-by-message):__ 推奨事項は、公式のGTFS Realtimeリファレンスに記載されているのと同じ順序で、messageとフィールド別にまとめられています。 +* __[ケース別にまとめたプラクティス推奨事項](#practice-recommendations-organized-by-use-case):__ 頻度ベースのサービス (対スケジュール ベースのサービス) などの特定のケースでは、プラクティスを複数のメッセージとフィールド、および対応するGTFS scheduleデータに適用する必要がある場合があります。このセクションでは、このような推奨事項をまとめています。 + +### フィード公開と一般的なプラクティス + +* フィードは、公開された永続的な URL で公開する必要があります +* URL は、フィードにアクセスするためにログインする必要なく、直接アクセスできる必要があります。必要に応じて API キーを使用できますが、API キーの登録は自動化され、すべての人が利用できるようにする必要があります。 +* フィードの反復にわたって、 GTFS Realtimeフィード内の永続的な識別子（id フィールド）を維持します（例: FeedEntity.id、 VehicleDescriptor.id、 CarriageDetails.id）。 +* GTFS Realtimeフィードは、少なくとも 30 秒ごとに 1 回、またはフィード内に表示される情報（車両の位置）が変更されるたびに、どちらかの頻度が高いほうで更新する必要があります。VehiclePositions は他のフィード エンティティよりも頻繁に変更される傾向があるため、できるだけ頻繁に更新する必要があります。コンテンツが変更されていない場合は、そのタイムスタンプの時点で情報がまだ関連していることを反映する新しい`FeedHeader.timestamp`でフィードを更新する必要があります。 +* GTFS Realtimeフィード内のデータは、ルート更新情報と車両位置の場合は 90 秒以内、サービス アラートの場合は 10 分以内である必要があります。たとえば、プロデューサーが`FeedHeader.timestamp`を` 30 秒ごとに継続的に更新している場合でも、そのフィード内の車両位置の経過時間は 90 秒以内である必要があります。 +* GTFS Realtimeデータをホストするサーバーは信頼性が高く、有効な形式の protobuf エンコードされたレスポンスを一貫して返す必要があります。応答の 1% 未満が無効である必要があります (protobuf エラーまたは取得エラー)。 +* GTFS Realtimeデータをホストするウェブ サーバーは、ファイルの変更dateを正しく報告するように設定する必要があります (HTTP/1.1- Request for Comments 2616、セクション 14.29 を参照)。これにより、消費者は`If-Modified-Since` HTTP ヘッダーを活用できます。これにより、変更されていないフィード コンテンツの転送が回避され、プロデューサーとコンシューマーの帯域幅が節約されます。 +* フィードは、指定された URL で HTTP リクエストを介してクエリされた場合、デフォルトでプロトコル バッファでエンコードされたフィード コンテンツを提供する必要があります。コンシューマーは、プロトコル バッファでエンコードされたコンテンツを受信するために特別な HTTP 受け入れヘッダーを定義する必要はありません。 +* プロトコル バッファが [オプションの値](https://developers.google.com/protocol-buffers/docs/proto#optional) をエンコードする方法のため、 GTFS Realtimeフィードからデータを読み取る前に、コンシューマーはプロトコル バッファによって生成された`hasX()`() ` メソッドを使用して値の存在を確認してからその値を使用し、 `hasX()`が` true の場合のみ値を使用する必要があります ( `X`はフィールド名)。`hasX ()`hasX()`が`false`を返す場合は、 `gtfs-realtime.proto`値で定義されているそのフィールドのデフォルト値が想定されます。コンシューマーが最初に`hasX()`メソッドをチェックせずに値を使用すると、プロデューサーによって意図的に公開されていないデフォルト データを読み取る可能性があります。 +* フィードの整合性を確保するため、フィードでは HTTP (暗号化なし) ではなく HTTPS を使用する必要があります。 +* フィードは、付随する静的 GTFS データセットに含まれる旅行の大部分をカバーする必要があります。特に、高密度で交通量の多い市街地と混雑したルートのデータを含める必要があります。 + +## メッセージ別に整理された実践的な推奨事項 + +### FeedHeader + +| フィールド名 | 推奨事項 | +|---|---| +| `gtfs_realtime_version` | 現在のバージョンは`2.0`です。GTFS GTFS Realtimeの初期バージョンでは、さまざまな交通状況を適切に表すために必要なすべてのフィールドが要求されなかったため、すべてのGTFS Realtimeフィードは`2.0`以上である必要があります。| +| `timestamp` | このタイムスタンプは、2 つの連続したフィード反復間で減少してはなりません。| +| |フィード コンテンツが変更された場合、このタイムスタンプ値は常に変更される必要があります。つまり、ヘッダー`timestamp`ド` コンテンツを変更してはなりません。

*よくある間違い* - ロードバランサの背後にGTFS Realtimeフィードのインスタンスが複数ある場合、各インスタンスがリアルタイム データ ソースから情報を取得し、わずかに同期がずれた状態で消費者に公開している可能性があります。GTFSGTFS Realtimeの消費者が 2 つのリクエストを連続して行い、各リクエストが異なるGTFS Realtimeフィード インスタンスによって処理された場合、同じフィード コンテンツが異なるタイムスタンプで消費者に返される可能性があります。

*考えられる解決策* - プロデューサーは`Last-Modified` HTTP ヘッダーを提供し、コンシューマーは最新の`If-Modified-Since` HTTP ヘッダーを渡すことで、古いデータを受け取らないようにする必要があります。

*考えられる解決策* - HTTP ヘッダーを使用できない場合は、スティッキー セッションなどのオプションを使用して、各コンシューマーが同じプロデューサー サーバーにルーティングされるようにすることができます。| + +### FeedEntity + +すべてのエンティティは、ユーザーにとって関連性がなくなった場合にのみ、 GTFS Realtimeフィードから削除する必要があります。フィードはステートレスであると見なされます。つまり、各フィードは交通システムのリアルタイムの状態全体を反映します。あるフィード インスタンスでエンティティが提供され、その後のフィード更新で削除された場合、そのエンティティにはリアルタイムの情報がないものと見なす必要があります。 + +| フィールド名 | 推奨事項 | +|---|---| +| `id` |旅行期間全体にわたって安定している必要があります | + +### TripUpdate + +旅行キャンセルに関する一般的なガイドライン: + +* 数日間にわたる旅行をキャンセルする場合、プロデューサーは、指定された`trip_ids`と`start_dates` を`CANCELED`る` TripUpdates と、同じ`trip_ids`と`TimeRange`を参照する`NO_SERVICE`む` Alert を提供する必要があります。この Alert は、乗客にキャンセルの理由 (迂回など) を説明するために表示できます。 +* 旅行中に訪問先がない場合は、すべての`stop_time_updates`を`SKIPPED`としてマークするのではなく、旅行を`CANCELED`にする必要があります。 + +| フィールド名 | 推奨事項 | +|---|---| +| `trip` | [message TripDescriptor](#tripdescriptor) を参照してください。| +| | `VehiclePosition`と`TripUpdate`フィードが別々に提供される場合、[TripDescriptor](#tripdescriptor) と [VehicleDescriptor](#vehicledescriptor) ID値のペアは、2 つのフィード間で一致する必要があります。

たとえば、 `VehiclePosition`エンティティに`vehicle_id:A`と`trip_id:4` がある場合、対応する`TripUpdate``TripUpdate`にも`vehicle_id:A`と`trip_id:4`が必要です。`TripUpdate` エンティティに`trip_id:4`と` 4 以外の`vehicle_id`がある場合は、エラーになります。| +| `vehicle` | [message VehicleDescriptor](#vehicledescriptor) を参照してください。| +| | `VehiclePosition`と`TripUpdate`フィードが別々に提供されている場合、[TripDescriptor](#tripdescriptor) と [VehicleDescriptor](#vehicledescriptor) のID値のペアは、2 つのフィード間で一致する必要があります。

たとえば、 `VehiclePosition`エンティティに`vehicle_id:A`と`trip_id:4` がある場合、対応する`TripUpdate``TripUpdate`にも`vehicle_id:A`と`trip_id:4`が必要です。`TripUpdate` エンティティに`trip_id:4`があり、 `vehicle_id`が` 4 以外の場合、エラーになります。| +| `stop_time_update` | 特定の`trip_id`の`stop_time_updates` は、 `stop_sequence`の昇順で厳密に順序付けする必要があり、 `stop_sequence` を繰り返さないでください。| +| | 旅行の進行中は、すべての`TripUpdates`に、将来の予測到着時刻または出発時刻を含む`stop_time_update` が少なくとも 1 つ含まれている必要があります。 [GTFS Realtime仕様](../feed_entities/trip-updates/#stoptimeupdate)では、過去の`StopTimeUpdate`が、特定の旅程で予定到着時刻が未来の停留所を参照している場合（つまり、車両が予定より早く停留所を通過した場合）、プロデューサーはそれを削除してはならないと規定されていることに注意してください。そうしないと、この停留所には更新がないと判断されます。| +| `timestamp` | この旅程の予測が更新された時間を反映する必要があります。| +| `delay` | `TripUpdate.delay` はスケジュールの偏差、つまり車両がスケジュールよりどれだけ進んでいるか/遅れているかの過去の観測値を表す必要があります。将来の停留所の予測は、`StopTimeEvent.delay`または`StopTimeEvent.time`を通じて提供される必要があります。 | + +### TripDescriptor + +`VehiclePosition``VehiclePosition`と`TripUpdate`フィードが別々に提供される場合、[TripDescriptor](#tripdescriptor) と [VehicleDescriptor](#vehicledescriptor) ID値のペアリングは 2 つのフィード間で一致する必要があります。 + +たとえば、 `VehiclePosition`エンティティに`vehicle_id:A`と`trip_id:4` がある場合、対応する`TripUpdate`エンティティにも`vehicle_id:A`と`trip_id:4`が必要です。 + +| フィールド名 | 推奨事項 | +|---|---| +| `schedule_relationship` | `ADDED`旅行の動作は指定されていないため、この列挙体の使用は推奨されません。 | + + +### VehicleDescriptor + +`VehiclePosition``VehiclePosition`と`TripUpdate`フィードが別々に提供される場合、[TripDescriptor](#tripdescriptor) と [VehicleDescriptor](#vehicledescriptor) ID値のペアリングは 2 つのフィード間で一致する必要があります。 + +たとえば、 `VehiclePosition`エンティティに`vehicle_id:A`と`trip_id:4` がある場合、対応する`TripUpdate`エンティティにも`vehicle_id:A`と`trip_id:4` が必要です。 + +| フィールド名 | 推奨事項 | +|---|---| +| `id` | 旅行期間全体にわたって車両を一意かつ安定的に識別する必要があります | + +### StopTimeUpdate + +| フィールド名 | 推奨事項 | +|---|---| +| `stop_sequence` |可能な場合は常に`stop_sequence`を指定します。これは、 `stop_id`とは異なり、 `stop_times.txt`の` GTFS 停車時刻に明確に解決されるためです。`stop_id` は、旅程で複数回出現することがあります (例: ループ ルート)。| +| `arrival` | 連続する停車地間の到着時刻は増加する必要があります。同じにしたり、減少したりしてはなりません。| +| | 乗り継ぎまたは停車時間が予想される場合、到着`time` ([StopTimeEvent](#stoptimeevent) で指定) は同じ停車地の出発`time`より前である必要があります。それ以外の場合、到着`time`は出発`time`と同じである必要があります。| +| `departure` | 連続する停車地間の出発時刻は増加する必要があります。同じにしたり、減少したりしてはなりません。| +| |出発`time` `time` ([StopTimeEvent](#stoptimeevent) で指定) は、乗り継ぎ時間や停車時間が予想されない場合は、同じ停車地の到着 `time` と同じにする必要があります。それ以外の場合は、出発`time` は到着`time`より後である必要があります。 | + +### StopTimeEvent + +| フィールド名 | 推奨事項 | +|---|---| +| `delay` | `stop_time_update`の`arrival`または`departure`で`delay`のみが指定されている場合 ( `time`は指定されていない場合)、GTFS [`stop_times.txt`](../../schedule/reference/#stop_timestxt) には、これらの対応する停車地の`arrival_times`および/または`departure_times` が含まれている必要があります。リアルタイム フィード内の`delay`値は、GTFS `stop_times.txt`ファイルに追加するための時刻がない限り、意味がありません。 | + +### VehiclePosition + +消費者に高品質のデータを提供するために (予測の生成などのために) VehiclePositions フィードに含める必要がある推奨フィールドは次のとおりです。 + +| フィールド名 | 注 | +|---|---| +| `entity.id` | 乗車時間全体にわたって一定に保つ必要があります +| `vehicle.timestamp` | 車両の位置が測定されたタイムスタンプを提供することを強くお勧めします。そうしないと、消費者はmessageのタイムスタンプを使用する必要があります。最後のmessageが個々の位置よりも頻繁に更新された場合、乗客に誤解を与える可能性があります。 +| `vehicle.vehicle.id` |旅行期間全体にわたって車両を一意かつ安定的に識別する必要があります | + +###Position + +車両の位置は、この`trip_id`に対して`DETOUR`の効果を持つアラートがない限り、現在の旅行の GTFS `shapes.txt`ら` 200 メートル以内である必要があります。 + +### アラート + +アラートの一般的なガイドライン: + +* `trip_id`と`start_time`が`exact_time=1`間隔内にある場合、 `start_time` は間隔の開始よりも`headway_secs`の正確な倍数だけ後にする必要があります。 +* 数日間にわたって運行をキャンセルする場合、運行者は、指定された`trip_ids`と`start_dates`を`CANCELED`る` TripUpdates と、同じ`trip_ids`と`TimeRange`を参照する`NO_SERVICE`の` Alert を提供して、乗客にキャンセルの理由 (迂回など) を説明できるようにする必要があります。 +* アラートが路線のすべての停留所に影響する場合は、停留所ベースのアラートではなく、路線ベースのアラートを使用します。路線のすべての停留所にアラートを適用しないでください。 +* サービスアラートに文字数制限はありませんが、交通機関の乗客は多くの場合、モバイルデバイスでアラートを表示します。簡潔にしてください。 + +| フィールド名 | 推奨事項 | +|---|---| +| `description_text` | サービスアラートを読みやすくするために改行を使用します。 | + +## ユースケース別にまとめた実践的な推奨事項 + +### 頻度ベースの旅程 + +頻度ベースの旅程は、固定のスケジュールには従わず、事前に決められた間隔を維持しようとします。これらの旅程は、[GTFS 頻度.txt](../../schedule/reference/#frequenciestxt) で`exact_times=0`を設定するか、 `exact_times`フィールドを省略することで示されます ( `exact_times=1` の旅程は頻度ベースの旅程ではないことに注意してください`exact_times=1`を指定した`frequencies.txt`は、スケジュールベースの旅程をよりコンパクトに保存するための便利な方法として使用されているだけです)。頻度ベースの旅程のGTFS Realtimeフィードを作成する際には、いくつかのベスト プラクティスに留意する必要があります。 + +* [TripUpdate. StopTimeUpdate](#stoptimeupdate) では、頻度ベースの旅行は固定スケジュールに従わないため、 `arrival`と`departure`の [StopTimeEvent](#stoptimeevent) に`delay`を含めないでください。代わりに、到着/出発の予測を示すために`time`を指定する必要があります。 + +* 仕様で要求されているように、[TripUpdate](#tripupdate) または [VehiclePosition](#vehicleposition) で [TripDescriptor](#tripdescriptor) を使用して`trip`を記述する場合は、 `trip_id`、 `start_time`、および`start_date`をすべて指定する必要があります。さらに、 `schedule_relationship` は`UNSCHEDULED`にする必要があります。 + (例: 強化旅行)。 + + +## このドキュメントについて + +### 目的GTFS Realtimeのベスト プラクティスを維持する目的は、次のとおりです。 + +* 公共交通機関アプリにおけるエンドユーザーの顧客エクスペリエンスを向上させる +* ソフトウェア デベロッパーがアプリケーション、製品、サービスをより簡単に導入および拡張できるようにする + +### 公開済みのGTFS Realtimeのベスト プラクティスを提案または修正する方法 + +GTFS のアプリケーションとプラクティスは進化するため、このドキュメントは随時修正する必要がある場合があります。このドキュメントの修正を提案するには、[GTFS Realtimeのベスト プラクティス GitHub リポジトリ](https://github.com/MobilityData/GTFS_Realtime_Best-Practices) でpull requestを開き、変更を支持してください。 + +### このドキュメントへのリンク + +フィード作成者にGTFS Realtimeデータを正しく形成するためのガイダンスを提供するために、ここにリンクしてください。それぞれの推奨事項にはアンカー リンクがあります。推奨事項をクリックすると、ページ内のアンカー リンクの URL が表示されます。 + +GTFSGTFS Realtimeを使用するアプリケーションが、ここで説明されていないGTFS Realtimeデータの取り扱いに関する要件や推奨事項を定めている場合は、これらの一般的なベスト プラクティスを補足するために、それらの要件や推奨事項を記載したドキュメントを公開することをお勧めします。 + + diff --git a/docs/ja/documentation/realtime/reference.md b/docs/ja/documentation/realtime/reference.md new file mode 100644 index 000000000..6844e8ae4 --- /dev/null +++ b/docs/ja/documentation/realtime/reference.md @@ -0,0 +1,691 @@ +# GTFS RealtimeリファレンスGTFS Realtimeフィードを使用すると、交通機関はサービスへの混乱 (駅の閉鎖、路線の運行停止、大幅な遅延など)、車両の位置、到着予定時刻に関するリアルタイム情報を消費者に提供できます。 + +フィード仕様のバージョン 2.0 については、このサイトで説明および文書化されています。有効なバージョンは`2.0`、`1.0`です。 + +## 用語の定義 + +###必須 + +GTFS リアルタイム v2.0 以降では、*必須* 列は、交通データが有効で、使用するアプリケーションにとって意味を成すために、プロデューサーが提供する必要があるフィールドを示します。 + +*必須* フィールドでは次の値が使用されます: + +* **必須**: このフィールドは、GTFS リアルタイム フィード プロデューサーが提供する必要があります。 +* **条件付きで必須**: このフィールドは、フィールド *説明* で概説されている特定の条件下で必須です。これらの条件以外では、フィールドはオプションです。 +* **任意**: このフィールドはオプションであり、プロデューサーが実装する必要はありません。ただし、基礎となる自動車両位置システム (例: VehiclePosition `timestamp`) でデータが利用可能な場合は、プロデューサーが可能な場合はこれらのオプション フィールドを提供することが推奨されます。 + +*セマンティック要件は GTFS リアルタイム バージョン 1.0 では定義されていないため、 `gtfs_realtime_version`が`1`のフィードはこれらの要件を満たさない可能性があることに注意してください (詳細については、[セマンティック要件の提案](https://github.com/google/transit/pull/64) を参照してください)。* + +### カーディナリティ + +*カーディナリティ* は、特定のフィールドに提供できる要素の数を表し、次の値があります: + +* **1** - このフィールドには 1 つの要素を指定できます。これは、[プロトコル バッファの *必須* および *オプション* の基数](https://developers.google.com/protocol-buffers/docs/proto#simple) にマップされます。 +* **多数** - このフィールドには、多数の要素 (0、1、またはそれ以上) を指定できます。これは、[プロトコル バッファの *繰り返し* 基数](https://developers.google.com/protocol-buffers/docs/proto#simple) にマップされます。 + +フィールドが必須、条件付きで必須、またはオプションであるかどうかを確認するには、常に *必須* フィールドと *説明* フィールドを参照してください。プロトコル バッファのカーディナリティについては、[`gtfs-realtime.proto`](https://github.com/google/transit/blob/master/gtfs-realtime/proto/gtfs-realtime.proto) を参照してください。 + +### プロトコル バッファのデータ型 + +フィード要素の記述には、次のプロトコル バッファのデータ型が使用されます: + +* **message**: 複合型 +* **enum**: 固定値のリスト + +### 試験的なフィールド + +**試験的** というラベルの付いたフィールドは変更される可能性があり、まだ正式に仕様に採用されていません。 **実験的** フィールドは、将来正式に採用される可能性があります。 + +## 要素インデックス + +* [FeedMessage](#message-feedmessage) + * [FeedHeader](#message-feedheader) + * [Incrementality](#enum-incrementality) + * [FeedEntity](#message-feedentity) + * [TripUpdate](#message-tripupdate) + * [TripDescriptor](#message-tripdescriptor) + * [ScheduleRelationship](#enum-schedulerelationship_1) + * [VehicleDescriptor](#message-vehicledescriptor) + * [WheelchairAccessible](#enum-wheelchairaccessible) + * [StopTimeUpdate](#message-stoptimeupdate) + * [StopTimeEvent](#message-stoptimeevent) + * [ScheduleRelationship](#enum-schedulerelationship) + * [StopTimeProperties](#message-stoptimeproperties) + * [TripProperties](#message-tripproperties) + * [VehiclePosition](#message-vehicleposition) + * [TripDescriptor](#message-tripdescriptor) + * [ScheduleRelationship](#enum-schedulerelationship_1) + * [VehicleDescriptor](#message-vehicledescriptor) + * [WheelchairAccessible](#enum-wheelchairaccessible) + * [Position](#message-position) + * [VehicleStopStatus](#enum-vehiclestopstatus) + * [CongestionLevel](#enum-congestionlevel) + * [OccupancyStatus](#enum-occupancystatus) + * [CarriageDetails](#message-carriagedetails) + * [Alert](#message-alert) + * [TimeRange](#message-timerange) + * [EntitySelector](#message-entityselector) + * [TripDescriptor](#message-tripdescriptor) + * [ScheduleRelationship](#enum-schedulerelationship_1) + * [原因](#enum-cause) + * [効果](#enum-effect) + * [TranslatedString](#message-translatedstring) + * [翻訳](#message-translation) + * [SeverityLevel](#enum-severitylevel) + * [形状](#message-shape) + * [停止](#message-stop) + * [WheelchairBoarding](#enum-wheelchairboarding) + * [TripModifications](#message-tripmodifications) + * [Modification](#message-modification) + * [ReplacementStop](#message-replacementstop) + + +##要素 + +### _message_ FeedMessage + +フィードmessageの内容。ストリーム内の各messageは、適切な HTTP GET リクエストへの応答として取得されます。リアルタイム フィードは常に、既存の GTFS フィードとの関連で定義されます。すべてのエンティティ ID は、GTFS フィードを基準にして解決されます。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **header** | [FeedHeader](#message-feedheader) |必須| 1 つ | このフィードとフィードmessageに関するメタデータ。 | +| **entity** | [FeedEntity](#message-feedentity) | 条件付きで必須 | 複数 | フィードの内容。交通システムに関するリアルタイム情報がある場合は、このフィールドを指定する必要があります。このフィールドが空の場合、ユーザーはシステムに関するリアルタイム情報がないものと想定する必要があります。 | + +### _message_ FeedHeader + +フィード メッセージに含まれる、フィードに関するメタデータ。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **gtfs_realtime_version** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | フィード仕様のバージョン。現在のバージョンは 2.0 です。 | +| **incrementality** | [Incrementality](#enum-incrementality) |必須| 1 | +| **timestamp** | [uint64](https:) |必須| 1 | このタイムスタンプは、このフィードの内容が作成された瞬間を識別します (サーバー時間)。POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。リアルタイム情報を生成するシステムと消費するシステム間の時間のずれを回避するには、タイム サーバーからタイムスタンプを取得することを強くお勧めします。数秒までの時間差は許容されるため、Stratum 3 またはそれより低い Strata サーバーを使用することはまったく問題ありません。 | + +### _enum_Incrementality + +現在のフェッチが増分かどうかを決定します。 + +* **FULL_DATASET**: このフィード更新により、フィードの以前のすべてのリアルタイム情報が上書きされます。したがって、このアップデートでは、既知のすべてのリアルタイム情報の完全なスナップショットが提供される予定です。 +* **DIFFERENTIAL**: 現在、このモードは**サポートされていません**。このモードを使用するフィードの動作は**未指定**です。[GTFS Realtimeメーリング リスト](http://groups.google.com/group/gtfs-realtime)で、DIFFERENTIAL モードの動作を完全に指定することについて議論されており、その議論が完了した時点でドキュメントが更新されます。 + +**値** + +| _**値**_ | +|-------------| +| ** **FULL_DATASET** ** | +| **DIFFERENTIAL** | + +### _message_ FeedEntity + +交通フィード内のエンティティの定義 (または更新)。エンティティが削除されない場合は、`trip_update`、`vehicle`、`alert`、および`shape`ち` 1 つだけを入力する必要があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | このエンティティのフィード固有の識別子。ID は増分サポートを提供するためだけに使用されます。フィードによって参照される実際のエンティティは、明示的なセレクターによって指定する必要があります (詳細については、以下のEntitySelectorを参照してください)。| +| **is_deleted** | [bool](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | このエンティティを削除するかどうか。増分性が DIFFERENTIAL のIncrementalityに対してのみ指定する必要があります。このフィールドは、Incrementalityが FULL_DATASET のフィードには指定しないでください。 | +| **trip_update** | [TripUpdate](#message-tripupdate) | 条件付きで必須 | 1 つ | 旅行の出発遅延に関するリアルタイムのデータ。trip_update、vehicle、alert、または shape のフィールドのうち少なくとも 1 つを指定する必要があります。これらのフィールドすべてを空にすることはできません。 | +| **vehicle** | [VehiclePosition](#message-vehicleposition) | 条件付きで必須 | 1 つ | 車両のリアルタイムの位置に関するデータ。trip_update、vehicle、alert、または shape のフィールドのうち少なくとも 1 つを指定する必要があります。これらのフィールドすべてを空にすることはできません。 | +| **alert** | [アラート](#message-alert) | 条件付きで必須 | 1 つ | リアルタイム アラートに関するデータ。trip_update、vehicle、alert、shape のフィールドのうち少なくとも 1 つを指定する必要があります。これらのフィールドすべてを空にすることはできません。| +| **shape** | [シェイプ](#message-shape) | 条件付きで必須 | 1 つ | 迂回路などのリアルタイムで追加されたシェイプに関するデータ。trip_update、vehicle、alert、shape のフィールドのうち少なくとも 1 つを指定する必要があります。これらのフィールドすべてを空にすることはできません。

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来、正式に採用される可能性があります。 | + + +### _message_ TripUpdate + +旅程に沿った車両の進行状況に関するリアルタイム更新。[旅程更新エンティティ](../../../documentation/realtime/feed_entities/trip-updates)の一般的な説明も参照してください。 +upd +ScheduleRelationship の値に応じて、 TripUpdate以下を指定できます。 + +* ScheduleRelationshipに沿って進む旅程。 +* ルートに沿って進むが、スケジュールが固定されていない旅程。 +* スケジュールに関して追加または削除された旅程。 +* 静的 GTFS の既存の旅程のコピーである新しい旅程。TripProperties で指定されたサービスdateで実行されますTripProperties更新は、将来の予測到着/出発イベント、またはすでに発生した過去のイベントに対して行うことができます。ほとんどの場合、過去のイベントに関する情報は測定値であるため、その不確実性の値は 0 にすることをお勧めします。ただし、これに当てはまらない場合もあり、その場合は過去のイベントの不確実性の値が 0 以外になることが許可されます。更新の不確実性が 0 でない場合、更新は完了していない旅行のおおよその予測であるか、測定が正確でないか、更新はイベント発生後に検証されていない過去の予測であったかのいずれかです。 + +車両が同じブロック内で複数の旅行を提供している場合 (旅行とブロックの詳細については、[GTFS trips.txt](../../schedule/reference/#tripstxt) を参照してください): + +* フィードには、車両が現在提供している旅行のTripUpdateを含める必要があります。プロデューサーは、将来の旅行の予測の品質に自信がある場合は、この車両のブロックの現在の旅行の後の 1 つ以上の旅行の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdates を含めると、車両が 1 つの旅程から別の旅程に移行する際に乗客に予測の`TripUpdateエンティティは、ブロック内でスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、 `trip_ids`が` 1、2、3 の旅程がすべて 1 つのブロックに属していて、車両が旅程 1、旅程 2、旅程 3 の順に移動する場合、 `trip_update`エンティティは任意の順序で表示できます。たとえば、旅程 2、旅程 1、旅程 3 の順で追加できます。 + +更新ではすでに完了した旅程を記述できることに注意してください。このためには、旅程の最後の停車地の更新を提供すれば十分です。最後の停車地への到着時刻が過去である場合、クライアントは旅行全体が過去であると結論付けます (重要ではありませんが、前の停車地の更新も提供できます)。このオプションは、スケジュールより早く完了したが、スケジュールによると現時点で旅行がまだ進行中である旅行に最も関連しています。この旅行の更新を削除すると、クライアントは旅行がまだ進行中であると想定する可能性があります。フィード プロバイダーは過去の更新を消去できますが、必須ではないことに注意してください。これは、これが実際に役立つ 1 つのケースです。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|-----------|----------------|-------------------|-------------------| +| **trip** | [TripDescriptor](#message-tripdescriptor) |必須| 1 つ | このmessageが適用される旅行。実際の旅行インスタンスごとに、最大 1 つのTripUpdateエンティティを指定できます。存在しない場合は、予測情報がないことを意味します。旅行がスケジュールどおりに進んでいることを意味するわけではありません。 | +| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) |任意| 1 つ | この旅行にサービスを提供する車両に関する追加情報。 | +| **stop_time_update** | [StopTimeUpdate](#message-stoptimeupdate) | 条件付きで必須 | 複数 | 旅行の StopTimes の更新 (将来の予測と、場合によっては過去の停止時刻 (すでに発生した停止時刻) の両方)。更新はstop_sequenceで並べ替える必要があり、次に指定された stop_time_update までの旅行のすべての後続の停車地に適用されます。trip.schedule_relationship が CANCELED、DELETED、または DUPLICATED でない限り、旅行に対して少なくとも 1 つの stop_time_update を指定する必要があります。旅行がキャンセルまたは削除された場合、stop_time_updates を指定する必要はありません。キャンセルまたは削除された旅行に対して stop_time_updates が指定されている場合、trip.schedule_relationship は、stop_time_updates および関連する schedule_relationship よりも優先されます。旅行が重複している場合は、新しい旅行のリアルタイム情報を示すために stop_time_updates を指定できます。| +| **timestamp** | [uint64](https:) |任意| 1 つ | 将来の StopTimes を推定するために車両のリアルタイムの進行状況が測定された最新の瞬間。過去の StopTimes が指定されている場合、到着/出発時刻はこの値よりも早くなることがあります。POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数) です。| +| **delay** | [int32](https:) |任意| 1 つ | 旅行の現在のスケジュールの偏差。遅延は、予測が GTFS の既存のスケジュールと比較して提供される場合にのみ指定する必要があります。
遅延 (秒単位) は、正 (車両が遅れていることを意味する) または負 (車両が予定より進んでいることを意味する) になります。遅延が 0 の場合、車両は正確に時間通りであることを意味します。
StopTimeUpdates の遅延情報は、旅行レベルの遅延情報よりも優先されるため、旅行レベルの遅延は、 StopTimeUpdate遅延値が指定された旅行の次の停車地までのみ伝播されます。
フィード プロバイダーは、データの鮮度を評価するために、遅延値が最後に更新された日時を示すTripUpdate.timestamp 値を提供することを強くお勧めします。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。| +| **trip_properties** | [TripProperties](#message-tripproperties) |任意| 1 つ | 旅行の更新されたプロパティを提供します。

**注意:**このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _message_ StopTimeEvent + +単一の予測イベント (到着または出発) のタイミング情報。タイミングは、遅延および/または推定時間、および不確実性で構成されます。 + +* 遅延は、GTFS の既存のスケジュールを基準にして予測が示される場合に使用します。 +* 時間は、予測スケジュールがあるかどうかに関係なく指定する必要があります。時間と遅延の両方が指定されている場合は、時間が優先されます (ただし、通常、スケジュールされた旅行に対して時間が指定されている場合は、GTFS のスケジュールされた時間 + 遅延に等しくする必要があります)。 + +不確実性は、時間と遅延の両方に等しく適用されます。不確実性は、実際の遅延の予想される誤差を大まかに指定します (ただし、その正確な統計的意味はまだ定義されていません)。たとえば、コンピューターのタイミング制御下で運転される列車の場合、不確実性が 0 になることがあります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | 遅延 (秒単位) は正 (車両が遅れていることを意味する) または負 (車両が予定より進んでいることを意味する) になります。遅延が 0 の場合、車両は正確に時間通りです。StopTimeEvent 内では遅延または時間のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。 | +| **time** | [int64](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件StopTimeEventで必須 | 1 つ | 絶対時間としてのイベント。 POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。StopTimeEvent 内では、遅延または時間のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。 | +| **uncertainty** | [int32](https:) |任意| 1StopTimeEvent| 不確実性が省略されている場合は、不明と解釈されます。完全に確実な予測を指定するには、不確実性を 0 に設定します。 | + +### _message_ StopTimeUpdate + +旅行中の特定の停車地の到着イベントや出発イベントのリアルタイム更新。[TripDescriptor](#message-tripdescriptor) および [旅行更新エンティティ](../../../documentation/realtime/feed_entities/trip-updates) ドキュメントの停車時間更新に関する一般的な説明も参照してください。 + +過去と未来の両方のイベントの更新を提供できます。プロデューサーは過去のイベントを削除できますが、必須ではありません。 +更新はstop_sequenceまたは stop_id のいずれかを介して特定の停車地にリンクされるため、これらのフィールドのいずれかが必ず設定されている必要があります。1 つの旅程で同じ stop_id を複数回訪問する場合は、その旅程のその stop_id のすべての StopTimeUpdates でstop_sequenceを指定する必要があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | 対応する GTFS フィードのstop_times.txtと同じであるしなければならない。 StopTimeUpdate内ではstop_sequenceまたは stop_id のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。stop_sequenceは、予測の対象となる停留所を区別するために、同じ stop_id を複数回訪れる旅程 (ループなど) に必要です。`StopTimeProperties.assigned_stop_id` が設定されている場合は、 `stop_sequence`設定する必要があります。| +| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | 対応する GTFS フィードのstops.txtと同じであるしなければならない。StopTimeUpdate 内ではstop_sequenceまたは stop_id のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。`StopTimeProperties.assigned_stop_id` がStopTimeUpdate`StopTimeProperties.assigned_stop_id`れている場合は、 `stop_id` を省略して`stop_sequence`のみを使用することをお勧めします。 `StopTimeProperties.assigned_stop_id`と`stop_id` が設定されている場合、 `stop_id` は`assigned_stop_id`と一致する必要があります。 | +| **arrival** | [StopTimeEvent](#message-stoptimeevent) | 条件付きで必須 | 1 つ | schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrive または destination のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と destination の両方を空にすることができます。schedule_relationship が NO_DATA の場合、arrival と destination の両方を空にする必要があります。 | +| **departure** | [StopTimeEvent](#message-stoptimeevent) | 条件付きで必須 | 1 つ | schedule_relationship が空または SCHEDULED の場合、 StopTimeUpdate内で arrive または destination のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。schedule_relationship が SKIPPED の場合、arrival と destination の両方を空にすることができます。 schedule_relationship が NO_DATA の場合、到着と出発は空でなければなりません。| +| **departure_occupancy_status** | [OccupancyStatus](#enum-occupancystatus) |任意| 1 つ | 指定された停留所から出発した直後の車両の乗客の占有状況の予測。指定されている場合は、 stop_sequence を指定する必要があります。リアルタイムの到着または出発の予測を提供せずに、departure_occupancy_status を提供するには、このフィールドに値を入力し、 StopTimeUpdate.schedule_relationship = NO_DATA を設定します。

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship) |任意| 1 つ | デフォルトの関係は SCHEDULED です。 | +| **stop_time_properties** | [StopTimeProperties](#message-stoptimeproperties) |任意| 1 つ | GTFS stop_times.txt内で定義されている特定のプロパティのリアルタイム更新

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _enum_ ScheduleRelationship + +この StopTime と静的スケジュールの関係。 + +**値** + +| _**値**_ | _**コメント**_ | +|-------------|---------------| +| **SCHEDULED** | 車両は、必ずしもスケジュールの時間に従っているわけではありませんが、静的な停車スケジュールに従って進んでいます。これが**デフォルト**の動作です。到着と出発の少なくとも 1 つを指定する必要があります。頻度ベースの旅程 (exact_times = 0 の GTFS frequencies.txt ) には SCHEDULED 値を指定せず、代わりに UNSCHEDULED を使用する必要があります。 | +| **SKIPPED** | 停車地はスキップされます。つまり、車両はこの停車地には停車しません。到着と出発はオプションです。設定されている場合、 `SKIPPED` は同じルート内の後続の停車地には伝播されません (つまり、車両はルート内の後続の停車地にも停止しますが、それらの停車地にも`schedule_relationship: SKIPPED`の ` `stop_time_update`がある場合には除きます)。ルート内の前の停車地からの遅延は`SKIPPED`停車地にも伝播します。つまり、 `SKIPPED`停車地後の停車地に対して`arrival`または`departure`予測を含む`stop_time_update`が設定されていない場合、 `SKIPPED`停車地の上流の予測は、後続の停車地の`stop_time_update`が提供されるまで、ルート内の`SKIPPED`停車地後の停車地と後続の停車地に伝播します。| +| **NO_DATA** | この停車地にはデータがありません。リアルタイムのタイミング情報がないことを示します。設定すると、NO_DATA は後続の停車地にも伝播されるため、リアルタイムのタイミング情報がない停車地を指定するには、この方法をお勧めします。NO_DATA が設定されている場合は、到着も出発も指定しないでください。| +| **UNSCHEDULED** | 車両は、頻度ベースの旅程 (GTFS frequencies.txtで exact_times = 0) を運行しています。この値は、GTFS frequencies.txtで定義されていない旅程、または GTFS frequencies.txtで exact_times = 1. の旅程には使用しないでください。`schedule_relationship : `schedule_relationship: UNSCHEDULED`の`stop_time_updates`を含む便では、 TripDescriptor `schedule_relationship: UNSCHEDULED`も設定する必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +### _message_ StopTimeProperties + +GTFS stop_times.txt内で定義されている特定のプロパティのリアルタイム更新。 + +**注意:**このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。
+ +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **assigned_stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | リアルタイムの停留所割り当てをサポートします。GTFS `stops.txt`で定義されている`stop_id`を参照します。
新しい`assigned_stop_id`によって、エンドユーザーの旅行体験が GTFS `stop_times.txt`で定義された`stop_id`と大幅に異なることはあってはなりません。言い換えれば、新しい停留所が追加のコンテキストなしでアプリ内に表示された場合は、エンドユーザーがこの新しい`stop_id`を`異常な変更`と見なすべきではありません。たとえば、このフィールドは、GTFS `stop_times.txt`で元々定義された停留所と同じ駅に属する`stop_id`を使用してプラットフォームの割り当てに使用することを目的としています。
リアルタイムの到着または出発の予測を提供せずに停留所を割り当てるには、このフィールドに値を入力し、 `StopTimeUpdate.schedule_relationship = NO_DATA`を設定します。
このフィールドに値を入力する場合は、 `StopTimeUpdate.stop_sequence`を入力する必要がありますが、 `StopTimeUpdate.stop_id`は入力しないでください。停車地の割り当ては、他の GTFS リアルタイム フィールドにも反映される必要があります (例: `VehiclePosition.stop_id`)。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _message_ TripProperties + +旅行の更新されたプロパティを定義します + +**注意:**このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。
. + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|---------------------------|----------------|-------------------|-------------------| +| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | (CSV) GTFS trips.txtで定義されている既存の旅行の複製であるが、異なるサービスdateおよび/または時刻 ( `TripProperties.start_date`および`TripProperties.start_time`を使用して定義) に開始する新しい旅行の識別子を定義します。(CSV) GTFS の`trips.trip_id`の定義を参照してください。その値は、(CSV) GTFS で使用されている値と異なる必要があります。このフィールドは、 `schedule_relationship`が`DUPLICATED`の場合に必須です。それ以外の場合、このフィールドに値を入力することはできず、コンシューマーによって無視されます。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **start_date** | [string](https:) | 条件付きで必須 | 1つ | 複製された旅行が実行されるサービスdate。YYYYMMDD 形式で提供するしなければならない。このフィールドは、 `schedule_relationship`が`DUPLICATED`の場合に必須です。それ以外の場合は、このフィールドに値を入力してはならず、コンシューマーによって無視されます。

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 | 重複している旅行の出発開始時刻を定義します。(CSV) GTFS の`stop_times.departure_time`の定義を参照してください。重複した旅行の予定到着時刻と出発時刻は、元の旅行の`departure_time`とこのフィールドのオフセットに基づいて計算されます。たとえば、GTFS の旅程に停車地 A の`departure_time`が`10:00:00` 、停車地 B の`departure_time`が`10:01:00`で、このフィールドに`10:30:00`の値が入力されている場合、複製された旅程の停車地 B のスケジュールされた`departure_time`は`10:31:00`になります。リアルタイム予測の`delay`値は、この計算されたスケジュール時間に適用され、予測時間を決定します。たとえば、停車地 B の出発`delay`が`30`の場合、予測される出発時刻は`10:31:30`です。リアルタイム予測の`time`値にはオフセットが適用されず、提供された予測時間を示します。たとえば、停留所 B の出発`time`が` 10:31:30 と指定されている場合、予測出発時刻は`10:31:30` になります。このフィールドは、 `schedule_relationship`が`DUPLICATED`の場合に必須です。それ以外の場合、このフィールドに値を入力することはできず、消費者によって無視されます。

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | この旅程の車両移動経路の形状が元のものと異なる場合に、その形状を指定します。(CSV) GTFS で定義された形状、またはリアルタイム フィードの新しい形状エンティティを参照します。(CSV) GTFS の`trips.shape_id`の定義をご覧ください。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _message_ VehiclePosition + +特定の車両のリアルタイム位置情報。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ* + +*_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **trip** | [TripDescriptor](#message-tripdescriptor) |任意| 1 つ | この車両が運行する運行。特定の運行インスタンスで車両を識別できない場合は、空または一部を指定できます。 | +| **vehicle** | [VehicleDescriptor](#message-vehicledescriptor) |任意| 1 つ | この運行に運行する車両に関する追加情報。各エントリには、**一意の** 車両 ID が必要です。 | +| **position** | [Position](#message-position) |任意| 1 つ | この車両の現在の位置。 | +| **current_stop_sequence** | [uint32](https:) |任意| 1 つ |現在の停車地の停車シーケンス インデックス。current_stop_sequence (つまり、それが参照する停車地) の意味は、current_status によって決まります。current_status が指定されていない場合は、IN_TRANSIT_TO が想定されます。| +| **stop_id** | [string](https:) |任意| 1 つ | 現在の停車地を識別します。値は、対応する GTFS フィード内のstops.txtと同じである必要があります。`StopTimeProperties.assigned_stop_id` を使用して`stop_id`を割り当てる場合は、このフィールドに`stop_id`の変更も反映させる必要があります。| +| **current_status** | [VehicleStopStatus](#enum-vehiclestopstatus) |任意| 1 つ | 現在の停車地に関する車両の正確なステータス。current_stop_sequence が指定されていない場合は無視されます。| +| **timestamp** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両の位置が測定された瞬間。POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。 | +| **congestion_level** | [CongestionLevel](#enum-congestionlevel) |任意| 1 つ | +| **occupancy_status** | [OccupancyStatus](#enum-occupancystatus) | _オプション_ | 1 つ | 車両または客車の乗客の占有状態。multi_carriage_details に客車ごとのOccupancyStatusが設定されている場合、このフィールドは、乗客を受け入れるすべての客車を考慮して車両全体を記述する必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。| +| **occupancy_percentage** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両内の乗客の占有率を示すパーセンテージ値。値 100 は、座席と立席の両方の定員を含む、車両が設計された最大占有率を表し、現在の運行規則で許可されています。設計された最大定員よりも多くの乗客がいる場合、値は 100 を超えることがあります。occupancy_percentage の精度は、個々の乗客が車両に乗り降りするのを追跡できないほど低くする必要があります。multi_carriage_details に車両ごとの occupancy_percentage が設定されている場合、このフィールドは、乗客を受け入れるすべての車両を考慮して車両全体を記述する必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **multi_carriage_details** | [CarriageDetails](#message-carriagedetails) |任意| 多数 | この車両の複数の客車の詳細。最初の出現は、**現在の移動方向を前提として**、車両の最初の客車を表します。multi_carriage_details フィールドの出現回数は、車両の客車数を表します。また、機関車、保守用車両など、乗客がプラットフォームのどこに立つべきかに関する貴重な情報を提供する、乗車できない車両も含まれます。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + + +### _enum_ VehicleStopStatus + +**値** + +| _**値**_ | _**コメント**_ | +|-------------|---------------| +| **INCOMING_AT** | 車両が停車場に到着しようとしています (停車場表示では、通常、車両のシンボルが点滅します)。 | +| **STOPPED_AT** | 車両が停車場に停止しています。 | +| **IN_TRANSIT_TO** | 車両が前の停車場を出発し、移動中です。 | + +### _enum_ CongestionLevel + +この車両に影響を与えている混雑レベル。 + +**値** + +| _**値**_ | +|-------------| +| **UNKNOWN_CONGESTION_LEVEL** | +| **RUNNING_SMOOTHLY** | +| **STOP_AND_GO** | +| **CONGESTION** | +| **SEVERE_CONGESTION** | + +### _enum OccupancyStatus_ + +車両または客車の乗客の占有状態。 + +個々のプロデューサーは、すべてのOccupancyStatus値を公開しない場合があります。したがって、コンシューマーは、 OccupancyStatus値が線形スケールに従うと想定してはなりません。コンシューマーは、プロデューサーが示し意図した状態としてOccupancyStatus値を表す必要があります。同様に、プロデューサーは、実際の車両占有状態に対応するOccupancyStatus値を使用する必要があります。 + +線形スケールでの乗客の占有レベルを説明するには、 `occupancy_percentage`を参照してください。 + +**注意:**このフィールドはまだ **実験的** であり、変更される可能性があります。将来、正式に採用される可能性があります。 + +***値*** + +| _**値**_ | _**コメント**_ | +|-------------|---------------| +| _ **EMPTY**_ | _ほとんどの基準では車両が空であるとみなされ、乗客はほとんどいないか、まったくいませんが、乗客を受け入れています。_ | +| _ **MANY_SEATS_AVAILABLE**_ | _車両または客車の空席数が多い。使用可能な総座席数のうち、このカテゴリに該当するほど空いている座席の数は、プロデューサーの裁量で決定されます。_ | +| _ **FEW_SEATS_AVAILABLE**_ | _車両または客車の空席数が少ない。使用可能な総座席数のうち、このカテゴリに該当するほど空いている座席の数は、プロデューサーの裁量で決定されます。_ | +| _ **STANDING_ROOM_ONLY**_ | _現在、車両または客車は立っている乗客のみを収容できます。_ | +| _ **CRUSHED_STANDING_ROOM_ONLY**_ | _現在、車両または客車は立っている乗客のみを収容でき、立っている乗客のためのスペースが限られています。_ | +| _ ****FULL** _ | _ほとんどの基準では車両は満席とみなされますが、乗客の乗車は許可されている可能性があります。_ | +| _ **NO_DATA_AVAILABLE****NOT_ACCEPTING_PASSENGERS**** _ | _車両または客車は乗客を受け入れていません。車両または客車は通常、乗客の乗車を受け入れます。_ | +| _ **NOT_BOARDABLE**_ | _車両または客車は乗車できず、乗客を受け入れることはありません。特別な車両や客車（エンジン、メンテナンス用客車など）に役立ちます。_ | + + +### _message_ CarriageDetails + +複数の客車で構成された車両に使用される、客車固有の詳細。 + +**注意:**このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 客車の ID。車両ごとに一意である必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **label** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両を識別するために乗客に表示される、ユーザーに表示されるラベル。例: "7712"、"Car ABC-32" など...
**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **occupancy_status** | [OccupancyStatus](#enum-occupancystatus) |任意| 1 つ | この車両のこの車両の乗車状況。デフォルトは`NO_DATA_AVAILABLE`に設定されています。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。| +| **occupancy_percentage** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 | この車両のこの車両の占有率。"VehiclePosition.occupancy_percentage" と同じルールに従います。この車両のデータが利用できない場合は -1 を使用します。

**注意:**このフィールドはまだ **実験的** であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **carriage_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 | 車両の CarriageStatus リスト内の他の車両に対するこの車両の順序を識別します。移動方向の最初の車両の値は1.である必要があります。2 番目の値は移動方向の 2 番目の車両に対応し、値 2 である必要があります。以下同様です。たとえば、移動方向の最初の車両の値は1.です。移動方向の 2 番目の車両の値が 3 の場合、コンシューマーはすべての車両のデータ (つまり、multi_carriage_details フィールド) を破棄します。データのないキャリッジは、有効な carrier_sequence 番号で表す必要があり、データのないフィールドは省略する必要があります (代わりに、それらのフィールドを含めて、`データなし`の値に設定することもできます)。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _message_ Alert + +公共交通機関ネットワークで何らかのインシデントが発生したことを示すアラート。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **active_period** | [TimeRange](#message-timerange) |任意| 複数 | アラートをユーザーに示す時間。指定しない場合は、フィードに表示される限りアラートが表示されます。複数の範囲が指定されている場合は、そのすべての範囲でアラートが表示されます。 | +| **informed_entity** | [EntitySelector](#message-entityselector) |必須| 複数 | このアラートをユーザーに通知する必要があるエンティティ。少なくとも 1 つの inform_entity を指定する必要があります。| +| **cause** | [Cause](#enum-cause) |条件付きで必須| 1 つ | cause_detail が含まれている場合は、Cause も含める必要があります。 +| **cause_detail** | [TranslatedString](#message-translatedstring) |任意| 1 つ | アラートの原因の説明。機関固有の言語を使用できます。Cause よりも具体的です。cause_detail が含まれている場合は、Cause も含める必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 +| **effect** | [Effect](#enum-effect) |条件付きで必須| 1 つ | effect_detail が含まれている場合は、Effect も含める必要があります。 +| **effect_detail** | [TranslatedString](#message-translatedstring) |任意| 1 つ | アラートの効果の説明。機関固有の言語を使用できます。Effect よりも具体的です。effect_detail が含まれている場合は、Effect も含める必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 +| **url** | [TranslatedString](#message-translatedstring) |任意| 1 つ | アラートに関する追加情報を提供する URL。| +| **header_text** | [TranslatedString](#message-translatedstring) |必須| 1 つ | アラートのヘッダー。このプレーン テキストstringは、たとえば太字で強調表示されます。| +| **description_text** | [TranslatedString](#message-translatedstring) |必須| 1 つ | アラートの説明。このプレーン テキストstringは、アラートの本文としてフォーマットされます (または、ユーザーによる明示的な`展開`要求で表示されます)。説明の情報は、ヘッダーの情報に追加される必要があります。| +| **tts_header_text** | [TranslatedString](#message-translatedstring) |任意| 1 つ |音声合成実装に使用されるアラートのヘッダーを含むText。このフィールドは、header_text の音声合成バージョンです。header_text と同じ情報を含める必要がありますが、音声合成として読み取れる形式にする必要があります (たとえば、省略形は削除、数字はスペルアウトなど)。| +| **tts_description_text** | [TranslatedString](#message-translatedstring) |任意| 1 つ | 音声合成実装に使用されるアラートの説明を含むText。このフィールドは、description_text の音声合成バージョンです。description_text と同じ情報を含める必要がありますが、音声合成として読み取れる形式にする必要があります (たとえば、省略形は削除、数字はスペルアウトなど)。| +| **severity_level** | [SeverityLevel](#enum-severitylevel) |任意| 1 つ | アラートの重大度。 | +| **image** | [TranslatedImage](#message-translatedimage) |任意| 1 つの | 警告テキストとともに表示されるTranslatedImage 。迂回、駅の閉鎖などの警告効果を視覚的に説明するために使用されます。画像は警告の理解を深めるものであり、重要な情報の唯一の場所であってはなりません。次の種類の画像は推奨されません : 主にテキストを含む画像、追加情報を含まないマーケティングまたはブランド画像。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **image_alternative_text** | [TranslatedString](#message-translatedstring) |任意| 1つ | `image`フィールドでリンクされた画像の外観を説明するText(たとえば、画像を表示できない場合や、アクセシビリティ上の理由でユーザーが画像を見ることができない場合など)。HTML [alt 画像のテキストの仕様](https:) を参照してください。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | + + +### _enum_ Cause + +このアラートの原因。 + +**値** + +| _**値**_ | +|-------------| +| ** **UNKNOWN_CAUSE** **OTHER_CAUSE** ** | +| **TECHNICAL_PROBLEM** | +| ** **STRIKE** **DEMONSTRATION** | +| **ACCIDENT** | +| ** **HOLIDAY** | +| **WEATHER** | +| **MAINTENANCE** | +| **CONSTRUCTION** | +| **POLICE_ACTIVITY** | +| **MEDICAL_EMERGENCY** | + +### _enum_ Effect + +この問題が影響を受けるエンティティに与える影響。 + +**Values** + +| _**Value**_ | +|-------------| +| **NO_SERVICE** | +| **REDUCED_SERVICE** | +| **SIGNIFICANT_DELAYS** | +| **DETOUR** | +| **ADDITIONAL_SERVICE** | +| **MODIFIED_SERVICE** | +| **OTHER_EFFECT** | +| **UNKNOWN_EFFECT** | +| **STOP_MOVED** | +| **NO_EFFECT** | +| ** **ACCESSIBILITY_ISSUE** | + +### _enum_ SeverityLevel + +アラートの重大度。 + +**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来、正式に採用される可能性があります。 + +**値** + +| _**値**_ | +|-------------| +| **UNKNOWN_SEVERITY** | +| **INFO** | +| **WARNING** | +| **SEVERE** | + +### _message_ TimeRange + +時間間隔。`t` が開始時刻以上で終了時刻未満の場合、時間`t`で間隔はアクティブであると見なされます。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **start** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) |TimeRange付きで必須 | 1 つ | 開始時刻、POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。指定されていない場合、間隔はマイナス無限大で始まります。TimeRange が指定されている場合は、start または end のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。| +| **end** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | 終了時刻、POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数)。指定されていない場合、TimeRangeはプラス無限大で終了します。TimeRange が指定されている場合は、start または end のいずれかを指定する必要があります。両方のフィールドを空にすることはできません。 | + +### _message_Position + +車両の地理的位置。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|---------------------------|----------------|-------------------|-------------------| +| **latitude** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 | WGS-84 座標系での北緯。 | +| **longitude** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 | WGS-84 座標系での東経。 | +| **bearing** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 真北から時計回りの度数で表した方位。つまり、0 は北、90 は東です。これはコンパス方位、または次の停止地点または中間地点への方向になります。これは、クライアントが以前のデータから計算できる以前の位置のシーケンスから推測されるべきではありません。 | +| **odometer** | [double](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 走行距離計の値 (メートル単位)。 | +| **speed** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両によって測定された瞬間速度 (メートル/秒単位)。 | + +### _message_ TripDescriptor + +GTFS 旅行の単一のインスタンスを識別する記述子。 + +単一の旅行インスタンスを指定するには、多くの場合、 `trip_id`だけで十分です。ただし、次の場合には、単一の旅行インスタンスを解決するために追加の情報が必要です: + +* frequencies.txtで定義されている旅行の場合、 `trip_id`に加えて`start_date`と`start_time` が必要です。 +* 旅行が 24 時間以上続く場合、または翌日の予定旅行と重なるように遅れる場合は、 `trip_id`に加えて`start_date` が必要です。 +* `trip_id`フィールドを指定できない場合は、 `route_id`、 `direction_id`、 `start_date`、および`start_time` をすべて指定する必要があります。 + +すべての場合において、 `trip_id`に加えて`route_id`を指定する場合、 `trip_id` `route_id`は` GTFS trips.txtで特定の旅行に割り当てられた`route_id`と同じである必要があります。 + +`trip_id` フィールドは、単独でも、または次のフィールドと組み合わせても、他のTripDescriptorフィールドは、複数の旅行インスタンスを識別するために使用できます。たとえば、GTFS frequencies.txt exact_times=0 の旅行の場合、 TripDescriptorはtrip_idを単独で指定しないでください。start_time も、特定の時刻に開始する単一の旅行インスタンスに解決される必要があるためです。TripDescriptorが単一の旅行インスタンスに解決されない場合 (つまり、0 個以上の旅行インスタンスに解決される場合)、エラーと見なされ、エラーのあるTripDescriptorを含むエンティティはコンシューマーによって破棄される場合があります。 + +trip_idが不明な場合は、 TripUpdateの駅シーケンス ID では不十分であり、stop_id も提供する必要があります。さらに、絶対的な到着/出発時刻も提供する必要がありますTripDescriptor.route_id は、ルートのすべての旅行に影響するルート全体のアラートを指定する Alert EntitySelector内では使用できません。代わりにEntitySelector.route_id を使用してください。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **trip_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS フィードのtrip_id 。非定期運行の旅程 (GTFS frequencies.txtで定義されていない旅程) の場合、このフィールドだけで旅程を一意に識別できます。GTFS frequencies.txtで定義されている定期運行の旅程の場合、 trip_id、start_time、start_date はすべて必須です。スケジュールベースの旅程（GTFS frequencies.txtで定義されていない旅程）の場合、 trip_id を省略できるのは、 route_id、 direction_id 、 start_time 、 start_date の組み合わせによって旅程を一意に識別でき、それらのフィールドがすべて指定されている場合のみです。 schedule_relationship がTripUpdate内で DUPLICATED の場合、 trip_id は複製される静的 GTFS からの旅程を識別します。 schedule_relationship がVehiclePosition内で DUPLICATED の場合、 trip_idは複製される新しい旅程を識別し、対応するTripUpdateの値を含める必要があります。 TripProperties。 trip_id。 | +| **route_id** | [string](https:) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS からのroute_id 。 trip_idを省略した場合、 route_id 、 direction_id、 start_time、および schedule_relationship=SCHEDULED をすべて設定して、旅程インスタンスを識別する必要があります。ルートのすべての旅程に影響するルート全体のアラートを指定するために、 Alert EntitySelector内でTripDescriptor.route_idを使用しないでください。代わりにEntitySelector.route_id を使用してください。 | +| **direction_id** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | GTFS フィードのtrips.txtファイルの direction_id。このセレクタが参照する旅程の移動方向を示します。trip_idを省略した場合、 direction_id を指定する必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。
| +| **start_time** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 | この旅程インスタンスの当初の予定開始時刻。trip_idが非頻度ベースの旅程に対応する場合、このフィールドは省略するか、GTFS フィードの値と同じにする必要があります。trip_idがGTFS frequencies.txtで定義された頻度ベースの旅程に対応する場合、start_time は必須であり、旅程の更新と車両の位置のために指定する必要があります。旅程が exact_times=1 の GTFS レコードに対応する場合、start_time は対応する期間のfrequencies.txtの start_time より headway_secs の倍数 (0 を含む) 後にする必要があります。旅程が exact_times=0 に対応する場合、start_time は任意でかまいませんが、当初は旅程の最初の出発時刻になると予想されます。一度設定されると、この頻度ベースの exact_times=0 の旅程の start_time は、最初の出発時刻が変更された場合でも不変と見なす必要があります。その時間変更は、代わりにStopTimeUpdateに反映される場合があります。trip_idを省略する場合は、start_time を指定する必要があります。フィールドの形式とセマンティクスは、GTFS/frequencies.txt/start_time と同じです (例: 11:15:35 または 25:15:35)。| +| **start_date** | [string](https:) | 条件付きで必須 | 1 つ | この旅程インスタンスの開始date(YYYYMMDD 形式)。スケジュールされた旅程 (GTFS frequencies.txtで定義されていない旅程) の場合、翌日のスケジュールされた旅程と重なるほど遅れている旅程を明確にするために、このフィールドを指定する必要があります。たとえば、毎日 8:00 と 20:00 に出発し、12 時間遅れている列車の場合、同じ時間に 2 つの異なる旅行があることになります。このフィールドは指定できますが、このような衝突が不可能なスケジュールでは必須ではありません。たとえば、1 時間遅れている車両はスケジュールとは関係がないと見なされる、1 時間ごとのスケジュールで実行されるサービスなどです。このフィールドは、GTFS frequencies.txtで定義されている頻度ベースの旅行に必須です。trip_idが省略されている場合は、start_date を指定する必要があります。| +| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship_1) |任意| 1 つ | この旅行と静的スケジュールの関係。TripDescriptorがAlert `EntitySelector`で指定されている場合、一致する旅行インスタンスを識別するときに、 `schedule_relationship`フィールドはコンシューマーによって無視されます。 + +### _enum_ ScheduleRelationship + +この旅行と静的スケジュールの関係。旅程が GTFS に反映されていない臨時スケジュールに従って行われる場合、SCHEDULED ではなく ADDED としてマークする必要があります。 + +**値** + +| _**値**_ | _**コメント**_ | +|-------------|---------------| +| **SCHEDULED** | GTFS scheduleに従って実行されている旅程、またはスケジュールされた旅程に十分近いためそれに関連付けられている旅程。| +| **ADDED** | 故障した車両の交換や突然の乗客の増加に対応するためなど、実行スケジュールに加えて追加された旅程。*注: 現在、このモードを使用するフィードの動作は指定されていません。 GTFS GitHub [(1)](https://github.com/google/transit/issues/106) [(2)](https://github.com/google/transit/pull/221) [(3)](https://github.com/google/transit/pull/219) では、ADDED 旅行を完全に指定するか廃止するかについて議論されており、その議論が確定次第、ドキュメントが更新される予定です。* | +| **UNSCHEDULED** |スケジュールが関連付けられていない運行中の旅程です。この値は、GTFS frequencies.txtで exact_times = 0 と定義されている旅程を識別するために使用されます。GTFS frequencies.txtで定義されていない旅程や、GTFS frequencies.txtで exact_times = 1.と定義されている旅程を説明するために使用しないでください。`schedule_relationship : `schedule_relationship: UNSCHEDULED` の便では、すべての StopTimeUpdates も`schedule_relationship: UNSCHEDULED` に設定する必要があります。| +| **CANCELED** | スケジュールに存在していたが削除された旅程。| +| **DUPLICATED** | サービス開始dateを除き、既存のスケジュールされた旅程と同じ新しい旅程。 `TripUpdate.TripProperties.trip_id`、 `TripUpdate.TripProperties.start_date`、および`TripUpdate.TripProperties.start_time`と一緒に使用して、静的 GTFS から既存の旅程をコピーしますが、開始日は異なるサービスdateおよび/または時刻にします。(CSV) GTFS ( `calendar.txt`または`calendar_dates.txt`内) 内の元の旅程に関連するサービスが今後 30 日以内に運行される場合、旅程の複製が許可されます。複製する旅程は、 `TripUpdate.TripDescriptor.trip_id`によって識別されます。

この列挙は、 `TripUpdate.TripDescriptor.trip_id`によって参照される既存の旅程を変更しません。プロデューサーが元の旅程をキャンセルする場合は、CANCELED の値を持つ別の`TripUpdate`を公開する必要があります。GTFS `frequencies.txt`で定義されている便で、 `exact_times`が空または `0` に等しいものは複製できません。新しい旅程の`VehiclePosition.TripDescriptor.trip_id`には、`TripUpdate.TripProperties.trip_id`の一致する値が含まれている必要があり、 `VehiclePosition.TripDescriptor.ScheduleRelationship`も`DUPLICATED`に設定する必要があります。

*重複した旅行を表すために ADDED 列挙を使用していた既存のプロデューサーとコンシューマーは、[移行ガイド](../../realtime/examples//migration-duplicated) に従って DUPLICATED 列挙に移行する必要があります。* | +| **DELETED** | スケジュールに存在していたが削除された旅行で、ユーザーに表示してはいけません。

交通機関プロバイダーが、対応する旅行に関する情報を消費アプリケーションから完全に削除し、乗客に旅行がキャンセルされたと表示されないようにするには、CANCELED の代わりに DELETED を使用する必要があります。たとえば、旅行が別の旅行に完全に置き換えられる場合などです。この指定は、複数の旅行がキャンセルされ、代替サービスに置き換えられる場合に特に重要になります。消費者がキャンセルに関する明示的な情報を表示すると、より重要なリアルタイム予測が妨げられてしまいます。

**注意:**このフィールドはまだ **実験的** であり、変更される可能性があります。将来正式に採用される可能性があります。 | + +### _message_ VehicleDescriptor + +旅行を実行する車両の識別情報。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両の内部システム ID。車両ごとに **一意** である必要があり、システム内を進む車両を追跡するために使用されます。この ID は、エンドユーザーには表示しないでください。そのためには、**label**フィールドを使用します | +| **label** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | ユーザーに表示されるラベル。つまり、正しい車両を識別するために乗客に表示する必要があるもの。 | +| **license_plate** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 車両のナンバー プレート。 | +| **wheelchair_accessible** | [WheelchairAccessible](#enum-wheelchairaccessible) |任意| 1 つ | 指定されている場合、静的 GTFS の *wheelchair_accessible* 値を上書きできます。 | + +### _enum_ WheelchairAccessible + +特定の旅行が車椅子でアクセス可能かどうか。利用可能な場合、この値は静的 GTFS の _wheelchair_accessible_ 値を上書きします。 + +##### 値 + +| _**値**_ | _**コメント**_ | +|-------------|---------------| +| **NO_VALUE** | 旅行には車椅子でのアクセスに関する情報がありません。これは **デフォルト** の動作です。静的 GTFS に _wheelchair_accessible_ 値が含まれている場合、上書きされません。| +| **UNKNOWN** | 旅行にはアクセシビリティ値が存在しません。この値は GTFS の値を上書きします。| +| **WHEELCHAIR_ACCESSIBLE** | 旅行は車椅子でアクセスできます。 + +s の値は GTFS の値を上書きします。 | +| **WHEELCHAIR_INACCESSIBLE** | 旅行は車椅子でアクセスできません。この値は GTFS の値を上書きします。 | + +### _message_ EntitySelector + +GTFS フィード内のエンティティのセレクター。フィールドの値は、GTFS フィード内の適切なフィールドに対応している必要があります。少なくとも 1 つの指定子を指定する必要があります。複数指定した場合は、論理`AND`演算子で結合されていると解釈されます。また、指定子の組み合わせは、GTFS フィード内の対応する情報と一致する必要があります。つまり、GTFS 内のエンティティにアラートを適用するには、提供されているEntitySelectorフィールドのすべてと一致する必要があります。たとえば、フィールド`route_id: "5"`および`route_type: "3"`r` は、 `route_id: "5"`バスにのみ適用され、 `route_type: "3"`の他のルートには適用されません。プロデューサーがアラートを`route_id: "5"`と`route_type: "3"`の両方に適用する場合、 ` `route_id: "5"`" ` を参照する EntitySelector と ` `route_type: "3"`"` を参照する EntitySelector を別々に 2 つ提供する必要があります。 + +少なくとも 1 つの指定子を指定する必要があります。EntitySelector のすべてのフィールドを空にすることはできません。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **agency_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS フィードの agency_id。 +| **route_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS のroute_idが指定されている場合は、 route_idも指定する必要があります。 +| **route_type** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ |このセレクタが参照する GTFS の route_type。 +| **direction_id** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | GTFS フィードtrips.txtファイルの direction_id。route_id で指定されたルートの 1 方向のすべてのルートを選択するために使用されますroute_idが指定されている場合は、 route_idも指定する必要があります。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。
| +| **trip** | [TripDescriptor](#message-tripdescriptor) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS の旅程インスタンス。このTripDescriptor は、GTFS データ内の単一の旅程インスタンスに解決される必要があります (たとえば、プロデューサーは exact_times=0 の旅程に対してtrip_idのみを提供することはできません)。このTripDescriptor内にScheduleRelationshipフィールドが設定されている場合、コンシューマーが GTFS の旅程を識別しようとすると無視されます。 +| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | このセレクタが参照する GTFS フィードの stop_id。 + +### _message_ TranslatedString + +テキストのスニペットまたは URL の言語別バージョンを含む国際化message。messageから文字列の 1 つが取得されます。解決は次のように進行します: UI 言語が翻訳の言語コードと一致する場合、最初に一致する翻訳が選択されます。デフォルトの UI 言語 (例: 英語) が翻訳の言語コードと一致する場合、最初に一致する翻訳が選択されます。翻訳に未指定の言語コードがある場合は、その翻訳が選択されます。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **translation** | [Translation](#message-translation) |必須| 多数 | 少なくとも 1 つの翻訳を指定する必要があります。| + +### _message_ 翻訳 + +言語にマップされたローカライズされたstring。 + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **text**string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ |messageを含む UTF-8string。 | +| **language** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1つ | BCP-47 言語コード。言語が不明な場合、またはフィードに対して国際化が行われていない場合は省略できます。最大で 1 つの翻訳に未指定の言語タグを指定できます。翻訳が複数ある場合は、言語を指定する必要があります。 | + +### _メッセージ_ TranslatedImage + +言語ごとの画像を含む国際化されたmessage。messageからの画像が 1 つ取得されます。解決は次のように進行します: UI 言語が翻訳の言語コードと一致する場合、最初に一致する翻訳が選択されます。デフォルトの UI 言語 (例: 英語) が翻訳の言語コードと一致する場合、最初に一致する翻訳が選択されます。翻訳に未指定の言語コードがある場合は、その翻訳が選択されます。 + +**注意:**このmessageはまだ **実験的** であり、変更される可能性があります。将来、正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **localized_image** | [LocalizedImage](#message-localizedimage) |必須| 多数 | 少なくとも 1 つのローカライズされた画像を指定する必要があります。 | + +### _message_ LocalizedImage + +言語にマップされたローカライズされたイメージの URL。 + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **url** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | イメージにリンクする URL を含む文字列。リンクされるイメージは 2 MB 未満である必要があります。イメージが大幅に変更され、コンシューマー側で更新が必要になる場合、プロデューサーは URL を新しいものに更新する必要があります。

URL は http://または https://を含む完全修飾 URL である必要があり、URL 内の特殊文字は正しくエスケープする必要があります。完全修飾 URL 値の作成方法については、次の http://www.w3.org/Addressing/URL/4_URI_Recommentations.html を参照してください。 | +| **media_type** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | 表示する画像のタイプを指定するための IANA メディア タイプ。タイプは "image/" で始まる必要があります。 | +| **language** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 条件付きで必須 | 1 つ | BCP-47 言語コード。言語が不明な場合、またはフィードに対して国際化が行われていない場合は省略できます。最大で 1 つの翻訳に未指定の言語タグを指定できます。翻訳が複数ある場合は、言語を指定する必要があります。 | + +### _message_ シェイプ + +シェイプが (CSV) GTFS の一部ではない場合 (アドホック迂回など) に車両がたどる物理的な経路を説明します。ルート形状は便に属し、より効率的な送信のためにエンコードされたポリラインで構成されます。ルート形状は停留所等の位置を正確に横切る必要はありませんが、トリップ上のすべての停留所等は、そのトリップのシェイプからわずかな距離内、つまりシェイプ ポイントを結ぶ直線セグメントの近くに配置する必要があります。 + +

**注意:**このmessageはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | シェイプの識別子。(CSV) GTFS で定義されている`shape_id`とは異なるしなければならない。

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 | +| **encoded_polyline** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | シェイプのエンコードされたポリライン表現。このポリラインには少なくとも 2 つのポイントが含まれている必要があります。エンコードされたポリラインの詳細については、https://developers.google.com/maps/documentation/utilities/polylinealgorithm をご覧ください。

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。| + +### _message_ 停留所 + +フィードに動的に追加された新しい停留所を表します。すべてのフィールドは、(CSV) GTFS 仕様で説明されているとおりです。新しい停留所の場所タイプは `0` (ルート可能な停留所) です。 + +

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | 停留所の識別子。(CSV) GTFS で定義されている`stop_id`と異なるしなければならない。| +| **stop_code** | [TranslatedString](#message-translatedstring) |任意| 1 つ | (CSV) GTFS の [stops.stop_code](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_name** | [TranslatedString](#message-translatedstring) |必須| 1 つ | (CSV) GTFS の [stops.stop_name](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **tts_stop_name** | [TranslatedString](#message-translatedstring) |任意| 1 つ | (CSV) GTFS の [stops.tts_stop_name](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_desc** | [TranslatedString](#message-translatedstring) |任意| 1 つ | (CSV) GTFS の [stops.stop_desc](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_lat** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | (CSV) GTFS の [stops.stop_lat](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_lon** | [float](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | (CSV) GTFS の [stops.stop_lon](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **zone_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | (CSV) GTFS の [stops.zone_id](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_url** | [TranslatedString](#message-translatedstring) |任意| 1 つ | (CSV) GTFS の [stops.stop_url](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **parent_station** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | (CSV) GTFS の [stops.parent_station](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **stop_timezone** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | (CSV) GTFS の [stops.stop_timezone](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **wheelchair_boarding** | [WheelchairBoarding](#enum-wheelchairboarding) |任意| 1 つ | (CSV) GTFS の [stops.wheelchair_boarding](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。| +| **level_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | (CSV) GTFS の [stops.level_id](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。 | +| **platform_code** | [TranslatedString](#message-translatedstring) |任意| 1 つ | (CSV) GTFS の [stops.platform_code](https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#stopstxt) の定義を参照してください。 | + +### _enum_ WheelchairBoarding + +**Values** + +| _**Value**_ | _**Comment**_ | +|-------------|---------------| +| **UNKNOWN** | 停留所のアクセシビリティ情報がありません。 | +| **AVAILABLE** |この停留所の一部の車両には、車椅子の乗客が乗車できます。 | +| **NOT_AVAILABLE** | この停留所では車椅子での乗車はできません。 | + +### _message_ TripModifications `TripModifications`messageは、迂回などの特定の変更の影響を受ける類似の旅行のリストを示します。 + +

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来、正式に採用される可能性があります。 + +[旅行の変更についての詳細...](../../../documentation/realtime/feed_entities/trip-modifications) + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **selected_trips** | [SelectedTrips](#message-selectedtrips) |必須| 多数 | このTripModificationsの影響を受ける選択された旅行のリスト。少なくとも 1 つの `SelectedTrips ` を含める必要があります。値 `start_times` が設定されている場合、1 つのtrip_idを持つ ` SelectedTrips ` を最大 1 つリストできます。 | +| **start_times** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 多数 | trip_ids で定義されたtrip_idのリアルタイム旅行記述子の開始時刻のリスト。頻度ベースの旅行でtrip_idの複数の出発をターゲットにするのに役立ちます。 | +| **service_dates** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 多数 | 変更が発生する日付 (YYYYMMDD 形式)。trip_idは、特定のサービスdateに実行される場合にのみ変更されます。旅行はすべてのサービス日に実行する必要はありません。プロデューサーは、次の 1 週間以内に発生する迂回のみを送信する必要がするべきである。提供された日付は、ユーザー向けの情報として使用しないでください。ユーザー向けの開始日と終了dateを提供する必要がある場合は、リンクされたサービスアラートで `service_alert_id` を使用して提供できます。 | +| **modifications** | [Modification](#message-modification) |必須| 多数 | 影響を受ける旅行に適用する変更のリスト。 | + +### _message_Modification + +`Modification`messageは、`start_stop_selector` から始まる、影響を受ける各旅行への変更について説明します。 + +

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + + + +特定の旅行に対する変更の効果を示す例。この変更は、他のいくつかの旅行にも適用される場合があります。_ + + + +伝播された迂回遅延は、変更の終了後にすべての停車地に影響します。旅行に複数の変更がある場合、遅延は累積されます。_ + + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **start_stop_selector** | [StopSelector](#message-stopselector) |必須| 1 つ | この変更によって影響を受ける元の旅行の最初の停車地の停車地セレクター。`end_stop_selector` と組み合わせて使用​​します。`start_stop_selector` は必須であり、`travel_time_to_stop` で使用される参照停車地を定義するために使用されます。詳細については、[`travel_time_to_stop`](#message-replacementstop) を参照してください | +| **end_stop_selector** | [StopSelector](#message-stopselector) | 条件付きで必須 | 1 つ | この変更によって影響を受ける元の旅行の最後の停車地の停車地セレクター。選択は包括的であるため、その変更によって 1 つの stop_time のみが置き換えられる場合は、`start_stop_selector` と `end_stop_selector` は同等である必要があります。stop_time が置き換えられない場合は、`end_stop_selector` を指定しないでください。それ以外の場合は必須です。 | +| **propagated_modification_delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | 変更によって挿入された最後の停車地の後のすべての出発時刻と到着時刻に追加する遅延の秒数。変更がシェイプのみに影響する場合 (つまり、`end_stop_selector` も `replacement_stops` も指定されていない場合)、遅延の伝播は `start_stop_selector` の後続の停車地から開始されます。正または負の数値を指定できます。同じ旅行に複数の変更が適用されると、旅行が進むにつれて遅延が蓄積されます。

値が指定されていない場合、コンシューマーは他のデータに基づいて `propagated_modification_delay` を補間または推測するしてもよい。 | +| **replacement_stops** | [ReplacementStop](#message-replacementstop) |任意| 複数 | 元の旅行の停留所を置き換える代替停留所のリスト。新しい停車時刻の長さは、置き換えられた停車時刻の数より短くなったり、同じになったり、長くなったりすることがあります。 | +| **service_alert_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ | ユーザー向けの通信用にこのModificationを説明する`Alert`を含む`FeedEntity`messageからの`id`値。 | +| **last_modified_time** | [uint64](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1 つ |このタイムスタンプは、変更が最後に行われた瞬間を識別します。POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数) です。| + +### _message_ StopSelector + +停止のセレクター`stop_id`または`stop_sequence`のいずれか。2 つの値のうち少なくとも 1 つを指定する必要があります。 + +

**注意:**このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **stop_sequence** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 つ | 対応する GTFS フィードのstop_times.txtと同じであるしなければならない。`StopSelector` 内では`stop_sequence`または`stop_id` のStopSelectorかを指定する必要があります。両方のフィールドを空にすることはできません。 `stop_sequence` は、同じ stop_id を複数回訪れるルート (ループなど) で、予測の対象となる停留所を明確にするために必要です。| +| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 1 つ | 対応する GTFS フィードのstops.txtと同じであるしなければならない。`StopSelector` 内では`stop_sequence`または`stop_id` のStopSelectorかを指定する必要があります。両方のフィールドを空にすることはできません。| + +### _message_ SelectedTrips + +関連するシェイプを持つ選択されたルートのリスト。 + +

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **trip_ids** | [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) | 多数 | 1 つ | 元の (CSV) GTFS のtrip_idのリストで、含まれている置換によって影響を受けます。少なくとも 1 つのtrip_idを含める必要があります。| +| **shape_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ |このSelectedTripsで変更された旅程の新しいシェイプのID-RT Shapemessageを使用して追加された新しいシェイプ、または GTFS-Static フィードのshapes.txtで定義されている既存のシェイプを参照する場合があります。| + +### _message_ ReplacementStop + +各`ReplacementStop`messageは、旅程で今後訪問する停留所を定義し、オプションで停留所までの推定移動時間を指定します。 + +

**注意:**このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用される可能性があります。 + + + +変更が旅程の最初の停車地に影響する場合、その停車地は変更の参照停車地としても機能します。_ + + +**フィールド** + +| _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | +|------------------|------------|----------------|-------------------|-------------------| +| **stop_id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1 つ | 旅程で今後訪問される代替の停車地ID-RT の`Stop`messageを使用して追加された新しい停車地、または (CSV) GTFS フィードの``stops.txt``で定義されている既存の停車地を参照する場合があります。停車地には``location_type=0`` (ルート可能な停車地) がしなければならない。| +| **travel_time_to_stop** | [int32](https:) |任意| 1 つ | この停留所への到着時間と参照停留所への到着時間の差 (秒単位)。参照停留所は、`start_stop_selector` の前の停留所です。変更が旅行の最初の停留所で開始される場合、旅行の最初の停留所が参照停留所になります。

この値は単調に増加するしなければならない、元の旅行の最初の停車地が参照停車地である場合にのみ負の数になる場合があります。

値が指定されていない場合、消費者は他のデータに基づいて `travel_time_to_stop` を補間または推測するしてもよい。| diff --git a/docs/ja/documentation/schedule/change_history/recent_additions.md b/docs/ja/documentation/schedule/change_history/recent_additions.md new file mode 100644 index 000000000..83b18bb9d --- /dev/null +++ b/docs/ja/documentation/schedule/change_history/recent_additions.md @@ -0,0 +1,110 @@ +# GTFS Scheduleの変更 + +GTFSGTFS Scheduleリファレンスは固定されたものではありません。GTFS を使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 + +GTFS に貢献するには、[GTFS Schedule修正プロセス](../../../../community/governance/gtfs_schedule_amendment_process) を読み、GTFS Github リポジトリ ( google/transit ) の未解決の問題とプル リクエストでの議論に従ってください。![](../../../assets/mark-github.svg) + + + + + +## 最近採択された提案 + +最近統合された提案は、[公式GTFS Scheduleリファレンス](../../reference) の機能になりました。詳細については、完全な [改訂履歴](../revision_history) を参照してください。 + +
+
+

GTFS Flexを採用

+

#433 by tzujenchanmbdは 2024 年 3 月 19 日に統合されました

+
+
+
    +
  • GTFS-Flex提案により、乗客は旅行計画者で需要に応じたサービスを発見できるようになる。
    • +
  • 仕様には、GTFSにGeoJsonを統合するlocations.geojsonを含む複数のファイルが追加されました。
    • +
+
+
+ +
+
+

networks.txtとroute_networks.txt を追加します。

+

#406 by tzujenchanmbdは 2023 年 11 月 28 日に統合されました

+
+
+
    +
  • 運賃に関連付けられたルートのネットワークを構築するための 2 つの新しいファイル ( networks.txtとroute_networks.txtを追加します。
    • +
  • スケジュールと運賃ファイルを区別できるように、 routes.network_idの代替手段を提供します。
    • +
+
+
+ +
+
+

ベストプラクティス: データセット公開ガイドラインを追加する
すべてのファイルに対する実践的な推奨事項

+

Sergioderoによる#406 は 2023 年 11 月 16 日に統合されました

+
+
+
    +
  • GTFS ベスト プラクティスの 2 つのセクション (データセット公開ガイドラインとすべてのファイルに対する実践推奨事項) を仕様に追加します。
    • +
  • Googleのトランジットフィードツールのマージ機能への参照を更新し、代わりにマージツールのリストを参照するようにしました。
    • +
+
+
+ +
+
+

ベストプラクティス: 推奨プレゼンスを追加する

+

#386 by emmambdは 2023 年 8 月 1 日に統合されました

+
+
+
    +
  • RFC 規則に準拠した仕様に新しい推奨項目を追加します。
    • +
  • フィールドまたはファイルが必須ではないことを明確に示すことができますが、追加することは考慮すべきベストプラクティスです。
    • +
  • GTFS ベスト プラクティスに基づいて、複数のファイルとフィールドの推奨される存在を反映するように情報を更新します。
    • +
+
+
+ +
+
+

時間や曜日によって変動する運賃を追加する

+

isabelle-drによる#357 は 2023 年 7 月 27 日に統合されました

+
+
+
    +
  • 時間変動運賃は、GTFS運賃v2拡張提案の一部として開発された重要な機能です。
    • +
  • ピーク料金やオフピーク料金など、時間帯や曜日に基づいて異なる料金を表現できます。
    • +
  • 運賃が適用される時間を定義するための新しいファイルtimeframes.txtを追加します。
    • +
  • fare_leg_rules.txt from_timeframe_idとto_timeframe_idで拡張し、区間の開始または終了が指定された時間枠内にある場合にのみ運賃区間ルールが適用されることを指定します。
    • +
+
+
+ +
+
+

運賃メディアを追加

+

isabelle-drによる#355 は 2023 年 3 月 14 日に統合されました

+
+
+
    +
  • チケットメディアはGTFS運賃v2拡張提案の重要な要素である
    • +
  • これは、乗客が乗車を認証するために使用できるものを表します（例：交通カード、モバイルアプリ、または非接触型銀行カードを使用したタップして支払う）
    • +
  • 運賃商品は特定のチケットメディアに関連付けることができます（例：月間パスは交通カードでのみ利用可能）
    • +
  • 運賃商品の価格はチケットメディアに基づいて定義できます（例：モバイルアプリ経由で購入するとチケットが安くなります）
    • +
+
+
+ +
\ No newline at end of file diff --git a/docs/ja/documentation/schedule/change_history/revision_history.md b/docs/ja/documentation/schedule/change_history/revision_history.md new file mode 100644 index 000000000..1a47ffcda --- /dev/null +++ b/docs/ja/documentation/schedule/change_history/revision_history.md @@ -0,0 +1,323 @@ +# GTFS Schedule + +### 改訂履歴 + +#### 2024 年 8 月 +* 需要対応型サービスのため、 stops.txt の存在を変更します。[ディスカッション](https://github.com/google/transit/pull/472)を参照してください。 +* stop_times.txtの timepoint の使用目的を明確にします。[ディスカッション](https://github.com/google/transit/pull/474)を参照してください。 +* 行頭標識が推奨されることを追加します。[ディスカッション](https://github.com/google/transit/pull/485)を参照してください。 + +#### 2024 年 7 月 +* feed_info.txtの要件を更新します。[ディスカッション](https://github.com/google/transit/pull/460)を参照してください。 +* シェイプを含める必要があることを追加します。 [ディスカッション](https://github.com/google/transit/pull/470) を参照してください。 + +#### 2024 年 5 月 +* `fare_leg_rules.txt`に `rule_priority` フィールドを追加しました。[ディスカッション](https://github.com/google/transit/pull/418) を参照してください。 + * `stops.zone_id`の存在を明確にしました。[ディスカッション](https://github.com/google/transit/pull/432) を参照してください。 + +#### 2024 年 4 月 +* 運賃商品の定義を明確にしました。[ディスカッション](https://github.com/google/transit/pull/426) を参照してください。 + +#### 2024 年 3 月 +* GTFS Flex を追加しました。 [ディスカッション](https://github.com/google/transit/pull/433) を参照してください。 + +#### 2023 年 11 月 +* ベスト プラクティス: すべてのファイルにデータセット公開ガイドラインと実践推奨事項を追加します。[ディスカッション](https://github.com/google/transit/pull/406) を参照してください。 +* networks.txtとroute_networks.txtを追加します。[ディスカッション](https://github.com/google/transit/pull/405) を参照してください。 + +#### 2023 年 8 月 +* fare_media_type= 1.を追加します。[ディスカッション](https:)を参照してください。 + +#### 2023 年 7 月 +* GTFS ファイル内のサブフォルダを禁止します。 [ディスカッション](https://github.com/google/transit/pull/379) を参照してください。 +* 時間または曜日による変動運賃を追加しました。[ディスカッション](https://github.com/google/transit/pull/357) を参照してください。 +* stop_times.txtの暗黙のタイムゾーンを明確にしました。[ディスカッション](https://github.com/google/transit/pull/378) を参照してください。 + * 停車時刻を指定します。shape_dist_traveled は、旅行シェイプの最大距離を超えてはいけません。[ディスカッション](https://github.com/google/transit/pull/380) を参照してください。 +* ベスト プラクティス: 推奨プレゼンスを追加します。[ディスカッション](https://github.com/google/transit/pull/386) を参照してください。 + +#### 2023 年 3 月 14 日 + +* 運賃メディアを追加しました。 [ディスカッション](https://github.com/google/transit/pull/355) を参照してください。 + +#### 2022 年 7 月 26 日 + +* 座席オプションによる旅行間の乗り換えを追加しました。[ディスカッション](https://github.com/google/transit/pull/303) を参照してください。 + +#### 2022 年 5 月 17 日 + +* GTFS-Fares v2ベースの実装。[ディスカッション](https://github.com/google/transit/pull/286) を参照してください。 + +#### 2021 年 10 月 22 日 + +* プライマリ ID フィールドと外部 IDフィールドを追加しました。[ディスカッション](https:](https:)を参照してください。 + +#### 2021 年 10 月 5 日 + +* 旅行間の乗り換えとルート間の乗り換えを追加しました。 [ディスカッション](https://github.com/google/transit/pull/284) を参照してください。 + +#### 2021 年 9 月 15 日 + +* 改札ゲート (pathway_mode=6) を双方向にできるようになりました。[ディスカッション](https://github.com/google/transit/pull/276) を参照してください。 + +#### 2021 年 9 月 13 日 + +* `stop_name` のベスト プラクティスを更新しました。[ディスカッション](https://github.com/google/transit/pull/282) を参照してください。 + +#### 2021 年 8 月 27 日 + +* GTFS Scheduleを [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) に更新しました。 [ディスカッション](https://github.com/google/transit/pull/277) を参照してください。 + +#### 2021 年 1 月 4 日 + +* `stop_times.stop_id`の説明を明確にしました。[ディスカッション](https://github.com/google/transit/pull/258) を参照してください。 +* 正および非ゼロのフィールド符号を定義しました。[ディスカッション](https://github.com/google/transit/pull/251) を参照してください。 + +#### 2020 年 10 月 2 日 + +* `frequencies.headway_secs` のフィールド タイプを非負から正の整数に変更しました。 [ディスカッション](https://github.com/google/transit/pull/249) を参照してください。 + +#### 2020 年 5 月 25 日 + +* `pathways.txt`、 `levels.txt` 、 `attributions.txt`を翻訳可能なテーブルとして定義しました。多言語`signposted_as`値を翻訳するための推奨事項を追加しました。[ディスカッション](https://github.com/google/transit/pull/220) を参照してください。 + +#### 2020 年 5 月 13 日 + +* `routes.txt`と`stop_times.txt`に`continuous_pickup`と`continuous_drop_off` を追加しました。`shape_id`を`任意`から`条件付きで必須`に変更しました。 [ディスカッション](https://github.com/google/transit/pull/208) を参照してください。 + +#### 2020 年 3 月 24 日 + +* テキスト読み上げフィールドを定義し、 `stops.txt`に`tts_stop_name`を追加しました。[ディスカッション](https://github.com/google/transit/pull/49) を参照してください。 + +#### 2020 年 2 月 5 日 + +* トロリーバスとモノレールの `route_types` を追加しました。[ディスカッション](https:](https:)を参照してください。 + +#### 2020 年 1 月 9 日 + +* `translations.txt`を追加しました。 [ディスカッション](](https://github.com/google/transit/pull/180) を参照してください。 + +#### 2019年12月26日 + +* `route_type`のケーブルトラムと高所作業車の定義を更新しました。[ディスカッション](https://github.com/google/transit/pull/186) を参照してください。 + +#### 2019年12月20日 + +* `attributions.txt`を追加しました。[ディスカッション](https://github.com/google/transit/pull/192) を参照してください。 + +#### 2019年8月26日 + +* `stop_lat`と`stop_lon`を、乗客が車両に搭乗するまで待つ場所に配置することを指定しました。 [ディスカッション](https://github.com/google/transit/pull/179) を参照してください。 + +#### 2019 年 7 月 9 日 + +* 到着時間と出発時間のベスト プラクティスを追加しました。[ディスカッション](https://github.com/google/transit/pull/165) を参照してください。 +* 行先標識のベスト プラクティスを追加しました。[ディスカッション](https://github.com/google/transit/pull/167) を参照してください`stop_id` のベスト プラクティスを追加しました。[ディスカッション](https://github.com/google/transit/pull/169) を参照してください。 + +#### 2019 年 6 月 25 日 + +* シェイプ ポイントと停留所の関係を明確にしました。 [ディスカッション](https://github.com/google/transit/pull/39) を参照してください。 + +#### 2019 年 4 月 4 日 + +* `stops.txt`に`platform_code`フィールドを追加しました。[ディスカッション](https://github.com/google/transit/pull/146) を参照してください。 + +#### 2019 年 3 月 27 日 + +* `pathways.txt`と`levels.txt`を追加しました。[ディスカッション](https:](](https://github.com/google/transit/pull/120) を参照してください。 + +#### 2018 年 10 月 2 日 + +* フィールド タイプを因数分解しました。 [ディスカッション](https://github.com/google/transit/pull/104) を参照してください。 + +#### 2018 年 9 月 14 日 + +* `条件付きで必須`の概念を追加しました。[ディスカッション](https://github.com/google/transit/pull/100) を参照してください。 + +#### 2018 年 9 月 4 日 + +* `agency_lang`と`feed_lang`の定義を統合しました。[ディスカッション](https://github.com/google/transit/pull/98) を参照してください。 + +#### 2018 年 8 月 27 日 + +* `CHANGES.md` と最終更新dateを更新しました。 [ディスカッション](](https://github.com/google/transit/pull/99) を参照してください。 + +#### 2018 年 8 月 22 日 + +* `feed_info.txt`ファイルに`feed_contact_email`フィールドと`feed_contact_url`フィールドを追加しました。[ディスカッション](https://github.com/google/transit/pull/31) を参照してください。 + +#### 2017 年 12 月 11 日 + +* `routes.txt`に`route_sort_order`を追加しました。[ディスカッション](https://github.com/google/transit/pull/83) を参照してください。 + +#### 2017 年 3 月 15 日 + +* 提案者の投票は合計にカウントされないことを明確にしました。 [ディスカッション](https://github.com/google/transit/pull/50) を参照してください。 +* 投票を呼びかける前に、少なくとも 1 つの GTFS プロデューサーと 1 つの GTFS コンシューマーが提案された変更を実装する必要があることを明記しました。[ディスカッション](https://github.com/google/transit/pull/46) を参照してください。 + +#### 2017 年 2 月 7 日 + +* `block_id`と`service_id`の関係を明確にしました。[ディスカッション](https://github.com/google/transit/pull/44) を参照してください。 +* 頻度ベースのサービスは車両の出発時に開始されることを明確にしました。[ディスカッション](https:](https:)を参照してください。 +* `stop_id`と`stop_code`の説明を明確にしました。 [ディスカッション](https://github.com/google/transit/pull/40) を参照してください。 + +#### 2017 年 12 月 11 日 + +* `routes.txt`ファイルに`route_sort_order`フィールドを追加しました。[ディスカッション](https://github.com/google/transit/pull/83) を参照してください。 + +#### 2016 年 11 月 27 日 + +* `stops.location_type`として駅の入口を追加しました。[ディスカッション](https://github.com/google/transit/pull/30) を参照してください。 + +#### 2016 年 9 月 2 日 + +* ドキュメントを更新し、 `fare_attributes.txt`の下に`agency_id`を追加しました。 [ディスカッション](https://github.com/google/transit/pull/27) を参照してください。 + +#### 2016 年 3 月 16 日 + +* GTFS ドキュメントを Github (https://github.com/google/transit) に移行 + +#### 2016 年 2 月 3 日 + +* `agency_email`を`agency.txt`に追加しました。仕様への提案: [ディスカッション](https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/aezjQsriLYA) + +#### 2015 年 2 月 2 日 + +* stop_times.txtの ’timepoint’ の提案を仕様に追加しました: [ディスカッション](https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/Ah-J9JP2rJY) + +#### 2015 年 2 月2014 年 17 月 17 日 + +* trips.txtの`bikes_allowed`提案を仕様に追加しました: [discussion](https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/rEiSeKNc4cs) + +#### 2012 年 10 月 15 日trips.txtの`wheelchair_accessible`提案を仕様に追加しました: [discussion](https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/ASxItgsQlh4) + +#### 2012 年 6 月 20 日 + +* ’wheelchair_boarding’ 提案を仕様に追加しました: [discussion](https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/ASxItgsQlh4) + +#### 2012 年 2 月 2 日2012 + +* 仕様に`stop_timezone`提案を追加しました: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/2Il0Q9OXqu4) + +#### 2012 年 1 月 18 日 + +* ドキュメントを古い code.google.com から新しい場所である developer.google.com に移行しました。 + +#### 2011 年 9 月 26 日 + +* 仕様に`feed_info`提案を追加しました: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/Sh0e4o9o2Gw) + +#### 2011 年 9 月 6 日 + +* 仕様に`agency_fare_url`提案を追加しました: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/Zp9rPG07CgE) +* 仕様に`exact_times`提案を追加しました: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/nZF9lbQ7TQs) + +#### 2009 年 3 月 30 日 + +* 交通フィードを一般公開するための新しいセクション。これは、データの解釈方法や記述方法に厳密に変更を加えるものではないため、これまでグループで議論されていませんでした。ただし、GTFS 形式のデータを利用できるアプリケーションが増えているため、Google 以外の GTFS の使用に関する説明を含めることが有益であると考える Google スタッフもいました。 +* CSV 形式の明確化: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/03qz5aTA2mk)。 +* route_color フィールドと route_text_color フィールドの説明で対照的な色を選択する方法に関する追加ガイダンス。 +* trip_short_name は、次のスレッドで提案およびテストされています: a および b。 +* ドキュメントの末尾に含まれるサンプル データの軽微なエラーを修正しました (stop S7 に parent_station S8 が割り当てられています)。 +* コメント期間中に Marcy から提案されたように、ドキュメントの末尾のサンプル データに`agency_lang`情報を追加しました: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/5qP1kDUFqx0)。 +* サイドバーの OCTA の GTFS フィードへのリンクを更新しました +* [オリジナルの概要](https://groups.google.com/forum/#!topic/gtfs-changes/cL1E4oKKpKw) を参照してください。 + +#### 2009 年 2 月 26 日 + +* 現時点では GTFS データを使用するアプリケーションが他にも多数あるため、Google 固有のフィード送信手順のほとんどを削除しました。 +* サイドバーの Orange County OCTA のパブリック フィードへの壊れたリンクを修正しました。 + +#### 2008 年 8 月 7 日 + +* 8 月 6 日のバージョンで誤って省略されていた stop_url フィールドを復元しました +* サンプル データに agency_phone を追加しました +* Google にフィードを送信する際のデータ使用契約についての言及を追加しました + +#### 2008 年 8 月 6 日2008 + +* transfers.txtファイルを追加し、フィード発行者が望ましい乗り換え動作に関するヒントを提供できるようにしました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/cL1E4oKKpKw)) +* locations_type および parent_station フィールドをstops.txtに追加し、停車地点を駅にグループ化できるようにしました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/ScGAyZ9a_yw)) +* agency_phone フィールドを追加し、代理店の音声電話番号を指定できるようにしました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/8Itt58ueyqA)) +* オープンソースのテスト ツールについて言及した`フィードのテスト`セクションを追加しました +* CSV 形式、agency_timezone、agency_lang についての説明を追加しましたroute_color、route_text_color、arrival_time、departure_time、 calendar.txtとcalendar_dates.txtの比較、運賃表、 frequencies.txt +* フィード履歴ドキュメントへのリンクを追加し、一部のパブリック フィード リンクを修正しました +* 現在の Google マップ UI を表すようにサンプル画像を更新しました +* ドキュメントのサンプル データを更新/修正しました + +#### 2008 年 2 月 29 日 + +* 乗客向けの停止コードを指定できるように、 stops.txtに stop_code フィールドを追加しました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/k9A95fYZexc)) +* routes.txtの route_short_name と route_long_name の説明を明確にしました +* stop_times.txtの arrive_time と destination_time の説明を明確にしました +* サンプル データ セクションのタイプミスを修正しました + +#### 2007 年 11 月 20 日 + +* block_id の説明を明確化しました +* Google Transit を強調しないように言語を変更しました (Google 以外のアプリケーションは GTFS を使用しており、交通機関のルーティングは Google マップの統合機能になったため)。また、さまざまなタイプミスを修正しました +* 現在の Google マップ UI での GTFS フィールドの表示を反映するようにサンプルのスクリーンショットを更新しました +* 交通機関データ プロバイダの Google 連絡先メール アドレスを更新しました +* 書式を更新しました + +#### 2007 年 10 月 5 日 + +* stop_sequenceと shape_pt_sequence を変更し、増加する非負の整数を使用できるようにしました +* 説明を明確化し、タイプミスを修正しました + +#### 2007 年 5 月 31 日 + +* ページ スタイルを更新し、HTML をよりわかりやすくアクセスしやすくしました +* 公開フィード サンプルやその他の便利なサイトへのリンクを追加しました +* 個々のフィールドの説明からサンプルを削除しました + +#### 2007 年 4 月 9 日 + +* [フィードの送信](https://developers.google.com/transit/google-transit#SubmitFeedToGoogle). +* [サンプル デモ交通事業者フィード](https://developers.google.com/transit/gtfs/examples/gtfs-feed) を追加しました。 +* すべてのサービス日付がcalendar_dates.txtで定義されている場合は、 calendar.txt を省略できるという注記を追加しました。 +* 1 つの交通機関のみを含むフィードでは agency_id フィールドをオプションにしました。これにより、agency_id のない既存のフィードが有効なままになります。 +* agency_url、stop_url、route_url のより完全な仕様と、これらのフィールドの追加の例の値を追加しました。 +* 有効な route_type 値として 6 (ゴンドラ) と 7 (ケーブルカー) を追加しました。 + +#### 2007 年 3 月 8 日 + +* 2 月 28 日の更新で誤って指定されたstop_times.txtの stop_url フィールドを、適切な位置にあるstops.txtに移動するための軽微な編集を行いました。 + +#### 2007 年 3 月 5 日 + +* route_long_name フィールドの説明を明確にするための軽微な編集を行いました。 + +#### 2007 年 2 月 28 日 + +* ヘッドウェイベースのスケジュールをサポートするためにfrequencies.txtを追加しました。 +* 同じフィードで複数の機関が許可されるようになりました。また、agencys.txtとroutes.txtの両方に新しい agency_id フィールドが追加され、どのルートがどの機関によって運営されているかを指定できるようになりました。 +* ルートごとおよび停留所ごとの URL の追加。 +* trips.txtに direction_id フィールドが追加されました。 +* stop_times.txtに stop_headsign フィールドが追加され、途中での行先標識の変更がサポートされるようになりました。 +* routes.txtにオプションの route_color と route_text_color が追加され、ルートの色をサポートできるようになりました。 +* 住所を使用して停留所を指定する機能が削除されました。以前のバージョンの仕様では、stop_street、stop_city、stop_region、stop_postcode、stop_country フィールドで住所を使用して交通機関の停留所の場所を指定できました。現在は、停車地は緯度に stop_lat、経度に stop_lon を使用して指定する必要があります。これは、ほとんどのアプリケーションでより便利です。 +* routes.txtの route_type フィールドにケーブルカーの車両タイプを追加しました。 +*変更の概要については、元の [Headway ブログ投稿](http://headwayblog.com/2007/03/02/google-feed-spec-update-2007-02/) を参照してください。 + +#### 2006 年 11 月 29 日 + +* shapes.txtによる旅行形状情報のサポートを追加しました +* stop_sequenceの定義を明確化しました +* pickup_typeとdrop_off_type をオプションとしてマークしました + +#### 2006 年 10 月 31 日 + +*運賃情報のサポートを追加しました +*個々のファイル名から日付を削除しました +* route_type 値の定義を変更しました +*サービス期間が重複しない限り、複数のフィード ファイルを同時に投稿できるようにしました +* trips.txt を修正して、正しく任意マークされるようにしました。 +* 列ヘッダーを含める必要があることに注意しました + +#### 2006 年 9 月 29 日 + +* 例のいくつかのエラーを修正するために、小さな編集を行いました。 + +#### 2006 年 9 月 25 日 + +* 最初のバージョン。 \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/attributions.md b/docs/ja/documentation/schedule/examples/attributions.md new file mode 100644 index 000000000..8ee8afccc --- /dev/null +++ b/docs/ja/documentation/schedule/examples/attributions.md @@ -0,0 +1,26 @@ +# データセットの帰属 + +## 集約された GTFS データセット内のデータ プロデューサーにデータを帰属させる + +一部の GTFS データセットには、同じ管轄区域にサービスを提供する異なるサービス プロバイダーなど、複数のソースから集約されたデータが含まれています。場合によっては、[agency.txt](../../reference/#agencytxt) にリストされている機関をプロデューサー、オペレーター、または当局として分類する必要があります。 + +たとえば、Rejseplanen はデンマークの鉄道およびバス サービスの検索エンジンです。この会社は、以下の [agency.txt](../../reference/#agencytxt) に示すように、複数の機関とプロバイダーからのデータを含む GTFS データセットを公開しています。 + +[** agency.txt**](../../reference/#agencytxt) + +``` +agency_id,agency_name,agency_url,agency_timezone,agency_lang +202,Bornholms Trafik,https://bat.dk,Europe/Berlin,da +204,FYNBUS,https://fynbus.dk,Europe/Berlin, +206,NT,https://www.nordjyllandstrafikselskab.dk,Europe/Berlin, +276,Rejseplanen,https://www.rejseplanen.dk,Europe/Berlin, +``` + +Rejseplanen をデータ プロデューサーとして属性付けるには、ファイル [attributions.txt](../../reference/#attributionstxt) が使用されます。IDと URL とともに定義されます組織の。フィールド`is_producer`、 `is_operator`、および`is_authority`は、以下に示すように、Rejseplanen を分類​​するために使用されます。 + +[** attributions.txt**](../../reference/#attributionstxt) + +``` +attribution_id、organization_name、attribution_url、is_producer、is_operator、is_authority +rp、Rejseplanen、https://www.rejseplanen.dk、1、、 +``` diff --git a/docs/ja/documentation/schedule/examples/continuous-stops.md b/docs/ja/documentation/schedule/examples/continuous-stops.md new file mode 100644 index 000000000..5a05e60c5 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/continuous-stops.md @@ -0,0 +1,68 @@ +# 連続停車 + +## どこでも乗降可能 + +交通機関 The Current (ロッキンガム、米国バーモント州) は、ルート 2、53、55 に連続停車ポリシーを適用しています。バスが安全に停車できる場所がある限り、ルート上のすべての予定停車間で乗客の乗降が可能です。 + +ファイル [routes.txt](../../reference/#routestxt) は、フィールド`continuous_pickup`および`continuous_drop_off`を使用してこのサービスを説明するために使用されます。連続乗降が許可されていることを示すために、フィールドは `0` に設定されています。 + +[** routes.txt**](../../reference/#routestxt) + +``` + route_id、route_short_name、route_long_name、route_type、連続乗車、連続降車 +2,2、ベローズ フォールズ市内、3,0,0 +53,53、ベローズ フォールズ/バトルボロ通勤、3,0,0 +55,55、ベローズ フォールズ/スプリングフィールド シャトル、3,0,0 +``` + +
+ +## 路線の一部での乗降 + +交通機関 Victor Valley Transit (ビクタービル、米国カリフォルニア州) は、路線 22 の一部にのみ連続停車ポリシーを適用しています。乗客は、郡運賃ゾーン内の安全な場所でのみバスに乗降できます。ローカル運賃ゾーン内で連続した乗降はできません。 + +ローカル運賃ゾーンと郡運賃ゾーンは、下の図に示すように、エア エクスプレスウェイによって分離されています。予定されている停留所 National Trails Highway- Air Expressway は、この境界の少し北にあります。正確には、交通機関はバス路線と境界の実際の交差点に停留所を追加し、そこから連続した乗降を利用できます。この停留所は予定されていない場合があります。 + +![](../../../assets/victor-valley-transit.svg) + +これは、[stop.txt](../../reference/#stopstxt) および [stop_times.txt](../../reference/#stop_timestxt) ファイルを使用して説明されています: + +- 最初のファイルはルート沿いの停留所を定義します +- 2 番目のファイルは停留所間の連続的な乗降ルールを定義します。 + +[**stop.txt**](../../reference/#stopstxt) + +``` +stop_id、stop_name、stop_lat、stop_lon +A、Victoriaville Transfer Station、34.514356、-117.318323 +B、Dante St & Venus Ave、34.564499、-117.287097 +C、Victorville Transportationセンター、34.538433、-117.294703 +X、地方/郡運賃境界、34.566224、-117.318357 +D、ナショナル トレイルズ ハイウェイ - エア エクスプレスウェイ、34.567536、-117.319716 +E、オロ グランデ郵便局、34.599292、-117.334452 +F、シルバー レイクス マーケット、34.744662、-117.335407 +``` + +[stop_times.txt](../../reference/#stop_timestxt) では、特定の旅行について次のようになります。 + +- `continuous_pickup=0` のレコードは、その停車地から次の停車地まで連続乗車が許可されていることを示します。 +- `continuous_pickup=1` のレコードは、連続乗車が許可されていないことを示します。次の停留所までその停留所から立ち入り禁止 + +[** stop_times.txt**](../../reference/#stop_timestxt) + +``` + trip_id、stop_id、 stop_sequence、departure_time、arrival_time、continuous_pickup、continuous_drop_off、timepoint +22NB9AM、A、1、09:00:00、09:00:00、1、1、1 +22NB9AM、B、2、09:14:00、09:14:00、1、1、1 +22NB9AM、C、3,09:21:00,09:21:00,1,1,1 +22NB9AM,X,4,,,0,0,0 +22NB9AM,D,5,09:25:00,09:25:00,0,0,1 +22NB9AM,E,6,09:31:00,09:31:00,0,0,1 +22NB9AM,F,7,09:46:00,09:46:00,0,0,1 +``` + +降車の場合、フィールド`continuous_drop_off`に同じロジックが適用されます。 + +上記の例では、停車地 A、B、C の Continuous_pickup と`continuous_drop_off` が`1`に設定されており、それらの間での連続的な乗車と降車が禁止されています。停留所`X`、`D`、`E`、`F` では、フィールド`continuous_pickup`と`continuous_drop_off`が `0` に設定されており、それらの間での連続的な乗車と降車が許可されます。 + + [例のソース](https://vvta.org/routes/route-22/) \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/fares-v1.md b/docs/ja/documentation/schedule/examples/fares-v1.md new file mode 100644 index 000000000..9c478842a --- /dev/null +++ b/docs/ja/documentation/schedule/examples/fares-v1.md @@ -0,0 +1,71 @@ +#Fares v1 + +[fare_attributes.txt](../../reference/#fare_attributestxt) と [fare_rules.txt](../../reference/#fare_rulestxt) で構成されるFares v1 は、歴史的に GTFS で運賃情報を記述するための公式の方法でした。しかし、2 つのファイルは、効率的に記述できる要素の幅が限られており、実装があいまいです。 +[Fares v2](../../examples/fares-v2/) は現在開発中の拡張プロジェクトで、Fares v1の制限に対処することを目的としています。 + +## 機関の運賃規則を定義する + +トロント交通委員会の地下鉄ネットワークで乗客が PRESTO カードを使用して支払う場合、乗車料金は 3.20 カナダドルです。乗客は、2 時間以内に TTC が運営する他の地下鉄、路面電車、またはバス路線に乗り換えることもできます。 + +このサービスは、[fare_attributes.txt](../../reference/#fare_attributestxt)、[fare_rules.txt](../../reference/#fare_rulestxt)、および [transfers.txt](../../reference/#transferstxt) ファイルを使用して表すことができます。最初のファイル [fare_attributes.txt](../../reference/#fare_attributestxt) には、交通機関の運賃が記載されています。以下は、プレスト運賃の例です: + +[** fare_attributes.txt**](../../reference/#fare_attributestxt) + +``` +fare_id,price,currency_type,payment_method,transfers,transfer_duration +presto_fare,3.2,CAD,1,,7200 +``` + +- 運賃は、price と`currency_type`の下に表示されます。 +- 乗客は、地下鉄に乗る前に、駅の改札口で運賃を支払う必要があります。これは `payment_method=1` で表されます +- フィールド transfers は、無制限の乗り換えを表すために空白のままにされています +- フィールド`transfer_duration` は、2 時間の乗り換えウィンドウに対応します (秒単位) + +2 番目のファイル [fare_rules.txt](../../reference/#fare_rulestxt) は、運賃をルートおよびそのルートの出発地/目的地に結び付けて、運賃を旅程に割り当てます。 + +そのために、2 つの地下鉄路線が [routes.txt](../../reference/#routestxt) で以下のように定義されています: + +[** routes.txt**](../../reference/#routestxt) + +``` +agency_id、 route_id、route_type +TTC、Line1、1 +TTC、Line2、1 +``` + +この例では、Bloor-Yonge 駅での乗り換えがモデル化されています。そのため、この駅は 2 つの別々の停留所としてモデル化されています。1 つ目は 1 号線が停車する Bloor 駅、2 つ目は2.号線が停車する Yonge 駅です。両方の駅に `zone_id=ttc_subway_stations` が設定されており、すべての地下鉄駅を 1 つの料金ゾーンにグループ化しています。 + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id,stop_name,stop_lat,stop_lon,zone_id +Bloor,Bloor Station,,43.670049,-79.385389,ttc_subway_stations +Yonge,Yonge Station,,43.671049,-79.386789,ttc_subway_stations +``` + +[fare_rules.txt](../../reference/#fare_rulestxt)では、PRESTO運賃は、次の関係を使用して地下鉄の路線と駅の両方に関連付けられています: + +- `fare_id=presto_fare`の場合、乗客はLine 1 (`route_id=line1`)の任意の2つの駅間を移動でき、 `origin_id=ttc_subway_stations` および `destination_id=ttc_subway_stations`。 + +[** fare_rules.txt**](../../reference/#fare_rulestxt) + +``` +fare_id、 route_id、origin_id、destination_id +presto_fare、line1、ttc_subway_stations、ttc_subway_stations +presto_fare、line2、ttc_subway_stations、ttc_subway_stations +``` + +3 番目のファイル [transfers.txt](../../reference/#transferstxt) は、異なるルート間の乗り換えポイントを定義します。 Bloor-Yonge 駅での乗り換えをモデル化するには、次の 2 つのエントリが必要です。 + +[** transfers.txt**](../../reference/#transferstxt) + +``` +from_stop_id、to_stop_id、from_route_id、to_route_id、transfer_type +Bloor、Yonge、line1、line2、0 +Yonge、Bloor、line2、line1、0 +``` + +- 最初のモデルは、Bloor 駅から Yonge 駅までの`from_route_id`と`to_route_id`を`to_route_id`して、Line 2 から Line 1 への乗り換えをモデル化します +- 乗り換えに関する特定の要件や考慮事項がないため、 `transfer_type`の値は `0` です + + [ソースの例](https:) diff --git a/docs/ja/documentation/schedule/examples/fares-v2.md b/docs/ja/documentation/schedule/examples/fares-v2.md new file mode 100644 index 000000000..05204ddfe --- /dev/null +++ b/docs/ja/documentation/schedule/examples/fares-v2.md @@ -0,0 +1,422 @@ +# Fares v2 + + Fares v2は、 Fares v1の制限に対処することを目的とした GTFS 拡張プロジェクトです。この拡張プロジェクトは、段階的に採用されています。以下の例では、運賃商品や乗客が運賃を乗り換えに使用する方法など、基本概念をモデル化する方法の概要を示します。詳細については、[Fares v2拡張プロジェクト](../../../../community/extensions/fares-v2) を参照してください。 + +当面の間、プロデューサーはFares v2 をFares v1の実装と同じデータセットに実装できます。両者の間に技術的な競合はありません。コンシューマーは、どちらの実装を他方から独立して使用するか選択できます。 + Fares v2が採用され、十分な支持が得られれば、将来的にFares v1 は廃止される可能性があります。 +当面の間、プロデューサーはFares v2をFares v1の実装と同じデータセットに実装できます。両者の間に技術的な競合はありません。消費者は、他の実装とは独立して、どちらの実装を使用するかを選択できます。 + +以下の例は、 Fares v2を使用してデータをモデル化する方法の概要を示しており、完全な [提案ドキュメント](https://share.mobilitydata.org/gtfs-fares-v2) で概説されている実験的な機能を使用して完了できます。 + +## Fares v2 のトレーニングと無料リソース + +GTFS Fares-v2 を使い始めるには、これらの 4 つのビデオ チュートリアルを視聴し、[この書面によるリソース](https://share.mobilitydata.org/Fares-v2-written-resource-guide-for-videos) に従ってください。 + +- [動画 1](https://share.mobilitydata.org/faresv2-intro): GTFS 運賃 v2: 概要 +- [動画 2](https://share.mobilitydata.org/faresv2-setting-up-google-sheets): GTFSFares v2: Google スプレッドシートの設定 +- [動画 3](https://share.mobilitydata.org/faresv2-creating-and-maintaining-data): GTFSFares v2: データの作成と維持 +- [動画 4](https://share.mobilitydata.org/faresv2-exporting-and-publishing): GTFSFares v2 のエクスポートと公開 + +これらは、交通機関がGTFS-Fares v2の目的と、Google スプレッドシートを使用してGTFS-Fares v2データを作成、編集、アップロードする方法を理解できるように作成されています。 + +この [Fares v2テンプレート](https:) は、必要な運賃ファイルを最初から作成するために使用できます。 + +##Fares v2データ モデリングの例 + +### 交通運賃を定義する + +メリーランド交通局システムを使用するための運賃の支払い方法はいくつかあります。通常の正規料金の運賃オプションには次の 4 種類があります。 + +- 2.00 米ドルの片道チケット +- 4.60 米ドルの 1 日パス +- 22 米ドルの週パス +- 77 米ドルの月間パス + +交通チケットまたは運賃は、GTFS では運賃商品と呼ばれます。これらは [fare_products.txt](../../reference/#fare_productstxt) ファイルを使用して記述できます。各エントリは特定の運賃に対応します。 + +[** fare_products.txt**](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name | amount | currency | +|------------------------|--------------------|---|---| +| core_local_oneway_fare | 片道正規運賃 | 2.00 | USD | +| core_local_1_day_fare | 1 日パス - コアサービス | 4.60 | USD | +| core_local_31_day_fare | 31 日パス - コアサービス | 77.00 | USD | +| core_local_7_day_fare | 7 日パス - コアサービス | 22.00 | USD | + + + [メリーランド州交通局のローカルバス GTFS フィードをダウンロード](https://feeds.mta.maryland.gov/gtfs/local-bus) + +
+ +### 単一区間の旅程のルールを作成する + +GTFS では、運賃区間は、乗客が異なるモード、ルート、ネットワーク、または機関間で乗り換えを行わずに行う旅行に対応します。メリーランド州交通局のフィードでは、単一運賃で、乗客は BaltimoreLink バス、Light RailLink、および Metro SubwayLink ルートの`コア`ネットワーク内にある任意の停留所と地下鉄駅のペア内を移動できます。 + +区間グループは、ネットワーク内の出発地から目的地 (または、エリア ID がグループ化された停留所に対応する場合は、出発地のセットから目的地のセット) への旅行を定義します。以下のファイルには、メリーランド州交通局のコア ネットワーク内の任意の場所を移動するためのルールが記述されています。各ルールは、[交通機関運賃の定義例](#define-a-transit-fare) の通常運賃商品の 1 つに対応します。 + +[** fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) + +| leg_group_id | network_id | fare_product_id | +|---|---|---| +| core_local_one_way_trip | core | core_local_oneway_fare | +| core_local_one_way_trip | core | core_local_1_day_fare | +| core_local_one_way_trip | core | core_local_31_day_fare | +| core_local_one_way_trip | core | core_local_7_day_fare | + + [メリーランド州交通局のローカルバス GTFS フィードをダウンロード](https://feeds.mta.maryland.gov/gtfs/local-bus) + +
+ +### 乗り換えのルールを作成する + +BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLink に乗車するために片道料金を購入した乗客には、90 分間の乗り換えがあります。つまり、90 分間にローカル バス、地下鉄、ライト レール間を無制限に乗り換えることができます。 + +[** fare_transfer_rules.txt**](../../reference/#fare_transfer_rulestxt) + +| from_leg_group_id | to_leg_group_id | duration_limit | duration_limit_type | fare_transfer_type | transfer_count | +|-------------------------|---|----------------|-------------------|---------------------|----------------| +| core_local_one_way_trip | core_local_one_way_trip | 5400 | 1 | 0 |-1 | + + +上記のファイルは、GTFS で次のフィールドを使用してこれを表しています: + +- 片道旅行 (`core_local_one_way_trip`) の区間への乗り換えが可能です +- 許可される乗り換え回数に制限がないため、 `transfer_count`は `-1` に設定されます +- `duration_limit`は `5400` 秒に設定されており、これは 90 分に相当します +- 乗り換え時間は、乗客が ` `duration_limit_type`運賃区間のいずれかのルートで出発したときに開始され、別の運賃区間で出発したときに終了するため、`duration_limit_type` は`1`に設定されます。 +- 乗客は最初の運賃のみを支払うため、 `fare_transfer_type`は `0` に設定されます。90 分の時間枠内での乗り換えには、乗り換え料金や 2 つ目の運賃はかかりません。したがって、コストは、最初の運賃の合計と乗り換え料金の合計としてモデル化できます。 +- 乗客は 90 分の`duration_limit`ウィンドウ内で無制限に乗り換えることができるため、 `transfer_count`は `-1` に設定されています。 + +運賃を定義し、適切な `fare_leg_rule` を作成し、`fare_transfer_rule` を定義すると、旅行計画者に 2.00 USD の `core_local_oneway_fare` が表示されます。以下は Transit からの例です: + +
+ 運賃2ドル +
+ + [メリーランド州交通局のローカルバス GTFS フィードをダウンロード](https:) + +### 同じ運賃ゾーン内のサービス場所を説明する + +一部の交通機関はゾーンベースの運賃体系を運用しています。運賃ゾーンは、異なる運賃に関連付けられた地理的エリアに分割されています。ベイエリアの BART システムでは、出発地と目的地によって運賃が異なり(BART 運賃の違い) 、交通機関の利用者は正しい運賃を知る必要があります。料金エリアは、[stops_areas.txt](../../reference/#stop_areastxt) ファイルを使用して記述できます。このファイルは、[stops.txt](../../reference/#stopstxt) から [areas.txt](../../reference/#areastxt) に停車地を割り当てます。 + +まず、[areas.txt](../../reference/#areastxt) でエリアを特定します。エリア名がない場合は、 `area_name` を空白のままにしておくことができます。下の表には、`ASHB`、`GLEN`、および `OAKL` の 3 つの`area_id`があります。 + +[** areas.txt **](../../reference/#areastxt) + +| area_id | area_name | +|---------|-----------| +| ASHB | | +| GLEN | | +| OAKL | | + +その後、[stops.txt](../../reference/#stopstxt) ファイルの`stop_id`を使用して、停留所をそれぞれの識別されたエリア (運賃ゾーン) にグループ化します。 + +次に、 `stop_id`を各`area_id`にグループ化します。BART の例では、各エリアには 1 つの`stop_id`のみが含まれます。たとえば、エリア `ASHB` には停留所 `ASHB` (Ashby Station) のみが含まれます。ただし、エリアに複数の停留所が含まれる場合は、複数の`stop_id`をリストする必要があります。 + +[**stops_areas.txt**](../../reference/#stop_areastxt) + +| area_id | stop_id | +|---------|---------| +| ASHB | ASHB | +| GLEN | GLEN | +| OAKL | OAKL | `fare_leg_rules.txt`では、出発地と到着地の異なるエリアに基づいて、異なる運賃商品を識別できます。 たとえば、最初のエントリは次を示します: + +* 出発エリアは `ASHB` です。 +* 到着エリアは `GLEN` です。 +* 出発/到着エリアの運賃商品は `BA:matrix:ASHB-GLEN` です。 + +[** fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) + +| leg_group_id | from_area_id|to_area_id|fare_product_id| +|--------------|-----------|------------|---------------| +| BA | ASHB | GLEN | BA:matrix:ASHB-GLEN | +| BA | ASKB | OAKL | BA:matrix:ASHB-OAKL | + +運賃は`fare_products.txt`で識別されます。 + +[** fare_products.txt**](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name| amount | currency | +|---------------------|-----------|---------|----------| +| BA:matrix:ASHB-GLEN | generated | 4.75 | USD | +| BA:matrix:ASHB-OAKL | generated | 9.45 | USD | + + +サンフランシスコ ベイエリア地域フィードをご覧ください + +
+ +### 受け入れられる運賃媒体について説明します + +サンフランシスコ Muni の乗客は、乗車料金の支払いと運賃の検証に、いくつかの異なるタイプの運賃媒体を使用できます。 + +- ベイエリアの交通カードであるClipper カードを使用する +- Munimobile アプリを使用する +- 現金で運賃を支払う + +これらの検証方法は、 GTFS-Fares v2では `fare_media` と呼ばれ、`fare_media.txt` を使用して説明できます。 + +以下は、511 SF Bay API でアクセスできるサンフランシスコ ベイエリア地域フィードのサンプル スニペットです。 + +`Clipper` は、`fare_media_type=2` の物理的な交通カードとして説明されています。`A` Munimobile` は、`fare_media_type=2` のモバイル アプリとして説明されています。`現金` には運賃媒体がありません。チケットなしで運転手に直接渡されるためです。その結果、`Cash` は `fare_media_type=0` になります。 + +[** fare_media.txt**](../../reference/#fare_mediatxt) + +| fare_media_id | fare_media_name | fare_media_type | +|--------------|------------------|-----------------| +| clipper | Clipper | 2 | +| munimobile | SFMTA MuniMobile | 4 | +| cas​​h | Cash | 0 | + +サンフランシスコ ベイエリア地域フィードをご覧ください + +さらに、物理的なチケットを運賃メディアとして記述したいプロデューサーは、`fare_media_type=1` を使用できます。 + +マサチューセッツ湾交通局 (MBTA) では、 CharlieTicket と呼ばれる物理的な紙のチケットを使用して、ユーザーが旅行やパスの料金を支払うことを許可しています。これを反映するために、MBTA のフィードには `fare_media_type=1` の `charlieticket` 運賃メディアがあります。 + +[** fare_media.txt**](../../reference/#fare_mediatxt) + +| fare_media_id | fare_media_name | fare_media_type | +|--------------|------------------|-----------------| +|cash |Cash |0 | +|charlieticket |CharlieTicket |1 | +|mticket |m Ticket app |4 | + +マサチューセッツ湾交通局フィードを参照してください + +### 運賃メディアに基づく価格差を定義する + +Muni の運賃は、乗客が使用する運賃メディアによって異なります。この例では、現金または Clipper カードを使用した場合に大人のローカル運賃がどのように変化するかについて説明します。現金で支払う大人のローカル運賃は 3 米ドルですが、同じ運賃を Clipper カードで支払うと 50 セント安い 2.50 米ドルになります。 + +以下の各エントリは運賃メディアについて説明しています。 + +[** fare_media.txt**](../../reference/#fare_mediatxt) + +| fare_media_id | fare_media_name | fare_media_type | +|--------------|------------------|-----------------| +| clipper | Clipper | 2 | +| cas​​h | Cash | 0 | + +以下の`fare_products.txt`ル` スニペットは、乗客が使用する運賃メディアに応じて `i` シングル ローカル運賃` 商品の金額がどのように変化するかを示しています。 + +[** fare_products.txt**](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name | amount | currency | fare_media_id | +|--------------|------------------|-------|---|--------------| +| SF:local:single | Muni 片道ローカル運賃 | 3 | USD | cas​​h | +| SF:local:single | Muni 片道ローカル運賃 | 2.5 |USD | clipper | + +Apple マップでは、乗客は運賃がどのように変化するかを確認できます。`i` J Church 列車に乗る`という指示の下で運賃を比較できます。 + +
+ 現金運賃3ドル + クリッパーカードの運賃は2.50米ドル +
+ +サンフランシスコ ベイエリア地域フィードを参照してください + + +### 非接触型運賃メディア オプションについて説明します + + サンタバーバラ郡北部の Clean Air Express では、クレジットカード、Google Pay、 Apple Payによる非接触型支払いが受け付けられます。 + +Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard、Visa) オプションであるため、`fare_media_type=3` の `tap_to_ride` 運賃メディアがあります。 + +| fare_media_id | fare_media_name | fare_media_type | +|---------------|-----------------|-----------------| +| tap_to_ride | Tap to Ride | 3 | + +以下に示す 1 回の乗車運賃製品には、`cash` と `tap-to-ride` の両方の運賃メディア オプションがあります。 1 回の乗車料金を`タップして乗車`運賃メディアで支払うと、1 ドル安くなります。 + +[** fare_products.txt**](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name | fare_media_id | amount | currency | +|--------------|------------------|---------------|--------|---------| +| single-ride | Single Ride | tap_to_ride | 6 | USD | +| single-ride | Single Ride | | 7 | USD | + + Clean Air Express フィードをダウンロードする + + +### 時間と旅行日に基づいて価格差を定義する + +一部の交通機関は、時間や曜日に基づいて運賃を変更します。つまり、運賃は、ピーク時、オフピーク時、週末など、旅行が行われる時間帯に関連付けられます。 + +ワシントン DC のメトロレールの運賃は、旅行の日時など、複数の要因によって異なります。GTFS の可変時間運賃は、`timeframes.txtを使用して定義できます。このファイルでは、特定の時間帯を指定して、それを`fare_leg_rules.txt`で関連付け、旅行が行われる時間に対応する適用可能な運賃商品を割り当てることができます。以下は、2023 年春現在の WMATA の運賃に基づいた架空の例です。 + +まず、サービス日は`calendar.txt`を使用して定義されます。 + +[** calendar.txt**](../../reference/#calendartxt) + +| service_id | monday | tuesday | wednesday | thursday | friday | saturday | sunday | start_date | end_date | +|------------------|--------|----------|-----------|----------|----------|----------|----------|-----------| +| weekday_service | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 20220708 | 20221231 | +| saturday_service | 0 | 0 | 0 | 0 | 1 | 0 | 20220708 | 20221231 | +| sunday_service | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 20220708 | 20221231 | + + +その後、必要な時間枠が `timeframes.txt` で定義され、ID、 `calendar.service_id`への参照を介した適用可能な日、および該当する場合は各期間の開始時刻と終了時刻が提供されます。 + +[** timeframes.txt**](../../reference/#timeframestxt) + +| timeframe_group_id | start_time | end_time | service_id | +|--------------------|------------|----------|------------------| +| weekday_peak | 5:00:00 | 9:30:00 | weekday_service | +| weekday_offpeak | 9:30:00 | 15:00:00 | weekday_service | +| weekday_peak | 15:00:00 | 19:00:00 | weekday_service | +| weekday_offpeak | 19:00:00 | 21:30:00 | weekday_service | +| weekday_late_night | 21:30:00 | 24:00:00 | weekday_service | +| weekday_late_night | 00:00:00 | 5:00:00 | weekday_service | +| weekend | | | saturday_service | +| weekend | | | sunday_service | + +次に、 `fare_products.txt`内の対応する時間指定運賃が作成されます (例: Peak 運賃) + +[** fare_products.txt **](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name | amount | currency | +|-----------------|-----------------------------------------------|---------|----------| +|peak_fare | Peak fare | 5 | USD | +| normal_fare | Off-peak fare | 3 | USD | +| weekend_fare | Weekend Metrorail one-way fare | 2 | USD | +| late_night_fare |深夜均一運賃（月曜～金曜午後 9:30 以降）| 2 | USD | + +最後に、 `from_timeframe_group_id`および`to_timeframe_group_id`フィールドを使用して、 `fare_leg_rules.txt`で時間枠が運賃商品に関連付けられます。これらのフィールドは、運賃が区間の開始のみに適用されるか、区間の開始と終了の両方に適用されるかを決定します。 +この例では、WMATA 運賃に基づいて、運賃は区間の出発時間枠のみに依存するため、 `to_timeframe_group_id`は空白のままになっています。 + +[** fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) + +| network_id | fare_product_id | from_timeframe_group_id | to_timeframe_group_id | +|------------|-----------------|----------|-------------------------| +| 1 | weekend_fare | weekend | | +| 1 | late_night_fare | weekday_late_night | | +| 1 |peak_fare | weekday_peak | | +| 1 | normal_fare | weekday_offpeak | | `network_id`は外部ID `networks.network_id`または`routes.network_id`を参照し、各旅行の正しい運賃商品の選択は、 `stop_times.txt`の到着時間と出発時間と、`timeframes.txt` で定義された時間の組み合わせになることに注意してください。 + +この場合、午前 7:30 に出発する旅行の料金を支払うユーザーは 5.00 USD (ピーク料金) を支払う必要がありますが、午前 11:30 に出発する別のユーザーは 3.00 USD (オフピーク料金) のみを支払う必要があります。 + + +### 時間変動運賃とゾーンベース運賃を定義する + +ニューヨークの MTA メトロノース鉄道ネットワークでは、運賃は旅行の時間帯と、旅行の出発地と目的地の両方に基づいて変わります。次の例は、グランド セントラル駅からコールド スプリング (米国ニューヨーク州) への旅行に適用される運賃規則を示しています。 + +この例は、 ITO Worldによって作成されたデータセットに基づいており、6 つの異なるエリアに分散した 10 の停留所を使用する旅行を特徴としています。 + +[** stops.txt**](../../reference/#stopstxt) + +| stop_id | stop_name | stop_lat | stop_lon | +|---------|----------------------|------------|------------| +| ITO1669 | Peekskill | 41.285103 |-73.930916 | +| ITO1777 | Beacon | 41.505814 |-73.984474 | +| ITO1789 | New Hamburg | 41.58691 |-73.947624 | +| ITO1804 | クロトン-ハーモン | 41.190002 |-73.882393 | +| ITO1824 | コートランド | 41.246258 |-73.921783 | +| ITO1856 | ギャリソン | 41.381126 |-73.947334 | +| ITO1887 | ハーレム-125 番街 | 40.805256 |-73.939148 | +| ITO1897 | コールド スプリング | 41.415382 |-73.958092 | +| ITO2096 | ポキプシー | 41.707058 |-73.93792 | +| ITO2383 | グランドセントラル | 40.752823 |-73.977196 | + + +[** stop_areas.txt**](../../reference/#stop_areastxt) + +| area_id | stop_id | +|-----------|---------| +| mnr_1 | ITO1887 | +| mnr_1 | ITO2383 | +| mnr_HUD-5 | ITO1804 | +| mnr_HUD-6 | ITO1669 | +| mnr_HUD-6 | ITO1824 | +| mnr_HUD-7 | ITO1856 | +| mnr_HUD-7 | ITO1897 | +| mnr_HUD-8 | ITO1777 | +| mnr_HUD-8 | ITO1789 | +| mnr_HUD-9 | ITO2096 | + + +[** route_networks.txt**](../../reference/#route_networkstxt) + +| network_id | route_id | +|------------|----------| +| mnr_hudson | 669 | + + +[** networks.txt**](../../reference/#networkstxt) + +| network_id | network_name | +|------------|-----------------| +| mnr_hudson | MNR Hudson Line | + +列車サービス 3 および 13 の運行日は`calendar.txt`を使用して定義されます。特に、どの旅行にも関連付けられていない一般的な日 (つまり、平日、週末、および任意の日) を持つ他のレコードが定義されており、これらは `時間変動運賃` をモデル化するために時間枠に関連付けられます。 + +[** calendar.txt**](../../reference/#calendartxt) + +| service_id | monday | tuesday | wednesday | thursday | friday | saturday | sunday | start_date | end_date | +|------------|---------|----------|----------|----------|----------|----------|----------|----------|----------| +| 13 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 20230612 | 20231006 | +| 3 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 20230609 | 20231006 | +|平日 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 20220101 | 20240101 | +|週末 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 20220101 | 20240101 | +| anyday | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 20220101 | 20240101 | + + +レコードは `timeframes.txt` に作成されます。これには、時間が 24 時間の範囲の期間 (`anytime`、`weekdays`、および `weekends`) をカバーする場合、およびピーク期間とオフピーク期間が含まれます: + +* AM ピーク: 平日の午前 6 時から午前 10 時まで +* AM2PM ピーク: 平日の午前 6 時から午前 9 時まで、および午後 4 時から午後 8 時まで +* AM ピーク以外: AM ピークに含まれない平日の時間帯 +* AM2PM ピーク以外: AM2PM ピークに含まれない平日の時間帯 + +[** timeframes.txt**](../../reference/#timeframestxt) + +| timeframe_group_id | start_time | end_time | service_id | +|:------------------:|:----------:|:--------:|:---------:| +| いつでも | 00:00:00 | 24:00:00 | いつでも | +| 平日 | 00:00:00 | 24:00:00 | 平日 | +| 週末 | 00:00:00 | 24:00:00 | 週末 | +| mnr_ampeak | 06:00:00 | 10:00:00 | 平日 | +| mnr_notampeak | 00:00:00 | 06:00:00 |平日 | +| mnr_notampeak | 10:00:00 | 24:00:00 | 平日 | +| mnr_am2pmpeak | 06:00:00 | 09:00:00 | 平日 | +| mnr_am2pmpeak | 16:00:00 | 20:00:00 | 平日 | +| mnr_notam2pmpeak | 00:00:00 | 06:00:00 | 平日 | +| mnr_notam2pmpeak | 09:00:00 | 16:00:00 | 平日 | +| mnr_notam2pmpeak | 20:00:00 | 24:00:00 | weekdays | + + +各運賃商品は`fare_products.txt`で定義されています。Cold Spring はゾーン 7 にあるため、この例ではゾーン 1 と7.の間の旅行のみをリストしています。完全なデータセットには、時間とゾーンの組み合わせで定義された各価格のレコードが含まれます。また、この例では 1 つの運賃媒体 (`paper`) のみが表示されていますが、運賃媒体によって価格も異なる場合は、追加の組み合わせを作成できます。 + +[** fare_products.txt**](../../reference/#fare_productstxt) + +| fare_product_id | fare_product_name | fare_media_id | amount | currency | +|------------------------|------------------------------------|---------------|---------|---------| +| mnr_1:HUD-7_adult_peak | Outbound Adult Peak Zonal Fare | paper | 20.00 | USD | +| mnr_1:HUD-7_adult | 出発大人オフピークゾーン運賃 | paper | 15.00 | USD | +| mnr_HUD-7:1_adult_peak | 到着大人ピークゾーン運賃 | paper | 20.00 | USD | +| mnr_HUD-7:1_adult | 到着大人オフピークゾーン運賃 | paper | 15.00 | USD | + + +最後に、出発地と目的地のエリアの組み合わせとそれぞれの時間枠が、 `fare_leg_rules.txt`の対応する運賃商品に関連付けられます。ここで、ピーク時にゾーン 1 (つまり `area_id=mnr_1`) から出発または到着する旅行には、旅行の到着ゾーンと出発ゾーンに対応する特定のピーク料金 (つまり `fare_product_id=mnr_1:HUD-7_adult_peak`) が適用されます。 + +[** fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) + +| network_id | from_area_id | to_area_id | fare_product_id | from_timeframe_group_id | to_timeframe_group_id | +|------------|--------------|------------|-------------------------|-------------------------|------------------------| +| mnr_hudson | mnr_1 | mnr_HUD-7 | mnr_1:HUD-7_adult | mnr_notam2pmpeak | いつでも | +| mnr_hudson | mnr_1 | mnr_HUD-7 | mnr_1:HUD-7_adult | 週末 | いつでも | +| mnr_hudson | mnr_1 | mnr_HUD-7 | mnr_1:HUD-7_adult_peak | mnr_am2pmpeak | いつでも | +| mnr_hudson | mnr_HUD-7 | mnr_1 | mnr_HUD-7:1_adult | 平日 | mnr_notampeak | +| mnr_hudson | mnr_HUD-7 | mnr_1 | mnr_HUD-7:1_adult | 週末 | いつでも | +| mnr_hudson | mnr_HUD-7 | mnr_1 | mnr_HUD-7:1_adult_peak | 平日 | mnr_ampeak | + + +このデータセットを使用すると、グランド セントラル (ゾーン `mnr_1`) を午後 6:45 に出発する予定の列車#869 (`service_id=3`) に乗車するユーザーは、旅行が `mnr_am2pmpeak` 期間に開始され、`e` mnr_1` から始まるため、アウトバウンド大人ピーク ゾーン運賃 20.00 USD を支払う必要があります。 + +または、列車#883 (`service_id=13`) で旅行するユーザーは、この列車がグランド セントラル (ゾーン `mnr_1`) を午後 9:04 に出発する予定であるため、アウトバウンド大人オフピーク ゾーン運賃 15.00 USD のみを支払う必要があります。 + +Appleマップでは、乗客は運賃がどのように変化するかを確認し、列車の出発予定時刻の横にある運賃を比較できます。 + +
+ 出発大人ピークゾーン料金 20.00 USD + 出発大人オフピークゾーン料金 15.00 USD +
diff --git a/docs/ja/documentation/schedule/examples/feed-info.md b/docs/ja/documentation/schedule/examples/feed-info.md new file mode 100644 index 000000000..3da6542be --- /dev/null +++ b/docs/ja/documentation/schedule/examples/feed-info.md @@ -0,0 +1,21 @@ +# フィード情報 + +## GTFS データセットに関する情報を提供する + +機関とそのサービスに関する情報の提供に加えて、[feed_info.txt](../../reference/#feed_infotxt) ファイルを使用して GTFS データセットに関する情報を提供することもできます。これには以下が含まれます: + +- パブリッシャーの詳細 +- フィード言語 +- フィードの有効性 +- バージョン + +以下は、カイロ交通局からの例です: + +[** feed_info.txt**](../../reference/#feed_infotxt) + +``` +feed_publisher_name、feed_publisher_url、feed_lang、feed_start_date、feed_end_date、feed_version +カイロ交通局、http://transportforcairo.com/、en、20160101、20161201、0.5 +``` + + [サンプルソース](https://github.com/transportforcairo/Metro-GTFS/archive/master.zip#Metro-GTFS-master) \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/flex.md b/docs/ja/documentation/schedule/examples/flex.md new file mode 100644 index 000000000..50cd5b697 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/flex.md @@ -0,0 +1,343 @@ +# デマンド レスポンシブ サービス + +GTFS Flex は、2024 年 3 月に GTFS 仕様に正式に採用された GTFS 拡張プロジェクトであり、デマンド レスポンシブ交通 (DRT) サービスの検出を容易にすることを目的としています。 +デマンド レスポンシブ サービスには、世界の地域に基づいて異なる用語が存在することに注意してください。詳細については、[用語集](#glossary) を参照してください。 + +次の例は、Flex を使用してさまざまなデマンド レスポンシブ サービスのユース ケースをモデル化する方法を示しています。**次の例は、必ずしも機関のサービスを正確にまたは完全に表しているわけではないことに注意してください。** + +## 単一ゾーン内のオンデマンド サービス + +デマンド レスポンシブ サービスは特定のゾーン内で運用できるため、乗客はゾーン内の任意のポイント A で乗車を予約し、同じゾーン内の任意のポイント B で降車を予約できます。一例として、米国ミネソタ州の [Heartland Express Transit](https:) サービスが挙げられます。 + + [Heartland Express のサンプル データセットをダウンロード](../../../assets/on-demand_services_within_a_single_zone.zip) + +### 旅行の定義 + +Heartland Express のサービス時間は次のとおりです。 + +- 平日: + - 午前 8:00 ～ 午後 5:00- 午前 6:15 ～ 午後 5:45 (ニュー アルム ゾーンのみ) +- 日曜日: 午前 8:00 ～ 正午 (ニュー アルム ゾーンのみ) + +ニュー アルム市ゾーンはブラウン郡ゾーン内に含まれます。 ["ゾーン重複制約"](#zone-overlap-constraint) の問題を回避するために、Heartland Express は 4 つの旅行で定義できます。 + +- 平日の午前 6:15 から午前 8:00 までの New Ulm ゾーンでのサービス。 +- 平日の午前 8:00 から午後 5:00 までの郡全体のサービス。 +- 平日の午後 5:00 から午後 5:45 までの New Ulm ゾーンでのサービス。 +- 日曜日の午前 8:00 から午後 12:00 までの New Ulm ゾーンでのサービス。 + +[** trips.txt**](../../reference/#tripstxt) + + route_id | service_id | trip_id +--|--|-- +74362 | c_67295_b_77497_d_31 | t_5374945_b_77497_tn_0 +74362 | c_67295_b_77497_d_31 | t_5374946_b_77497_tn_0 +74362 | c_67295_b_77497_d_31 | t_5374944_b_77497_tn_0 +74362 | c_67295_b_77497_d_64 | t_5374947_b_77497_tn_0 + +`service_id = c_67295_b_77497_d_31` は平日を指し、`service_id = c_67295_b_77497_d_64` は日曜日を指します。 + +### ゾーンの定義 (GeoJSON ロケーション) + +[locations.geojson](../../reference/#locationsgeojson) を使用して Heartland Express サービスの運用ゾーンを定義する場合、Brown County と New Ulm City に個別のゾーンを定義する必要があります。以下は、ブラウン郡のゾーンを定義する簡略化された GeoJSON です: +```json +{ + "type": "FeatureCollection", + "機能": [ + { + "id": "area_708", + "type": "Feature", + "geometry": { + "type": "Polygon", + # 簡略化されており、ここでは 3 つの座標のみを示しています。 + "coordinates": [ + [ + [ + -94.7805702, + 44.4560958 + ], + [ + -94.7805608, + 44.4559928 + ], + [ + -94.7805218, + 44.4559649 + ] + ] + ] + }, + "properties": {} + } +] +``` + +### 予約ルールの定義 + +Heartland Express サービスすべてに適用される予約ルールは次のとおりです: + +- 乗車リクエストは、平日の午前 8 時から午後 3 時の間に行う必要があります。 +- 乗車は、乗車日の 1 営業日前までにリクエストする必要があります。 +- 乗車リクエストは、最大 14 日前まで行うことができます。 + +`booking_type = 2` を使用すると、サービスには前日までの予約が必要であることを示します。 `prior_notice_last_day = 1` および `prior_notice_start_day = 14` は、このサービスを 14 日前から前日まで予約できることを示します。 + +[** booking_rules.txt**](../../reference/#booking_rulestxt) + +booking_rule_id | booking_type | prior_notice_start_day | prior_notice_start_time | prior_notice_last_day | prior_notice_last_time | message | phone_number | info_url +--|--|--|--|--|--|--|--|--|-- +booking_route_74362 | 2 | 14 | 8:00:00 | 1 | 15:00:00 | Brown County Heartland Express は、オンデマンドのドアツードアの交通手段を提供します。乗車をリクエストするには、旅行の少なくとも 1 営業日前の午後 3 時までに 1-507-359-2717 または 1-800-707-2717 に電話してください。 | (507) 359-2717 | https://www.co.brown.mn.us/heartland-express-transit###停車時刻の定義 + +運行時間は、 `start_pickup_drop_off_window`フィールドと`end_pickup_drop_off_window`フィールドを使用して定義されます。同じゾーン内を移動するには、 stop_times.txtに同じ`location_id`つ` 2 つのレコードが必要です。 + +- `pickup_type = 2` および `drop_off_type = 1` の最初のレコードは、ゾーン内で予約のピックアップが許可されていることを示します。 +- `pickup_type = 1` および `drop_off_type = 2` の 2 番目のレコードは、ゾーン内で予約のドロップオフが許可されていることを示します。 + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | start_pickup_drop_off_window | end_pickup_drop_off_window | pickup_type | drop_off_type | pickup_booking_rule_id | drop_off_booking_rule_id +--|--|--|--|--|--|--|-- +t_5374944_b_77497_tn_0 | area_715 | 1 | 06:15:00 | 08:00:00 | 2 | 1 | booking_route_74362 | booking_route_74362 +t_5374944_b_77497_tn_0 | area_715 | 2 | 06:15:00 | 08:00:00 | 1 | 2 | booking_route_74362 | booking_route_74362 +t_5374945_b_77497_tn_0 | area_708 | 1 | 08:00:00 | 17:00:00 | 2 | 1 | booking_route_74362 | booking_route_74362 +t_5374945_b_77497_tn_0 | area_708 | 2 | 08:00:00 | 17:00:00 | 1 | 2 | booking_route_74362 | booking_route_74362 +t_5374946_b_77497_tn_0 | area_715 | 1 | 17:00:00 | 17:45:00 | 2 | 1 | booking_route_74362 | booking_route_74362 +t_5374946_b_77497_tn_0 | area_715 | 2 | 17:00:00 | 17:45:00 | 1 | 2 | booking_route_74362 | booking_route_74362 +t_5374947_b_77497_tn_0 | area_715 | 1 | 08:00:00 | 12:00:00 | 2 | 1 | booking_route_74362 | booking_route_74362 +t_5374947_b_77497_tn_0 | area_715 | 2 | 08:00:00 | 12:45:00 | 1 | 2 | booking_route_74362 | booking_route_74362 + +`area_715` はニュー アルム シティ ゾーンを指し、`area_708` はブラウン カウンティ ゾーンを指します。 + +## 複数のゾーンにまたがるオンデマンド サービス + +一部のデマンド対応サービスは複数の異なるゾーンにまたがって運営されており、乗客は 1 つのエリア内の任意の場所 A で乗車を予約し、別のエリア内の任意の場所で降車を予約できます。たとえば、[Minnesota River Valley Transit](https:) は、Saint Peter 市と Kasota 市の間でオンデマンド サービスを提供しています。 + + [River Valley Transit のサンプル データセットをダウンロード](../../../assets/on-demand_services_between_multiple_zones(r).zip) + +### 旅行の定義 + +前の例と同様に、サービス時間は日によって異なるため、平日と土曜日で旅行を個別に定義する必要があります。 + +[** trips.txt**](../../reference/#tripstxt) + + route_id | service_id | trip_id +--|--|-- +74375 | 平日 | t_5298036_b_77503_tn_0 +74375 | 土曜日 | t_5298041_b_77503_tn_0 + +(前の例と同じように、[booking_rules.txt](../../reference/#booking_rulestxt) と [locations.geojson](../../reference/#locationsgeojson) を使用して予約ルールとゾーンを定義します) + +###停車時刻を定義します + +次のデータは、乗車は 1 つのゾーンでのみ許可され、降車は別のゾーンでのみ許可されていることを示しています。同じゾーンでの乗車と降車は許可されません。 + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | start_pickup_drop_off_window | end_pickup_drop_off_window | pickup_type | drop_off_type | pickup_booking_rule_id | drop_off_booking_rule_id +--|--|--|--|--|--|--|--|-- +t_5298036_b_77503_tn_0 | area_713 | 1 | 06:30:00 | 20:00:00 | 2 | 1 | booking_route_74375 | booking_route_74375 +t_5298036_b_77503_tn_0 | area_714 | 2 | 06:30:00 | 20:00:00 | 1 | 2 | booking_route_74375 | booking_route_74375 +t_5298041_b_77503_tn_0 | area_713 | 1 | 09:00:00 | 19:00:00 | 2 | 1 | booking_route_74375 | booking_route_74375 +t_5298041_b_77503_tn_0 | area_714 | 2 | 09:00:00 | 19:00:00 | 1 | 2 | booking_route_74375 | booking_route_74375## 特定の場所で乗客の乗降が必要なオンデマンド サービス + +特定のデマンド対応サービスでは、乗客はゾーン内の任意の場所での乗降を指定できません。代わりに、乗客は特定の指定停留所 (集合場所/仮想停留所) での乗降のみを予約できます。一例として、ドイツのアンガーミュンデとガルツの [RufBus サービス](https:) が挙げられます。 + +### 旅行の定義 + +ルート 476 は、アンガーミュンデ地域の各停留所間でオンデマンド サービスを提供しています。2 つのサービス (平日用と週末用) を運行しており、それぞれに 1 つのtrip_idが関連付けられています。 + +[** trips.txt**](../../reference/#tripstxt) + + route_id | service_id | trip_id +--|--|-- +476 | on_demand_weekdays | 476_weekdays +476 | on_demand_weekends | 476_weekends### ロケーション グループを定義する + +乗客は各停留所間でサービスを予約できるため、 stop_times.txtですべての停留所間の組み合わせを定義しなくても済むように、 location_groups.txtとlocation_group_stops.txtを使用してこれらの停留所をロケーション グループとして定義するのが適切な方法です。 + +[** location_groups.txt**](../../reference/#location_groupstxt) + + location_group_id | location_group_name +--|-- +476_stops | RufBus 476 がエリア内を移動するときに使用します + +[** location_group_stops.txt**](../../reference/#location_group_stopstxt) + + location_group_id | stop_id +--|-- +476_stops | de:12073:900340004::1 +476_stops | de:12073:900340004::2 +476_stops | de:12073:900340004::3 +476_stops | de:12073:900340004::4 +476_stops | de:12073:900340100::1 +476_stops | de:12073:900340100::2 +476_stops |... + +### 予約ルールを定義する + +476 ルートのサービスでは、少なくとも 1 時間前までに予約する必要があります。`booking_type = 1` を使用すると、事前の通知により当日までの予約がサービスに必要になります。 `prior_notice_duration_min = 60` は、少なくとも 60 分前に予約する必要があることを意味します。 + +平日の予約と週末の予約には若干の違いがあるため、平日のサービスと休日のサービスに別々の予約ルールを定義できます。詳細は`message`フィールドに入力できます。情報と予約ページのリンクは`info_url`フィールドと`booking_url`フィールドに入力できます。 + +[** booking_rules.txt**](../../reference/#booking_rulestxt) + +booking_rule_id | booking_type | prior_notice_duration_min | message | phone_number | info_url | booking_url +--|--|--|--|--|--|--|-- +平日のバスの運行時間 | 1 | 60 | 登録してください。 60 分 vorher erforderlich、Anruf zwischen 08:00 と 24:00 möglich、オンラインでの注文 | +49 3332 442 755 | https://uvg-online.com/rufbus-angermuende/| https://uvg.tdimo.net/bapp/#/astBuchungenView +flächenrufbus_angermünde_weekends | 1 | 60 | 1€ Komfortzuschlag プロ人;アンメルドゥンの心。 60 分 vorher erforderlich、Anruf zwischen 08:00 と 24:00 möglich、オンラインでの注文 | +49 3332 442 755 | https://uvg-online.com/rufbus-angermuende/| https://uvg.tdimo.net/bapp/#/astBuchungenView###停車時刻の定義 + +476 ルートは、平日は午後 5 時 30 分から午後 10 時まで、週末は午前 8 時から午後 10 時まで運行しています。運行時間は、`start_pickup_drop_off_window`フィールドと`end_pickup_drop_off_window`フィールドを使用して定義されます。同じ場所グループ内を移動するには、 stop_times.txtに同じ`location_group_id`つ` 2 つのレコードが必要です。 + + - `pickup_type = 2 ` および `drop_off_type = 1` の最初のレコードは、場所グループで予約のピックアップが許可されていることを示します。 + - `pickup_type = 1` および `drop_off_type = 2 ` の 2 番目のレコードは、場所グループで予約のドロップオフが許可されていることを示します。 + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_group_id | stop_sequence | start_pickup_drop_off_window | end_pickup_drop_off_window | pickup_type | drop_off_type | pickup_booking_rule_id | drop_off_booking_rule_id +--|--|--|--|--|--|--|--|--|-- +476_weekdays | 476_stops | 1 | 17:30:00 | 22:00:00 | 2 | 1 | flächenrufbus_angermünde_weekdays | flächenrufbus_angermünde_weekdays +476_weekdays | 476_stops | 2 | 17:30:00 | 22:00:00 | 1 | 2 | flächenrufbus_angermünde_weekdays | flächenrufbus_angermünde_weekdays +476_weekends | 476_stops | 1 | 08:00:00 | 22:00:00 | 2 | 1 | flächenrufbus-angermünde_weekdays | flächenrufbus_angermünde_weekends +476_weekends | 476_stops | 2 | 08:00:00 | 22:00:00 | 1 | 2 | flächenrufbus-angermünde_weekdays | flächenrufbus-angermünde_weekends## ルート変更 + +`ルート変更`とは、車両が一定の停車順序で固定ルートをたどりますが、停車場所間で乗客を乗せたり降ろしたりするためにこのルートから変更できる柔軟性があるサービスを指します。通常、変更はサービスの定時性を維持するために制限されており、変更された乗車および降車には事前の予約が必要です。 + +この例では、ニューウルム市の [Hermann Express](https://www.newulmmn.gov/553/Hermann-Express-City-Bus-Service) サービスにより、ユーザーは固定の停留所でのみ乗車でき、これらの停留所間の特定の逸脱エリア内の任意の地点で降車できます。 + +**以下の例は簡略化されています。詳細については、[Hermann Express サンプル データセット](../../../assets/deviated _drop-off _route.zip)をダウンロードしてください。** + +### 旅行の定義 + +このタイプのサービスには、一連の固定の停留所と固定のスケジュールが含まれるため、旅行の定義は通常の固定ルートのバス サービスと同様です。関連するすべてのサービス期間を通じて各ルートで提供される旅行を定義する必要があります。 + +[** trips.txt**](../../reference/#tripstxt) + + route_id | service_id | trip_id | share_id +--|--|--|-- +74513 | c_67295_b_77497_d_31 | t_5374704_b_77497_tn_0 | p_1426044 +74513 | c_67295_b_77497_d_31 | t_5374699_b_77497_tn_0 | p_1426044 +74513 | c_67295_b_77497_d_31 | t_5374698_b_77497_tn_0 | p_1426044 +74513 | c_67295_b_77497_d_31 | t_5374697_b_77497_tn_0 | p_1426044 +...|...|...|... + +### ゾーンの定義 (GeoJSON ロケーション) + +[locations.geojson](../../reference/#locationsgeojson) を使用して、ルートを逸脱するゾーンを定義します。通常、逸脱はサービスをスケジュールどおりに維持するために制限されます。したがって、車両が移動すると、各固定停留所間の逸脱エリアがそれに応じて変化する可能性があります。ルート逸脱のエリアは、次の画像のようになります: + +
+ 迂回ルートゾーン +
+ +###停車時刻を定義する + +固定の停車地の場合、通常のバス路線と同様の方法で、 `arrival_time`、 `departure_time`、 `stop_id`などのフィールドを定義します。固定の停車地間で、逸脱が許可されるゾーンを定義します。`pickup_type = 1` および `drop_off_type = 3` は、逸脱した乗車が許可されていないこと (乗車を固定の停車地のみに制限) を示し、逸脱ゾーンで降ろすには乗客が運転手と調整する必要があります。 + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | arrive_time | department_id | stop_id | location_id | stop_sequence | start_pickup_drop_off_window | end_pickup_drop_off_window | pickup_type | drop_off_type | shape_dist_traveled | pickup_booking_rule_id | drop_off_booking_rule_id +--|--|--|--|--|--|--|--|--|--|--|--|-- +t_5374696_b_77497_tn_0 | 08:00:00 | 08:00:00 | 4149546 | | 1 | | | | | 0 | | +t_5374696_b_77497_tn_0 | | | | radius_300_s_4149546_s_4149547 | 2 | 08:00:00 | 8:02:22 | 1 | 3 | | booking_route_74513 | booking_route_74513 +t_5374696_b_77497_tn_0 | 08:02:22 | 08:02:22 | 4149547 | | 3 | | | | | 1221.627114 | | +t_5374696_b_77497_tn_0 | | | | radius_300_s_4149546_s_4149548 | 4 | 08:02:22 | 8:03:00 | 1 | 3 | | booking_route_74513 | booking_route_74513 +t_5374696_b_77497_tn_0 | 08:03:22 | 08:03:22 | 4149548 | | 5 | | | | | 1548.216356 | | +t_5374696_b_77497_tn_0 | | | | radius_300_s_4149546_s_4149549 | 6 | 08:03:22 | 8:05:00 | 1 | 3 | | booking_route_74513 | booking_route_74513 +...|...|...|...|...|...|...|...|...|...|...|...|... +t_5374696_b_77497_tn_0 | 08:50:00 | 08:50:00 | 4210601 | | 35 | | | | | 23429.19558 | | +t_5374696_b_77497_tn_0 | 08:56:00 | 08:56:00 | 4149564 | | 36 | | | | | 25320.8471 | | + +## ルーティング動作 + +### ピックアップ/ドロップオフ ウィンドウによる中間停車時刻レコードの無視 + +出発地と目的地の間のルーティングまたは移動時間を提供する場合、データ コンシューマーは、 `start_pickup_drop_off_window`および`end_pickup_drop_off_window`が定義されている中間stop_times.txtレコードを無視する必要があります。例: + + trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window +--|--|--|--|--|--|-- +tripA | Zone1 | 1 | 2 | 1 | 08:00:00 | 18:00:00 +tripA | Zone2 | 2 | 1 | 2 | 08:00:00 | 14:00:00 +tripA | Zone3 | 3 | 1 | 2 | 10:00:00 | 18:00:00 + +Zone1 から Zone3 への旅行のルートや移動時間を指定する場合、消費者は Zone2 を考慮に入れるべきではありません。 + +### ゾーン重複制約 + +同じ`trip_id`つ` 2 つ以上のstop_times.txtレコード間で、 locations.geojson `id`ジオメトリ、 `start/end_pickup_drop_off_window`時間、および`pickup_type`または`drop_off_type`が同時に重複することは禁止されています。 + +例: +(`northportland` は `portland` 内のゾーンを指します) + +**禁止** + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window +--|--|--|--|--|--|-- +tripA | portland | 1 | 2 | 1 | 08:00:00 | 12:00:00 +tripA | northportland | 2 | 2 | 1 | 10:00:00 | 14:00:00 +tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00 + +**許可** + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window +--|--|--|--|--|--|-- +tripA | ポートランド | 1 | 2 | 1 | 08:00:00 | 12:00:00 +tripA | ノースポートランド | 2 | 2 | 1 | 12:00:00 | 14:00:00 +tripA | バンクーバー | 3 | 1 | 2 | 10:00:00 | 14:00:00 + +または + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window +--|--|--|--|--|--|--|-- +tripA | ポートランド | 1 | 2 | 1 | 08:00:00 | 12:00:00 +tripA | northportland | 2 | 1 | 2 | 10:00:00 | 14:00:00 +tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00 + +または + +[** stop_times.txt**](../../reference/#stop_timestxt) + + trip_id | location_id | stop_sequence | pickup_type | drop_off_type | start_pickup_drop_off_window | end_pickup_drop_off_window +--|--|--|--|--|--|-- +tripA | portland | 1 | 2 | 1 | 08:00:00 | 12:00:00 +tripA | gresham | 2 | 2 | 1 | 10:00:00 | 14:00:00 +tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00## 用語集 + +📲 Dial-a-ride は、ヨーロッパ全土で使用されている複数の用語のバリエーションです。 + +🇨🇭 スイスでは、Rufbus/On-call bus という用語に該当します。[PostAuto による PubliCar システム](https://www.postauto.ch/en/timetable-and-network/publicar) も利用できます。この提案では、PubliCar アプリとサービスは、ユーザーが好む旅行プランナー アプリで見つけられるようになります。 + +🇦🇹 オーストリアでは、ダイヤル・ア・ライドは Rufbus とも呼ばれ、Bedarfsverkehr (Demand Responsive Transport) と Mikro-ÖV (Microtransit) のより大きな傘下にあります。 + +- [bedarfsverkehr.at](https://www.bedarfsverkehr.at/) +- [Wiener Linien](https://www.wienerlinien.at/documents/843721/4770179/Anleitung_Rufbus_359531.pdf/df430b95-9dd4-0d13-ffdf-bdace15932a8?t=1614165175643) +- Rufbus (英語: dial-a-bus、以前は Anruf-Sammel-Taxi または ASTAX call-collect-taxi) +-現在の GTFS 実装 [年間サービスアラートとして](https://www.google.com/maps/dir/S%C3%BC%C3%9Fenbrunner+Pl.,+1220+Wien,+Austria/2201+Gerasdorf,+Austria/@48.2867283,16.4429959,13z/am=t/data=!4m15!4m14!1m5!1m1!1s0x47 6d0393b15bc6d9:0x517f69839511fb31!2m2!1d16.4958186!2d48.2772635!1m5!1m1!1s0x476d0488292e6f61:0xeee80d3d2bb6b1f5!2m2!1d16.4690073!2d48.2962096!3e3!5i1?エントリ=ttu ) + +🇩🇰 デンマークでは、NT/midttrafik/sydtrafik/FYNBUS/movia (https://flextur.dk/) + +- flextur (英語: flex trip) +- 以前は flextrafik (英語: flex transit) + +🇫🇷 ⚠️ フランスでは、パラトランジット サービスに対して TDA (Transport à la Demande) および PMR (Personnes à Mobilité Réduite) という用語が使用されます + +- [Reseau Mistral](https://www.reseaumistral.com/services/service-appel-bus) +- Appel bus (英語: call bus) + +🇩🇪 ドイツでは、On-Demand-Angebot、Flexible Fahrt、AST- [BVG](https://www.bvg.de/de/verbindungen/bvg-muva/flexible-fahrt) +- ブランド：Muva- On-Demand-Angebot（英語：on-demand-service） +- Flexible Fahrt（英語：flexible trip） +- その他の地域 +- Anruf-sammel-taxi または AST（英語：call-collect-taxi） + +🇬🇧 英国には、次のサービスがあります： + +- [go2 Sevenoaks](https:) +- オンデマンド サービス + +用語は国境によって異なりますが、一般的に、ダイヤル ア ライドは、乗客からオペレーターへの何らかの連絡を必要とする、需要に応じたサービスであると想定できます。 +
diff --git a/docs/ja/documentation/schedule/examples/frequencies.md b/docs/ja/documentation/schedule/examples/frequencies.md new file mode 100644 index 000000000..327a6b790 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/frequencies.md @@ -0,0 +1,19 @@ +#頻度 + +## 頻度ベースのサービスを説明する + +モントリオール交通局はモントリオールで交通サービスを運営しており、地下鉄路線で頻度ベースのサービスを提供しています。そのため、GTFS データセットで到着時間と出発時間を含むスケジュールを提供する代わりに、ファイル [frequencies.txt](../../reference/#frequenciestxt) を使用して、サービス期間全体にわたるサービス頻度を説明します。旅行の繰り返しは、停留所間のタイミングがすべての停留所で一貫している場合にのみ機能します。頻度ベースのサービスをモデル化する場合、 stop_times.txt (@TODO リンク) には、乗客に表示される時間を決定するために停留所間の相対時間が含まれます。 + +[** frequencies.txt**](../../reference/#frequenciestxt) + +``` + trip_id、start_time、end_time、headway_secs +22M-GLOBAUX-00-S_1_2、16:01:25、16:19:25、180 +22M-GLOBAUX-00-S_1_2、16:19:25、17:03:25、165 +``` + +上記では、`trip_id=22M-GLOBAUX-00-S_1_2` のグリーンラインの旅行が例として使用されています。この旅行では、最初のレコードは午後 4:01:25 から午後 4:19:25 までの間、列車が 180 秒 (または 3 分) ごとに運行していることを示しています。同様に、2 番目のレコードは、午後 4 時 19 分 25 秒から午後 5 時 3 分 25 秒までの間、列車が 165 秒間隔で運行していることを示しています。 + + + + [サンプル ソース](https://www.stm.info/en/about/developers) \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/pathways.md b/docs/ja/documentation/schedule/examples/pathways.md new file mode 100644 index 000000000..7704ea480 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/pathways.md @@ -0,0 +1,137 @@ +#構内通路と物理的なアクセシビリティ + +##アクセシビリティ情報を表示する理由 + +**人口の大部分に影響:** 世界保健機関は、[世界中の人々の 16% が障害を抱えている](https://www.who.int/news-room/fact-sheets/detail/disability-and-health)と推定しており、障害のある人は`障害のない人よりも、アクセスできない、または手頃な価格ではない交通機関を利用するのが 15 倍困難`です。また、障害のある人は、[新しい健康状態になる割合が高い](https://www.who.int/publications/i/item/9789240063600)ですが、これは医療やサービスへのアクセスが限られていることが一因です。 + +**障害者にとって重要:** 乗客は、交通機関の選択肢に関する最新かつ正確な情報を必要としています。多くの機関は、乗客が旅行を計画し、選択肢を理解する上で重要なルート、スケジュール、停留所の場所情報を表すために、 General Transit Feed Specification (GTFS) をすでに使用しています。アクセシビリティを必要とする乗客にとって、停車地や車両のアクセシビリティを知ることは、場所を知ることと同じくらい重要です。これらの乗客は、どこかで立ち往生したり、最終停車地に到着できないことに気付いたときに手遅れになったりしないように、旅行のあらゆる部分について知っておく必要があります。 + +**法律で定められている場合もあります:** 場所によっては、地方または国の法律で、障害のある人に平等なアクセスと機会を提供することが義務付けられている場合があります。検討したい情報源は次のとおりです。 + +* **米国:** [アメリカ障害者法 (ADA)](https://www.ada.gov/topics/intro-to-ada/#public-transit) および 1973 年リハビリテーション法の [第 504 条](https://www.dol.gov/agencies/oasam/centers-offices/civil-rights-center/statutes/section-504-rehabilitation-act-of-1973) +* **日本:** 国土交通省の高齢者、障害者等の移動の容易さ、およびアクセシビリティの促進に関する法律 (“[バリアフリー法](https://www.mlit.go.jp/sogoseisaku/barrierfree/index.html)”) +* **欧州連合:** [雇用、社会問題、インクルージョン](https://ec.europa.eu/social/main.jsp?catId=1485&langId=en) + +##アクセシビリティチェックリスト + +データにアクセシビリティ情報を追加するために必要な手順は次のとおりです。次のセクションでは、各手順について詳しく説明します。 + +* ステップ 1: `stops.txt`に車椅子のアクセシビリティ情報を追加する +* ステップ 2: `trips.txt`に車椅子のアクセシビリティ情報を追加する +* ステップ 3: `stops.txt`に音声ナビゲーション情報を追加する +* ステップ 4: GTFS 構内通路を使用して交通機関の駅に関する物理的なアクセシビリティ情報を追加する + +## GTFS に車椅子のアクセシビリティを追加する + +GTFS の構造が一連の.txtファイルであることは、すでにご存知かもしれません。車椅子でのアクセス可能性は、 `stops.txt`の`wheelchair_boarding`と`trips.txt`の`wheelchair_accessible`の` 2 つのフィールドを更新することで表示できます。 + +** stops.txtの車椅子でのアクセス可能性** `stops.txt`の`wheelchair_boarding`フィールドを使用すると、指定した場所から車椅子での乗車が可能かどうかを示すことができます。 + +[参照: stops.txt](../../reference/#stopstxt) + +このフィールドが空の場合、アクセス可能性に関する情報は表示されません。これにより、乗客はアクセス可能性について確信が持てず、車椅子での乗車が実際に不可能なのか、それとも情報が欠落しているだけなのかを判断できなくなります。車椅子での乗車が利用できない場合でも、その情報を記入して乗客に明確にし、正確な情報で旅行を計画できるようにすることが最善です。 + +** trips.txtでの車椅子でのアクセシビリティ** `trips.txt`の`wheelchair_accessible`フィールドを使用すると、特定の旅行に使用される車両が車椅子に対応しているかどうかを示すことができます。 + +[参照: trips.txt](../../reference/#tripstxt) `wheelchair_boarding`と同様に、このフィールドが空のままの場合、アクセシビリティ情報は表示されません。車両が車椅子で利用できない場合でも、その情報を記入して乗客に明確にし、正確な情報で旅行を計画できるようにすることが最善です。 + +## 音声ナビゲーション補助の追加 + +テキスト読み上げは、GTFS のアクセシビリティを向上させるもう 1 つの方法です。正確なテキスト読み上げ情報により、支援技術を使用してテキストを読み上げる乗客が正しい情報を得ることができます。この情報は、 `stops.txt`の`tts_stop_name` を各`stop_name`に対応するように更新することで、GTFS に含めることができます。GTFS 内の各停留所には、停留所を音声で綴り、正しく発音できるようにするためのテキスト読み上げの曖昧さ回避が必要です。 + +[例:テキスト読み上げ](../../examples/text-to-speech) `tts_stop_name`は現在、GTFS 仕様内で正式に採用されている唯一のテキスト読み上げフィールドですが、他のフィールドについても議論されており、追加される可能性があります。これらには、`tts_agency_name`、`tts_route_short_name`、`tts_route_long_name`、`tts_trip_headsign`、`tts_trip_short_name`、および `tts_stop_headsign` が含まれます。 + +乗客は、この情報を活用するために、テキスト読み上げ機能をサポートするアプリを使用する必要があります。[NaviLensGo](https:) などの一部のアプリは、視覚障害のある乗客が駅をナビゲートして適切な車両を見つけるのを支援するために特別に設計されています。 + +## 駅に関する物理的なアクセシビリティ情報の追加 + + GTFS-Pathwaysは、交通機関の駅の詳細を表す GTFS のコンポーネントです。これにより、乗客は交通機関の駅で必要な乗り換えができるかどうかを把握できます。 + + GTFS-Pathwaysは、 `pathways.txt`および`levels.txt`ファイルを追加するとともに、 `stops.txt`に`location_type`フィールドを追加して、 `pathways.txt`に記述されている情報をリンクします。 + + + +### 駅の出入口の位置を記述する + +GTFS を使用すると、出入口と駅内部の情報を使用して駅を正確に記述できます。この例では、バンクーバーのダウンタウンにあるウォーターフロント駅の一部について説明します。この駅は市内のスカイトレイン ネットワークの一部であり、カナダ ライン、エクスポ ライン、シーバス、ウェスト コースト エクスプレスが運行しています。乗客は地上階の 3 つの出入口から駅に出入りできます。駅の残りの部分は地下にあり、運賃確認用のコンコース レベルとプラットフォームのある下層階があります。 + +まず、駅の位置と入口は [stops.txt](../../reference/#stopstxt) で定義されています: + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id、stop_name、stop_lat、stop_lon、location_type、parent_station、wheelchair_boarding +12034、ウォーターフロント駅、49.285687、-123.111773、1、、 +90、ウォーターフロント駅の階段入口 (Granville 側)、49.285054、-123.114375、2、12034、2 +91、ウォーターフロント駅のエスカレーター入口 (Granville 側)、49.285061、-123.114395、2、12034、2 +92、ウォーターフロント駅Granville のエレベーター入口、49.285257、-123.114163、2、12034、1 +93、Cordova のウォーターフロント駅入口、49.285607、-123.111993、2、12034、1 +94、Howe のウォーターフロント駅入口、49.286898、-123.113367、2、12034、2 +``` + +上記のファイルでは、最初のレコードは駅の場所に関するものであるため、 `location_type`は`1`に設定されています。他の 5 つは、3 つの駅入口に関するものです (Granville 入口には、階段、エスカレーター、エレベーターの 3 つの入口があるため、5 つのレコードが必要です)。これらの 5 つのレコードは、 `location_type`が `2` に設定されているため、入口として定義されています。 + +さらに、ウォーターフロント駅の`stop_id`は、入口を駅に関連付けるために、入口の`parent_station`の下にリストされています。アクセス可能な入口の`wheelchair_boarding`は`1`に設定され、アクセス不可能な入口は `2` に設定されています。 + +### 階段とエスカレーターについて説明します + +グランビル ストリートのウォーターフロント駅の入口にはエレベーター、エスカレーター、階段があり、入口は上記の [stops.txt](../../reference/#stopstxt) のノードとして定義されています。入口を駅の内部セクションに接続するには、[stops.txt](../../reference/#stopstxt) のウォーターフロント駅の`parent_station`の下に追加のノードを作成する必要があります。以下の [stops.txt](../../reference/#stopstxt) ファイルでは、階段とエスカレーターの下部に対応する汎用ノード (`e` 3`) が定義されています。 + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id、stop_name、stop_lat、stop_lon、location_type、parent_station、wheelchair_boarding +... +95、Waterfront Station Granville Stair Landing、49.285169、-123.114198、3、12034、 +96、Waterfront Station Granville Escalator Landing、49.285183、-123.114222、3、12034、 +``` + + + +次に、ファイル [pathways.txt](../../reference/#pathwaystxt) を使用してノードをリンクし、経路を作成します。最初のレコードは、階段の上部と下部に関連するノードをリンクします。`pathway_mode` は階段を示すために`pathway_mode` 2` に設定され、最後のフィールドは、乗客が階段で両方向 (上りと下り) に移動できることを記述します。 + +同様に、2 番目のレコードはエスカレーターを記述します (`pathway_mode`は `4` に設定)。エスカレーターは一方向にしか移動できないため、フィールド`is_bidirectional`は `0` に設定され、したがってエスカレーターはノード `96` から `91` (上方向) への一方向に移動します。 + +[** pathways.txt**](../../reference/#pathwaystxt) + +``` +pathway_id,from_stop_id,to_stop_id_pathway_mode,is_bidirectional +stairsA,90,95,2,1 +escalatorA,96,91,4,0​​ +``` + +### エレベーターと経路を記述する + +Granville street のエレベーターは、エスカレーターと階段が終了するコンコース レベルの経路に乗客を運びます。地上レベルのエレベーターは、上記の駅の入口 (`stop_id` `92`) として既に定義されています。したがって、コンコース レベルのエレベーターのドアも定義する必要があります。 + +また、下図に示すように、グランビル ストリートの階段、エスカレーター、エレベーターの下部とメイン駅舎を結ぶ地下通路があります。そのため、通路セクションを定義するために 2 つの追加ノードが作成されます。 + + + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id、stop_name、stop_lat、stop_lon、location_type、parent_station、wheelchair_boarding +… +97、地下通路の曲がり角、49.286253、-123.112660、3、12034、 +98、地下通路の終点、49.286106、-123.112428、3、12034、 +99、エレベーター通路、49.285257、-123.114163、3、12034、 +``` + + + +最後に、以下のファイル [pathways.txt](../../reference/#pathwaystxt) に示すように、ノードが接続されて地下通路が定義されます。 + +[** pathways.txt**](../../reference/#pathwaystxt) + +``` +pathway_id,from_stop_id,to_stop_id_pathway_mode,is_bidirectional +underground_walkway1,99,96,1,1 +underground_walkway2,96,95,1,1 +underground_walkway3,95,97,1,1 +underground_walkway4,97,98,1,1 +``` + +## GTFS-Pathwaysへの将来の追加 + +GTFS GTFS-Pathwaysのコア仕様は GTFS に完全に統合されていますが、追加のアクセシビリティ情報をモデル化して乗客に役立つ可能性があると認識されています。これには、音声合成による指示、車椅子の支援情報、機器の故障報告、計画または予定されている入口または出口の閉鎖、エレベーターとエスカレーターの停止などの情報が含まれます。残りの部分の詳細については、[このドキュメント](http://bit.ly/gtfs-pathways)を参照してください。 \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/routes-stops-trips.md b/docs/ja/documentation/schedule/examples/routes-stops-trips.md new file mode 100644 index 000000000..828aed2fa --- /dev/null +++ b/docs/ja/documentation/schedule/examples/routes-stops-trips.md @@ -0,0 +1,139 @@ +#ルート・路線系統、停留所、および旅行 + +##ルート・路線系統 + +ルート・路線系統は、交通ネットワークの地理的範囲を記述するため、固定ルートの交通運営の中核となります。GTFS では、ルートの定義が交通機関の運営を記述する最初のステップです。 + +最初のステップは、以下のファイル [agency.txt](../../reference/#agencytxt) に示すように、機関の情報を追加することです。このファイルには、機関に関する概要情報が含まれています。 + +[** agency.txt**](../../reference/#agencytxt) + +``` +agency_id、agency_name、agency_url、agency_timezone、agency_lang、agency_phone +CT、Calgary Transit、http://www.calgarytransit.com、America/Edmonton、、403-262-1000 +``` + +Calgary Transit は、アルバータ州カルガリーで LRT、BRT、定期バス サービス、準交通機関、オンデマンド交通を運営しています。この例では、2 つのルートが定義されており、1 つ目はバス、2 つ目は LRT です。ファイル [routes.txt](../../reference/#routestxt) を使用して、各ルートに一意のIDと、人間が読みやすいように短い名前と長い名前が割り当てられます。 + +[** routes.txt**](../../reference/#routestxt) + +``` +agency_id、 route_id、route_short_name、route_long_name、route_type、route_url、route_color、route_text_color +CT、303-20670、303、MAX Orange Brentwood/Saddletowne、3、www.calgarytransit.com/content/transit/en/home/rider-information/max.html、#ff8000、#ffffff +CT、202-20666、202、Blue Line- Saddletowne/69 Street CTrain、0、www.calgarytransit.com/content/transit/en/home/rider-information/lrt-and-bus-station-maps.html、#ff0000、#ffffff +``` + +5 番目のフィールド (`route_type`) は、ルートの種類を区別するために使用されます。 + +- 1 番目はバスなので、`route_type=3` です。 +- 2 番目は LRT なので、`route_type=0` です。 +- `route_type`の値の完全なリストは、[こちら](../../reference/#routestxt) にあります。 + +残りのフィールドには、ルートに固有の URL や、地図上でサービスを表す機関固有の色などの追加情報が含まれます。 + +
+ +##停留所等 + +GTFS では、停留所と駅はファイル [stops.txt](../../reference/#stopstxt) を使用して記述されます。以下では、バス停は最初のレコードで定義され、LRT 駅は 2 番目のレコードで定義されます。 + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id、stop_code、stop_name、stop_lat、stop_lon、location_type +8157、8157、44th Avenue NE (SB)、51.091106、-113.958565、0 +6810、6810、NB Marlborough CTrain Station、51.058990、-113.981582、1 +``` + +- `stop_id`は一意の識別子です`stop_code`と`stop_name`には通常、乗客向けの情報が含まれます +- 正確な場所は座標 (`stop_lat`と`stop_lon`) を使用して提供されます +- 6 番目のフィールド (`location_type`) は、停留所と駅を区別するために使用されます +- 最初のレコードはバス停に対応しているため、 `location_type=0` +- 2 番目のレコードは駅に対応するため、 `location_type=1`となります。 +- `e` の値の完全なリストは [こちら](../../reference/#stopstxt) にあります。 + +
+ +##便 + +機関のルートを記述した後、各ルートで提供される旅行を記述できるようになります。 + +まず、[calendar.txt](../../reference/#calendartxt) を使用してサービスの範囲を定義する必要があります。 + +[** calendar.txt**](../../reference/#calendartxt) + +``` + service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date +weekend_service,0,0,0,0,0,1,1,20220623,20220903 +``` + +ここでは、土曜日と日曜日のみに実行されるサービスが記述されているため、それらの曜日のフィールドには 1 が設定され、残りの曜日のフィールドには 0 が設定されます。このサービスは、 `start_date`フィールドと`end_date`フィールドに示されているように、2022 年 6 月 23 日から 2022 年 9 月 3 日まで実行されます。 + +この例では、ファイル [trips.txt](../../reference/#tripstxt) に、上で説明した MAX Orange ルートで運行される 3 つの週末旅行が記述されています。 + +[** trips.txt**](../../reference/#tripstxt) + +``` + route_id、 service_id、 trip_id 、 trip_headsign、direction_id、shape_id +303-20670、weekend_service、60270564、,"MAX ORANGE SADDLETOWNE",0、3030026 +303-20670、weekend_service、60270565、,"MAX ORANGE BRENTWOOD",1、3030027 +303-20670、weekend_service、60270566、,"MAX ORANGE BRENTWOOD",1,3030027 +``` + +- MAX Orange に対応する [routes.txt](../../reference/#routestxt) の`route_id` がリストされます +- 週末に対応する [calendar.txt](../../reference/#calendartxt) の`service_id`がリストされます +- 各レコードには、各旅行の一意のIDが含まれます。 +バスの車掌テキストが提供されます。これは通常、バスの車内外の標識に表示されます +- フィールド`direction_id`すると、同じルートの異なる方向への旅行を区別できます。たとえば、インバウンド旅行とアウトバウンド旅行、または南行き旅行と北行き旅行を区別できます。 + - この場合、Saddletowne への旅行には `direction_id=0` があり、Brentwood への旅行には `direction_id=1` があります。 direction_id の値には固有の意味はなく、移動の方向を別の方向に割り当てるためにのみ使用されます +- [shapes.txt](../../reference/#shapestxt) の`shape_id`は、サドルタウンに向かう MAX Orange ルートに対応しており、最初のレコードにはリストされています。また、2 番目と 3 番目のレコードには、ブレントウッドに向かう MAX Orange ルートに対応しています + + +`shape_id=3030026` は、サドルタウンに向かう MAX Orange に対応しています。以下のファイルには、旅行のアウトラインを示すポイントに関する情報と、各ポイントと旅行の開始点の間の距離が含まれています。この情報を使用して、旅行計画や分析の目的で、地図上にルートをプロットすることができます。 + +[** shapes.txt **](../../reference/#shapestxt) + +``` +shape_id、shape_pt_lat、shape_pt_lon、shape_pt_sequence、shape_dist_traveled +3030026、51.086506、-114.132259、10001、0.000 +3030026、51.086558、-114.132371、10002、 0.010 +3030026,51.086781,-114.132865,10003,0.052 +3030026,51.086938,-114.133179,10004,0.080 +3030026,51.086953,-114.133205,1 0005,0.083 +3030026,51.086968,-114.133 224,10006,0.085 +3030026,51.086992,-114.133249,10007,0.088 +3030026,51.087029,-114.133275,10008,0.093 +3030026,51.087057,-11 4.133286,10009,0.096 +3030026,51.0872 78、-114.133356、10010、0.121 +3030026、51.087036、-114.132864、10011、0.165 +3030026、51.086990、-114.132766、10012、0.173 +3030026、51 .086937,-114.132663,10013,0.183 +``` + +
+ +## サービスの例外 + +追加のサービス日 (特別日) や削除されたサービス日 (休日のサービスなしなど) などのサービスの例外を定義できます。 + +たとえば、2022 年 7 月 17 日 (日曜日) にスケジュールされたサービスがない場合は、サービスを 2 つに分割して、[calendar.txt](../../reference/#calendartxt) の `weekend_service` からそのdateを削除できます。 + +| サービス | 開始 | 終了 | +|-----|-----|-----| +| `weekend_service1` | `20220623` | `20220716` | +| `weekend_service2` | `20220718` | `20220903` | + +ただし、 `service_id`が` 2 つに分割され、この分割が [trips.txt](../../reference/#tripstxt) にカスケードされるため、ファイルが複雑になります。代わりに、以下に示すように [calendar_dates.txt](../../reference/#calendar_datestxt) を使用して、これをより簡単な方法で行うことができます。 + +[** calendar_dates.txt**](../../reference/#calendar_datestxt) + +``` + service_id、 date、exception_type +weekend_service、20220717、2 +``` + +- `service_id` `weekend_service` がリストされます +- 削除または追加されたサービスのdateが `date` の下にリストされます (2022 年 7 月 17 日) +- フィールド`exception_type`は` 2 に設定されています。これは、この日にサービスが削除されたことを意味します + + [サンプルソース](https:) \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/text-to-speech.md b/docs/ja/documentation/schedule/examples/text-to-speech.md new file mode 100644 index 000000000..9ba1082ae --- /dev/null +++ b/docs/ja/documentation/schedule/examples/text-to-speech.md @@ -0,0 +1,48 @@ +# テキスト読み上げ + +## 略語、珍しい発音、大きな数字、序数 + +略語、珍しい発音、大きな数字は、GTFS テキスト フィールドでよく使用されます。以下の TriMEt の例では、テキスト読み上げフィールドの使用方法がわかります。 + +- 略語は完全に綴ります。たとえば、`SW`は`southwest`、`Ave`は`avenue`になります。 +- 発音は、ソフトウェアが正しく読み取れるように綴ります。たとえば、`Orenco`は`orrainkoe​​`になります。 “Merlo” は “murlo” になります。 +- 大きな数字は発音どおりに表記されます: “3300” は “thirty-three hundred” になります。 +そうしないと、ソフトウェアは “3300” を “three thousand three hundred” と読み取ります。 +- 1st、2nd、3rd などの序数は表記する必要があります: たとえば “1st” は “first” になります。 + +[** stops.txt**](../../reference/#stopstxt) + +| stop_id | stop_name | tts_stop_name | +|----|----|----| +| 9163 | SW 125th & Longhorn | southwest one century five & longhorn | +| 9836 | Orenco MAX Station | orrainkoe​​ max station | +| 9828 | Merlo Rd/SW 158th Ave MAX Station | murlo road southwest one hundred fifty eighth avenue max station | +| 10074 | 3300 Block NW 35th | third-three-hundred block northwest third five | + +## 頭字語 + +頭字語を文字で表す場合は、文字の後にピリオドを付けるか、スペースで区切ります。これにより、頭字語は単語としてではなく、文字ごとに読む必要があることが明確になります。 + +タンパの案内標識`h` to UATC`には、個々の文字で発音される頭字語が含まれています。テキスト読み上げによる曖昧さ回避は次のようになります。 + +[** trips.txt**](../../reference/#tripstxt) + +| trip_headsign | tts_trip_headsign | +|----|----| +| North to UATC | north to uatc | + +または + +| trip_headsign | tts_trip_headsign | +|----|----| +| North to UATC | north to uatc | + +逆に、一部の頭字語は単語として読み上げられる必要があります: 例: NATO; NASA。音声合成フィールドはこれを反映する必要があります。 + +!!! 注 + + フィールド `trips.tts_trip_headsign` は、まだ仕様で公式ではありません。 + +## 複数の意味を持つ略語の明確化 + +`St`の略語には複数の意味があります: `street`、`saint`、`station`、および`first`を意味する`1st`です。音声合成フィールドは、正しい単語をスペルアウトし、TTS ソフトウェアで判読可能な方法で行うことで、これらの二重の意味に対処できます。 \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/transfers.md b/docs/ja/documentation/schedule/examples/transfers.md new file mode 100644 index 000000000..0d8a93d57 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/transfers.md @@ -0,0 +1,43 @@ +#乗り換え + +## ブロック乗り換え + +ブロック乗り換えは、座席内乗り換えとも呼ばれ、一連の旅行が次の条件を満たす場合に利用できます。 + + 1.旅行が連続している。 + 2.両方の旅行を同じ車両が運行している。 + 3.旅行は、交通フィード内の [trips.txt](../../reference/#tripstxt) ファイルで同じ`block_id`値を使用してプロビジョニングされている。 + +### ブロック乗り換えを有効にするには`block_id`を使用します + +ブロック乗り換えは、異なるルートの連続する旅行間、またはルートがループ線の場合は同じルート上の連続する旅行間で行うことができます。 `block_id`フィールドを使用して、どの旅行が 1 つのブロックに含まれるか、および座席内乗り換えが利用可能なオプションを指定します。 + +たとえば、次の [trips.txt](../../reference/#tripstxt) および [stop_times.txt](../../reference/#stop_timestxt) の値を検討します: + +[** trips.txt**](../../reference/#tripstxt) + +| route_id | trip_id | block_id | +|----------|-------------|---| +| RouteA | RouteATrip1 | Block1 | +| RouteB | RouteBTrip1 | Block1 | + +[** stop_times.txt**](../../reference/#stop_timestxt) + +| trip_id | arrive_time | departmental | stop_id | stop_sequence | +|----------|---------------|---|----|-----| +|ルートAトリップ1 | 12:00:00| 12:01:00 |あ | 1 | +|ルートAトリップ1 | 12:05:00| 12:06:00 | B | 2 | +|ルートAトリップ1 | 12:15:00 | | C | 3| +|ルートBトリップ1 | | 12:18:00 | C | 1 | +| RouteBTrip1 |12:22:00 | 12:23:00 | D | 2 | +| RouteBTrip1 |12:30:00 | | E | 3 | + +この例では、次のようになります。 + +- 停留所 A から停留所 E までのルートを検索するユーザーは、ルート A の 12:00 に停留所 A で乗車し、`RouteATrip1` の終了後に停留所 C に到着したら車両にとどまるように指示されます。これは、同じ車両がルート B の `RouteBTrip1` を運行しているためです。 +- `RouteATrip1` の乗客が `RouteBTrip1` の停留所まで進みたい場合は、この乗り換えの間、車両にとどまることができます。 +- これらの同じルートを他の車両で移動する他の旅行の乗客は、旅行ごとに異なる車両を使用するため、このオプションはありません。 + +### ループ ラインでのブロック乗り換え + +ループ ラインでは、旅行の最初の停留所と最後の停留所は同じで、同じ`stop_id`を持ちます。連続するループ旅行に同じ`block_id`がある場合、ブロックまたは座席内乗り換えが有効になり、最初の旅行の乗客は車両に留まり、次のループに進むことができます。 \ No newline at end of file diff --git a/docs/ja/documentation/schedule/examples/translations.md b/docs/ja/documentation/schedule/examples/translations.md new file mode 100644 index 000000000..7619a6994 --- /dev/null +++ b/docs/ja/documentation/schedule/examples/translations.md @@ -0,0 +1,52 @@ +#翻訳 + +## 駅名を翻訳する + +一部の交通機関プロバイダーは複数の言語でサービスを提供しています。その 1 つがベルギー国鉄 (現地では NMBS/SNCB、オランダ語では Nationale Maatschappij der Belgische Spoorwegen、フランス語では Société nationale des chemins de fer belges として知られています) です。同社は駅名を複数の言語で提供しており、ユーザーの言語と場所の設定に応じて表示されます。 + +NMBS/SNCB は、以下のファイルに示すように、GTFS データをフランス語で公開しています。 + +[** agency.txt**](../../reference/#agencytxt) + +``` +agency_id,agency_name,agency_url,agency_timezone,agency_lang +NMBS/SNCB、NMBS/SNCB、http://www.belgiantrain.be/、Europe/Brussels、fr +``` + + +機関の言語がフランス語に設定されているため、[stops.txt](../../reference/#stopstxt) には駅名がフランス語で記載されています。 + +[** stops.txt**](../../reference/#stopstxt) + +``` +stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,zone_id,stop_url,location_type,parent_station,platform_code +S8815040,,Bruxelles-Ouest,,50.8485600,4.32104000,,,1,, +S8821006,,Anvers-Central,,51.2172000,4.42109800,,,1,, +``` + + +[translations.txt](../../reference/#translationstxt) ファイルを使用して、駅名をデフォルトの機関言語 (この場合はフランス語) からオランダ語に翻訳します。 + +[** translations.txt**](../../reference/#translationstxt) + +``` +table_name、field_name、record_id、language、translation +stops、stop_name、S8815040、nl、Brussel-West +``` + +- この例では、[stops.txt](../../reference/#stopstxt) の駅名が翻訳され、[stops.txt](../../reference/#stopstxt) 内のレコードは`stop_id`によって識別されます。したがって、 + - `stops`はテーブル名の下にリストされます ([stops.txt](../../reference/#stopstxt) を参照して) + - `stop_name` は`field_name`の下にリストされます (駅名が翻訳されるため) + - フランス語から翻訳される駅名の`stop_id` は`record_id`の下にリストされます (この場合、Bruxelles-Ouest の`stop_id` ) +- 名前はオランダ語 (nl) に翻訳されます +- 最後に、翻訳された名前は translation の下にリストされます + +GTFS で名前を翻訳する別の方法として、[translations.txt](../../reference/#translationstxt) ファイルを使用する方法があります。この方法では、フィールド`field_value`が`record_id`の代わりに使用されます。この場合、駅名は [stops.txt](../../reference/#stopstxt) から翻訳するレコードを検索するために使用されます。 + +[** translations.txt**](../../reference/#translationstxt) + +``` +table_name、field_name、field_value、language、translation +stops、stop_name、Bruxelles-Ouest、nl、Brussel-West +``` + diff --git a/docs/ja/documentation/schedule/reference.md b/docs/ja/documentation/schedule/reference.md new file mode 100644 index 000000000..3e6b7e967 --- /dev/null +++ b/docs/ja/documentation/schedule/reference.md @@ -0,0 +1,861 @@ +##General Transit Feed Specificationリファレンス + +**2024 年 8 月 16 日に改訂されました。詳細については、[改訂履歴](../change_history/revision_history)を参照してください。** + +このドキュメントでは、GTFS データセットを構成するファイルの形式と構造を定義します。 + +## 目次 + + 1. [ドキュメントの規則](#document-conventions) + 2. [データセット ファイル](#dataset-files) + 3. [ファイル要件](#file-requirements) + 4. [データセットの公開と一般的な慣行](#dataset-publishing-general-practices) + 5. [フィールド定義](#field-definitions) + - [agency.txt](#agencytxt) + - [stops.txt](#stopstxt) + - [routes.txt](#routestxt) + - [trips.txt](#tripstxt) + - [stop\_times.txt](#stop_timestxt) + - [calendar.txt](#calendartxt) + - [calendar\_dates.txt](#calendar_datestxt) + - [fare\_attributes.txt](#fare_attributestxt) + - [fare\_rules.txt](#fare_rulestxt) + - [timeframes.txt](#timeframestxt) + - [fare\_media.txt](#fare_mediatxt) + - [fare\_products.txt](#fare_productstxt) + - [fare\_leg\_rules.txt](#fare_leg_rulestxt) + - [fare\_transfer\_rules.txt](#fare_transfer_rulestxt) + - [areas.txt](#areastxt) + - [stop_areas.txt](#stop_areastxt) + - [networks.txt](#networkstxt) + - [route_networks.txt](#route_networkstxt) + - [shapes.txt](#shapestxt) + - [frequencies.txt](#frequenciestxt) + - [transfers.txt](#transferstxt) + - [pathways.txt](#pathwaystxt) + - [levels.txt](#levelstxt) + - [location_groups.txt](#location_groupstxt) + - [location_group_stops.txt](#location_group_stopstxt) + - [locations.geojson](#locationsgeojson) + - [booking_rules.txt](#booking_rulestxt) + - [translations.txt](#translationstxt) + - [feed\_info.txt](#feed_infotxt) + - [attributions.txt](#attributionstxt) + +## ドキュメントの規則 +このドキュメント内のキーワード`しなければならない`、`してはいけない`、`必須`、`しなければならない`、`してはならない`、`するべきである`、`するべきではない`、`推奨される`、`してもよい`、および`任意`は、[RFC 2119](https:)で説明されているとおりに解釈されます。 + + +### 用語の定義 + +このセクションでは、このドキュメント全体で使用される用語を定義します。 + +* **データセット** - この仕様リファレンスによって定義されるファイルの完全なセット。データセットを変更すると、データセットの新しいバージョンが作成されます。データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります (例: https://www.agency.org/gtfs/gtfs.zip)。 +* **レコード** - 単一のエンティティ (交通機関、停留所、ルートなど) を説明するさまざまなフィールド値で構成される基本データ構造。テーブルでは行として表されます。 +* **フィールド** - オブジェクトまたはエンティティのプロパティ。テーブルでは列として表されます。フィールドは、ファイルにヘッダーとして追加された場合に存在します。フィールド値が定義されている場合と、定義されていない場合があります。 +* **フィールド値** - フィールド内の個々のエントリ。テーブルでは 1 つのセルとして表されます。 +* **サービス日** - サービス日は、ルートのスケジュールを示すために使用される期間です。サービス日の正確な定義は機関によって異なりますが、サービス日は多くの場合、暦日と一致しません。サービスが 1 日に開始され、翌日に終了する場合、サービス日は 24:00:00 を超えることがあります。たとえば、金曜日の 08:00:00 から土曜日の 02:00:00 まで実行されるサービスは、1 つのサービス日に 08:00:00 から 26:00:00 まで実行されると示される場合があります。 +* **音声合成フィールド** - フィールドには、親フィールド (空の場合はフォールバックされるフィールド) と同じ情報が含まれている必要があります。これは音声合成で読み上げられることを目的としているため、省略形は削除するか (`St`は`Street`または`Saint`と読み上げ、`h` I`は`h` the first`と読み上げます)、そのまま読み上げます (`K` Airport`は省略されているとされています)。 +* **区間** - 乗客が旅行中の 2 つの連続する場所の間で乗り降りする旅行。 +* **旅程** - 出発地から目的地までの全体的な旅行。途中のすべての区間と乗り換えを含みます。 +* **サブ旅程** - 旅程のサブセットを構成する 2 つ以上の区間。 +* **運賃商品** - 旅行の支払いや検証に使用できる購入可能な運賃商品。 + +### 存在 +フィールドとファイルに適用される存在条件: + +* **必須** - フィールドまたはファイルはデータセットに含まれ、各レコードに有効な値が含まれている必要があります。 +* **任意** - フィールドまたはファイルは、データセットから省略できます。 +* **条件付きで必須** - フィールドまたはファイルは、フィールドまたはファイルの説明に記載されている条件に従って含める必要があります。 +* **条件付きで禁止** - フィールドまたはファイルは、フィールドまたはファイルの説明に記載されている条件に従って含めないでください。 +* **推奨** - フィールドまたはファイルはデータセットから省略できますが、含めることがベストプラクティスです。このフィールドまたはファイルを省略する前に、ベストプラクティスを慎重に評価し、省略による影響を完全に理解する必要があります。 + +### フィールドタイプ + +- **色** - 6桁の16進数としてエンコードされた色。有効な値を生成するには、[https://htmlcolorcodes.com](https://htmlcolorcodes.com) を参照してください (先頭の`#`を含めることはできません)。
*例: 白の場合は`FFFFFF` 、黒の場合は `000000`、NYMTA の A、C、E ラインの場合は `0039A6`。* +- **通貨コード** - ISO 4217 アルファベット順の通貨コード。現在の通貨のリストについては、[https://en.wikipedia.org/wiki/ISO_4217#Active\_codes](https://en.wikipedia.org/wiki/ISO_4217#Active_codes) を参照してください。
*例: カナダドルの場合は`CAD` 、ユーロの場合は`EUR` 、日本円の場合は`JPY` 。* +- **通貨金額** - 通貨金額を示す小数値。小数点以下の桁数は、付随する通貨コードの [ISO 4217](https:) で指定されています。すべての財務計算は、データの使用に使用するプログラミング言語に応じて、小数点、通貨、または財務計算に適した同等の型として処理する必要があります。計算中に金銭の損益が発生する可能性があるため、通貨金額をfloatとして処理することは推奨されません。 +- **日付** - YYYYMMDD 形式のサービス日。サービス日内の時刻は 24:00:00 を超える場合があるため、サービス日には後続の日の情報が含まれることがあります。
*例: 2018 年 9 月 13 日の場合は`20180913`。* +- **電子メール** - 電子メール アドレス。
*例: `example@example.com`* +- **Enum** - `説明`列で定義された定義済み定数のセットからのオプション。
*例: `route_type`フィールドには、路面電車の場合は `0`、地下鉄の場合は`1` が含まれます...* +- **ID** - IDフィールドの値は内部IDであり、乗客に表示されるものではなく、UTF-8 文字のシーケンスです。印刷可能な ASCII 文字のみを使用することをお勧めします。ファイル内で一意である必要がある ID には、`一意のID`というラベルが付けられます。1 つの.txtファイルで定義されたIDは、別の.txtファイルで参照されることがよくあります。別のテーブルのIDを参照する ID には、`外部ID `というラベルが付けられます。
*例: [stops.txt](#stopstxt) の`stop_id`フィールドは`一意のID `です。[stops.txt](#stopstxt) の`parent_station`フィールドは` `stops.stop_id`を参照する外部ID `です。* +- **言語コード** - IETF BCP 47 言語コード。IETF BCP 47 の概要については、[http://www.rfc-editor.org/rfc/bcp/bcp47 .txt](http://www.rfc-editor.org/rfc/bcp/bcp47 .txt) および [http://www.w3.org/International/articles/language-tags/](http ://www.w3.org/International/articles/language-tags/) を参照してください。
*例: 英語の場合は`en` 、アメリカ英語の場合は`en-US` 、ドイツ語の場合は `de`。* +- **緯度** - 10 進度での WGS84 緯度。値は -90.0 以上 90.0 以下である必要があります。 *
例: ローマのコロッセオの場合は `41.890169`。* +- **経度** - 10 進度での WGS84 経度。値は -180.0 以上 180.0 以下である必要があります。
*例: ローマのコロッセオの場合は `12.492269`。* +- **Float** - 浮動小数点数。 +- **Integer** - 整数。 +- **Phone number** - 電話番号。 +- **Time** - HH:MM:SS 形式の時間 (H:MM:SS も使用可能)。時間は、サービス日の`ら` 12 時間を引いた時間`から測定されます (夏時間の変更が行われる日を除いて、実質的には真夜中)。サービス日の真夜中以降に発生する時間については、HH:MM:SS で 24:00:00 より大きい値として時間を入力します。
*例: 午後 2:30 の場合は `14:30:00`、翌日の午前 1:35 の場合は `25:35:00`。* +- **Text** - UTF-8 文字のstring。表示を目的としているため、人間が判読できる必要があります。 +- **タイムゾーン** - [https://www.iana.org/time-zones](https://www.iana.org/time-zones) の TZ タイムゾーン。タイムゾーン名にはスペース文字は含まれませんが、アンダースコアは含めることができます。有効な値の一覧については、[http://en.wikipedia.org/wiki/List\_of\_tz\_zones](http://en.wikipedia.org/wiki/List\_of\_tz\_zones) を参照してください。
*例: `Asia/Tokyo`、 `America/Los_Angeles` 、 `Africa/Cairo`。* +- **URL** - http://または https://を含む完全修飾 URL。URL 内の特殊文字は正しくエスケープする必要があります。完全修飾 URL 値の作成方法については、次の [http://www.w3.org/Addressing/URL/4\_URI\_Recommentations.html](http://www.w3.org/Addressing/URL/4\_URI\_Recommentations.html) を参照してください。 + +### フィールド記号 +Float または Integer フィールド タイプに適用される記号: + +* **非負** - 0 以上。 +* **非ゼロ** - 0 と等しくない。 +* **正** - 0 より大きい。 + +例: **非負float** - 0 以上の浮動小数点数。_ + +### データセット属性 +データセットの **主キー** は、行を一意に識別するフィールドまたはフィールドの組み合わせです。`y` key (*)` は、ファイルに提供されたすべてのフィールドを使用して行を一意に識別するときに使用されます。 `y` key (none)` は、ファイルで 1 行のみが許可されることを意味します。 + +例: `trip_id`フィールドと`stop_sequence`フィールドは [stop_times.txt](#stop_timestxt) の主キーになります。_ + +## データセット ファイル + +この仕様では、次のファイルを定義します: + +| ファイル名 | 存在 | 説明 | +|------|------|------| +| [agency.txt](#agencytxt) | **必須** | このデータセットで表されるサービスを提供する交通機関。| +| [stops.txt](#stopstxt) | **条件付きで必須** | 車両が乗客を乗降させる停留所等。駅と駅の入口も定義します。

条件付きで必須:
- [locations.geojson](#locationsgeojson ) で需要対応ゾーンが定義されている場合は任意。
- **それ以外の場合は必須**。 | +| [routes.txt](#routestxt) | **必須** | 交通機関のルート。ルートは、乗客に単一のサービスとして表示される旅行のグループです。 | +| [trips.txt](#tripstxt) | **必須** | 各ルートの便。旅行とは、特定の期間内に発生する 2 つ以上の停留所のシーケンスです。 | +| [stop_times.txt](#stop_timestxt) | **必須** | 各旅行で車両が停留所に到着および出発する時刻。 | +| [calendar.txt](#calendartxt) | **条件付きで必須** | 開始日と終了日を含む週次スケジュールを使用して指定された運行日。

条件付きで必須:
- [calendar_dates.txt](#calendar_datestxt) ですべてのサービス日付が定義されていない限り、**必須** です。
- それ以外の場合は任意。 | +| [calendar_dates.txt](#calendar_datestxt) | **条件付きで必須** | [calendar.txt](#calendartxt) で定義されたサービスの例外。

条件付きで必須:
- ** [calendar.txt](#calendartxt) が省略されている場合は必須。その場合、[calendar_dates.txt](#calendar_datestxt) にはサービスの日付がすべて含まれている必要があります。
- それ以外の場合は任意。 | +| [fare_attributes.txt](#fare_attributestxt) |任意| 交通機関のルートの運賃情報。 | +| [fare_rules.txt](#fare_rulestxt) |任意| 旅程に運賃を適用するルール。 | +| [timeframes.txt](#timeframestxt) |任意|dateと時間の要因に依存する運賃の運賃ルールで使用する日付と時間の期間。 | +| [fare_media.txt](#fare_mediatxt) |任意| 運賃製品を使用するために使用できる運賃メディアを説明します。

ファイル [fare_media.txt](#fare_mediatxt) は、[fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) に示されていない概念について説明します。そのため、[fare_media.txt](#fare_mediatxt) の使用は、ファイル [fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) とは完全に独立しています。| +| [fare_products.txt](#fare_productstxt) |任意| 乗客が購入できるさまざまな種類のチケットまたは運賃について説明します。

ファイル [fare_products.txt](#fare_productstxt) には、[fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) に示されていない運賃商品が記載されています。そのため、[fare_products.txt](#fare_productstxt) の使用は、ファイル [fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) とは完全に独立しています。| +| [fare_leg_rules.txt](#fare_leg_rulestxt) |任意| 個々の旅行区間の運賃規則。

ファイル [fare_leg_rules.txt](#fare_leg_rulestxt) は、運賃構造をモデル化するためのより詳細な方法を提供します。そのため、[fare_leg_rules.txt](#fare_leg_rulestxt) の使用は、ファイル [fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) とは完全に別です。 | +| [fare_transfer_rules.txt](#fare_transfer_rulestxt) |任意| 旅行区間間の乗り継ぎに関する運賃規則。

[fare_leg_rules.txt](#fare_leg_rulestxt) とともに、ファイル [fare_transfer_rules.txt](#fare_transfer_rulestxt) は、運賃構造をモデル化するより詳細な方法を提供します。そのため、[fare_transfer_rules.txt](#fare_transfer_rulestxt) の使用は、ファイル [fare_attributes.txt](#fare_attributestxt) および [fare_rules.txt](#fare_rulestxt) とは完全に別です。 | +| [areas.txt](#areastxt) |任意| 場所のエリアグループ化。 | +| [stop_areas.txt](#stop_areastxt) |任意| 停留所をエリアに割り当てるルール。 | +| [networks.txt](#networkstxt) | **条件付きで禁止** | ルートのネットワークグループ化。

条件付きで禁止:
- [routes.txt](#routestxt)に`network_id`が存在する場合は**禁止**です。
- それ以外の場合は任意。 | +| [route_networks.txt](#route_networkstxt) | **条件付きで禁止** | ネットワークにルートを割り当てるルール。

条件付きで禁止:
- [routes.txt](#routestxt)に`network_id`が存在する場合は**禁止**です。
- それ以外の場合は任意。 | +| [shapes.txt](#shapestxt) |任意| 車両の移動経路をマッピングするためのルール。ルート配置と呼ばれることもあります。 | +| [frequencies.txt](#frequenciestxt) |任意| ヘッドウェイベースのサービスのヘッドウェイ (旅行間の時間)、または固定スケジュールサービスの圧縮表現。 | +| [transfers.txt](#transferstxt) |任意| ルート間の乗り換えポイントでの接続を確立するためのルール。 | +| [pathways.txt](#pathwaystxt) |任意| 駅内の場所をリンクする構内通路。 | +| [levels.txt](#levelstxt) | **条件付きで必須** | 駅内の階・フロア。

条件付きで必須:
- エレベーター付きの経路を記述する場合 ( `pathway_mode=5` ) **必須**。
- それ以外の場合は任意。 | +| [location_groups.txt](#location_groupstxt) |任意| 乗客が乗車または降車をリクエストできる場所を示す停車地のグループ。 | +| [location_group_stops.txt](#location_group_stopstxt) |任意| 停車地を場所グループに割り当てるルール。 | +| [locations.geojson](#locationsgeojson) |任意| オンデマンド サービスによる乗客の乗車または降車リクエストのゾーン。GeoJSON ポリゴンとして表されます。 | +| [booking_rules.txt](#booking_rulestxt) |任意| 乗客がリクエストしたサービスの予約情報。 | +| [translations.txt](#translationstxt) |任意| 顧客向けのデータセット値の翻訳。 | +| [feed_info.txt](#feed_infotxt) | **条件付きで必須** | 発行者、バージョン、有効期限情報を含むデータセットのメタデータ。

条件付きで必須:
- [translations.txt](#translationstxt) が提供されている場合は**必須**です。
- それ以外の場合は推奨。| +| [attributions.txt](#attributionstxt) |任意| データセットの帰属表示。| + +## ファイル要件 + +データセット ファイルの形式と内容には、次の要件が適用されます。 + +* すべてのファイルは、カンマ区切りのテキストとして保存する必要があります。 +* 各ファイルの最初の行には、フィールド名が含まれている必要があります。[フィールド定義](#field-definitions) セクションの各サブセクションは、GTFS データセット内のファイルの 1 つに対応し、そのファイルで使用できるフィールド名をリストします。 +* すべてのファイル名とフィールド名は、大文字と小文字が区別されます。 +* フィールド値には、タブ、復帰改行、または改行を含めることはできません。 +* 引用符またはカンマを含むフィールド値は、引用符で囲む必要があります。また、フィールド値内の各引用符の前には引用符を付ける必要があります。これは、Microsoft Excel がカンマ区切り (CSV) ファイルを出力する方法と一致しています。 CSV ファイル形式の詳細については、[http://tools.ietf.org/html/rfc4180](http://tools.ietf.org/html/rfc4180) を参照してください。 +次の例は、フィールド値がコンマ区切りファイルでどのように表示されるかを示しています。 + * **元のフィールド値:** ``引用符`、コンマ、およびテキストが含まれています` + * **CSV ファイル内のフィールド値:** `"`引用符`、コンマ、およびテキストが含まれています"` +* フィールド値には、HTML タグ、コメント、またはエスケープ シーケンスを含めることはできません。 +* フィールド間またはフィールド名間の余分なスペースは削除する必要があります。多くのパーサーは、スペースを値の一部と見なすため、エラーが発生する可能性があります。 +* 各行は、CRLF または LF 改行文字で終了する必要があります。 +* すべての Unicode 文字をサポートするには、ファイルを UTF-8 でエンコードする必要があります。Unicode バイト オーダー マーク (BOM) 文字を含むファイルは許容されます。 BOM 文字と UTF-8 の詳細については、[http://unicode.org/faq/utf_bom.html#BOM](http://unicode.org/faq/utf_bom.html#BOM) を参照してください。 +* すべてのデータセット ファイルは、まとめて zip 圧縮する必要があります。ファイルは、サブフォルダーではなく、ルート レベルに直接配置する必要があります。 +* 顧客向けのすべてのテキスト文字列 (停留所名、ルート名、行先標識を含む) では、小文字を表示できるディスプレイで地名を大文字にするローカル規則に従い、大文字と小文字を混在させる必要があります (例: “Brighton Churchill Square”、“Villiers-sur-Marne”、“Market Street”)。 +* フィード全体で、名前やその他のテキストの略語の使用は避けてください (例: Street の代わりに St.)。ただし、場所が略称で呼ばれる場合は除きます (例: “JFK Airport”)。略語は、スクリーン リーダー ソフトウェアや音声ユーザー インターフェイスによるアクセシビリティに問題が生じる可能性があります。使用ソフトウェアは、完全な単語を略語に確実に変換して表示するように設計できますが、略語から完全な単語に変換すると、エラーが発生するリスクが高くなります。 + +## データセットの公開と一般的な方法 + +* データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります。(例: www.agency.org/gtfs/gtfs.zip) 理想的には、使用ソフトウェア アプリケーションによるダウンロードを容易にするために、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできる必要があります。 GTFS データセットはオープンにダウンロードできるようにすることが推奨されています（そして最も一般的な方法です）が、データ プロバイダーがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することが推奨されます。 +* GTFS データは、安定した場所にある 1 つのファイルに、交通機関（または機関群）のサービスの最新の公式説明が常に含まれるように、反復して公開する必要があります。 +* データセットは、可能な限り、データの反復をまたいで`stop_id`、 `route_id`、および`agency_id`の永続的な識別子（id フィールド）を維持する必要があります。 +* 1 つの GTFS データセットには、現在のサービスと今後のサービスを含める必要があります（`統合`データセットと呼ばれることもあります）。 2 つの異なる GTFS フィードから結合されたデータセットを作成するために使用できる [マージ ツール](../../../resources/gtfs/#gtfs-merge-tools) が複数あります。 + * 公開された GTFS データセットは、いつでも少なくとも今後 7 日間は有効である必要があります。理想的には、運行会社がスケジュールが継続して運用されると確信している限り有効です。 + * 可能であれば、GTFS データセットは少なくとも今後 30 日間のサービスをカバーする必要があります。 + * 古いサービス (期限切れのカレンダー) はフィードから削除する必要があります。 + * サービスの変更が 7 日以内に有効になる場合は、このサービスの変更は、静的な GTFS データセットではなく、GTFS リアルタイム フィード (サービス アドバイザリまたは旅行更新) を通じて表現する必要があります。 + * GTFS データをホストする Web サーバーは、ファイル変更dateを正しく報告するように構成する必要があります ([HTTP/1.1- Request for Comments 2616、セクション 14.29 を参照)。](https://tools.ietf.org/html/rfc2616#section-14.29)). + +## フィールド定義 + +### agency.txt + +ファイル: **必須** + +主キー(`agency_id`) + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `agency_id` |ユニーク ID | **条件付きで必須** | 多くの場合、交通機関と同義である交通ブランドを識別します。 1 つの機関が複数の個別のサービスを運営している場合など、機関とブランドは異なる場合があることに注意してください。 このドキュメントでは、`ブランド`の代わりに`機関`という用語を使用します。 データセットには、複数の機関のデータが含まれる場合があります。

条件付きで必須:
- データセットに複数の交通機関のデータが含まれている場合は**必須**です。
- それ以外の場合は推奨。 | +| `agency_name` |Text| **必須** | 交通機関の正式名称。 | +| `agency_url` | URL | **必須** | 交通機関の URL。 | +| `agency_timezone` | タイムゾーン | **必須** | 交通機関が所在するタイムゾーン。データセットで複数の機関が指定されている場合、それぞれに同じ`agency_timezone`が必要です。 | +| `agency_lang` | 言語コード |任意| この交通機関が使用する主な言語。GTFS のユーザーがデータセットの大文字と小文字の規則やその他の言語固有の設定を選択できるようにするために提供する必要があります。 | +| `agency_phone` | 電話番号 |任意| 指定された機関の音声電話番号。このフィールドは、機関のサービスエリアの一般的な電話番号を表すstring値です。数字をグループ化するために句読点を含めることができます。ダイヤル可能なテキスト (TriMet の`503-238-RIDE`など) は許可されていますが、フィールドにはその他の説明テキストを含めることはできません。 | +| `agency_fare_url` | URL |任意| 乗客がその機関のチケットやその他の運賃手段をオンラインで購入できる Web ページの URL。 | +| `agency_email` | 電子メール |任意| 機関のカスタマー サービス部門によってアクティブに監視されている電子メール アドレス。この電子メール アドレスは、交通機関の乗客が機関のカスタマー サービス担当者に連絡できる直接の連絡先である必要があります。 | + +### stops.txt + +ファイル: **条件付きで必須** + +主キー(`stop_id`) + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `stop_id` |ユニーク ID | **必須** |場所を識別します: 停留所/プラットフォーム、駅、入口/出口、汎用ノード、または乗車エリア ( ``location_type``を参照)。

ID は、すべての`stops.stop_id`、 locations.geojson `id`、および`location_groups.location_group_id`値にわたって一意である必要があります。

複数のルートで同じ`stop_id`が使用される場合があります。 | +| `stop_code` |Text|任意| 乗客に対して場所を識別する短いテキストまたは番号。これらのコードは、多くの場合、電話ベースの交通情報システムで使用され、または乗客が特定の場所の情報を入手しやすくするために標識に印刷されます。 `stop_code` は、一般向けである場合は`stop_id`と同じになることがあります。乗客にコードが提示されない場所では、このフィールドは空白のままにしてください。 | +| `stop_name` |Text| **条件付きで必須** | 場所の名前。 `stop_name` は、時刻表に印刷されているか、オンラインで公開されているか、標識に表示されている、機関の乗客向けの場所の名前と一致する必要があります。他の言語に翻訳するには、[translations.txt](#translationstxt) を使用します。

場所が乗車エリアの場合 (`location_type=4`)、 `stop_name` には、機関が表示する乗車エリアの名前を含める必要があります。これは、1 文字だけの場合 (一部のヨーロッパの都市間鉄道駅のように) もあれば、`車椅子乗車エリア`(ニューヨーク市の地下鉄) や`短距離列車の先頭`(パリの RER) のようなテキストの場合もあります。

条件付きで必須:
- 停留所 ( `location_type=0`)、駅 (`location_type=1`)、または入口/出口 (`location_type=2` ) の場所の場合は **必須** です。
- 汎用ノード ( `location_type=3`) または乗車エリア (`location_type=4` ) の場所の場合は任意。| +| `tts_stop_name` |Text|任意| `stop_name`の読み取り可能なバージョン。詳細については、[用語の定義](#term-definitions)の`テキスト読み上げフィールド`を参照してください。| +| `stop_desc` |Text|任意| 有用で質の高い情報を提供する場所の説明。`stop_name` と重複してはいけません。| +| `stop_name` `stop_lat` | 緯度 | **条件付きで必須** | 場所の緯度。

停留所/プラットフォーム (`location_type=0`) および乗車エリア (`location_type=4`) の場合、座標はバスポール (存在する場合) の座標でなければならず、そうでない場合は旅行者が車両に乗車する場所 (車両が停止する道路や線路ではなく、歩道またはプラットフォーム) の座標でなければなりません。

条件付きで必須:
- 停留所 ( `location_type=0`)、駅 (`location_type=1`)、または入口/出口 (`location_type=2` ) の場所の場合は **必須** です。
- 汎用ノード ( `location_type=3`) または乗車エリア (`location_type=4` ) の場所の場合は任意。| +| `stop_lon` | 経度 | **条件付きで必須** | 場所の経度。

停留所/プラットフォーム (`location_type=0`) および乗車エリア (`location_type=4`) の場合、座標はバスポール (存在する場合) の座標でなければならず、そうでない場合は旅行者が車両に乗車する場所 (車両が停止する道路や線路ではなく、歩道またはプラットフォーム) の座標でなければなりません。

条件付きで必須:
- 停留所 ( `location_type=0`)、駅 (`location_type=1`)、または入口/出口 (`location_type=2` ) の場所の場合は **必須** です。
- 汎用ノード ( `location_type=3`) または乗車エリア (`location_type=4` ) の場所の場合は任意。| +| `zone_id` | ID |任意| 停車場の料金ゾーンを識別します。このレコードが駅または駅の入口を表す場合、 `zone_id`は無視されます。| +| `stop_url` | URL |任意| 場所に関する Web ページの URL。これは、`agency.agency_url`および`routes.route_url`フィールド値とは異なる必要があります。| +| `location_type` | 列挙型 |任意| 場所の種類。有効なオプションは次のとおりです。

`0` (または空白) - **停留所** (または **プラットフォーム**)。乗客が交通機関の車両に乗車`parent_station`降車する場所です。`parent_station` 内で定義されている場合はプラットフォームと呼ばれます。
`1` - **駅**。1 つ以上のプラットフォームを含む物理的な構造またはエリア。
`2` - **入口/出口**。乗客が通りから駅に出入りできる場所です。入口/出口が複数の駅に属している場合、両方の駅に経路でリンクされている可能性がありますが、データ プロバイダーはそのうちの 1 つを親として選択する必要があります。
`3` - **汎用ノード**。他の`location_type`に一致しない駅内の場所。[pathways.txt](#pathwaystxt) で定義された経路をリンクするために使用できます。
`4` - **乗車エリア**。乗客が車両に乗ったり降車したりできるプラットフォーム上の特定の場所です。| +| `parent_station` | `stops.stop_id`部` ID | **条件付きで必須** | [stops.txt](#stopstxt) で定義されているさまざまな場所間の階層を定義します。次のように、親の場所のIDが含まれます。

- **停車駅/プラットフォーム** (`location_type=0`): `parent_station`フィールドには駅のIDが含まれます。
- **駅** (`location_type=1`): このフィールドは空でなければなりません。
- **入口/出口** (`location_type=2`) または **汎用ノード** (`location_type=3`): `parent_station`フィールドには駅のIDが含まれます (`location_type=1`)
- **乗車エリア** (`location_type=4`): `parent_station`フィールドにはプラットフォームのIDが含まれます。

条件付きで必須:
- ** 入口 ( `location_type=2`)、汎用ノード (`location_type=3`)、または搭乗エリア (`location_type=4` ) の場所の場合は **必須** です。
- 停留所/プラットフォームの場合は任意(`location_type=0`)。
- 駅 (`location_type=1`) では禁止されています。| +| `stop_timezone` | タイムゾーン |任意| 場所のタイムゾーン。場所に親駅がある場合は、独自のタイムゾーンを適用する代わりに、親駅のタイムゾーンを継承します。 `stop_timezone`が空の駅と親のない停留所は、 `agency.agency_timezone`で指定されたタイムゾーンを継承します。[stop_times.txt](#stop_timestxt) で提供される時間は、 ` `stop_timezone` `agency.agency_timezone`で指定されたタイムゾーンです。これにより、旅行がどのタイムゾーンを通過するかに関係なく、旅行の途中で旅行の時間値が常に増加することが保証されます。| +| `wheelchair_boarding` | 列挙型 |任意| 場所から車椅子で乗車できるかどうかを示します。有効なオプションは次のとおりです。

保護者のいない場合の停止:
`0` または空 - 停留所のアクセシビリティ情報がありません。
`1` - この停留所の一部の車両は + +車椅子に乗ったライダーが乗っています。
`2` - この停留所では車椅子での乗車はできません。

チャイルドストップの場合:
`0` または空 - 親ステーションで指定されている場合、停留所は親ステーションから`wheelchair_boarding`動作を継承します。
`1` - 駅の外から特定の停留所/プラットフォームまでアクセス可能な経路が存在します。
`2` - 駅の外から特定の停留所/プラットフォームまでアクセス可能な経路が存在しません。

駅の出入口について：
`0` または空 - 親に指定されている場合、駅の入口は親駅の`wheelchair_boarding`動作を継承します。
`1` - 駅の入り口は車椅子でアクセス可能です。
`2` - 駅の入口から停留所/プラットフォームへのアクセス経路がありません。 | +| `level_id` | `levels.level_id`部` ID |任意| 場所のレベル。同じレベルが、リンクされていない複数の駅で使用される場合があります。| +| `platform_code` |Text|任意| プラットフォーム停留所 (駅に属する停留所) のプラットフォーム識別子。これは、プラットフォーム識別子のみである必要があります (例: "G" または "3")。`プラットフォーム`や`トラック`などの単語 (またはフィードの言語固有の同等語) を含めないでください。これにより、フィード コンシューマーは、プラットフォーム識別子を他の言語に国際化およびローカライズしやすくなります。 | + + +### routes.txt + +ファイル: **必須** + +主キー(`route_id`) + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `route_id` |ユニーク ID | **必須** | ルートを識別します。 | +| `agency_id` | `agency.agency_id`部` ID | **条件付きで必須** | 指定されたルートの事業者。

条件付きで必須:
- [agency.txt](#agencytxt ) に複数の代理店が定義されている場合は**必須**です。
- それ以外の場合は推奨。 | +| `route_short_name` |Text| **条件付きで必須** | ルートの短縮名。多くの場合、乗客がルートを識別するために使用する短い抽象的な識別子 (例: "32"、"100X"、"緑")。`route_short_name` と`route_long_name` の`route_short_name`を定義できます。

条件付きで必須:
- ** `routes.route_long_name`が空の場合は必須** です。
- 簡単なサービス指定がある場合に推奨。これは、サービスの一般的な乗客名である必要があり、12 文字以内にする必要があります。| +| `route_long_name` |Text| **条件付きで必須** | ルートの完全な名前。この名前は通常、 `route_short_name`よりも説明的で、ルートの目的地または停車地が含まれることがよくあります。`route_short_name` と`route_long_name` の両方を定義できます。

条件付きで必須:
- ** `routes.route_short_name`が空の場合は必須** です。
- それ以外の場合は任意。 | +| `route_desc` |Text|任意| 有用で質の高い情報を提供するルートの説明。 `route_short_name`または`route_long_name`と重複してはいけません。
_例: `A`列車は、マンハッタンの Inwood-207 St とクイーンズの Far Rockaway-Mott Avenue の間を常時運行しています。また、午前 6 時頃から深夜頃まで、追加の`A`が` Inwood-207 St と Lefferts Boulevard の間を運行しています (列車は通常、Lefferts Blvd と Far Rockaway の間を交互に運行します)。_ | +| `route_type` | Enum | **必須** | ルートで使用される交通機関の種類を示します。有効なオプションは次のとおりです。

`0` - 路面電車、路面電車、ライトレール。大都市圏内のライトレールまたはストリートレベルのシステム。
`1` - 地下鉄。大都市圏内のあらゆる地下鉄システム。
`2` - 鉄道。都市間または長距離の移動に使用されます。
`3` - バス。短距離および長距離のバス路線に使用されます。
`4` - フェリー。短距離および長距離の船舶サービスに使用されます。
`5` - ケーブル トラム。ケーブルが車両の下を走る路面電車に使用されます (例: サンフランシスコのケーブルカー)。
`6` - 空中リフト、吊り下げ式ケーブルカー（例：ゴンドラリフト、空中ケーブルウェイ）。キャビン、車両、ゴンドラ、またはオープンチェアが 1 本以上のケーブルによって吊り下げられているケーブル輸送。
`7` - ケーブルカー。急勾配向けに設計された鉄道システム。
`11` - トロリーバス。ポールを使用して架空線から電力を供給する電気バス。
`12` - モノレール。線路が単一のレールまたはビームで構成される鉄道。 | +| `route_url` | URL |任意| 特定のルートに関する Web ページの URL。`agency.agency_url` 値とは異なる必要があります。 | +| `route_color` | 色 |任意| 公開資料に一致するルートの色の指定。省略または空のままにした場合、デフォルトで白 (`FFFFFF`) になります。 `route_color`と`route_text_color`の色の違いは、白黒`agency.agency_url`で表示したときに十分なコントラストを提供する必要があります。 | +| `route_text_color` | 色 |任意| `route_color`の背景に描画されるテキストに使用する判読可能な色。省略または空のままにした場合、デフォルトで黒 (`000000`) になります。 `route_color`と`route_text_color`の色の違いは、白黒画面で表示したときに十分なコントラストを提供する必要があります。 | +| `route_sort_order` | 負でない整数 |任意| 顧客への提示に最適な方法でルートを並べ替えます。`route_sort_order` 値が小さいルート・路線系統が最初に表示されます。 | +| `continuous_pickup` | 列挙型 | **条件付きで禁止** | ルートのすべての旅行で、[shapes.txt](# `route_sort_order` ) で説明されているように、乗客が車両の移動経路に沿った任意の地点で交通機関の車両に乗車できることを示します。有効なオプションは次のとおりです。

`0` - 連続停止ピックアップ。
`1`または空 - 連続停止ピックアップなし。
`2` - 継続的な停車ピックアップを手配するには代理店に電話するしなければならない。
`3` - 連続停止ピックアップを手配するにはドライバーと調整するしなければならない。

`routes.continuous_pickup`の値は、ルート沿いの特定の`stop_time`に対して`stop_times.continuous_pickup`の値を定義することによって上書きできます。

**条件付きで禁止**:
- このルートのいずれかの旅行に `stop_times.start_pickup_drop_off_window` または `stop_times.end_pickup_drop_off_window` が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `continuous_drop_off` | 列挙型 | **条件付きで禁止** | 乗客がルートのすべての旅行で、[shapes.txt](#shapestxt) で説明されているように、車両の移動経路に沿った任意の地点で交通機関の車両から降車できることを示します。有効なオプションは次のとおりです。

`0` - 連続停止ドロップオフ。
`1`または空 - 連続停止ドロップオフなし。
`2` - 連続停車降車を手配するには代理店に電話するしなければならない。
`3` - 連続停車降車を手配するには、ドライバーと調整するしなければならない。

`routes.continuous_drop_off`の値は、ルート沿いの特定の`stop_time`に対して`stop_times.continuous_drop_off`の値を定義することによって上書きできます。

**条件付きで禁止**:
- このルートのいずれかの旅行に `stop_times.start_pickup_drop_off_window` または `stop_times.end_pickup_drop_off_window` が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `network_id` | ID | **条件付きで禁止** | ルートのグループを識別します。[routes.txt](#routestxt) 内の複数の行に同じ`network_id`が含まれる場合があります。

条件付きで禁止:
- [route_networks.txt](#route_networkstxt) ファイルが存在する場合は**禁止**です。
- それ以外の場合は任意。 + +### trips.txt + +ファイル: **必須** + +主キー(`trip_id`) + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `route_id` | `routes.route_id`部` ID | **必須** | ルートを識別します。 | +| `service_id` | `calendar.service_id`または`calendar_dates.service_id`部` ID | **必須** | 1 つ以上のルートでサービスが利用可能な日付のセットを識別します。 | +| `trip_id` |ユニーク ID | **必須** | 旅行を識別します。 | +| `trip_headsign` |Text|任意| 乗客に旅行の目的地を示す標識に表示されるText。このフィールドは、ルート内の旅行を区別するために使用できる、車両にヘッドサイン テキストが表示されるすべてのサービスに推奨されます。

旅行中にヘッドサインが変わる場合、旅行中の特定の`stop_time`の ` `stop_times.stop_headsign`の値を定義することで、 `trip_headsign`の値を上書きできます。 | +| `trip_short_name` |Text|任意| 通勤電車の列車番号を識別するなど、乗客に旅行を識別するために使用される一般向けのテキスト。乗客が旅行名をあまり使用しない場合は、 `trip_short_name` `trip_short_name`を空にする必要があります。`trip_short_name` 値を指定する場合、サービス日内の旅行を一意に識別する必要があります。目的地名や特急/急行の指定には使用しないでください。 | +| `direction_id` | 列挙型 |任意| 旅行の移動方向を示します。このフィールドはルーティングには使用しないでください。時刻表を公開するときに方向別に旅行を分ける方法を提供します。有効なオプションは次のとおりです。

`0` - 一方向への移動（例：往路）。
`1` - 反対方向に移動します（例：入線）。
*例: `trip_headsign`と`direction_id`フィールドを一緒に使用して、一連の旅行の各方向への旅行に名前を割り当てることができます。[trips.txt](#tripstxt) ファイルには、時刻表で使用するために次のレコードを含めることができます。*
`trip_id,..., 旅行の見出し, 方向 ID`
`1234,...,空港,0`
`1505,...,Downtown,1` | +| `block_id` | ID |任意| 旅行が属するブロックを識別します。ブロックは、共有のサービス日と`block_id`によって定義される、同じ車両を使用して行われる単一の旅行または複数の連続した旅行で構成されます。 `block_id`には、異なるサービス日の旅行が含まれる場合があり、個別のブロックが作成されます。[以下の例](#example-blocks-and-service-day)を参照してください。座席内乗り換え情報を提供するには、代わりに`transfer_type` `4` の [transfers](#transferstxt) を指定する必要があります。 | +| `shape_id` | `shapes.shape_id`部` ID | **条件付きで必須** | 旅行の車両移動経路を説明する地理空間シェイプを識別します。

条件付きで必須:
- 旅行に [routes.txt](#routestxt) または [stop_times.txt](#stop_timestxt) のいずれかで定義された連続的な乗車または降車動作がある場合、**必須** です。
- それ以外の場合は任意です。 | +| `wheelchair_accessible` | 列挙型 |任意| 車椅子でのアクセス可能性を示します。有効なオプションは次のとおりです:

`0` または空 - 旅行のアクセシビリティ情報はありません。
`1` - この特定の旅行で使用される車両には、少なくとも 1 人の車椅子の乗客を収容できます。
`2` - この旅行では車椅子の乗客は乗車できません。 | +| `bikes_allowed` | 列挙型 |任意| 自転車が許可されているかどうかを示します。有効なオプションは次のとおりです:

`0` または空 - 旅行の自転車情報がありません。
`1` - この特定の旅行で使用される車両には、少なくとも 1 台の自転車を収容できます。
`2` - この旅行では自転車は許可されていません。 | + +#### 例: ブロックとサービス日 + +以下の例は有効で、曜日ごとに異なるブロックがあります。 + +| route_id | trip_id | service_id | block_id | *(最初の停止時刻)* | *(最後の停止時刻)* | +|----------|---------|--------------------------------|-----------|-----------------------------------------|-----------------------------------------| +| red | trip_1 | mon-tues-wed-thurs-fri-sat-sun | red_loop | 22:00:00 | 22:55:00 | +| red | trip_2 | fri-sat-sun | red_loop | 23:00:00 | 23:55:00 | +| red | trip_3 | fri-sat | red_loop | 24:00:00 | 24:55:00 | +| red | trip_4 | mon-tues-wed-thurs | red_loop | 20:00:00 | 20:50:00 | +| red | trip_5 | mon-tues-wed-thurs | red_loop | 21:00:00 | 21:50:00 | + +上記表に関する注記: + +* たとえば、金曜日から土曜日の朝にかけて、1 台の車両が`trip_1`、 `trip_2`、および`trip_3`を運行します (午後 10 時から午前 12 時 55 分まで)。最後の運行は土曜日の午前 12 時から午前 12 時 55 分までですが、時刻が 24:00:00 から 24:55:00 であるため、金曜日の`​​運行日`の一部であることに注意してください。 +* 月曜日、火曜日、水曜日、および木曜日には、1 台の車両が午後 8 時から午後 10 時 55 分までのブロックで`trip_1`、 `trip_4`、および`trip_5` を運行します。 + +### stop_times.txt + +ファイル: **必須** + +主キー(`trip_id`、 `stop_sequence`) + +| フィールド名 |タイプ | 存在 | 説明 | +|------|------|------|------| +| `trip_id` | `trips.trip_id`部` ID | **必須** | 旅行を識別します。 | +| `arrival_time` | 時間 | **条件付きで必須** | `stops.stop_timezone`ではなく`agency.agency_timezone`ム` ゾーンでの、特定の旅行 ( `stop_times.stop_id`で定義) の停留所 ( `stop_times.trip_id` stop_times.stop_id` で定義) への到着時刻。

停留所での到着時間と出発時間が別々でない場合は、 `arrival_time`と`departure_time` は同じである必要があります。

サービス日の深夜以降の時間については、HH:MM:SS 形式で 24:00:00 より大きい値を入力します。

正確な到着時刻と出発時刻 (`timepoint=1`) が利用できない場合は、推定または補間された到着時刻と出発時刻 (`timepoint=0`) を指定する必要があります。

条件付きで必須:
- **旅行の最初と最後の停車地に必須** ( `stop_times.stop_sequence`で定義)。
- ** ` timepoint=1 ` の場合は必須** です。
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合は**禁止**です。
- それ以外の場合は任意。| +| `departure_time` | 時間 | **条件付きで必須** | `stops.stop_timezone`ではなく`agency.agency_timezone`で指定されたタイムゾーンでの、特定の旅行 ( `stop_times.trip_id`で定義) からの出発時刻。

停留所での到着時間と出発時間が別々でない場合は、 `arrival_time`と`departure_time` は同じである必要があります。

サービス日の深夜以降の時間については、HH:MM:SS 形式で 24:00:00 より大きい値を入力します。

正確な到着時刻と出発時刻 (`timepoint=1`) が利用できない場合は、推定または補間された到着時刻と出発時刻 (`timepoint=0`) を指定する必要があります。

条件付きで必須:
- ** ` timepoint=1 ` の場合は必須** です。
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `stop_id` | `stops.stop_id`部` ID | **条件付きで必須** | サービス対象の停留所を識別します。旅行中にサービスされるすべての停留所は、[stop_times.txt](#stop_timestxt) に記録されている必要があります。参照される場所は停留所/プラットフォームである必要があります。つまり、 `stops.location_type`値は `0` または空である必要があります。同じ旅行で停留所が複数回サービスされる場合があり、複数の旅行とルートが同じ停留所にサービスを提供する場合があります。

停留所を使用するオンデマンド サービスは、それらの停留所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 stop_time の`pickup/drop_off_type`と各`start/end_pickup_drop_off_window`の時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

条件付きで必須:
- **必須** `stop_times.location_group_id`と`stop_times.location_id`が定義されていない場合。
- `stop_times.location_group_id`または`stop_times.location_id`が定義されている場合は**禁止**です。| +| `location_group_id` | `location_groups.location_group_id`部` ID | **条件付きで禁止** | 乗客が乗車または降車をリクエストできる停留所のグループを示すサービス対象の場所グループを識別します。旅行中にサービスされるすべての場所グループは、[stop_times.txt](#stop_timestxt) に記録されている必要があります。複数の旅行とルートが同じ場所グループにサービスを提供できます。

ロケーション グループを使用するオンデマンド サービスは、それらのロケーション グループでサービスが利用可能な順序で参照する必要があります。データ コンシューマーは、各 stop_time の`pickup/drop_off_type`と各`start/end_pickup_drop_off_window`の時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

**条件付きで禁止**:
- `stop_times.stop_id`または`stop_times.location_id`が定義されている場合は**禁止**です。| +| `location_id` | `locations.geojson`から`id`部` ID | **条件付きで禁止** | 乗客が乗車または降車をリクエストできるサービス提供ゾーンに対応する GeoJSON ロケーションを識別します。旅行中にサービス提供されるすべての GeoJSON ロケーションは、[stop_times.txt](#stop_timestxt) に記録されている必要があります。複数の旅行とルートで同じ GeoJSON ロケーションにサービスを提供できます。

場所内のオンデマンド サービスは、その場所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 stop_time の`pickup/drop_off_type`と各`start/end_pickup_drop_off_window`の時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

**条件付きで禁止**:
- `stop_times.stop_id`または`stop_times.location_group_id`が定義されている場合は**禁止**です。 | +| `stop_sequence` | 負でない整数 | **必須** | 特定の旅行の停車地、場所グループ、または GeoJSON の場所の順序。値は旅行に沿って増加する必要がありますが、連続している必要はありません。
*例: 旅行の最初の場所には`stop_sequence`= `1`、旅行の 2 番目の場所には`stop_sequence`=`23` 、3 番目の場所には`stop_sequence`=`40` などとなります。*

同じ場所グループまたは GeoJSON の場所内での移動には、[stop_times.txt](#stop_timestxt) に同じ`location_group_id`または`location_id`つ` 2 つのレコードが必要です。 | +| `stop_headsign` |Text|任意| 乗客に旅行の目的地を示す標識に表示されるText。このフィールドは、停留所間でヘッドサインが変わるときに、デフォルトの`trips.trip_headsign`を上書きします。ヘッドサインが旅行全体にわたって表示される場合は、代わりに`trips.trip_headsign`を使用する必要があります。

1 つの`stop_time`に指定された`stop_headsign`値は、同じ旅行内の後続の`stop_time`には適用されません。同じ旅行内の複数の`stop_time`の`trip_headsign`を上書きする場合は、各`stop_time`行で`stop_headsign`値を繰り返す必要があります。| +| `start_pickup_drop_off_window` | 時間 | **条件付きで必須** | GeoJSON の場所、場所グループ、または停留所でオンデマンド サービスが利用可能になる時間。

**条件付きで必須**:
- `stop_times.location_group_id`または`stop_times.location_id`が定義されている場合は **必須** です。
- ** `end_pickup_drop_off_window`が定義されている場合は必須。
- `arrival_time`または`departure_time`が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `end_pickup_drop_off_window` | 時間 | **条件付きで必須** | GeoJSON の場所、場所グループ、または停留所でオンデマンド サービスが終了する時間。

**条件付きで必須**:
- `stop_times.location_group_id`または`stop_times.location_id`が定義されている場合は **必須** です。
- ** `start_pickup_drop_off_window`が定義されている場合は必須。
- `arrival_time`または`departure_time`が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `pickup_type` | 列挙型 | **条件付きで禁止** | ピックアップ方法を示します。有効なオプションは次のとおりです:

`0` または空 - 定期的にスケジュールされたピックアップ。
`1` - ピックアップできません。
`2` - 代理店に電話して集荷を手配するしなければならない。
`3` - ピックアップを手配するにはドライバーと調整するしなければならない。

**条件付きで禁止**:
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合、` pickup_type =0` は**禁止**です。
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合、` pickup_type =3` は**禁止** です。
- それ以外の場合は任意。 | +| `drop_off_type` | 列挙型 | **条件付きで禁止** | ドロップオフ方法を示します。有効なオプションは次のとおりです:

`0` または空 - 定期的に予定されている降車。
`1` - ドロップオフは利用できません。
`2` - 降車手配のため代理店に電話するしなければならない。
`3` - 降車手配についてはドライバーと調整するしなければならない。

**条件付きで禁止**:
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合、` drop_off_type =0` は**禁止**です。
- それ以外の場合は任意。 | +| `continuous_pickup` | 列挙型 | **条件付きで禁止** | 乗客は、[shapes.txt](#shapestxt) で説明されているように、この`stop_time`から旅行の`stop_sequence`の次の`stop_time`まで、車両の移動経路に沿った任意の時点で交通機関の車両に乗車できることを示します。有効なオプションは次のとおりです。

`0` - 連続停止ピックアップ。
`1`または空 - 連続停止ピックアップなし。
`2` - 継続的な停車ピックアップを手配するには代理店に電話するしなければならない。
`3` - 連続停止ピックアップを手配するには、ドライバーと調整するしなければならない。

このフィールドに値が入力されている場合は、[routes.txt](#routestxt) で定義されている連続ピックアップ動作が上書きされます。このフィールドが空の場合、 `stop_time`は [routes.txt](#routestxt) で定義されている連続ピックアップ動作を継承します。

**条件付きで禁止**:
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `continuous_drop_off` | 列挙型 | **条件付きで禁止** | 乗客は、[shapes.txt](#shapestxt) で説明されているように、この`stop_time`から旅行の`stop_sequence`の次の`stop_time`まで、車両の移動経路に沿った任意の地点で交通機関の車両から降車できることを示します。有効なオプションは次のとおりです。

`0` - 連続停止ドロップオフ。
`1`または空 - 連続停止ドロップオフなし。
`2` - 連続停車降車を手配するには代理店に電話するしなければならない。
`3` - 連続停車降車を手配するには、ドライバーと調整するしなければならない。

このフィールドに値が入力されている場合は、[routes.txt](#routestxt) で定義されている連続降車動作が上書きされます。このフィールドが空の場合、 `stop_time`は [routes.txt](#routestxt) で定義されている連続降車動作を継承します。

**条件付きで禁止**:
- `start_pickup_drop_off_window`または`end_pickup_drop_off_window`が定義されている場合は**禁止**です。
- それ以外の場合は任意。 | +| `shape_dist_traveled` | 非負のfloat|任意| 最初の停車地からこのレコードで指定された停車地までの、関連付けられたシェイプに沿って実際に移動した距離。このフィールドは、旅行中に任意の 2 つの停車地間に描画するシェイプの量を指定します。[shapes.txt](#shapestxt) で使用されているのと同じ単位にするしなければならない。 `shape_dist_traveled`に使用する値は`stop_sequence`とともに増加する必要があります。ルートに沿った逆方向の移動を示すために使用してはなりません。

ループまたはインライン（車両が 1 回の移動で同じ線形部分を横断または移動する）があるルートに推奨。[`shapes.shape_dist_traveled`](#shapestxt) を参照してください。
*例: バスがシェイプの開始から停留所まで 5.25 キロメートルの距離を移動する場合、 `shape_dist_traveled`=`5.25` となります。*| +| `timepoint` | 列挙型 |任意| 停留所の到着時間と出発時間が車両によって厳密に遵守されているか、または概算時間や補間時間であるかを示します。このフィールドにより、GTFS プロデューサーは、概算時間であることを示すとともに、補間された停留所時間を提供できます。有効なオプションは次のとおりです。

`0` - 時間はおおよそのものとみなされます。
`1` - 時間は正確であるとみなされます。

到着時刻または出発時刻が定義されている [stop_times.txt](#stop_timestxt) のすべてのレコードには、タイムポイント値が入力されている必要があります。タイムポイント値が指定されていない場合は、すべての時刻が正確であるとみなされます。 | +| `pickup_booking_rule_id` | `booking_rules.booking_rule_id` を参照する外部 ID |任意| この停車時刻での搭乗予約ルールを識別します。

` pickup_type =2 ` の場合に推奨。 | +| `drop_off_booking_rule_id` | `booking_rules.booking_rule_id` を参照する外部 ID |任意| この停車時間における降車予約ルールを識別します。

` drop_off_type =2` の場合に推奨。| + +#### オンデマンド サービスのルーティング動作 +- 出発地と目的地の間のルーティングまたは移動時間を提供する場合、データ コンシューマーは、 `start_pickup_drop_off_window`および`end_pickup_drop_off_window`が定義されている同じ`trip_id`を持つ中間のstop_times.txtレコードを無視する必要があります。無視する必要がある内容の例については、[データ例のページ](../examples/flex/#ignoring-intermediate-stop-times-records-with-pickupdrop-off-windows) を参照してください。 +- 同じ`trip_id`つ` 2 つ以上のstop_times.txtレコード間で、 locations.geojson `id`ジオメトリ、 `start/end_pickup_drop_off_window`時間、および`pickup_type`または`drop_off_type`が同時に重複することは禁止されています。禁止されている内容の例については、[データ例ページ](../examples/flex/#zone-overlap-constraint)を参照してください。 + +### calendar.txt + +ファイル: **条件付きで必須** + +主キー(`service_id`) + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `service_id` |ユニーク ID | **必須** | 1 つ以上のルートでサービスが利用可能な日付のセットを識別します。 | +| `monday` | 列挙型 | **必須** | `start_date`フィールドと`end_date`フィールドで指定されたdate範囲のすべての月曜日にサービスが実行されるかどうかを示します。特定の日付の例外は [calendar_dates.txt](#calendar_datestxt) にリストされていることに注意してください。有効なオプションは次のとおりです。

`1` - サービスはdate範囲内のすべての月曜日に利用できます。
`0` -date範囲内の月曜日にはサービスは利用できません。 | +| `tuesday` | 列挙型 | **必須** | 火曜日に適用される点を除き、 `monday`と同じように機能します | +| `wednesday` | 列挙型 | **必須** | 水曜日に適用される点を除き、 `monday`と同じように機能します | +| `thursday` | 列挙型 | **必須** | 木曜日に適用される点を除き、 `monday`と同じように機能します | +| `friday` | 列挙型 | **必須** | 金曜日に適用される点を除き、 `monday`と同じように機能します | +| `saturday` | 列挙型 | **必須** | 土曜日に適用される点を除き、 `monday`と同じように機能します。 | +| `sunday` | 列挙型 | **必須** | 日曜日に適用される点を除き、 `monday`と同じように機能します。 | +| `start_date` | 日付 | **必須** | サービス間隔の開始サービス日。 | +| `end_date` | 日付 | **必須** | サービス間隔の終了サービス日。このサービス日は間隔に含まれます。 | + +### calendar_dates.txt + +ファイル: **条件付きで必須** + +主キー(`service_id`、 `date`) + +[calendar_dates.txt](#calendar_datestxt) テーブルは、dateによってサービスを明示的に有効または無効にします。2 つの方法で使用できます。 + +*推奨: [calendar_dates.txt](#calendar_datestxt) を [calendar.txt](#calendartxt) と組み合わせて使用​​し、[calendar.txt](#calendartxt) で定義されているデフォルトのサービス パターンの例外を定義します。サービスが通常定期的で、明示的な日付にいくつかの変更がある場合 (たとえば、特別なイベント サービスや学校のスケジュールに対応するため)、これは適切なアプローチです。この場合、 `calendar_dates.service_id`は`calendar.service_id`を参照する外部IDです。 +* 代替: [calendar.txt](#calendartxt) を省略し、[calendar_dates.txt](#calendar_datestxt) で各サービスのdateを指定します。これにより、かなりのサービスバリエーションが可能になり、通常の週次スケジュールのないサービスに対応できます。この場合、 `service_id`はIDです。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `service_id` | `calendar.service_id`部` IDまたはID | **必須** | 1 つ以上のルートでサービス例外が発生する日付のセットを識別します。 [calendar_dates.txt](#calendartxt) と [calendar_dates.txt](#calendar_datestxt) を併用する場合、各 ( `service_id`、`date `service_id` ) ペアは [calendar.txt](#calendartxt) と [calendar_dates.txt](#calendar_datestxt) の両方に出現する場合、[calendar_dates.txt](#calendar_datestxt) の情報によって [calendar.txt](#calendartxt) で指定されたサービス情報が変更されます。| +| `date` | 日付 | **必須** | サービス例外が発生した日付。| +| `exception_type` | 列挙型 | **必須** |dateフィールドで指定されたdateにサービスが利用可能かどうかを示します。有効なオプションは次のとおりです。

`1` - 指定されたdateにサービスが追加されました。
`2` - 指定されたdateのサービスが削除されました。
*例: ルートに休日に利用できる一連の旅行と、それ以外の日に利用できる一連の旅行があるとします。1 つの`service_id` が通常のサービス スケジュールに対応し、別の`service_id` が休日スケジュールに対応します。特定の休日については、[calendar_dates.txt](#calendar_datestxt) ファイルを使用して休日を休日`service_id`に追加し、通常の`service_id`スケジュールから休日を削除できます。* | + +### fare_attributes.txt + +ファイル: **任意** + +主キー(`fare_id`) + +**バージョン**
+運賃を記述するためのモデル化オプションは2つあります。GTFS-運賃V1は、最小限の運賃情報を記述するための従来のオプションです。GTFS-運賃V2は、機関の運賃構造をより詳細に記述できる更新された方法です。どちらも広告に表示できます。 + +ataset ですが、特定のデータセットに対してデータ コンシューマーが使用する方法は 1 つだけです。GTFS-Fares V2 を GTFS- 運賃V1よりも優先することをお勧めします。

GTFS- 運賃V1に関連付けられているファイルは次のとおりです。
- [fare_attributes.txt](#運賃属性txt)
- [fare_rules.txt](#運賃規則txt)

GTFS-Fares V2 に関連付けられているファイルは次のとおりです。
- [fare_media.txt](#fare_mediatxt)
- [fare_products.txt](#fare_productstxt)
- [fare_leg_rules.txt](#運賃規則txt)
- [fare_transfer_rules.txt](#運賃振替ルールtxt) + +
+ +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `fare_id` |ユニーク ID | **必須** | 運賃クラスを識別します。 | +| `price` | 負でないfloat| **必須** | `currency_type`で指定された単位の運賃。 | +| `currency_type` | 通貨コード | **必須** | 運賃の支払いに使用する通貨。 | +| `payment_method` | 列挙型 | **必須** | 運賃を支払う必要がある時期を示します。有効なオプションは次のとおりです。

`0` - 運賃は乗車時に支払われます。
`1` - 乗車前に運賃を支払う必要があります。 | +| `transfers` | Enum | **必須** | この運賃で許可される乗り換え回数を示します。有効なオプションは次のとおりです:

`0` - この運賃では乗り換えは許可されません。
`1` - ライダーは 1 回乗り換えることができます。
`2` - ライダーは2回乗り換えることができます。
空 - 無制限の転送が許可されます。 | +| `agency_id` | `agency.agency_id`部` ID | **条件付きで必須** | 運賃の関連代理店を識別します。

条件付きで必須:
- [agency.txt](#agencytxt ) に複数の代理店が定義されている場合は**必須**です。
- それ以外の場合は推奨。 | +| `transfer_duration` | 負でない整数 |任意|`transfers`が期限切れになるまでの時間 (秒単位)。`transfers` =`0` の場合、このフィールドはチケットの有効期間を示すために使用されるか、空のままにすることができます。 | + +### fare_rules.txt + +ファイル: **任意** + +主キー(`*`) + +[fare_rules.txt](#fare_rulestxt) テーブルは、[fare_attributes.txt](#fare_attributestxt) の運賃が旅程にどのように適用されるかを指定します。ほとんどの運賃体系では、次のルールの組み合わせが使用されます。 + +* 運賃は出発駅または到着駅によって異なります。 +* 運賃は、旅程が通過するゾーンによって異なります。 +* 運賃は、旅程が使用するルートによって異なります。 + +[fare_rules.txt](#fare_rulestxt) および [fare_attributes.txt](#fare_attributestxt) を使用して運賃体系を指定する方法を示す例については、GoogleTransitDataFeed オープンソース プロジェクト wiki の [FareExamples](https://web.archive.org/web/20111207224351/https://code.google.com/p/googletransitdatafeed/wiki/FareExamples) をご覧ください。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `fare_id` | `fare_attributes.fare_id`部` ID | **必須** | 運賃クラスを識別します。 | +| `route_id` | `routes.route_id`部` ID |任意| 運賃クラスに関連付けられたルートを識別します。同じ運賃属性を持つルートが複数存在する場合は、ルートごとに [fare_rules.txt](#fare_rulestxt) にレコードを作成します。
*例: 運賃クラス`b`がルート`TSW`と`TSE`で有効な場合、[fare_rules.txt](#fare_rulestxt) ファイルには運賃クラスに関する次のレコードが含まれます。*
` 運賃ID、route_id`
`b,TSW`
`b,TSE`| +| `origin_id` | `stops.zone_id`部` ID |任意| 出発地ゾーンを識別します。運賃クラスに複数の出発地ゾーンがある場合は、[fare_rules.txt](#fare_rulestxt) に各`origin_id`のレコードを作成します。
*例: 運賃クラス`b`がゾーン`2`またはゾーン`8`から出発するすべての旅行に有効な場合、[fare_rules.txt](#fare_rulestxt) ファイルには運賃クラスに関する次のレコードが含まれます。*
`運賃ID,...,原産地ID`
`b,...,2`
`b,...,8` | +| `destination_id` | `stops.zone_id`部` ID |任意| 目的地ゾーンを識別します。運賃クラスに複数の目的地ゾーンがある場合は、[fare_rules.txt](#fare_rulestxt) に各`destination_id`のレコードを作成します。
*例: `origin_id`フィールドと`destination_id`フィールドを一緒に使用して、運賃クラス`b`ン` 3 と 4 の間の旅行に有効であることを指定できます。ゾーン 3 と 5 の間の旅行の場合、[fare_rules.txt](#fare_rulestxt) ファイルには、運賃クラスに関する次のレコードが含まれます。*
`運賃ID、...、出発地ID、目的地ID`
`b,...,3,4`
`b,...,3,5` | +| `contains_id` | `stops.zone_id`部` ID |任意| 特定の運賃クラスを使用しているときに乗客が進入するゾーンを識別します。一部のシステムで正しい運賃クラスを計算するために使用されます。
*例: 運賃クラス`c`ン` 5、6、7 を通過する GRT ルートのすべての旅行に関連付けられている場合、[fare_rules.txt](#fare_rulestxt) には次のレコードが含まれます。*
`fare_id, route_id,...,contains_id`
`c,GRT,...,5`
`c,GRT,...,6`
`c,GRT,...,7`
*運賃を適用するには、すべての`contains_id`ゾーンが一致している必要があるため、ゾーン 5 と 6 は通過するがゾーン 7 は通過しない旅程には運賃クラス`c`はありません。詳細については、GoogleTransitDataFeed プロジェクト wiki の [https://code.google.com/p/googletransitdatafeed/wiki/FareExamples](https://code.google.com/p/googletransitdatafeed/wiki/FareExamples) をご覧ください。* | + +### timeframes.txt + +ファイル: **任意** + +主キー(`*`) + +時間帯、曜日、または特定の日に基づいて変動する運賃を記述するために使用されます。タイムフレームは、[fare_leg_rules.txt](#fare_leg_rulestxt) で運賃商品に関連付けることができます。
+同じ`timeframe_group_id`値と`service_id`値に重複する時間間隔があってはなりません。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `timeframe_group_id` | ID | **必須** | 時間枠または時間枠のセットを識別します。| +| `start_time` | 時間 | **条件付きで必須** | 時間枠の開始を定義します。間隔には開始時刻が含まれます。
`24:00:00` より大きい値は禁止されています。`start_time` の値が空の`start_time`は `00:00:00` とみなされます。

条件付きで必須:
- ** `timeframes.end_time`が定義されている場合は必須。
- **それ以外の場合は禁止** | +| `end_time` | 時間 | **条件付きで必須** | 時間枠の終了を定義します。間隔には終了時刻は含まれません。
`24:00:00` より大きい値は禁止されています。`end_time` の値が空の`end_time`は `24:00:00` とみなされます。

条件付きで必須:
- ** `timeframes.start_time`が定義されている場合は必須。
- それ以外の場合は**禁止** | +| `service_id` | `calendar.service_id`または`calendar_dates.service_id`部` ID | **必須** | タイムフレームが有効な日付のセットを識別します。 | + +#### タイムフレームのローカル時間セマンティクス +- 運賃イベントの時間を [timeframes.txt](#timeframestxt) に対して評価する場合、イベント時間は、運賃イベントの停車駅または親駅の`stop_timezone`(指定されている場合) によって決定されるローカル タイムゾーンを使用してローカル時間で計算されます。指定されていない場合は、フィードの代理店のタイムゾーンを代わりに使用する必要があります。 +- `現在の日`は、ローカル タイムゾーンを基準に計算された運賃イベントの時間の現在のdateです。 `当日`は、特に深夜を過ぎる旅行の場合、運賃区間の旅行のサービス日とは異なる場合があります。 +- 運賃イベントの`時刻`は、GTFS 時間フィールドタイプのセマンティクスを使用して、`当日`を基準として計算されます。 + +### fare_media.txt + +ファイル: **任意** + +主キー(`fare_media_id`) + +運賃商品の使用に使用できるさまざまな運賃メディアを説明します。運賃メディアは、運賃商品の表示や検証に使用される物理的または仮想的なホルダーです。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `fare_media_id` |ユニーク ID | **必須** | 運賃メディアを識別します。| +| `fare_media_name` |Text|任意| 運賃メディアの名前。

交通カード (`fare_media_type =2`) またはモバイル アプリ (`fare_media_type =4`) などの運賃メディアの場合、 `fare_media_name`を含める必要があり、それを配信する組織が使用する乗客向けの名前と一致する必要があります。 | +| `fare_media_type` | Enum | **必須** | 運賃メディアのタイプ。有効なオプションは次のとおりです。

`0` - なし。物理的なチケットが提供されずに運転手または車掌に現金で支払うなど、運賃商品の購入または検証に運賃媒体が関与しない場合に使用されます。
`1` - 乗客が一定期間内に、事前に購入した一定数の旅行、または無制限の旅行のいずれかを利用できる物理的な紙のチケット。
`2` - チケット、パス、または金銭的価値が保存されている物理的な交通カード。
`3` - アカウントベースのチケット発行用のオープンループ トークン コンテナとしての cEMV (非接触型 Europay、Mastercard、Visa)。
`4` - 仮想交通カード、チケット、パス、または金銭的価値を保存したモバイル アプリ。| + +### fare_products.txt + +ファイル: **任意** + +主キー(`fare_product_id`、 `fare_media_id`) + +乗客が購入可能な運賃の範囲を記述したり、乗り換えコストなど、複数の区間を含む旅程の合計運賃を計算するときに考慮したりするために使用されます。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `fare_product_id` | ID | **必須** | 運賃商品または運賃商品のセットを識別します。

[fare_products.txt](#fare_productstxt) 内の複数のレコードが同じ`fare_product_id`を共有する場合があります。その場合、別のファイルから参照されたときに、そのIDを持つすべてのレコードが取得されます。

複数のレコードが同じ`fare_product_id`を共有していても、異なる`fare_media_id`を持つ場合があります。これは、運賃商品を使用するために利用できるさまざまな方法 (潜在的に異なる価格) を示します。| +| `fare_product_name` |Text|任意| 乗客に表示される運賃商品の名前。| +| `fare_media_id` | `fare_media.fare_media_id`部` ID |任意| 旅行中に運賃商品を使用するために使用できる運賃メディアを識別します。`fare_media_id` が空の場合、運賃メディアは不明であると見なされます。| +| `amount` | 通貨金額 | **必須** | 運賃商品のコスト。乗り継ぎ割引を表す場合は負の値になる場合があります。無料の運賃商品を表す場合はゼロになる場合があります。| +| `currency` | 通貨コード | **必須** | 運賃商品のコストの通貨。 | + + +### fare_leg_rules.txt + +ファイル: **任意** + +主キー(`network_id, from_area_id, to_area_id, from_timeframe_group_id, to_timeframe_group_id, fare_product_id`) + +旅行の各区間の運賃規則。 + + [`fare_leg_rules.txt`](#fare_leg_rulestxt) の運賃は、乗客が移動する区間に一致する規則を見つけるために、ファイル内のすべてのレコードをフィルタリングして照会する必要があります。 + +区間のコストを処理するには: + + 1.ファイル [fare_leg_rules.txt](#fare_leg_rulestxt) は、旅行の特性を定義するフィールドでフィルタリングする必要があります。これらのフィールドは次のとおりです: + - `fare_leg_rules.network_id` + - `fare_leg_rules.from_area_id` + - `fare_leg_rules.to_area_id` + - `fare_leg_rules.from_timeframe_group_id` + - `fare_leg_rules.to_timeframe_group_id` +
+ + 2.旅行の特性に基づいて、区間が [fare_leg_rules.txt](#fare_leg_rulestxt) のレコードと完全に一致する場合、そのレコードを処理して区間のコストを決定する必要があります。このファイルは、空のエントリを 2 つの方法で処理します: 空のセマンティクスまたはルールの優先順位。 +
+ + 3.完全一致が見つからず、`rule_priority` フィールドが存在しない場合は、 `fare_leg_rules.network_id`、 `fare_leg_rules.from_area_id`、および`fare_leg_rules.to_area_id`の空のエントリをチェックして、区間のコストを処理する必要があります。 + - `fare_leg_rules.network_id`の空のエントリは、[routes.txt](#routestxt) または [networks.txt](#networkstxt) で定義されているすべてのネットワークに対応しますが、 `fare_leg_rules.network_id`の下にリストされているネットワークは除きます。 + + - `fare_leg_rules.from_area_id`の空のエントリは、 `areas.area_id`で定義されているすべてのエリアに対応しますが、`fare_leg_rules.from_area_id`の下にリストされているエリアは除きます。 + - 空の`fare_leg_rules.to_area_id`のエントリは、 `fare_leg_rules.to_area_id`の下にリストされているものを除いて、 `areas.area_id`で定義されているすべてのエリアに対応します +
+ + 4. `rule_priority` フィールドが存在する場合、 + - `fare_leg_rules.network_id`のエントリが空の場合、区間のネットワークはこのルールのマッチングには影響しません。 + - `fare_leg_rules.from_area_id`のエントリが空の場合、区間の出発エリアはこのルールのマッチングには影響しません。 + - `fare_leg_rules.to_area_id`のエントリが空の場合、区間の到着エリアはこのルールのマッチングには影響しません。 +
+ + 5.区間が上記の規則のいずれにも一致しない場合は、運賃は不明です。 + +
+ +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `leg_group_id` | ID |任意| [fare_leg_rules.txt](#fare_leg_rulestxt) 内のエントリのグループを識別します。

`fare_transfer_rules.from_leg_group_id`と`fare_transfer_rules.to_leg_group_id`間の運賃振替ルールを記述するために使用されます。

[fare_leg_rules.txt](#fare_leg_rulestxt) 内の複数のエントリが同じ`fare_leg_rules.leg_group_id`に属している場合があります。

[fare_leg_rules.txt](#fare_leg_rulestxt) 内の同じエントリ ( `fare_leg_rules.leg_group_id`は含まない) は、複数の`fare_leg_rules.leg_group_id`に属してはなりません。| +| `network_id` | ` `routes.network_id`または`networks.network_id`部` ID |任意| 運賃区間ルールに適用されるルート ネットワークを識別します。

`rule_priority` フィールドが存在せず、フィルタリングされている`network_id`に一致する`fare_leg_rules.network_id`値がない場合、デフォルトで空の`fare_leg_rules.network_id`が一致します。

`fare_leg_rules.network_id`の空のエントリは、[routes.txt](#routestxt) または [networks.txt](#networkstxt) で定義されているすべてのネットワークに対応しますが、 `fare_leg_rules.network_id`の下にリストされているネットワークは除きます。

ファイルに `rule_priority` フィールドが存在する場合、空の`fare_leg_rules.network_id`は、区間のルート ネットワークがこのルールのマッチングに影響しないことを示します。 | +| `from_area_id` | `areas.area_id`部` ID |任意| 出発エリアを識別します。

`rule_priority` フィールドが存在せず、フィルタリングされている`area_id`に一致する`fare_leg_rules.from_area_id`値がない場合、デフォルトで空の`fare_leg_rules.from_area_id`が一致します。

`fare_leg_rules.from_area_id`の空のエントリは、 `fare_leg_rules.from_area_id`の下にリストされているものを除く、 `areas.area_id`で定義されているすべてのエリアに対応します。

ファイルに `rule_priority` フィールドが存在する場合、空の`fare_leg_rules.from_area_id`は、区間の出発エリアがこのルールのマッチングに影響しないことを示します。 | +| `to_area_id` | `areas.area_id`部` ID |任意| 到着エリアを識別します。

`rule_priority` フィールドが存在せず、フィルタリングされている`area_id`に一致する`fare_leg_rules.to_area_id`値がない場合、デフォルトで空の`fare_leg_rules.to_area_id`が一致します。

`fare_leg_rules.to_area_id`の空のエントリは、 `fare_leg_rules.to_area_id`の下にリストされているものを除く、 `areas.area_id`で定義されているすべてのエリアに対応します。

ファイルに `rule_priority` フィールドが存在する場合、空の`fare_leg_rules.to_area_id`は、区間の到着エリアがこのルールのマッチングに影響しないことを示します。 | +| `from_timeframe_group_id` | `timeframes.timeframe_group_id`部` ID |任意| 運賃区間の開始時に運賃検証イベントのタイムフレームを定義します。

運賃区間の`開始時間`は、イベントの発生が予定されている時間です。たとえば、乗客が乗車して運賃を確認する運賃区間の開始時のバスの予定出発時刻がその時間になります。以下のルール マッチング セマンティクスでは、開始時間は [timeframes.txt](#timeframestxt) の [ローカル時間セマンティクス](#timeframe-local-time-semantics) によって決定されるローカル時間で計算されます。運賃区間の出発イベントの停留所または駅は、必要に応じてタイムゾーン解決に使用する必要があります。

`from_timeframe_group_id`を指定する運賃区間ルールの場合、[timeframes.txt](#timeframestxt) に以下の条件がすべて満たされるレコードが少なくとも 1 つ存在する場合、そのルールは特定の区間と一致します。
- `timeframe_group_id`の値は`from_timeframe_group_id`の値と同じです。
- レコードの`service_id`によって識別される日のセットには、運賃区間の開始時刻の`現在の日`が含まれます。
- 運賃区間の開始時間の`時刻`は、レコードの`timeframes.start_time`値以上であり、 `timeframes.end_time`値未満です。

空の`fare_leg_rules.from_timeframe_group_id`は、区間の開始時刻がこのルールの一致に影響しないことを示します。 | +| `to_timeframe_group_id` | `timeframes.timeframe_group_id`部` ID |任意| 運賃区間の終了時の運賃検証イベントの期間を定義します。

運賃区間の`終了時間`は、イベントの発生が予定されている時間です。たとえば、乗客が降りて運賃を確認する運賃区間の終了時にバスが到着する予定の時刻が、その時間になります。以下のルール マッチング セマンティクスでは、終了時間は [timeframes.txt](#timeframestxt) の [ローカル時間セマンティクス](#timeframe-local-time-semantics) によって決定されるローカル時間で計算されます。運賃区間の到着イベントの停留所または駅は、必要に応じてタイムゾーン解決に使用する必要があります。

`to_timeframe_group_id`を指定する運賃区間ルールの場合、[timeframes.txt](#timeframestxt) に以下の条件がすべて満たされるレコードが少なくとも 1 つ存在する場合、そのルールは特定の区間と一致します。
- `timeframe_group_id`の値は`to_timeframe_group_id`の値と同じです。
- レコードの`service_id`によって識別される日のセットには、運賃区間の終了時刻の`現在の日`が含まれます。
- 運賃区間の終了時間の`時刻`は、レコードの`timeframes.start_time`値以上であり、 `timeframes.end_time`値未満です。

空の`fare_leg_rules.to_timeframe_group_id`は、区間の終了時刻がこのルールの一致に影響しないことを示します。 | +| `fare_product_id` | `fare_products.fare_product_id`部` ID | **必須** | 区間を旅行するために必要な運賃商品。 | +| `rule_priority` | 負でない整数 |任意| 一致ルールが区間に適用される優先順位を定義し、特定のルールが他のルールよりも優先されるようにします。 `fare_leg_rules.txt`内の複数のエントリが一致する場合、`rule_priority` の値が最も高いルールまたはルール セットが選択されます。

`rule_priority` の値が空の場合、ゼロとして扱われます。 | + +### fare_transfer_rules.txt + +ファイル: **任意** + +主キー(`from_leg_group_id, to_leg_group_id, fare_product_id, transfer_count, duration_limit`) + +[`fare_leg_rules.txt`](#fare_leg_rulestxt) で定義された旅行区間間の乗り換えの運賃規則。 + +複数区間の旅程の費用を処理するには: + + 1. `fare_leg_rules.txt`で定義された適用可能な運賃区間グループは、乗客の旅程に基づいて、すべての個々の旅行区間に対して決定する必要があります2.ファイル [fare_transfer_rules.txt](#fare_transfer_rulestxt) は、乗り換えの特性を定義するフィールドでフィルタリングする必要があります。これらのフィールドは次のとおりです: + - `fare_transfer_rules.from_leg_group_id` + - `fare_transfer_rules.to_leg_group_id`
+
+ + 3.乗り換えの特性に基づいて、乗り換えが [fare_transfer_rules.txt](#fare_transfer_rulestxt) のレコードと完全に一致する場合、そのレコードを処理して乗り換えコストを決定する必要があります。 + 4.完全に一致するものが見つからない場合は、乗り換えコストを処理するために、 `from_leg_group_id`または`to_leg_group_id`の空のエントリを確認する必要があります。 + - `fare_transfer_rules.from_leg_group_id`の空のエントリは、 `fare_leg_rules.leg_group_id`で定義されているすべての区間グループに対応しますが、 `fare_transfer_rules.from_leg_group_id`にリストされているものを除きます。 + - `fare_transfer_rules.to_leg_group_id`の空のエントリは、`fare_leg_rules.leg_group_id` で定義されているすべての区間グループに対応しますが、 `fare_leg_rules.leg_group_id`にリストされているものを除きます。 `fare_transfer_rules.to_leg_group_id`
+
+ 5.移籍が上記のいずれの規則にも該当しない場合は、移籍の取り決めはなく、各レグは別個のものとみなされます。 + +
+ +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `from_leg_group_id` | `fare_leg_rules.leg_group_id`部` ID |任意| 転送前の運賃区間ルールのグループを識別します。

フィルタリングされている`leg_group_id`に一致する`fare_transfer_rules.from_leg_group_id`値がない場合、デフォルトで空の`fare_transfer_rules.from_leg_group_id`が一致します。

`fare_transfer_rules.from_leg_group_id`の空のエントリは、`fare_leg_rules.leg_group_id`にリストされているものを除く、 `fare_transfer_rules.from_leg_group_id`で定義されているすべての区間グループに対応します | +| `to_leg_group_id` | `fare_leg_rules.leg_group_id`部` ID |任意| 転送後の運賃区間ルールのグループを識別します。

フィルタリングされている`leg_group_id`に一致する`fare_transfer_rules.to_leg_group_id`値がない場合、デフォルトで空の`fare_transfer_rules.to_leg_group_id`が一致します。

`fare_transfer_rules.to_leg_group_id`の空のエントリは、`fare_transfer_rules.to_leg_group_id` にリストされているものを除く、 `fare_transfer_rules.to_leg_group_id`で定義されているすべての区間グループに対応します | +| `transfer_count` | ゼロ以外の整数 | **条件付きで禁止** | 乗り換えルールを適用できる連続乗り換えの数を定義します。

有効なオプションは次のとおりです。
`-1` - 制限なし。
`1`以上 - 転送ルールが適用される転送の数を定義します。

サブジャーニーが異なる`transfer_count`を持つ複数のレコードと一致する場合、サブジャーニーの現在の転送カウント以上の最小`transfer_count`を持つルールが選択されます。

条件付きで禁止:
- `fare_transfer_rules.from_leg_group_id`が`fare_transfer_rules.to_leg_group_id`と等しくない場合は**禁止**です。
- **必須** `fare_transfer_rules.from_leg_group_id`が`fare_transfer_rules.to_leg_group_id`と等しい場合。 | +| `duration_limit` | 正の整数 |任意| 乗り換えの期間制限を定義します。

秒単位の整数増分で表現するしなければならない。

期間制限がない場合は、 `fare_transfer_rules.duration_limit`は空にする必要があります。 | +| `duration_limit_type` | 列挙型 | **条件付きで必須** | `fare_transfer_rules.duration_limit`の相対的な開始と終了を定義します。

有効なオプションは次のとおりです。
`0` - 現在の区間の出発運賃の検証と次の区間の到着運賃の検証の間。
`1` - 現在の区間の出発運賃の検証と次の区間の出発運賃の検証の間。
`2` - 現在の区間の到着運賃の検証と次の区間の出発運賃の検証の間。
`3` - 現在の区間の到着運賃の検証と次の区間の到着運賃の検証の間。

条件付きで必須:
- ** `fare_transfer_rules.duration_limit`が定義されている場合は必須。
- `fare_transfer_rules.duration_limit`が空の場合は**禁止**です。 | +| `fare_transfer_type` | 列挙型 | **必須** | 旅程中の区間間の乗り換えのコスト処理方法を示します。
![](../../assets/2-leg.svg)
有効なオプションは次のとおりです。
`0` - 出発区間`fare_leg_rules.fare_product_id`と`fare_transfer_rules.fare_product_id`を加算したもの。A + AB。
`1` - 出発区間の`fare_leg_rules.fare_product_id`と`fare_transfer_rules.fare_product_id`と到着区間の`fare_leg_rules.fare_product_id`を加算します。A + AB + B。
`2` - `fare_transfer_rules.fare_product_id`; AB.

旅程中の複数の転送間のコスト処理のやり取り:
![](../../assets/3-leg.svg)
`fare_transfer_type`処理A > B処理B > C
`0` A + A +B プラスS + BC
`1` A + AB + B S + BC + C
`2` AB S + BC
ここで、S は、前の区間と乗り換えの合計処理コストを示します。 | +| `fare_product_id` | `fare_products.fare_product_id`部` ID |任意| 2 つの運賃区間間の乗り換えに必要な運賃商品。空の場合、乗り換えルールのコストは 0 です。| + + +### areas.txt + +ファイル: **任意** + +主キー(`area_id`) + +エリア識別子を定義します。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `area_id` |ユニーク ID | **必須** | エリアを識別します。[areas.txt](#areastxt) 内で一意であるしなければならない。 | +| `area_name` |Text| **任意** | 乗客に表示されるエリアの名前。 | + +### stop_areas.txt + +ファイル: **任意** + +主キー(`*`) + +[stops.txt](#stopstxt) からエリアに停留所を割り当てます。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `area_id` | `areas.area_id`部` ID | **必須** | 1 つまたは複数の`stop_id`が属するエリアを識別します。同じ`stop_id` が複数の`area_id`で定義される場合があります。 | +| `stop_id` | `stops.stop_id`部` ID | **必須** | 停留所を識別します。このフィールドで駅（つまり、 `stops.location_type=1`の停留所）が定義されている場合、そのすべてのプラットフォーム（つまり、この駅が ` `stops.parent_station` `stops.location_type=0`のすべての停留所）は同じエリアの一部であると見なされます。この動作は、プラットフォームを他のエリアに割り当てることで上書きできます。 | + +### networks.txt + +ファイル: **条件付きで禁止** + +主キー(`network_id`) + +運賃区間ルールに適用されるネットワーク識別子を定義します。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `network_id` |ユニーク ID | **必須** | ネットワークを識別します。[networks.txt](#networkstxt) 内で一意であるしなければならない。 | +| `network_name` |Text| **任意** |運賃区間の規則に適用されるネットワークの名前。これは、地方機関とその乗客によって使用されます。 + +### route_networks.txt + +ファイル: **条件付きで禁止** + +主キー(`route_id`) + +[routes.txt](#routestxt) からのルートをネットワークに割り当てます。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `network_id` | `networks.network_id`部` ID | **必須** | 1 つまたは複数の`route_id`が属するネットワークを識別します。`route_id` は、1 つの`network_id`でのみ定義できます。| +| `route_id` | `routes.route_id`部` ID | **必須** | ルートを識別します。 | + +### shapes.txt + +ファイル: **任意** + +主キー(`shape_id`、 `shape_pt_sequence`) + +ルート形状は、車両がルート線形に沿って移動するパスを説明し、ファイルshapes.txtで定義されます。ルート形状は便に関連付けられ、車両が順番に通過する一連のポイントで構成されます。ルート形状は停留所等の位置を正確にインターセプトする必要はありませんが、トリップのすべての停留所等は、そのトリップのシェイプからわずかな距離内、つまりシェイプポイントを接続する直線セグメントの近くに配置する必要があります。 shapes.txtファイルは、すべてのルートベースのサービス (ゾーンベースのデマンドレスポンシブサービスではありません) に含める必要があります。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `shape_id` | ID | **必須** | シェイプを識別します。 | +| `shape_pt_lat` |緯度 | **必須** | シェイプ ポイントの緯度。[shapes.txt](#shapestxt) 内の各レコードは、シェイプを定義するために使用されるシェイプ ポイントを表します。| +| `shape_pt_lon` | 経度 | **必須** | シェイプ ポイントの経度。| +| `shape_pt_sequence` | 負でない整数 | **必須** | シェイプ ポイントが接続してシェイプを形成するシーケンス。値は移動に沿って増加する必要がありますが、連続している必要はありません。
*例: 図形`A_shp`に` 3 つの点がある場合、[shapes.txt](#shapestxt) ファイルには図形を定義する次のレコードが含まれる可能性があります。*
`shape_id、shape_pt_lat、shape_pt_lon、shape_pt_sequence`
`A_shp,37.61956,-122.48161,0`
`A_shp,37.64430,-122.41070,6`
`A_shp,37.65863,-122.30839,11` | +| `shape_dist_traveled` | 非負のfloat|任意| 最初のシェイプ ポイントからこのレコードで指定されたポイントまでのシェイプに沿った実際の移動距離。旅行計画者がマップ上にシェイプの正しい部分を表示するために使用します。値は`shape_pt_sequence`とともに増加する必要があります。ルートに沿った逆方向の移動を示すために使用してはなりません。距離の単位は [stop_times.txt](#stop_timestxt) で使用されている単位と一致している必要があります。

ループまたはインライン (車両が 1 回の移動で同じ線形部分を横断または移動する) があるルートに推奨。

車両が後退したり、 + +旅行の途中でルートの線形を横切るポイントがある場合、 `shape_dist_traveled` は、[shapes.txt](#shapestxt) 内のポイントの並び方が [stop_times.txt](#stop_timestxt) 内のレコードとどのように対応しているかを明確にするために重要です。
*例: バスが上記で A_shp に定義された 3 つのポイントに沿って移動する場合、追加の`shape_dist_traveled`値 (ここではキロメートル単位で表示) は次のようになります。*
`shape_id、shape_pt_lat、shape_pt_lon、shape_pt_sequence、shape_dist_traveled`
`A_shp,37.61956,-122.48161,0,0`
`A_shp,37.64430,-122.41070,6,6.8310`
`A_shp,37.65863,-122.30839,11,15.8765` | + +### frequencies.txt + +ファイル: **任意** + +主キー(`trip_id`、 `start_time`) + +[Frequencies.txt](#frequenciestxt) は、一定のヘッドウェイ (旅行間の時間) で動作する旅行を表します。このファイルは、2 つの異なるタイプのサービスを表すために使用できます。 + +* 頻度ベースのサービス (`exact_times`=`0`)。このサービスでは、サービスは 1 日を通して固定のスケジュールに従いません。代わりに、オペレーターは旅行に対して事前に決定されたヘッドウェイを厳密に維持しようとします。 +* スケジュール ベースのサービス (`exact_times`= `1`) の圧縮表現。指定された期間の旅行に対してまったく同じヘッドウェイを持ちます。スケジュール ベースのサービスでは、オペレーターはスケジュールに厳密に従おうとします。 + + +| フィールド名 | タイプ |存在 | 説明 | +|------|------|------|------| +| `trip_id` | ` `trips.trip_id`部` ID | **必須** | 指定されたサービス間隔が適用される旅行を識別します。 | +| `start_time` | 時間 | **必須** | 最初の車両が指定された間隔で旅行の最初の停車地から出発する時刻。 | +| `end_time` | 時間 | **必須** | 旅行の最初の停車地でサービスが別の間隔に変更される (または停止する) 時刻。 | +| `headway_secs` | 正の整数 | **必須** | `start_time`と`end_time`で指定された時間間隔中に、旅行の同じ停車地 (間隔) から出発する間隔 (秒単位)。同じ旅行に複数の間隔を定義できますが、重複することはできません。新しい運行間隔は、前の運行間隔が終了した正確な時間に開始される場合があります。 | +| `exact_times` | 列挙型 |任意| 旅行のサービスの種類を示します。詳細については、ファイルの説明を参照してください。有効なオプションは次のとおりです。

`0` または空 - 頻度ベースの旅行。
`1` - 一日を通してまったく同じヘッドウェイのスケジュールベースの旅行。この場合、 `end_time`値は、最後の希望旅行`start_time`より大きく、最後の希望旅行 start_time + `headway_secs`より小さくする必要があります。| + +### transfers.txt + +ファイル: **任意** + +主キー(`from_stop_id`、 `to_stop_id`、 `from_trip_id`、 `to_trip_id`、 ` `from_route_id`、 `to_route_id`) + +旅程を計算する際、GTFS を使用するアプリケーションは、許容される時間と停留所の近接性に基づいて乗り換えを補間します。 [Transfers.txt](#transferstxt) は、選択した乗り換えに対する追加のルールとオーバーライドを指定します。 + +`from_trip_id`、 `to_trip_id`、 `from_route_id` 、および`to_route_id` を使用すると、乗り換えルールの詳細度をさらに高めることができます。 `from_stop_id`と`to_stop_id`に加えて、詳細度の順位付けは次のようになります: + + 1.両方の`trip_id`が定義されています: `from_trip_id`と`to_trip_id`。 + 2. 1 つの`trip_id`と`route_id`セットが定義されています: (`from_trip_id`と`to_route_id`) または (`from_route_id`と`to_trip_id`) 。 + 3. 1 つの`trip_id`が定義されています: `from_trip_id`または`to_trip_id`。 + 4.両方の`route_id`が定義されています: `from_route_id`と`to_route_id`。 + 5. 1 つの`route_id`が定義されています: `from_route_id`または`to_route_id`。 + 6..`from_stop_id`および`to_stop_id`が定義されています: ルートまたは旅行関連のフィールドは設定されていません。 + +到着旅行と出発旅行の順序付けられたペアが指定されている場合、これら 2 つの旅行間に適用される最も詳細度の高い乗り換えが選択されます。どの旅行のペアにも、適用可能な最大詳細度が同等の 2 つの乗り換えが存在することはできません。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `from_stop_id` | ` `stops.stop_id`部` ID | **条件付きで必須** | ルート間の接続が開始される停留所または駅を識別します。このフィールドが駅を参照する場合、乗り換えルールはそのすべての子停留所に適用されます。`transfer_types` 4 および5.では駅の参照は禁止されています。| +| `to_stop_id` | `stops.stop_id`部` ID | **条件付きで必須** |ルート間の接続が終了する停留所または駅を識別します。このフィールドが駅を参照する場合、転送ルールはすべての子停留所に適用されます。`transfer_types` 4 および5.では、駅の参照は禁止されています。| +| `from_route_id` | `routes.route_id`部` ID |任意| 接続が始まるルートを識別します。

`from_route_id`が定義されている場合、乗り換えは指定された`from_stop_id`のルート上の到着旅行に適用されます。

`from_trip_id`と`from_route_id` の両方が定義されている場合、 `trip_id` は`route_id`に属している必要があり、 `from_trip_id`が優先されます。 | +| `to_route_id` | `routes.route_id`部` ID |任意| 接続が終了するルートを識別します。

`to_route_id`が定義されている場合、乗り換えは指定された`to_stop_id`のルートの出発便に適用されます。

`to_trip_id`と`to_route_id` の両方が定義されている場合、 `trip_id` は`route_id`に属している必要があり、 `to_trip_id`が優先されます。 | +| `from_trip_id` | `trips.trip_id`部` ID | **条件付きで必須** | ルート間の接続が始まる旅行を識別します。

`from_trip_id`が定義されている場合、乗り換えは指定された`from_stop_id`の到着旅行に適用されます。

`from_trip_id`と`from_route_id`の両方が定義されている場合、 `trip_id` は`route_id`に属している必要があり、 `from_trip_id`が優先されます。 `transfer_type`が `4` または `5` の場合は必須。 | +| `to_trip_id` | `trips.trip_id`部` ID | **条件付きで必須** | ルート間の接続が終了する旅行を識別します。

`to_trip_id`が定義されている場合、乗り換えは指定された`to_stop_id`の出発旅行に適用されます。

`to_trip_id`と`to_route_id`の両方が定義されている場合、 `trip_id` は`route_id`に属している必要があり、 `to_trip_id`が優先されます。 `transfer_type`が `4` または `5` の場合は必須。 | +| `transfer_type` | Enum | **必須** | 指定された (`from_stop_id`、 `to_stop_id`) ペアの接続タイプを示します。有効なオプションは次のとおりです。

`0` または空 - ルート間の推奨乗り換えポイント。
`1` - 2 つのルート間の時間指定の乗り換えポイント。出発車両は到着車両を待機し、乗客がルート間を乗り換えるのに十分な時間を残すことが求められます。
`2` - 乗り継ぎを確実に行うには、到着から出発までの間に最低限の時間が必要です。乗り継ぎに必要な時間は`min_transfer_time`で指定します。
`3` - その場所ではルート間の乗り換えはできません。
`4` - 乗客は同じ車両に乗車したまま、ある旅行から別の旅行へ乗り換えることができます (`座席内乗り換え`)。このタイプの乗り換えの詳細については、[以下](#linked-trips) を参照してください。
`5` - 連続する旅行間での座席内乗り換えは許可されません。乗客は車両から降りて再び乗車する必要があります。このタイプの乗り換えの詳細については、[下記](#linked-trips)を参照してください。 | +| `min_transfer_time` | 負でない整数 |任意| 指定された停留所でルート間の乗り換えを許可するために必要な時間 (秒単位)。`min_transfer_time` は、各ルートのスケジュール変更に対応するためのバッファ時間を含め、一般的な乗客が 2 つの停留所間を移動するのに十分な時間である必要があります。 | + +#### リンク`min_transfer_time`れた旅行 + +以下は、座席内乗り換えの有無にかかわらず、旅行をリンクするために使用される `transfer_type=4` および `=5` に適用されます。 + +リンクされた旅行は、同じ車両で運行されるしなければならない。車両は、他の車両と連結することも、連結を解除することもしてもよい。 + +リンクされたトリップ転送と block_id の両方が提供され、矛盾する結果が生成される場合は、リンクされたトリップ転送を使用する必要があります。 + +`from_trip_id` の最後の停車地は、 `from_trip_id` `to_trip_id`の最初の停車地に地理的に近いするべきであるがあり、 `from_trip_id`の最後の到着時刻は、` `to_trip_id`の最初の出発時刻より前であるが近いするべきである。`to_trip_id` トリップが次の運行日に発生する場合、 `from_trip_id`の最後の到着時刻は、`to_trip_id` `to_trip_id`の最初の出発時刻より遅くてもかまいしてもよい。 + + 通常の場合、便は1 対 1 でリンクできしてもよいが、より複雑なトリップの継続を表すために、1 対 n、n 対 1、または n 対 n でリンクすることもしてもよい。たとえば、2 つの列車の旅程 (下の図の旅程 A と旅程 B) は、共通の駅で車両連結操作を行った後、1 つの列車の旅程 (旅程 C) に統合できます。 + +- 1 対 n の継続では、各`to_trip_id`の`trips.service_id`は同一であるしなければならないがあります。 +- n 対 1 の継続では、各`from_trip_id`の`trips.service_id`は同一であるしなければならない。 +- n 対 n の継続では、両方の制約を尊重する必要があります。 +- `trip.service_id`がどのサービス日でも重複してはしてはいけないという条件で、便は複数の異なる継続の一部としてリンクできます。 + +
 
+旅行 A
+───────────────────\
+                   \    旅行 C
+                     ──────────────
+旅行 B           /
+───────────────────/
+
+ +### pathways.txt + +ファイル: **任意** + +主キー(`pathway_id`) + +ファイル [pathways.txt](#pathwaystxt) と [levels.txt](#levelstxt) は、グラフ表現を使用して地下鉄や電車の駅を記述します。グラフ表現では、ノードが場所を、エッジが経路を表します。 + +駅の出入口 (場所として`location_type=2`で表されるノード) からプラットフォーム (場所として`location_type=0`または空で表されるノード) に移動するには、通路、改札口、階段、および経路として表されるその他のエッジを通過します。汎用ノード (場所として`location_type=3`で表されるノード) は、駅全体の経路を接続するために使用できます。 + +構内通路は、駅内で網羅的に定義する必要があります。経路が定義されている場合は、駅全体のすべての経路が表されているものとみなされます。したがって、次のガイドラインが適用されます: + +- ぶら下がっている場所はありません: 駅内のいずれかの場所に経路がある場合は、その駅内のすべての場所に経路が必要です。ただし、乗車エリア (`location_type=4` 、以下のガイドラインを参照) があるプラットフォームは除きます。 +- 乗車エリアのあるプラットフォームには経路はありません: 乗車エリア ( `location_type= `location_type=4` ) があるプラットフォーム ( `location_type=0`または空) は、ポイントではなく親オブジェクトとして扱われます。このような場合、プラットフォームに経路を割り当ててはなりません。すべての経路は、プラットフォームの各乗車エリアに割り当てる必要があります。 +- ロックされたプラットフォームはありません: 各プラットフォーム ( `location_type=0`または空) または乗車エリア (`location_type=4`) は、経路のチェーンを介して少なくとも 1 つの入口/出口 (`location_type=2`) に接続されている必要があります。特定のプラットフォームから駅の外への経路を許可しない駅はまれです。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `pathway_id` |ユニーク ID | **必須** | 経路を識別します。システムによってレコードの内部識別子として使用されます。データセット内で一意であるしなければならない。

異なる経路では、 `from_stop_id`と`to_stop_id`の値が同一になる場合があります。
_例: 2 つのエスカレーターが反対方向に並んでいる場合、または階段セットとエレベーターが同じ場所から同じ場所に行く場合、異なる`pathway_id` が同じ`from_stop_id`および`to_stop_id`値を持つことがあります。_| +| `from_stop_id` | ` `stops.stop_id`部` ID | **必須** | 経路が始まる場所。

プラットフォーム ( `location_type=0`または空)、入口/出口 (`location_type=2`)、汎用ノード (`location_type=3`)、または乗車エリア (`location_type=4` ) を識別する`stop_id`を含めるしなければならない。

駅を識別する`stop_id`の値 (`location_type=1`) は禁止されています。| +| `to_stop_id` | `stops.stop_id`部` ID | **必須** | 経路が終了する場所。

プラットフォーム ( `location_type=0`または空)、入口/出口 (`location_type=2`)、汎用ノード (`location_type=3`)、または乗車エリア (`location_type=4` ) を識別する`stop_id`を含めるしなければならない。

駅を識別する`stop_id`の値 (`location_type=1`) は禁止されています。| +| `pathway_mode` | 列挙型 | **必須** | 指定された (`from_stop_id`、 `to_stop_id`) ペア間の経路のタイプ。有効なオプションは次のとおりです。

`1` - 歩道。
`2` - 階段。
`3` - 動く歩道/動く歩道。
`4` - エスカレーター。
`5` - エレベーター。
`6` - 改札口 (または支払いゲート): 駅のエリアに渡る通路で、通過するには支払いの証明が必要です。改札口は、駅の有料エリアと無料エリアを分けたり、同じ駅内の異なる支払いエリアを互いに分けたりします。この情報を使用すると、乗客に不要な支払いを要求する近道を使って駅を経由するルートを回避できます。たとえば、バス専用通路に到達するために地下鉄のプラットフォームを歩くように乗客を誘導するなどです。
`7`- 出口ゲート: 有料エリアから、支払い証明がなくても通過できる無料エリアへの通路。| +| `is_bidirectional` | 列挙型 | **必須** | 通路の方向を示します。

`0` - `from_stop_id`から`to_stop_id`までのみ使用できる一方向の経路。
`1` - 両方向に使用できる双方向経路。

出口ゲート (`pathway_mode=7`) は双方向にすることはできません。| +| `length` | 非負のfloat数 |任意| 出発地 ( `from_stop_id`で定義 ) から目的地 ( `to_stop_id`で定義 ) までの経路の水平方向の長さ (メートル単位)。

このフィールドは、歩道 (`pathway_mode=1`)、改札口 (`pathway_mode=6`)、出口ゲート (`pathway_mode=7`) に推奨されます。| +| `traversal_time` | 正の整数 |任意| 出発地 ( `from_stop_id`で定義 ) から目的地 ( `to_stop_id`で定義 ) までの経路を歩くのに必要な平均時間 (秒単位)。

このフィールドは、動く歩道 (`pathway_mode=3`)、エスカレーター (`pathway_mode=4`)、エレベーター (`pathway_mode=5`) に推奨されます。| +| `stair_count` | null 以外の整数 |任意| 通路の階段の数。

`stair_count`が正の場合、乗客は`from_stop_id`から`to_stop_id`まで歩いて上がることを意味します。また、 `stair_count`が負の場合、乗客は`from_stop_id`から`to_stop_id`まで歩いて下がることを意味します。

このフィールドは階段 (`pathway_mode=2`) に推奨されます。

推定階段数しか提供できない場合は、1 フロアあたり 15 段と見積もることをお勧めします。| +| `max_slope` | Float |任意| 通路の最大傾斜率。有効なオプションは次のとおりです。

`0` または空 - 傾斜なし。
`Float` - 経路の傾斜比。上向きの場合は正、下向きの場合は負。

このフィールドは、歩道 (`pathway_mode=1`) および動く歩道 (`pathway_mode=3`) でのみ使用してください。
_例: 米国では、手動車椅子の最大傾斜率は 0.083 (8.3% とも表記) で、1 メートルごとに 0.083 メートル (つまり 8.3 cm) 増加することを意味します。_| +| `min_width` | 正のfloat|任意| 通路の最小幅 (メートル単位)。

最小幅が 1 メートル未満の場合は、このフィールドが推奨されます。| +| `signposted_as` |Text|任意| 乗客に見える物理的な標識からの一般向けのテキスト。

`標識に従ってください`など、乗客にテキストに`singposted_as`指示を提供するために使用できます。`singposted_as` 内のテキストは、標識に印刷されているとおりに表示されます。

物理的な標識が多言語の場合、このフィールドは、`feed_info.feed_lang`のフィールド定義の`stops.stop_name`の例に従って入力および翻訳できます。| +| `reversed_signposted_as` |Text|任意| `signposted_as`と同じですが、経路が`to_stop_id`から`from_stop_id`に使用される場合です。| + +### levels.txt + +ファイル: **条件付きで必須** + +主キー(`level_id`) + +駅の階を説明します。[pathways.txt](#pathwaystxt) と併用すると便利です。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------|------| +| `level_id` |ユニーク ID | **必須** | 駅の階を識別します。| +| `level_index` | Float | **必須** | 相対的な位置を示すレベルの数値インデックス。

地上レベルのインデックスは `0` で、地上レベルは正のインデックスで示され、地下レベルは負のインデックスで示されます。| +| `level_name` |Text|任意| 建物または駅内の乗客から見たレベルの名前。
_例: エレベーターで`中二階`または`プラットフォーム`または`-1`まで行きます。_| + +### location_groups.txt + +ファイル: **任意** + +主キー(`location_group_id`) + +乗客が乗車または降車をリクエストできる停留所のグループである場所グループを定義します。 + +| フィールド名 | タイプ | 存在 | 説明 | +|----------|----|------------|-----------| +| `location_group_id` |ユニーク ID | **必須** | 場所グループを識別します。IDは、すべての`stops.stop_id`、 locations.geojson `id`、および`location_groups.location_group_id`値で一意である必要があります。

ロケーション グループとは、乗客が乗車または降車をリクエストできるロケーションを示す停留所のグループです。 | +| `location_group_name` |Text|任意| 乗客に表示されるロケーション グループの名前。 | + +### location_group_stops.txt + +ファイル: **任意** + +主キー(`*`) + +stops.txt のstops.txtをロケーション グループに割り当てます。 + +| フィールド名 | タイプ | 存在 | 説明 | +|----------|----|------------|-----------| +| `location_group_id` | ` `location_groups.location_group_id`部` ID | **必須** | 1 つまたは複数の`stop_id`ン` グループを識別します。同じ`stop_id` が複数の`location_group_id`で定義される場合があります。 | +| `stop_id` | `stops.stop_id`部` ID | **必須** | 場所グループに属する停留所を識別します。 | + + +### locations.geojson + +ファイル: **任意** + +乗客がオンデマンド サービスによる乗車または降車をリクエストできるゾーンを定義します。これらのゾーンは、GeoJSON ポリゴンとして表されます。 + +- このファイルは、[RFC 7946](https:)で説明されている GeoJSON 形式のサブセットを使用します。 +- `locations.geojson`ファイルには、 `FeatureCollection`が含まれている必要があります。 +- `FeatureCollection`は、乗客が乗車または降車をリクエストできるさまざまな停留所の場所を定義します。 +- すべての GeoJSON `Feature`には`id` が必要です。 `id` は、すべての`stops.stop_id`、 locations.geojson `id`、および`location_group_id`値で一意である必要があります。 +- すべての GeoJSON `Feature`には、次の表に従ってオブジェクトと関連キーが必要です: + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +|- `type` | 文字列 | **必須** | 場所の `"FeatureCollection"`。 | +|- `features` | 配列 | **必須** | 場所を説明する `"Feature"` オブジェクトのコレクション。 | +| \- `type` | 文字列 | **必須** | `"Feature"` | +| \- `id` | 文字列 | **必須** | 場所を識別します。 ID は、すべての`stops.stop_id`、 locations.geojson `id`、および`location_groups.location_group_id`値で一意である必要があります。 | +| \- `properties` | オブジェクト | **必須** | 場所のプロパティ キー。 | +| \- `stop_name` | 文字列 |任意| 乗客に表示される場所の名前を示します。 | +| \- `stop_desc` | 文字列 |任意| 乗客の方向を示すための場所のわかりやすい説明。 | +| \- `geometry` | オブジェクト | **必須** | 場所のジオメトリ。 | +| \- `type` | 文字列 | **必須** | 次のタイプであるしなければならない:
- `ポリゴン`
- `"MultiPolygon"` | +| \- `coordinates` | 配列 | **必須** | 場所のジオメトリを定義する地理座標 (緯度と経度)。 | + +### booking_rules.txt + +ファイル: **任意** + +主キー(`booking_rule_id`) + +乗客が要求するサービスの予約ルールを定義します + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `booking_rule_id` |ユニーク ID | **必須** | ルールを識別します。 | +| `booking_type` | 列挙型 | **必須** | どのくらい前に予約できるかを示します。有効なオプションは次のとおりです。

`0` - リアルタイム予約。
`1` - 事前連絡で当日予約まで。
`2` - 最大で前日の予約まで。 | +| `prior_notice_duration_min` | 整数 | **条件付きで必須** | 旅行前にリクエストを行う最小時間 (分)。

**条件付きで必須**:
- ** ` booking_type =1` の場合は必須**。
- **それ以外の場合は禁止**。 | +| `prior_notice_duration_max` | 整数 | **条件付きで禁止** | 旅行前に予約リクエストを行う最大分数。

**条件付きで禁止**:
- `booking_type=0` および `booking_type =2` の場合は**禁止**です。
- ` booking_type =1` の場合は任意。| +| `prior_notice_last_day` | 整数 | **条件付きで必須** | 予約リクエストを行う旅行前の最終日。

例: `は` 1 日前の午後 5 時までに予約する必要があります`は、`prior_notice_last_day=1` としてエンコードされます。

**条件付きで必須**:
- ** ` booking_type =2` の場合は必須** です。
- それ以外の場合は**禁止**。 | +| `prior_notice_last_time` | 時間 | **条件付きで必須** | 旅行前最終日に予約リクエストを行う最終時間。

例: `は` 1 日前の午後 5 時までに予約する必要があります`は、`prior_notice_last_time=17:00:00` としてエンコードされます。

**条件付きで必須**:
- ** `prior_notice_last_day`が定義されている場合は必須。
- **それ以外の場合は禁止**。 | +| `prior_notice_start_day` | 整数 | **条件付きで禁止** | 予約リクエストを行う旅行前の最も早い日。

例: `で` 1 週間前の深夜に予約できます`は、`prior_notice_start_day=7` としてエンコードされます。

**条件付きで禁止**:
- `booking_type =0` の場合は**禁止**です。
- `prior_notice_duration_max`が定義されている場合、` booking_type =1` では**禁止** です。
- それ以外の場合は任意。 | +| `prior_notice_start_time` | 時間 | **条件付きで必須** | 予約リクエストを行う旅行の最も早い日の最初の時間。

例: `で` 1 週間前の深夜に予約できます`は、`prior_notice_start_time=00​​:00:00` としてエンコードされます。

**条件付きで必須**:
- ** `prior_notice_start_day`が定義されている場合は必須。
- それ以外の場合は**禁止**。 | +| `prior_notice_service_id` | `calendar.service_id`部` ID | **条件付きで禁止** | `prior_notice_last_day`または`prior_notice_start_day`がカウントされるサービス日を示します。

例: 空の場合、`prior_notice_start_day=2` は 2 暦日前になります。営業日 (休日のない平日) のみを含む`service_id`として定義されている場合、`prior_notice_start_day=2` は 2 営業日前になります。

**条件付きで禁止**:
- ` booking_type =2` の場合は任意。
- それ以外の場合は**禁止**。 | +| `message` |Text|任意| オンデマンドのピックアップとドロップオフを予約するときに、 `stop_time`でサービスを利用する乗客へのメッセージ。ユーザーインターフェイス内で送信される、サービスを利用するために乗客が実行する必要があるアクションに関する最小限の情報を提供することを目的としています。 | +| `pickup_message` |Text|任意| `message`と同じように機能しますが、乗客がオンデマンドのピックアップのみを利用する場合に使用されます。 | +| `drop_off_message` |Text|任意| `message`と同じように機能しますが、乗客がオンデマンドのドロップオフのみを利用する場合に使用されます。 | +| `phone_number` | 電話番号 |任意| 予約リクエストを行うために電話する電話番号。 | +| `info_url` | URL |任意| 予約ルールに関する情報を提供する URL。 | +| `booking_url` | URL |任意| 予約リクエストを行うことができるオンラインインターフェイスまたはアプリへの URL。 | + +### translations.txt + +ファイル: **任意** + +主キー(`table_name`、 `field_name`、 `language`、 `record_id`、 `record_sub_id`、 `field_value`) + +複数の公用語がある地域では、交通機関/運営者は通常、言語固有の名前とウェブページを持っています。それらの地域の乗客に最適なサービスを提供するために、データセットにこれらの言語に依存する値を含めることは有用です。 + +2 つの異なる行で同じ値を翻訳するために (`record_id`、 `record_sub_id`) と`field_value`の両方の参照方法が使用されている場合、 (`record_id`、 `record_sub_id`) で提供される翻訳が優先されます。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `table_name` | Enum | **必須** | 翻訳するフィールドを含むテーブルを定義します。許可される値は次のとおりです:

- `agency`
- `stops`
- `routes`
- `trips`
- `stop_times`
- `pathways`
- `levels`
- `feed_info`
- `attributions`

GTFS に追加されたファイルには、上記のファイル名と同等の`table_name`値が含まれます (つまり、`.txt` ファイル拡張子は含まれません)。 | +| `field_name` |Text| **必須** | 翻訳するフィールドの名前。`Text` タイプのフィールドは翻訳できます`URL`、 `Email` 、 `e` number`タイプのフィールドも、正しい言語でリソースを提供するために`翻訳`できます。その他のタイプのフィールドは翻訳しないでください。 | +| `language` | 言語コード | **必須** | 翻訳の言語。

言語が`feed_info.feed_lang`と同じ場合、フィールドの元の値は、特定の翻訳のない言語で使用するデフォルト値であると見なされます ( `default_lang` で別途指定されていない場合)。
_例: スイスでは、公式にバイリンガルの州にある都市は正式には`ビール/ビエンヌ`と呼ばれますが、フランス語では単に`ビエンヌ`、ドイツ語では`ビール`と呼ばれます。_ | +| `translation` |Text、URL、メール、電話番号 | **必須** | 翻訳された値。 | +| `record_id` |外部 ID | **条件付きで必須** | 翻訳するフィールドに`record_id`するレコードを定義します。`record_id` の値は、各テーブルの主キー属性で定義されているように、テーブルの主キーの最初のフィールドまたは唯一のフィールドである必要があります。

- [agency.txt] の`agency_id` (#agencytxt )
- [stops.txt](#stopstxt) の`stop_id`
- [routes.txt](#routestxt) の`route_id` ;
- [trips.txt](#tripstxt) の`trip_id`
- [stop_times.txt](#stop_timestxt) の`trip_id` ;
- [pathways.txt](#pathwaystxt) の`pathway_id` ;
- [levels.txt](#levelstxt) の`level_id` ;
- [attributions.txt](#attributionstxt ) の`attribution_id` 。

上記で定義されていないテーブル内のフィールドは翻訳しないでください。ただし、プロデューサーが公式仕様外のフィールドを追加する場合があり、これらの非公式フィールドは翻訳される可能性があります。以下は、これらのテーブルで`record_id`を使用するための推奨方法です。

- [calendar.txt](#calendartxt) の`service_id` ;
- [calendar_dates.txt](#calendar_datestxt) の`service_id` ;
- [fare_attributes.txt](#fare_attributestxt) の`fare_id` ;
- [fare_rules.txt](#fare_rulestxt) の`fare_id` ;
- [shapes.txt](#shapestxt) の`shape_id` ;
- [frequencies.txt](#frequenciestxt ) の`trip_id` ;
- [transfers.txt](#transferstxt) の`from_stop_id` 。

条件付きで必須:
- `table_name`が`feed_info`の場合は**禁止**です。
- `field_value`が定義されている場合は**禁止**です。
- **必須** `field_value`が空の場合。 | +| `record_sub_id` |外部 ID | **条件付きで必須** | テーブルに一意のIDがない場合に、フィールドを含むレコードを翻訳するのに役立ちます。したがって、 `record_sub_id`の値は、次の表で定義されているように、テーブルのセカンダリIDです。

- [agency.txt](#agencytxt) にはなし。
- [stops.txt](#stopstxt) にはなし
- [routes.txt](#routestxt) にはなし。
- [trips.txt](#tripstxt) にはありません。
- [stop_times.txt](#stop_timestxt) の`stop_sequence` ;
- [pathways.txt](#pathwaystxt) にはなし。
- [levels.txt](#levelstxt) にはなし
- [attributions.txt](#attributionstxt) にはありません。

上記で定義されていないテーブル内のフィールドは翻訳しないでください。ただし、プロデューサーが公式仕様外のフィールドを追加する場合があり、これらの非公式フィールドは翻訳される可能性があります。以下は、これらのテーブルで`record_sub_id`を使用するための推奨方法です。

- [calendar.txt](#calendartxt) にはなし
- [calendar_dates.txt](#calendar_datestxt) の ` date `
- [fare_attributes.txt](#fare_attributestxt) にはなし
- [fare_rules.txt](#fare_rulestxt) の`route_id` ;
- [shapes.txt](#shapestxt) にはなし
- [frequencies.txt](#frequenciestxt ) の`start_time` ;
- [transfers.txt](#transferstxt) の`to_stop_id` 。

条件付きで必須:
- `table_name`が`feed_info`の場合は**禁止**です。
- `field_value`が定義されている場合は**禁止**です。
- **必須** `table_name=stop_times` の場合、 + + `record_id`が定義されています。 | +| `field_value` |Text、URL、メール、電話番号 | **条件付きで必須** | `record_id`と`record_sub_id`を使用してどのレコードを翻訳するかを定義する代わりに、このフィールドを使用して翻訳する値を定義できます。これを使用すると、 `table_name`と`field_name`で識別されるフィールドに、field_value で定義された値とまったく同じ値が含まれている場合に翻訳が適用されます。

フィールドには、 `field_value`で定義された値と **正確に** 一致している必要があります。値のサブセットのみが`field_value`と一致する場合、翻訳は適用されません。

2 つの翻訳ルールが同じレコードに一致する場合 (1 つは`field_value`、もう 1 つは`record_id`)、 `record_id`のルールが優先されます。

条件付きで必須:
- `table_name`が`feed_info`の場合は**禁止**です。
- `record_id`が定義されている場合は**禁止**です。
- **必須** `record_id`が空の場合。 | + +### feed_info.txt + +ファイル: **条件付きで必須** + +Primary key (none) + +ファイルには、データセットが記述するサービスではなく、データセット自体に関する情報が含まれます。場合によっては、データセットの発行者が機関とは異なるエンティティであることがあります。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `feed_publisher_name` |Text| **必須** | データセットを公開する組織のフルネーム。これは、 `agency.agency_name`値のいずれかと同じである可能性があります。 | +| `feed_publisher_url` | URL | **必須** | データセットを公開する組織の Web サイトの URL。これは、 `agency.agency_url`値のいずれかと同じである可能性があります。 | +| `feed_lang` |言語コード | **必須** | このデータセットのテキストに使用されるデフォルトの言語。この設定は、GTFS のユーザーがデータセットの大文字化ルールやその他の言語固有の設定を選択するのに役立ちます。テキストをデフォルト以外の言語に翻訳する必要がある場合は、ファイル`translations.txt`を使用できます。

元のテキストが複数の言語であるデータセットの場合、デフォルトの言語は多言語になることがあります。このような場合、 `feed_lang`に` ISO 639-2 規格で定義されている言語コード`mul`を含め、データセットで使用されている各言語の翻訳を`translations.txt`で提供する必要があります。データセット内の元のテキストがすべて同じ言語である場合は、 `mul` を使用しないでください。
例: スイスのような多言語国家のデータセットを考えてみましょう。元の`stops.stop_name`フィールドに、さまざまな言語の停留所名が入力されています。各停留所名は、その停留所の地理的位置で主流の言語に従って記述されます。たとえば、フランス語圏の都市ジュネーブの場合は`Genève` 、ドイツ語圏の都市チューリッヒの場合は`Zürich` 、バイリンガルの都市ビール/`Biel/Bienne`です。データセットの`feed_lang` は`mul`である必要があり、翻訳は`translations.txt`で提供されます。ドイツ語の場合: `Genf`、 `Zürich` 、 `Biel`。フランス語の場合: `Genève`、 `Zurich` 、 `Bienne`。イタリア語の場合: `Ginevra`、 `Zurigo` 、 `Bienna`。英語では、 ``Geneva``、 ``Zurich`` 、 ``Biel/Bienne`。_ | +| `default_lang` | 言語コード |任意| データ利用者が乗客の言語を知らない場合に使用する言語を定義します。多くの場合、 `en` (英語) になります。 | +| `feed_start_date` | 日付 |推奨| データセットは、 `feed_start_date`日の開始から`feed_end_date`日の終了までの期間のサービスの完全で信頼性の高いスケジュール情報を提供します。両方の日付が利用できない場合は空白のままにすることができます。両方が指定されている場合、 `feed_end_date`dateは`feed_start_date`dateより前にしてはなりません。データセットプロバイダーは、今後のサービスの可能性を通知するためにこの期間外のスケジュールデータを提供することが推奨されますが、データセット利用者はそれが正式なものではないことに留意して扱う必要があります。 `feed_start_date`または`feed_end_date` が[calendar.txt](#calendartxt) および [calendar_dates.txt](#calendar_datestxt) で定義されている有効なカレンダーの日付を超える場合、データセットは、 `feed_start_date`または`feed_end_date`の範囲内で、有効なカレンダーの日付に含まれない日付にはサービスがないことを明示的に主張しています。 | +| `feed_end_date` | 日付 |推奨| (上記を参照) | +| `feed_version` |Text|推奨| GTFS データセットの現在のバージョンを示す文字列。GTFS を使用するアプリケーションはこの値を表示して、データセットの公開者が最新のデータセットが組み込まれているかどうかを判断できるようにします。 | +| `feed_contact_email` | メール |任意| GTFS データセットとデータ公開方法に関する連絡用のメール アドレス。`feed_contact_email`は、GTFS を使用するアプリケーションの技術担当者の連絡先です。 [agency.txt](#agencytxt ) を通じてカスタマー サービスの連絡先情報を提供します。`feed_contact_email` または`feed_contact_url`も` 1 つを指定することをお勧めします。 | +| `feed_contact_url` | URL |任意| GTFS データセットとデータ公開方法に関する連絡用の連絡先情報、ウェブフォーム、サポート デスク、またはその他のツールの URL。`feed_contact_url`は、GTFS を利用するアプリケーションの`feed_contact_url`担当者の連絡先です。 [agency.txt](#agencytxt ) を通じてカスタマー サービスの連絡先情報を提供します。`feed_contact_url` または`feed_contact_email`も` 1 つを指定することをお勧めします。 | + +### attributions.txt + +ファイル: **任意** + +主キー(`attribution_id`) + +このファイルは、データセットに適用される属性を定義します。 + +| フィールド名 | タイプ | 存在 | 説明 | +|------|------|------|------| +| `attribution_id` |ユニーク ID |任意| データセットまたはそのサブセットの帰属を識別します。これは主に翻訳に役立ちます。 | +| `agency_id` | `agency.agency_id`部` ID |任意| 帰属が適用される事業者。

`agency_id`、 `route_id`、または`trip_id`属性のいずれかが定義されている場合、その他は空にする必要があります。いずれも指定されていない場合、属性はデータセット全体に適用されます。 | +| ` `route_id` | `routes.route_id`部` ID |任意| 属性がルートに適用されることを除いて、 `agency_id`と同じように機能します。同じルートに複数の属性を適用できます。 | +| ` `trip_id` | `trips.trip_id`部` ID |任意| 属性が旅行に適用されることを除いて、 `agency_id`と同じように機能します。同じ旅行に複数の属性を適用できます。 | +| `organization_name` |Text| **必須** | データセットの帰属先となる組織の名前。 | +| `is_producer` | 列挙型 |任意| 組織の役割はプロデューサーです。有効なオプションは次のとおりです。

`0` または空 - 組織にはこの役割がありません。
`1` - 組織にはこの役割があります。

`is_producer`、 `is_operator`、または`is_authority`も` 1 つを`1`に設定する必要があります。 | +| `is_operator` | 列挙型 |任意| 組織の役割がオペレータであることを除いて、 `is_producer`と同じように機能します。 | +| `is_authority` | 列挙型 |任意| 組織の役割が権限であることを除いて、 `is_producer`と同じように機能します。 | +| `attribution_url` | URL |任意| 組織の URL。 | +| `attribution_email` | 電子メール |任意| 組織の電子メール。 | +| `attribution_phone` | 電話番号 |任意| 組織の電話番号。 | diff --git a/docs/ja/documentation/schedule/schedule_best_practices.md b/docs/ja/documentation/schedule/schedule_best_practices.md new file mode 100644 index 000000000..cbd3c3e4d --- /dev/null +++ b/docs/ja/documentation/schedule/schedule_best_practices.md @@ -0,0 +1,321 @@ +# GTFS Scheduleのベスト プラクティス + +これらは、[General Transit Feed Specification (GTFS)](../reference) で公共交通機関のサービスを記述するための推奨プラクティスです。これらのプラクティスは、[GTFS ベスト プラクティス ワーキング グループ](#gtfs-best-practices-working-group) メンバーの経験と [アプリケーション固有の GTFS プラクティス推奨事項](http://www.transitwiki.org/TransitWiki/index.php/Best_practices_for_creating_GTFS) から統合されました。 + +詳細な背景については、[よくある質問](#frequently-asked-questions-faq)をご覧ください。 + +## ドキュメントの構造 + +プラクティスは、4つの主要なセクションに分かれています。 + +* __[データセットの公開と一般的なプラクティス](#dataset-publishing-general-practices):__ これらのプラクティスは、GTFSデータセットの全体的な構造と、GTFSデータセットが公開される方法に関連しています。 +* __[ファイル別にまとめたプラクティスの推奨事項](#practice-recommendations-organized-by-file):__ 推奨事項は、GTFS内のファイルとフィールド別にまとめられており、プラクティスを公式のGTFSリファレンスにマッピングしやすくなっています。 +* __[ケース別にまとめたプラクティスの推奨事項](#practice-recommendations-organized-by-case):__ ループルートなどの特定のケースでは、プラクティスを複数のファイルとフィールドに適用する必要がある場合があります。このような推奨事項は、このセクションにまとめられています。 + +## データセットの公開と一般的なプラクティス + +* データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります。(例: www.agency.org/gtfs/gtfs.zip) 理想的には、ソフトウェア アプリケーションを使用してダウンロードしやすいように、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできる必要があります。 GTFS データセットはオープンにダウンロード可能にすることが推奨されています (最も一般的な方法) が、データ プロバイダーがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することが推奨されます。 +* GTFS データは反復的に公開されるため、安定した場所にある 1 つのファイルには常に、交通機関 (または複数の機関) のサービスの最新の公式説明が含まれます。 +* 可能な限り、データの反復にわたって`stop_id`、 `route_id`、および`agency_id`の永続的な識別子 (id フィールド) を維持します。 +* 1 つの GTFS データセットには、現在のサービスと今後のサービス (`統合`データセットと呼ばれることもあります) を含める必要があります。 Google トランジットフィード ツールの [マージ機能](https://github.com/google/transitfeed/wiki/Merge) を使用すると、2 つの異なる GTFS フィードからマージされたデータセットを作成できます。 + * 公開された GTFS データセットは、いつでも少なくとも今後 7 日間は有効である必要があります。理想的には、運行会社がスケジュールが継続して運用されると確信している限り有効です。 + * 可能であれば、GTFS データセットは少なくとも今後 30 日間のサービスをカバーする必要があります。 +* フィードから古いサービス (期限切れのカレンダー) を削除します。 +* サービスの変更が 7 日以内に有効になる場合は、静的な GTFS データセットではなく、[GTFS-realtime](../../realtime/reference) フィード (サービス アドバイザリまたはルート更新) を使用してこのサービスの変更を表現します。 +* GTFS データをホストするウェブサーバーは、ファイル変更dateを正しく報告するように設定する必要があります ([HTTP/1.1- Request for Comments 2616](https://tools.ietf.org/html/rfc2616#section-14.29)、セクション 14.29 を参照してください。 + +## ファイル別にまとめた実践推奨事項 + +このセクションでは、[GTFS リファレンス](../reference) に沿って、ファイルとフィールド別にまとめた実践方法を示します。 + +### すべてのファイル + +| フィールド名 | 推奨事項 | +|---|---| +| 大文字と小文字の混在 | 顧客向けのすべてのテキスト文字列 (停留所名、路線名、行先標識を含む) では、小文字を表示できるディスプレイ上の地名の大文字化に関するローカルな慣例に従い、大文字と小文字の混在 (すべて大文字ではない) を使用する必要があります。 | +| | 例: | +| | Brighton Churchill Square | +| | Villiers-sur-Marne | +| | Market Street | +| 略語 | 場所が略称で呼ばれている場合 (例: “JFK Airport”) を除き、フィード全体で名前やその他のテキストの略語を使用しないでください。略語は、スクリーン リーダー ソフトウェアや音声ユーザー インターフェイスによるアクセシビリティに問題が生じる可能性があります。表示用に完全な単語を略語に確実に変換するようにソフトウェアを設計することはできますが、略語から完全な単語に変換すると、エラーが発生するリスクが高くなります。 | + +### agency.txt + +| フィールド名 | 推奨事項 | +|---|---| +| `agency_phone` | そのようなカスタマー サービス電話番号が存在しない限り、含める必要があります。 | +| `agency_email` | そのようなカスタマー サービス メールが存在しない限り、含める必要があります。 | +| `agency_fare_url` | 完全に無料の旅行会社でない限り、含める必要があります。 | + +例:__ + +- バス サービスは、いくつかの小さなバス会社によって運営されています。しかし、スケジュールとチケット発行を担当し、ユーザーの観点からバス サービスを担当する 1 つの大きな会社があります。フィード内では、1 つの大きな会社を代理店として定義する必要があります。データが複数の小規模バス運行会社によって内部的に分割されている場合でも、フィードに定義される代理店は 1 つだけにする必要があります。 + +- フィード プロバイダーはチケット ポータルを運営しますが、実際にサービスを運営し、ユーザーに責任があることが知られている代理店は複数あります。実際にサービスを運営する代理店は、フィード内で代理店として定義する必要があります。 + +### stops.txt + +| フィールド名 | 推奨事項 | +|---|---| +| `stop_name` | 停留所名が公開されていない場合は、フィード全体で一貫した停留所の命名規則に従います。 | | +| | デフォルトでは、 `stop_name`に`Station`や`Stop`などの一般的な単語や冗長な単語を含めないでください。ただし、一部の例外は許可されます。
  • 実際に名前の一部である場合（ユニオン駅、セントラル駅
  • `stop_name`が一般的すぎる場合 (都市名など)、`駅`、`ターミナル`などの単語を使用すると意味が明確になります。
| +| `stop_lat`と`stop_lon` | 停留所の位置はできる限り正確である必要があります。実際の停留所の位置と比較して、停留所の位置の誤差は 4 メートル以内である必要があります。 | +| | 停留所の位置は、乗客が乗車する歩行者通行権のすぐ近くに配置する必要があります (つまり、道路の正しい側)。 | +| | 停留所の位置が別のデータ フィード間で共有されている場合 (つまり、2 つの機関がまったく同じ停留所/乗車施設を使用している場合)、両方の停留所にまったく同じ`stop_lat`と`stop_lon`を使用して、停留所が共有されていることを示します。 | +| `parent_station`と`location_type` | 多くの駅やターミナルには複数の乗車施設があります (モードに応じて、バス ベイ、プラットフォーム、埠頭、ゲート、またはその他の用語で呼ばれる場合があります)。このような場合、フィード作成者は、駅、乗車施設 (子停留所とも呼ばれます)、およびそれらの関係を説明する必要があります。
  • 駅またはターミナルは、`location_type = 1`の`stops.txt`内のレコードとして定義する必要があります。
  • 各乗車施設は、`location_type = 0`の停留所として定義する必要があります。`parent_station` フィールドは、乗車施設がある駅の`stop_id`を参照する必要があります。
| +| | 駅や子供用停留所に名前を付ける場合は、乗客によく知られ、乗客が駅や乗車施設（バス停、プラットホーム、埠頭、ゲートなど）を識別できるような名前を付けてください。
親ステーション名子の停留所名
シカゴ ユニオン駅シカゴ ユニオン駅 19番線
サンフランシスコフェリービルディングターミナルサンフランシスコフェリービルターミナルゲートE
ダウンタウン トランジット センターダウンタウン トランジット センター ベイ B
| + +### routes.txt + +| フィールド名 | 推奨事項 | +|---|---| +| `route_long_name` | 仕様リファレンスの定義:この名前は、通常、 route_short_nameよりも説明的で、ルートの目的地または停車地が含まれることがよくあります。route_short_name またはroute_long_nameの少なくとも 1 つを指定する必要があります。適切な場合は、両方を指定することもroute_short_nameます。ルートに長い名前がない場合は、 route_short_nameを指定し、このフィールドの値として空のstringを使用してください。
長い名前の種類の例を以下に示します。
主な移動経路または回廊
ルート名形状事業者
`N`/`ユダ` route_short_name/
route_long_name		サンフランシスコのMuni
`6`/`L` キング ジュニア ブルバード` route_short_name/
route_long_name		オレゴン州ポートランドのTriMet 。
『6』/『ネイション～エトワール』 route_short_name/
route_long_name		フランスのパリにあるRATP 。
`U2`-`パンコウ – ルーレーベン` route_short_name -
route_long_name		 BVG 、ドイツ、ベルリン
サービスの説明
`ハートウェルエリアシャトル`
+| | `route_long_name`には`route_short_name`を含めないでください。 | +| | `route_long_name`を入力するときは、サービス ID を含む完全な指定を含めます。例:
サービス IDおすすめ例
`MAXライトレール`
オレゴン州ポートランドのTriMet		 route_long_nameはブランド（MAX）と特定のルート指定を含める必要があります。 `MAXレッドライン``MAXブルーライン`
`ラピッドライド`
ニューメキシコ州アルバカーキの ABQ ライド		route_long_nameはブランド（Rapid Ride）と特定のルート指定を含める必要があります。 `ラピッドライドレッドライン`
`ラピッドライドブルーライン`
+| `route_id` | 指定された名前付きルート上のすべての旅行は、同じ`route_id`を参照する必要があります。
  • ルートの異なる方向を異なる`route_id`値に分割しないでください。
  • ルートの異なる運行区間を異なる`route_id`値に分割しないでください。つまり、 `routes.txt`に`n` AM`サービスと`n` PM`サービスに異なるレコードを作成しないでください。
    • | +| | ルート グループに明確に名前が付けられた分岐 (1A と 1B など) が含まれる場合は、ルート [branches](#branches) の場合の推奨事項に従って、 `route_short_name`と`route_long_name`を決定します。 | +| `route_color`と`route_text_color` | 標識や印刷物およびオンラインの顧客情報と一致している必要があります (したがって、他の場所に存在しない場合は含めないでください)。 | + +### trips.txt + +* __ループ ルートの特殊なケースを参照してください:__ ループ ルートは、2 つの異なる終点がある線形ルートとは対照的に、旅行が同じ停留所で開始および終了する場合です。ループ ルートは、特定のプラクティスに従って記述する必要があります。[ループ ルートのケースを参照してください。](#loop-routes) +* __ラッソ ルートの特殊なケースを参照してください:__ ラッソ ルートは、線形ジオメトリとループ ジオメトリのハイブリッドであり、車両はルートの一部のみをループして移動します。ラッソ ルートは、特定のプラクティスに従って記述する必要があります。 [Lasso ルートのケースを参照してください。](#lasso-routes) + +| フィールド名 | 推奨事項 | +|---|---| +| `trip_headsign` | ` `trip_headsign`または`stop_headsign`フィールドにルート名 ( `route_short_name`および`route_long_name`と一致するもの) を指定しないでください。 | +| | ルート内の旅行を区別するために使用できる、車両のヘッドサイン上に表示される目的地、方向、およびその他の旅行指定テキストを含める必要があります。車両に表示される方向情報との一貫性は、GTFS データセットで提供されるヘッドサインを決定するための最優先の目標です。その他の情報は、この主要目標を損なわない場合にのみ含める必要があります。旅行中にヘッドサインが変更される場合は、 `trip_headsign`を`stop_times.stop_headsign`で上書きします。以下に、考えられるいくつかのケースに対する推奨事項を示します。 | +| |
    ルートの説明おすすめ
    2A. 目的地のみ終点の目的地を入力してください。例: `ト` センター`、`ド` シティ センター`、`ン` ビーチ`>
    2B. ウェイポイントのある目的地<destination> 経由 <waypoint> “Highgate via Charing Cross”。車両がそれらのウェイポイントを通過した後に、乗客に表示されるヘッドサインからウェイポイントが削除された場合は、 stop_times.stop_headsignを使用して更新されたヘッドサインを設定します。
    2C. 地方の地名と停留所目的地の市内または自治区内に複数の停留所がある場合は、目的地の市内に到着したらstop_times.stop_headsignを使用します。
    2D. 方向のみ`北行き`、`内向き`、`時計回り`などの用語を使用して方向を示します。
    2E. 目的地までの道順<方向> から <終点名> へ (例: `南行きサンノゼ行き`)
    2F. 目的地と経由地を含む方向<方向> から <ウェイポイント> を経由して <目的地> へ（`グ` クロス経由でハイゲートへ北行き`）。
    | +| | ヘッドサインの先頭に`To`や`Towards`という言葉を使用しないでください。 | +| `direction_id` | データセット全体で一貫して 0 と 1 の値を使用します。つまり
    • 1 = 赤ルートのアウトバウンドの場合、1 = 緑ルートのアウトバウンド
    • 1 = ルート X の北行きの場合、1 = ルート Y の北行き
    • ルートXが1 = 時計回りの場合、ルートYも1 = 時計回り
    | +| `bikes_allowed` | フェリー旅行の場合、自転車が許可されている (または許可されていない) ことを明示的に指定します。データが欠落しているためにフェリー旅行を避けると、通常、大きな迂回につながります。 | + +### stop_times.txt + +ループ ルート: ループ ルートでは、特別な`stop_times`の考慮が必要です。(参照: [ループ ルートのケース](#loop-routes)) + +| フィールド名 | 推奨事項 | +|---|---| +| `pickup_type`および`drop_off_type` | 旅客サービスを提供しない無収入 (回送) 旅行では、すべての`stop_times`行で`pickup_type`および`drop_off_type`の値を`1`に設定する必要があります。 +| |有償運行の場合、運行状況を監視するための内部の`グ` ポイント`や、乗客が乗車できない車庫などのその他の場所は、` pickup_type = 1` (乗車不可) および `drop_off_type = 1` (降車不可) でマークする必要があります。 | +| `arrival_time`および`departure_time` | `arrival_time`と`departure_time`フィールドには、可能な限り、拘束力のない推定時間またはタイム ポイント間の補間時間を含め、時間値を指定する必要があります。 | +| `stop_headsign` | 一般に、ヘッドサイン値は駅の標識にも対応する必要があります。

    以下の場合、`南行き`は駅の標識では使用されていないため、顧客に誤解を与える可能性があります。 +| |
    NYC で南行きの 2 名の場合:
    stop_times.txt行の場合: stop_headsign値を使用します:
    マンハッタンに到着するまでManhattan & Brooklyn
    ダウンタウンに到着するまでDowntown & Brooklyn
    ブルックリンに到着するまでBrooklyn
    ブルックリンに到着したらBrooklyn (New Lots Av)
    | +| |
    ボストン、レッドライン南行き、ブレインツリー支線の場合：
    stop_times.txt行の場合: stop_headsign値を使用します:
    ダウンタウンに到着するまでInbound to Braintree
    ダウンタウンに到着したらBraintree
    ダウンタウンの後Outbound to Braintree
    | + +### calendar.txt + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | `calendar.service_name`も` GTFS の可読性を高めることができますが、これは仕様では採用されていません。 | + +### calendar_dates.txt + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | `calendar.service_name`も` GTFS の可読性を高めることができますが、これは仕様では採用されていません。| + +### fare_attributes.txt + +| フィールド名 | 推奨事項 | +|---|---| +| | 運賃システムを正確にモデル化できない場合は、混乱を避けるために空白のままにしておきます。 | +| | 運賃 (`fare_attributes.txt`および`fare_rules.txt`) を含めて、できるだけ正確にモデル化します。運賃を正確にモデル化できないエッジケースでは、運賃を安くするのではなく高く表現して、顧客が不足運賃で搭乗しないようにする必要があります。運賃の大部分を正しくモデル化できない場合は、運賃情報をフィードに含めないでください。 | + +### fare_rules.txt + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | 運賃システムを正確にモデル化できない場合は、混乱を避けるために空白のままにしておきます。 | +| | 運賃 (`fare_attributes.txt`および`fare_rules.txt`) を含めて、できるだけ正確にモデル化します。運賃を正確にモデル化できないエッジケースでは、運賃を安くするのではなく高く表現して、顧客が不足運賃で搭乗しないようにする必要があります。運賃の大部分を正しくモデル化できない場合は、運賃情報をフィードに含めないでください。 | + +### shapes.txt + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | 理想的には、共有されている線形の場合 (つまり、ルート・路線系統1 と 2 が同じ道路または線路のセグメントで動作している場合)、線形の共有部分は完全に一致する必要があります。これにより、高品質の交通地図作成が容易になります。 +| | 線形は、車両が走行する道路の中心線に沿う必要があります。これは、指定された車線がない場合は道路の中心線、または車両の移動方向の道路側の中心線のいずれかになります。

    配置は、縁石の停留所、プラットフォーム、または乗車場所に対して`ギザギザ`になってはなりません。 | +| `shape_dist_traveled` | `shape_dist_traveled`フィールドを使用すると、機関は`shape_dist_traveled` `stop_times.txt`ファイル内の停留所がそれぞれの形状にどのように適合するかを正確に指定できます。`shape_dist_traveled` フィールドに使用する一般的な値は、車両が移動した形状の開始点からの距離です (走行距離計の読み取り値のようなものと考えてください)。
  • ルートの配置 ( `shapes.txt`内) は、旅行がサービスを提供する停留所の位置から 100 メートル以内である必要があります。
  • shapes.txtに余分な点が含まれないように配置を簡素化します (つまり、直線セグメント上の余分な点を削除します。線の簡素化の問題に関する説明を参照してください)。
    • + +### frequencies.txt + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | `frequencies.txt`で参照される旅行では、実際の停車時刻は無視されます。定期運行の旅行では、停車時刻間の移動時間間隔のみが重要です。明確さと可読性のため、 `frequencies.txt`は` 00:00:00 (最初の`arrival_time`が` 00:00:00) から開始することをお勧めします。 | +| `block_id` | 定期運行の旅行に指定できます。 | + +### transfers.txt + + `transfers.transfer_type`は、[GTFS で定義](../reference/#transferstxt) の 4 つの値のいずれかになります。これらの`transfer_type`定義は、以下の GTFS 仕様から _斜体_ で引用されており、追加の推奨事項が実践されています。 + +| フィールド名 |推奨 | +|---|---| +| `transfer_type` | 0 または (空): これはルート間の推奨される乗り換えポイントです。
    複数の乗り換え機会があり、その中により優れた選択肢（追加の設備を備えた交通センター、または隣接または接続された乗車施設/プラットフォームを備えた駅など）がある場合は、推奨される乗り換えポイントを指定します。 | +| | 1: これは、2 つのルート間の時間指定の乗り換えポイントです。出発車両は、乗客がルート間を乗り換えるのに十分な時間、到着車両を待つことが期待されます。
    この乗り換えタイプは、乗り換えを確実に行うために必要な間隔をオーバーライドします。たとえば、Google マップでは、乗客が安全に乗り換えを行うには 3 分かかると想定しています。他のアプリケーションでは、他のデフォルトを想定する場合があります。| +| | 2: この乗り換えでは、接続を確実にするために、到着と出発の間に最小限の時間が必要です。乗り換えに必要な時間は、 min_transfer_timeで指定します。
    停留所間の移動時間が長くなる障害物やその他の要因がある場合は、最小乗り換え時間を指定します。 | +| | 3: この場所ではルート間の乗り換えはできません。
    物理的な障壁のために乗り換えが不可能な場合、または困難な道路横断や歩行者ネットワークの隙間によって乗り換えが安全でなかったり複雑になったりする場合は、この値を指定します。 | +| | 乗車間で座席内 (ブロック) 乗り換えが許可されている場合、到着乗車の最後の停車地は、出発乗車の最初の停車地と同じである必要があります。 | + + +## 事例別に整理された実践推奨事項 + +このセクションでは、ファイルやフィールド全体に影響を与える特定の事例について説明します。 + +### ループルート・路線系統 + +ループ ルートでは、車両の乗車は同じ場所 (場合によってはトランジット センターまたは乗り換えセンター) で始まり、終わります。車両は通常、連続的に運行し、車両がループを続ける間、乗客は車内にとどまることができます。 + + + + したがって、乗客に車両の進行方向を示すために、行先表示の推奨事項を適用する必要があります。 + +移動方向の変更を示すには、 `stop_times.txt`ファイルに`stop_headsigns`を指定します。`stop_headsign`は、定義されている停留所から出発する旅行の方向を説明します。旅行の各停留所に`stop_headsigns`を追加すると、旅行中のヘッドサイン情報を変更できます。 + +2 つのエンドポイント間で動作するルート (同じバスが往復する場合など) に対して、 stop_times.txtファイルで 1 つの循環旅行を定義しないでください。代わりに、旅行を 2 つの別々の旅行方向に分割します。 + +循環旅行のモデリングの例:__ + +- 停留所ごとにヘッドサインが変化する循環旅行 + +| trip_id | arrive_time | department_id | stop_sequence | stop_headsign | +|---------|--------------|----------------|---------|---------------|---------------| +| trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 | "B" | +| trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 | "C" | +| trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 | "D" | +| trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 | "E" | +| trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 | "A" | +| trip_1 | 06:35:00 | 06:35:00 | stop_A | 6 | "" | + +- 2 つの行先標識がある循環旅行 + +| trip_id | arrive_time | departmental | stop_id | stop_sequence | stop_headsign | +|---------|--------------|----------------|---------|--------------|---------------| +| trip_1 | 06:10:00 | 06:10:00 | stop_A | 1 | "outbound" | +| trip_1 | 06:15:00 | 06:15:00 | stop_B | 2 | "outbound" | +| trip_1 | 06:20:00 | 06:20:00 | stop_C | 3 | "outbound" | +| trip_1 | 06:25:00 | 06:25:00 | stop_D | 4 | "inbound" | +| trip_1 | 06:30:00 | 06:30:00 | stop_E | 5 | "inbound" | +| trip_1 | 06:35:00 | 06:35:00 | stop_F | 6 | "inbound" | +| trip_1 | 06:40:00 | 06:40:00 | stop_A | 7 | "" | + +| フィールド名 | 推奨事項 | +|---|---| +| `trips.trip_id `| ループの完全な往復を 1 回の旅行でモデル化します。 | +| `stop_times.stop_id` | ループである旅行の場合は、 `stop_times.txt`に最初/最後の停車地を 2 回含めます。以下に例を示します。多くの場合、ループ ルートには、ループ全体を移動しない最初と最後の旅行が含まれることがあります。これらの旅行も含めます。
    trip_id stop_id stop_sequence
    9000 101 1
    9000 102 2
    9000 103 3
    9000 101 4
    | +| `trips.direction_id` | ループが反対方向 (つまり時計回りと反時計回り) に動作する場合、 `direction_id` を`0` または`1`に指定します。 | +| `trips.block_id` | 同じ`block_id`プ` トリップを示します。 | + +### Lassoルート・路線系統 + +Lasso ルートは、ループ ルートと方向ルートの側面を組み合わせたものです。 + + + +| 例: | +|--------| +| 地下鉄ルート・路線系統([シカゴ](https://www.transitchicago.com/assets/1/6/ctamap_Lsystem.pdf)) | +| 郊外からダウンタ​​ルート・路線系統へのバス路線 ([セント アルバート](https://stalbert.ca/uploads/PDF-infosheets/RideGuide-201-207_Revised_Oct_2017.pdf) または [エドモントン](http://webdocs.edmonton.ca/transit/route_schedules_and_maps/future/RT039.pdf)) | +| CTA ブラウン ライン ([CTA ウェブサイト](http://www.transitchicago.com/brownline/) および [TransitFeeds](https://transitfeeds.com/p/chicago-transit-authority/165/latest/route/Brn)) | + +| フィールド名 | 推奨事項 | +|---|---| +| `trips.trip_id` | `車両の往復`の全範囲 ([上記](#lasso-routes) の図を参照) は、A から B、B、そして A に戻る移動で構成されます。車両の往復全体は、次のように表すことができます。
  • `trips.txt`の` __single__ `trip_id`値/レコード
  • `trips.txt`は` __複数の__ `trip_id`値/レコードがあり、連続した移動は`block_id`で示されます。
    • | +| `stop_times.stop_headsign` | AB セクションに沿った停留所は両方向に通過します。`stop_headsign` により移動方向の区別が容易になります。したがって、これらの旅行では`stop_headsign`を指定することをお勧めします。example_table:
    例:
    `A経由B`
    `あ`
    シカゴ交通局のパープルライン
    `ループ南行き`
    `ループ経由北行き`
    `リンデンへ北上`
    エドモントン交通サービスバス路線、ここでは39
    `ラザフォード`
    `センチュリーパーク`
    +| `trip.trip_headsign` | 旅行の行先標識は、スケジュールに表示されるような旅行の全体的な説明である必要があります。`n` から Linden へ、Loop 経由`(シカゴの例) または`A` から A へ、B 経由`(一般的な例) などです。 | + +### 分岐 + +一部のルートには分岐が含まれる場合があります。これらの分岐間では配置と停留所が共有されますが、それぞれが異なる停留所と配置セクションも提供します。分岐間の関係は、以下の追加のガイドラインを使用して、ルート名、行先標識、旅行の短縮名で示すことができます。 + + + +| フィールド名 | 推奨事項 | +|---|---| +| すべてのフィールド | 分岐ルートに名前を付ける場合は、他の旅客情報資料に従うことをお勧めします。以下は、2 つのケースの説明と例です。 | +| | 時刻表と路上標識が 2 つの異なる名前のルート (例: 1A と 1B) を表している場合は、 `route_short_name`フィールドや`route_long_name`フィールドを使用して、GTFS でそのように示します。例: GoDurham Transit [ルート 2、2A、および 2B](https://gotriangle.org/sites/default/files/brochure/godurham-route2-2a-2b_1.pdf) は、ルートの大部分で共通の配置を共有していますが、いくつかの異なる側面で異なります。
    • ルート 2 はコア サービスであり、ほとんどの時間帯に運行されます。
    • ルート 2 では、夜間、日曜日、祝日にメイン ストリートを迂回します。
    • ルート・路線系統2Aと2Bは月曜日から土曜日までの日中に運行されます。
    • ルート 2B は、共有線形パスから外れて追加の停留所に停車します。
    | +| | 機関が提供する情報に同じ名前のルートとして分岐が記載されている場合は、 `trips.trip_headsign`、`stop_ti`を使用します。 + +mes.stop_headsign`、および/または`trips.trip_short_name`フィールド。例: GoTriangle [route 300](https:) は、時間帯に応じて異なる場所に移動します。通勤ラッシュ時には、市内に出入りする労働者に対応するために、標準ルートに追加の区間が追加されます。 | + +## よくある質問（FAQ） + +### これらの GTFS ベスト プラクティスはなぜ重要ですか？ + +GTFS ベスト プラクティスの目的は次のとおりです。 + +* 公共交通機関アプリにおけるエンドユーザーのカスタマー エクスペリエンスを向上させる +* 幅広いデータの相互運用性をサポートし、ソフトウェア開発者がアプリケーション、製品、サービスを導入および拡張しやすくする +* さまざまなアプリケーション カテゴリで GTFS の使用を促進する（旅行計画という当初の重点を超えて） + +GTFS ベスト プラクティスが調整されていないと、GTFS を利用するさまざまなアプリケーションが、調整されていない方法で要件と期待を確立する可能性があります。その結果、要件とアプリケーション固有のデータセットが分散し、相互運用性が低下します。ベスト プラクティスがリリースされる前は、正しい形式の GTFS データを構成する要素について、より大きな曖昧さと意見の不一致がありました。 + +### これらはどのように開発されたのですか？誰が開発しましたか? + +これらのベスト プラクティスは、GTFS に深く関わっているアプリ プロバイダーとデータ コンシューマー、交通機関プロバイダー、コンサルタントなど、GTFS に関わる 17 の組織からなるワーキング グループによって開発されました。ワーキング グループは [Rocky Mountain Institute](http://www.rmi.org/mobility) によって招集され、運営されました。 + +ワーキング グループのメンバーは、各ベスト プラクティスに投票しました。ほとんどのベスト プラクティスは満場一致で承認されました。少数のケースでは、ベスト プラクティスが組織の大多数で承認されました。 + +### GTFS 参照を変更しないのはなぜですか? + +よい質問です。仕様、データの使用法、ニーズを調査するプロセスによって、実際に仕様にいくつかの変更が加えられました ([GitHub のクローズされたプル リクエスト](https://github.com/google/transit/pulls?q=is%3Apr+is%3Aclosed) を参照)。 +仕様参照の修正は、ベスト プラクティスよりも厳しい精査とコメントの対象となります。特定のベスト プラクティスは、採用レベルとコミュニティの合意に基づいて仕様に統合されています。最終的には、すべての GTFS ベスト プラクティスがコア GTFS リファレンスの一部になる可能性があります。 + +### これらのベスト プラクティスへの準拠を確認するにはどうすればいいですか? + +Canonical GTFS Schedule Validator は、これらのベスト プラクティスへの準拠を確認します。この検証ツールの詳細については、[検証ページ](../../../getting_started/validate) を参照してください。 + +### 私は交通機関の代表です。ソフトウェア サービス プロバイダーとベンダーがこれらのベスト プラクティスに従うようにするには、どのような手順を踏めばよいでしょうか? + +ベンダーまたはソフトウェア サービス プロバイダーにこれらのベスト プラクティスを勧めてください。 GTFS を生成するソフトウェアを調達する際は、GTFS ベスト プラクティスの URL とコア仕様リファレンスを参照することをおすすめします。 + +### GTFS データ フィードがこれらのベスト プラクティスに準拠していないことに気付いた場合はどうすればよいですか? + +* feed_info.txt * に [提案された feed\_contact\_email または feed\_contact\_url](https://github.com/google/transit/pull/31/files) フィールドがある場合はそれを使用して、または交通機関またはフィード プロデューサーのウェブサイトで連絡先情報を検索して、フィードの連絡先を特定します。フィード プロデューサーに問題を伝えるときは、議論中の特定の GTFS ベスト プラクティスにリンクします。 （[`このドキュメントへのリンク`](#linking-to-this-document)を参照してください）。 + +### 参加するにはどうすればいいですか？ + +[specifications@mobilitydata.org](mailto:specifications@mobilitydata.org)にメールを送信してください。 + +## このドキュメントについて + +### 目的 + +GTFS ベスト プラクティスを維持する目的は次のとおりです。 + +* 交通データの相互運用性の向上をサポートする +* 公共交通機関アプリにおけるエンドユーザーの顧客エクスペリエンスを向上させる +* ソフトウェア開発者がアプリケーション、製品、およびサービスを導入および拡張しやすくする +* さまざまなアプリケーション カテゴリで GTFS を使用できるようにする（当初の重点である旅行計画を超えて） + +### 公開されている GTFS ベスト プラクティスを提案または修正する方法 + +ベスト プラクティスは、現在仕様に統合中です。新しいベスト プラクティスを提案したい場合は、[GTFS リファレンス GitHub リポジトリ](https://github.com/google/transit/) にアクセスして問題を報告または PR を作成するか、[specifications@mobilitydata.org](mailto:specifications@mobilitydata.org) にお問い合わせください。 + +### このドキュメントへのリンク + +フィード プロデューサーに GTFS データを正しく作成するためのガイダンスを提供するために、ここにリンクしてください。個々の推奨事項にはそれぞれアンカー リンクがあります。推奨事項をクリックすると、ページ内のアンカー リンクの URL が表示されます。 + +GTFS を利用するアプリケーションが、ここで説明されていない GTFS データの取り扱いに関する要件や推奨事項を提示している場合は、これらの一般的なベスト プラクティスを補足するために、それらの要件や推奨事項を記載したドキュメントを公開することをお勧めします。 + +### GTFS ベスト プラクティス ワーキング グループ + +GTFS ベスト プラクティス ワーキング グループは、2016 ～ 2017 年に [Rocky Mountain Institute](http:) によって招集され、公共交通機関、GTFS を利用するアプリケーションの開発者、コンサルタント、学術機関で構成され、GTFS データに関する一般的な取り扱いと期待を定義します。 +このワーキンググループのメンバーは次のとおりです: + +* [Cambridge Systematics](https://www.camsys.com/) +* [Capital Metro](https:://www.capmetro.org/) +* [Center for Urban Transportation Research at University of South Florida](https://www.cutr.usf.edu/) +* [Conveyal](http://conveyal.com/) +* [Google](https://www.google.com/) +* [IBI Group](http://www.ibigroup.com/) +* [Mapzen](https://mapzen.com/) +* [Microsoft](https://www.microsoft.com/) +* [Moovel](https://www.moovel.com/) +* [Oregon Department of Transportation](http://www.oregon.gov/odot/) +* [Swiftly](https://goswift.ly/) +* [Transit](https://transitapp.com/) +* [Trillium](http://trilliumtransit.com/) +* [TriMet](https://trimet.org/) +* [World Bank](http://www.worldbank.org/) + +現在、このドキュメントは [MobilityData](http://mobilitydata.org/) によって管理されています。