diff --git a/docs/ja/about/index.md b/docs/ja/about/index.md index 405b1d91..ceca7eba 100644 --- a/docs/ja/about/index.md +++ b/docs/ja/about/index.md @@ -15,17 +15,17 @@ GTFS.org ドメイン名の購入と使用貸与、そしてコミュニティ 翻訳に関しては、GTFS.org は自動化ツールを使用して、リポジトリの変更に合わせて翻訳をdateの状態に保っています。翻訳を最新の状態に保つことを最優先としているため、どの言語でも手動で修正された翻訳は最終的に上書きされることにご注意ください。 -旅行や駅など、GTFS.org 全体でするべきである使用される重要な用語の用語集の変更は受け付けています。サイト全体に適用される重要な用語の翻訳を提案したい場合は、[GTFS.org GitHub リポジトリ](https://github.com/mobilitydata/gtfs.org)で問題を作成できます。 +便や駅など、GTFS.org 全体でするべきである使用される重要な用語の用語集の変更は受け付けています。サイト全体に適用される重要な用語の翻訳を提案したい場合は、[GTFS.org GitHub リポジトリ](https://github.com/mobilitydata/gtfs.org)で問題を作成できます。 ## GTFS の進化 GTFSは、オレゴン州ポートランドの TriMet と Google のコラボレーションから始まりました。TriMet は Google と協力して、Google マップにインポートできる、管理しやすく使いやすい形式に交通データをフォーマットしました。この交通データ形式は、もともとGoogle Transit Feed Specification （GTFS）として知られていました。 -開発者の革新の結果、GTFS データは現在、旅行計画、時刻表作成、モバイルデータ、データの視覚化、アクセシビリティ、計画用分析ツールなど、さまざまなサードパーティ製ソフトウェア アプリケーションでさまざまな目的で使用されています。 +開発者の革新の結果、GTFS データは現在、便計画、時刻表作成、モバイルデータ、データの視覚化、アクセシビリティ、計画用分析ツールなど、さまざまなサードパーティ製ソフトウェア アプリケーションでさまざまな目的で使用されています。 2010 年には、Google 製品以外のさまざまなアプリケーションでの使用を正確に表すために、GTFS 形式の名前がGeneral Transit Feed Specificationに変更されました。2011 年にはGTFS realtimeが作成され、仕様にリアルタイム情報機能が追加されました。また、2019 年には、コミュニティの協力を得て GTFS をさらに維持するために、非営利団体の [MobilityData](https://mobilitydata.org/) が設立されました。 -公共交通機関のデータ形式の中で、GTFS が際立っているのは、運用の詳細を管理するための網羅的な語彙としてではなく、乗客にサービス情報を伝達するという具体的で実用的なニーズを満たすように考案されたことです。人間と機械の両方にとって、作成と読み取りが比較的簡単になるように設計されています。 +公共交通事業者のデータ形式の中で、GTFS が際立っているのは、運用の詳細を管理するための網羅的な語彙としてではなく、乗客にサービス情報を伝達するという具体的で実用的なニーズを満たすように考案されたことです。人間と機械の両方にとって、作成と読み取りが比較的簡単になるように設計されています。 GTFS の起源に関する詳細な背景については、[オープン データ標準の先駆者: GTFS の物語](https://beyondtransparency.org/chapters/part-2/pioneering-open-data-standards-the-gtfs-story/) および [Streetsblog SF の Google とポートランドの TriMet がオープン交通データの標準を設定した方法](https://sf.streetsblog.org/2010/01/05/how-google-and-portlands-trimet-set-the-standard-for-open-transit-data) を参照してください。 diff --git a/docs/ja/community/extensions/fares-v2.md b/docs/ja/community/extensions/fares-v2.md index 4fcdb718..77977680 100644 --- a/docs/ja/community/extensions/fares-v2.md +++ b/docs/ja/community/extensions/fares-v2.md @@ -6,10 +6,10 @@ Fares Fares v2で表現する予定の主な概念は次のとおりです。 - チケット商品(チケットやパスなど) - 乗客カテゴリ (高齢者や子供など) -- チケットメディア(交通パス、紙のチケット、非接触型銀行カードなど) +- 運賃メディア(交通パス、紙のチケット、非接触型銀行カードなど) - 運賃上限 -これらの概念により、データ作成者はゾーンベース、時間依存、および機関間運賃をモデル化できるようになります。この拡張プロジェクトは、反復的に採用されています。 +これらの概念により、データ作成者はゾーンベース、時間依存、および事業者間運賃をモデル化できるようになります。この拡張プロジェクトは、反復的に採用されています。 GTFS で公式に採用されているものを使用してモデル化できる内容を示す [例](../../../documentation/schedule/examples/fares-v2) をここで確認できます。 @@ -51,8 +51,8 @@ Slack チャネルや定期的なワーキング グループ ミーティング -**2022年3月**: オープン投票#2 → 不成立 -**2022年してもよい**: オープン投票#3 → 成立 -**2022年8月**: Fares v2の次のフェーズに関するコミュニティの議論開始 --**2022年11月**: チケットメディアドラフトのプルリクエストがフィードバック用に公開 +-**2022年11月**: 運賃メディアドラフトのプルリクエストがフィードバック用に公開 -**2022年12月**: コミュニティが機能のスタックランク付け順序を特定し、反復の優先順位を決定 --**2023年3月**: チケットメディアパス +-**2023年3月**: 運賃メディアパス -**2023年7月**: 時間/日によって異なる運賃パス -**2023年11月2023**: ネットワークを定義するための専用ファイル diff --git a/docs/ja/community/extensions/flex.md b/docs/ja/community/extensions/flex.md index e00a2767..1ef0002b 100644 --- a/docs/ja/community/extensions/flex.md +++ b/docs/ja/community/extensions/flex.md @@ -4,7 +4,7 @@ GTFS Flex は、デマンド レスポンシブ交通サービスの発見可能 大部分は、2024 年 GTFS で採用されています。[このページ](../../../documentation/schedule/examples/flex) には、GTFS Flex の公式に採用された部分を使用してモデル化できる内容を示す例がいくつかあります。 -🤔 ダイアル ア ライドなどのサービスは、利用者によって無視されることが多く、その存在すら知らない利用者もいます。このアクセシビリティの欠如は、交通機関、旅行計画者、利用者にとっての問題です。地元の空港に到着した観光客のグループが、オンデマンド バス サービスしか提供されていない田舎に行きたいと考えているところを想像してみてください。観光客は好みの旅行プランナー アプリをチェックしますが、実行可能な公共交通機関の選択肢が見つかりません。結局、レンタカーを借りることになります。観光客である乗客は、オンデマンド サービスを宣伝する紙のチラシを廊下にすべて見落とします。サービスが十分に利用されていないだけでなく、現在および将来の乗客の需要を満たすための発見可能性も欠いています。ここで GTFS-Flex の出番です。GTFS-Flex は乗客がサービスを発見できるようにし、あなたが一生懸命宣伝したサービスを乗客が楽しめるようにします。 +🤔 ダイアル ア ライドなどのサービスは、利用者によって無視されることが多く、その存在すら知らない利用者もいます。このアクセシビリティの欠如は、交通事業者、便計画者、利用者にとっての問題です。地元の空港に到着した観光客のグループが、オンデマンド バス サービスしか提供されていない田舎に行きたいと考えているところを想像してみてください。観光客は好みの便プランナー アプリをチェックしますが、実行可能な公共交通事業者の選択肢が見つかりません。結局、レンタカーを借りることになります。観光客である乗客は、オンデマンド サービスを宣伝する紙のチラシを廊下にすべて見落とします。サービスが十分に利用されていないだけでなく、現在および将来の乗客の需要を満たすための発見可能性も欠いています。ここで GTFS-Flex の出番です。GTFS-Flex は乗客がサービスを発見できるようにし、あなたが一生懸命宣伝したサービスを乗客が楽しめるようにします。 GTFS-Flex ユーザージャーニー @@ -36,7 +36,7 @@ GTFS Flex は、デマンド レスポンシブ交通サービスの発見可能 - `locations.geojson`、乗客がピックアップまたはドロップオフをリクエストできるゾーン (`Polygon`または`Multipolygon`) を定義します。 - `booking_rules.txt`、乗客にサービスのリクエスト方法に関する情報を提供する予約ルールを定義します。 -アンガーミュンデとアンガーミュンデの [RufBus](https://uvg-online.com/rufbus-angermuende/) の [データ例](https://docs.google.com/spreadsheets/d/1w5EHuHfxvejqApJFHA1Z0K2KytD9zahwbf8zyRlP_Ls/edit#gid=1451132209) を以下に示します。ガーツァー、ドイツ。下の画像は、旅行プランナーでデータがどのように表示されるかを示した例です。 +アンガーミュンデとアンガーミュンデの [RufBus](https://uvg-online.com/rufbus-angermuende/) の [データ例](https://docs.google.com/spreadsheets/d/1w5EHuHfxvejqApJFHA1Z0K2KytD9zahwbf8zyRlP_Ls/edit#gid=1451132209) を以下に示します。ガーツァー、ドイツ。下の画像は、便プランナーでデータがどのように表示されるかを示した例です。 diff --git a/docs/ja/community/extensions/overview.md b/docs/ja/community/extensions/overview.md index 674edb68..f91006fa 100644 --- a/docs/ja/community/extensions/overview.md +++ b/docs/ja/community/extensions/overview.md @@ -13,7 +13,7 @@ For more information, contact [specifications@mobilitydata.org](mailto:specifica === "GTFS schedule" - 追加のファイルとフィールドをGTFS scheduleデータセットに拡張して、交通機関とソフトウェア ベンダーの間で伝えられるさまざまなアプリケーション固有のニーズに対応することがしてもよい。これらのフィールドが [公式仕様](../../../documentation/schedule/reference) に含まれていなくてもかまいません。 + 追加のファイルとフィールドをGTFS scheduleデータセットに拡張して、交通事業者とソフトウェア ベンダーの間で伝えられるさまざまなアプリケーション固有のニーズに対応することがしてもよい。これらのフィールドが [公式仕様](../../../documentation/schedule/reference) に含まれていなくてもかまいません。 以下は、実装できるGTFS schedule拡張機能の一覧です。 @@ -25,6 +25,7 @@ For more information, contact [specifications@mobilitydata.org](mailto:specifica GTFS コミュニティと共有したい拡張機能をお持ちですか?こちらからGTFS.org に拡張機能を追加するようリクエストしてください。 +<<<<<<< Updated upstream

GTFS-Pathways

@@ -134,10 +135,127 @@ For more information, contact [specifications@mobilitydata.org](mailto:specifica
+======= +
+
+

GTFS-Pathways

+

MobilityDataによって管理されています

+
+
+ +
+
+ +
+
+

GTFS-Fares v2

+

MobilityDataによって管理されています

+
+
+ +
+
+ +
+
+

GTFSフレックス

+

MobilityDataによって管理されています

+
+
+ +
+
+ +
+
+

GTFS-Occupancies

+

MobilityDataによって管理されています

+
+
+ +
+
+ +
+
+

Google Transit の GTFS 拡張機能

+

Googleが管理

+
+
+ +
+
+ +
+
+

MTC GTFS+

+

MTCによって管理されています

+
+
+ +
+
+ +
+
+

MBTA

+

MBTAによって管理されています

+
+
+ +
+
+
+
+

GTFS-Eligibilities

+

オレゴン州運輸局が管理

+
+
+

GTFS-Eligibilitiesは、ユーザー アカウントに基づいて動作するシステムが、ユーザー アカウント情報に基づいて便が適格かどうかを判断できる方法を提供するという概念に基づいて形成されてするべきである。つまり、提案されているフィールドは次のものを提供します。

+ +
+
+
+
+

GTFS-Capabilities

+

オレゴン州運輸局が管理

+
+
+

障害のある人や移動装置を持つ人のためにサービスが提供してもよい追加機能について説明します。

+ +
+
+
+>>>>>>> Stashed changes === "GTFS realtime" - 追加のファイルとフィールドをGTFS realtimeフィードに拡張して、交通機関とソフトウェア ベンダーの間でやり取りされるさまざまなアプリケーション固有のニーズに対応することがしてもよい。これらのフィールドが [公式仕様](../../../documentation/realtime/reference) に含まれていなくてもかまいません。 + 追加のファイルとフィールドをGTFS realtimeフィードに拡張して、交通事業者とソフトウェア ベンダーの間でやり取りされるさまざまなアプリケーション固有のニーズに対応することがしてもよい。これらのフィールドが [公式仕様](../../../documentation/realtime/reference) に含まれていなくてもかまいません。 以下は、実装できるGTFS realtime拡張機能の一覧です。 @@ -173,4 +291,22 @@ For more information, contact [specifications@mobilitydata.org](mailto:specifica
+<<<<<<< Updated upstream +詳細については、[specifications@mobilitydata.org](mailto:specifications@mobilitydata.org)までお問い合わせください +======= +
+
+

GTFS-OccupancyStatus

+

MobilityDataによって管理されています

+
+
+ +
+
+ +
+ 詳細については、[specifications@mobilitydata.org](mailto:specifications@mobilitydata.org)までお問い合わせください +>>>>>>> Stashed changes diff --git a/docs/ja/community/get_involved.md b/docs/ja/community/get_involved.md index a1efc107..cd74d130 100644 --- a/docs/ja/community/get_involved.md +++ b/docs/ja/community/get_involved.md @@ -16,7 +16,7 @@ description: GTFS コミュニティに参加して、最新情報を入手し ## GTFS ガバナンス -GTFS 仕様は固定されたものではありません。GTFS を使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されるオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 +GTFS 仕様は固定されたものではありません。GTFS を使用する交通事業者、開発者、その他の関係者のコミュニティによって開発および保守されるオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 このプロセスを公式化するために、仕様修正プロセスを含む GTFS ガバナンス フレームワークを確立しました。 @@ -34,7 +34,7 @@ GTFS 仕様は固定されたものではありません。GTFS を使用する ## 拡張機能 -拡張機能は、関連するファイルとフィールドのコレクションで構成される仕様変更の提案です。これらのフィールドが公式仕様に含まれていなくても、交通機関とソフトウェア ベンダーの間で伝えられるさまざまなアプリケーション固有のニーズに対応するために、追加のファイルとフィールドを GTFS データセットに拡張できます。採用されると、拡張機能は機能セットとして公式仕様に統合され、文書化されます。 +拡張機能は、関連するファイルとフィールドのコレクションで構成される仕様変更の提案です。これらのフィールドが公式仕様に含まれていなくても、交通事業者とソフトウェア ベンダーの間で伝えられるさまざまなアプリケーション固有のニーズに対応するために、追加のファイルとフィールドを GTFS データセットに拡張できます。採用されると、拡張機能は機能セットとして公式仕様に統合され、文書化されます。
@@ -94,12 +94,12 @@ GTFS 仕様は固定されたものではありません。GTFS を使用する ### メーリング リスト -公共交通機関のデータ、ソフトウェア、GTFS や GTFS-realtime などの形式、その他の問題について質問がある場合に役立つメーリングリソースがいくつかあります。 +公共交通事業者のデータ、ソフトウェア、GTFS や GTFS-realtime などの形式、その他の問題について質問がある場合に役立つメーリングリソースがいくつかあります。 * [GTFS の変更](https://groups.google.com/group/gtfs-changes): [GTFS schedule修正プロセス](../../community/governance/gtfs_schedule_amendment_process) で概説されているGTFS schedule形式に関する投票に関する通知を受け取るには、このグループをフォローしてください。 * [GTFS Realtime](https://groups.google.com/group/gtfs-realtime): このグループは、[GTFS realtime仕様修正プロセス](../../community/governance/gtfs_realtime_amendment_process) に概説されているように、 GTFS realtimeについて話し合ったり、質問したり、変更を提案したりするための公式フォーラムです。 * [transit-developers](https://groups.google.com/group/transit-developers): 一般的な交通開発者の話し合い。 - * 多くの交通機関には、事業者固有の独自の開発者メーリング リストもあります。例: + * 多くの交通事業者には、事業者固有の独自の開発者メーリング リストもあります。例: * [NYC MTA](https://groups.google.com/group/mtadeveloperresources) * [オレゴン州ポートランド](https://groups.google.com/group/transit-developers-pdx) * [MBTA](https://groups.google.com/group/massdotdevelopers) diff --git a/docs/ja/community/governance/gtfs_realtime_amendment_process.md b/docs/ja/community/governance/gtfs_realtime_amendment_process.md index 90d30b35..7192e2a0 100644 --- a/docs/ja/community/governance/gtfs_realtime_amendment_process.md +++ b/docs/ja/community/governance/gtfs_realtime_amendment_process.md @@ -1,6 +1,6 @@ # GTFS realtime -GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS realtimeを使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFSGTFS realtimeデータのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。そのプロセスを管理できるように、次の手順とガイドラインが確立されています。 +GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS realtimeを使用する交通事業者、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFSGTFS realtimeデータのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。そのプロセスを管理できるように、次の手順とガイドラインが確立されています。 !!! 注 "" @@ -17,7 +17,7 @@ GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS - *試験的* フィールドが価値があり、プロデューサーとコンシューマーの両方がフィールドを使用していることを確認したら、以下の [仕様修正プロセス](#specification-amendment-process) に従います。 - *実験的* フィールドが、*実験的* フィールドとして承認されてから 2 年以内に [仕様修正プロセス](#specification-amendment-process) で採用されない場合は、[.proto ファイル](../../../documentation/realtime/proto/) ファイル内のフィールド値の横に`[deprecated=true]`を追加して非推奨になります`[deprecated=true]` ( `RESERVED`ではなく) を使用することで、すでにフィールドを採用しているプロデューサーとコンシューマーは、フィールドを使用から削除する必要がなくなります。さらに、フィールドは、 [仕様修正プロセス](#specification-amendment-process) 後の後続の投票で承認された場合 (追加のプロデューサーやコンシューマーがフィールドの使用を開始した場合など)、将来的に`非推奨ではなくなる`可能性があります。 - 1.新しいフィールドが単一のプロデューサーに固有であると見なされる場合、またはデータ タイプに関して紛争がある場合は、プロデューサーに [カスタム拡張機能](#extensions) を割り当てて、プロデューサーが独自のフィードでフィールドを使用できるようにします。可能であれば、拡張機能を避け、多くの機関に役立つフィールドをメイン仕様に追加して、断片化を回避し、コンシューマーが仕様のさまざまな拡張機能をサポートするための余分な作業を回避するべきである。 + 1.新しいフィールドが単一のプロデューサーに固有であると見なされる場合、またはデータ タイプに関して紛争がある場合は、プロデューサーに [カスタム拡張機能](#extensions) を割り当てて、プロデューサーが独自のフィードでフィールドを使用できるようにします。可能であれば、拡張機能を避け、多くの事業者に役立つフィールドをメイン仕様に追加して、断片化を回避し、コンシューマーが仕様のさまざまな拡張機能をサポートするための余分な作業を回避するべきである。 ## 仕様修正プロセス 1. プロトコル定義、仕様、ドキュメント ファイル (翻訳を除く) の関連部分をすべて更新した git ブランチを作成します。 @@ -50,12 +50,12 @@ GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS Google は、サポートされている言語に関連する翻訳を最終的に更新する責任がありますが、コミュニティからの純粋な翻訳のプル リクエストは歓迎されており、すべての編集コメントに対応次第受け入れられます。 ## 基本原則 -GTFS realtimeの当初のビジョンを維持するために、仕様を拡張する際に考慮すべき基本原則がいくつか確立されています。**フィードは、リアルタイムで効率的に生成および消費できる必要がするべきである。**リアルタイム情報は、効率的な処理を必要とする継続的かつ動的なデータ ストリームです。プロトコル バッファを仕様のベースとして選択したのは、開発者の使いやすさとデータ転送の効率性の点で適切なトレードオフを提供するためです。GTFS とは異なり、多くの機関がGTFS realtimeフィードを手動で編集するとは考えられません。プロトコル バッファの選択は、ほとんどのGTFS realtimeフィードがプログラムによって生成および消費されるという結論を反映しています。**この仕様は乗客情報に関するものです。**以前の GTFS と同様に、 GTFS realtimeは主に乗客情報に関係しています。つまり、仕様には何よりもまず、乗客向けのツールを強化するのに役立つ情報が含まれてするべきである。交通機関がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性がしてもよいます。GTFSGTFS realtimeはその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能性があります。**仕様の変更は下位互換性を保つするべきである。**仕様に機能を追加するときは、既存のフィードを無効にするような変更は避けたいと考えています。既存のフィード パブリッシャーがフィードに機能を追加したいと思うようになるまで、余分な作業を発生させたくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。プロトコル バッファを拡張するための規則により、ある程度の後方互換性が強制されます。ただし、後方互換性が損なわれる可能性のある既存のフィールドの意味の変更は避けたいと考えています。**推測による機能は推奨されません。**新しい機能を追加すると、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能を追加するように注意する必要があります。理想的には、新しい機能を使用する実際の交通機関のデータを生成し、それを読み取り、表示するソフトウェアを作成することで、提案はすべてテストされます。 +GTFS realtimeの当初のビジョンを維持するために、仕様を拡張する際に考慮すべき基本原則がいくつか確立されています。**フィードは、リアルタイムで効率的に生成および消費できる必要がするべきである。**リアルタイム情報は、効率的な処理を必要とする継続的かつ動的なデータ ストリームです。プロトコル バッファを仕様のベースとして選択したのは、開発者の使いやすさとデータ転送の効率性の点で適切なトレードオフを提供するためです。GTFS とは異なり、多くの事業者がGTFS realtimeフィードを手動で編集するとは考えられません。プロトコル バッファの選択は、ほとんどのGTFS realtimeフィードがプログラムによって生成および消費されるという結論を反映しています。**この仕様は乗客情報に関するものです。**以前の GTFS と同様に、 GTFS realtimeは主に乗客情報に関係しています。つまり、仕様には何よりもまず、乗客向けのツールを強化するのに役立つ情報が含まれてするべきである。交通事業者がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性がしてもよいます。GTFSGTFS realtimeはその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能性があります。**仕様の変更は下位互換性を保つするべきである。**仕様に機能を追加するときは、既存のフィードを無効にするような変更は避けたいと考えています。既存のフィード パブリッシャーがフィードに機能を追加したいと思うようになるまで、余分な作業を発生させたくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。プロトコル バッファを拡張するための規則により、ある程度の後方互換性が強制されます。ただし、後方互換性が損なわれる可能性のある既存のフィールドの意味の変更は避けたいと考えています。**推測による機能は推奨されません。**新しい機能を追加すると、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能を追加するように注意する必要があります。理想的には、新しい機能を使用する実際の交通事業者のデータを生成し、それを読み取り、表示するソフトウェアを作成することで、提案はすべてテストされます。 ## 拡張機能 プロデューサーがGTFS realtimeフィードにカスタム情報を追加できるようにするために、[プロトコル バッファの拡張機能](https://developers.google.com/protocol-buffers/docs/proto#extensions) を活用します。拡張機能を使用すると、プロトコル バッファ message 内に名前空間を定義できます。これにより、サードパーティの開発者は、元の proto 定義を変更することなく、追加のフィールドを定義できます。 -可能な場合は拡張機能を避け、多くの機関にとって有用なフィールドをメインの仕様に追加して、仕様の断片化と、仕様のさまざまな拡張機能をサポートするための消費者の余分な作業を回避するするべきであるがあります。拡張IDをリクエストする前に、プロデューサーは仕様にフィールドを追加することを提案するするべきである([GTFS realtimeへの新しいフィールドの追加](#adding-new-fields-to-gtfs-realtime)を参照) +可能な場合は拡張機能を避け、多くの事業者にとって有用なフィールドをメインの仕様に追加して、仕様の断片化と、仕様のさまざまな拡張機能をサポートするための消費者の余分な作業を回避するするべきであるがあります。拡張IDをリクエストする前に、プロデューサーは仕様にフィールドを追加することを提案するするべきである([GTFS realtimeへの新しいフィールドの追加](#adding-new-fields-to-gtfs-realtime)を参照) 9000～9999 の範囲内の拡張 ID は、GTFS-rt プロデューサーによるプライベート使用のために予約されています。これらの ID は、組織内で情報を伝達するためにのみ使用してください。この範囲の拡張は、パブリック フィードでは**使用しないでください**。 diff --git a/docs/ja/community/governance/gtfs_schedule_amendment_process.md b/docs/ja/community/governance/gtfs_schedule_amendment_process.md index a067a555..47db01e6 100644 --- a/docs/ja/community/governance/gtfs_schedule_amendment_process.md +++ b/docs/ja/community/governance/gtfs_schedule_amendment_process.md @@ -1,6 +1,6 @@ # GTFS schedule -GTFS 仕様は固定されたものではありません。GTFS を使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されるオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。そのプロセスを管理するために、次の手順とガイドラインが確立されています。 +GTFS 仕様は固定されたものではありません。GTFS を使用する交通事業者、開発者、その他の関係者のコミュニティによって開発および保守されるオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。そのプロセスを管理するために、次の手順とガイドラインが確立されています。 !!! note "" @@ -48,11 +48,11 @@ CSV を仕様のベースとして選択したのは、スプレッドシート フィード リーダーは、できるだけ少ない作業で、探している情報を抽出できるするべきである。するべきである。(ただし、最終的にはフィード リーダーよりもフィード パブリッシャーの数が多くなるため、作成を容易にするするべきである。) **この仕様は乗客情報についてです**
-GTFS は主に乗客情報に関係しています。つまり、仕様には、何よりもまず乗客のパワーツールに役立つ情報が含まれているするべきである。交通機関がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性があります。GTFS はその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能してもよいがあります。 +GTFS は主に乗客情報に関係しています。つまり、仕様には、何よりもまず乗客のパワーツールに役立つ情報が含まれているするべきである。交通事業者がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性があります。GTFS はその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能してもよいがあります。 **仕様の変更は下位互換性をするべきである**
仕様に機能を追加する際、既存のフィードを無効にするような変更は避けたいと考えています。既存のフィード パブリッシャーがフィードに機能を追加したいと思うまで、余分な作業を発生させたくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。 **推測的な機能は推奨されません**
-新しい機能が追加されるたびに、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能を追加するように注意する必要があります。理想的には、新しい機能を使用する実際の交通機関のデータを生成し、それを読み取り、表示するソフトウェアを作成して、すべての提案をテストする必要があります。GTFS では、公式のパーサーと検証ツールによって無視される追加の列とファイルを追加することで、形式を簡単に拡張できるため、提案を簡単にプロトタイプ化して既存のフィードでテストできます。 +新しい機能が追加されるたびに、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能を追加するように注意する必要があります。理想的には、新しい機能を使用する実際の交通事業者のデータを生成し、それを読み取り、表示するソフトウェアを作成して、すべての提案をテストする必要があります。GTFS では、公式のパーサーと検証ツールによって無視される追加の列とファイルを追加することで、形式を簡単に拡張できるため、提案を簡単にプロトタイプ化して既存のフィードでテストできます。
diff --git a/docs/ja/documentation/overview.md b/docs/ja/documentation/overview.md index 00ce345f..4de270cc 100644 --- a/docs/ja/documentation/overview.md +++ b/docs/ja/documentation/overview.md @@ -11,7 +11,7 @@ GTFS は、[GTFS schedule](../schedule/reference) と [GTFS realtime](../realtim ## [GTFS schedule](../schedule/reference) -GTFS scheduleは、静的な公共交通機関情報の共通形式を定義するフィード仕様です。これは、単一の ZIP ファイルに含まれる、主にTextファイル (.txt) の単純なファイルのコレクションで構成されています。 +GTFS scheduleは、静的な公共交通事業者情報の共通形式を定義するフィード仕様です。これは、単一の ZIP ファイルに含まれる、主にTextファイル (.txt) の単純なファイルのコレクションで構成されています。 各ファイルは、停留所等、ルート・路線系統、便などの交通情報の特定の側面を記述します。最も基本的な形式では、 GTFS scheduleデータセットは 7 つのファイルで構成されます: `agency.txt`、 `routes.txt`、 `trips.txt`、 `stops.txt`、 `stop_times.txt`、 `calendar.txt` 、および`calendar_dates.txt`ル` セットに加えて、追加の (任意の) ファイルをグループ化して、運賃、翻訳、乗り換え、駅構内構内通路などの他のサービス要素の情報を提供することもできます。現在、GTFS の基本要素を拡張する 15 を超える任意ファイルがあり、その中には、地理的なエリアを表すために使用できるTextファイル (.txt ) 以外の新しい形式を導入したlocations.geojsonも含まれます。 @@ -20,14 +20,14 @@ GTFS scheduleは、静的な公共交通機関情報の共通形式を定義す ## [GTFS realtime](../realtime/reference) -GTFS realtimeは、公共交通機関が現在の到着時刻と出発時刻、サービス アラート、車両のPositionに関する最新情報を提供できるようにするフィード仕様であり、ユーザーはスムーズに便を計画できます。 +GTFS realtimeは、公共交通事業者が現在の到着時刻と出発時刻、サービス アラート、車両のPositionに関する最新情報を提供できるようにするフィード仕様であり、ユーザーはスムーズに便を計画できます。 この仕様では現在、次の種類の情報がサポートされています。 -- 旅行の更新 - 遅延、キャンセル、ルート・路線系統変更 +- 便の更新 - 遅延、キャンセル、ルート・路線系統変更 - サービス アラート - 停留所の移動、駅、ルート、またはネットワーク全体に影響を及ぼす予期しないイベント - 車両の位置 - 場所や混雑レベルなどの車両に関する情報 詳細については、[フィード エンティティ](../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) に基づいて公開されていますGTFS realtimeデータ交換形式は [プロトコル バッファ](https://developers.google.com/protocol-buffers/) に基づいています。これは、構造化データをシリアル化する言語およびプラットフォームに依存しないメカニズムです (XML のようなものですが、より小さく、より高速で、よりシンプルです)。 GTFS scheduleと同様に、[GTFS realtimeリファレンス](../realtime/reference) は、あらゆるGTFS realtimeフィードのルールと要件を確立する信頼できる情報源であり、[gtfs-realtime.proto](../realtime/proto) ファイルは、使用される要素の階層とそのタイプ定義を定義します。 +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) に基づいて公開されていますGTFS realtimeデータ交換形式は [プロトコル バッファ](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 index 9c50cdad..98b5987e 100644 --- a/docs/ja/documentation/realtime/change_history/recent_additions.md +++ b/docs/ja/documentation/realtime/change_history/recent_additions.md @@ -1,6 +1,6 @@ # GTFS realtimeの変更 -GTFS realtimeリファレンスは固定されたものではありません。GTFS realtimeを使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFS realtimeデータのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 +GTFS realtimeリファレンスは固定されたものではありません。GTFS realtimeを使用する交通事業者、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFS realtimeデータのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 GTFSGTFS realtimeに貢献するには、[GTFS realtime修正プロセス](../../../../community/governance/gtfs_realtime_amendment_process)を読み、GTFS Github リポジトリ ( google/transit ) の未解決の問題とプルリクエストでの議論に従ってください。 ![](../../../assets/mark-github.svg) diff --git a/docs/ja/documentation/realtime/change_history/revision_history.md b/docs/ja/documentation/realtime/change_history/revision_history.md index d24eb31f..c325f3c2 100644 --- a/docs/ja/documentation/realtime/change_history/revision_history.md +++ b/docs/ja/documentation/realtime/change_history/revision_history.md @@ -8,7 +8,7 @@ #### 2022年11月 -* 削除された旅行のサポートを追加しました。[ディスカッション](https://github.com/google/transit/pull/352)を参照してください。 +* 削除された便のサポートを追加しました。[ディスカッション](https://github.com/google/transit/pull/352)を参照してください。 #### 2022年07月 @@ -52,7 +52,7 @@ #### 2020年3月12日 -* ブロック内の次の旅行についてTripUpdate予測を提供することを推奨します。 [ディスカッション](https://github.com/google/transit/pull/206)を参照してください。 +* ブロック内の次の便についてTripUpdate予測を提供することを推奨します。 [ディスカッション](https://github.com/google/transit/pull/206)を参照してください。 #### 2019年8月 diff --git a/docs/ja/documentation/realtime/examples/migration-duplicated.md b/docs/ja/documentation/realtime/examples/migration-duplicated.md index b68cfbf7..4fb283b2 100644 --- a/docs/ja/documentation/realtime/examples/migration-duplicated.md +++ b/docs/ja/documentation/realtime/examples/migration-duplicated.md @@ -1,10 +1,10 @@ ## 移行ガイド - ADDED から DUPLICATED の便への移行 -GTFS リアルタイムの `trip.schedule_relationship` の `DUPLICATED` は、サービス開始日時を除いて既存のスケジュールされた旅行と同じ新しい旅行を表します。 +GTFS リアルタイムの `trip.schedule_relationship` の `DUPLICATED` は、サービス開始日時を除いて既存のスケジュールされた便と同じ新しい便を表します。 -この移行ガイドでは、重複した旅行を表すために `ADDED` 列挙を使用していた既存のプロデューサーとコンシューマーが `DUPLICATED` 列挙に移行する方法を定義します。目標は、移行中にプロデューサーとコンシューマーの混乱を最小限に抑えることです。 +この移行ガイドでは、重複した便を表すために `ADDED` 列挙を使用していた既存のプロデューサーとコンシューマーが `DUPLICATED` 列挙に移行する方法を定義します。目標は、移行中にプロデューサーとコンシューマーの混乱を最小限に抑えることです。 -*重複した旅行を表すために `ADDED` 列挙を **使用していない** プロデューサーまたはコンシューマーの場合、アクションは必要ありません。`ADDED` エンティティを生成/消費することなく、`DUPLICATED` 旅行を生成/消費できます。* +*重複した便を表すために `ADDED` 列挙を **使用していない** プロデューサーまたはコンシューマーの場合、アクションは必要ありません。`ADDED` エンティティを生成/消費することなく、`DUPLICATED` 便を生成/消費できます。* `DUPLICATED` 列挙の完全な履歴については、[GitHub の `DUPLICATED` 提案](https://github.com/google/transit/pull/221) をご覧ください。 @@ -12,12 +12,12 @@ GTFS リアルタイムの `trip.schedule_relationship` の `DUPLICATED` は、 #### プロデューサー -重複した便に`ADDED`列挙を使用しているプロデューサーの場合、既存のコンシューマーの混乱を避けるため、これらの便に対して`ADDED`エンティティを生成し続けながら、同じ旅行に対して`DUPLICATED`エンティティも追加することを推奨。 +重複した便に`ADDED`列挙を使用しているプロデューサーの場合、既存のコンシューマーの混乱を避けるため、これらの便に対して`ADDED`エンティティを生成し続けながら、同じ便に対して`DUPLICATED`エンティティも追加することを推奨。 -ただし、ユーザーが誤って同じ旅行を 2 回追加するのを防ぐために、同じ旅行を参照するエンティティは同じ`trip_id` を使用してリンクされているしなければならない。2 つのエンティティは、次の 2 つの方法のいずれかでリンクできます。 +ただし、ユーザーが誤って同じ便を 2 回追加するのを防ぐために、同じ便を参照するエンティティは同じ`trip_id` を使用してリンクされているしなければならない。2 つのエンティティは、次の 2 つの方法のいずれかでリンクできます。 1. 両方のエンティティの `trip.trip_id` は同じである必要があります。または -2. `ADDED` 旅行の `trip.trip_id` は `DUPLICATED` 旅行の `trip_properties.trip_id` と同じである必要があります。 +2. `ADDED` 便の `trip.trip_id` は `DUPLICATED` 便の `trip_properties.trip_id` と同じである必要があります。 以下は、GTFS ` trip_id 1` を `trip.trip_id` を使用して複製する最初のオプション (1) の例です。 `ADDED`および`DUPLICATED`エンティティの`trip_id`の一致: @@ -93,14 +93,14 @@ entity { } ~~~ -既存のコンシューマーに、設定された期限までに重複した旅行に対する `ADDED` の使用が廃止され、代わりに `DUPLICATED` 旅行の使用を開始するよう通知することをお勧めします (開発者のメーリング リストなど)。`ADDED` と `DUPLICATED` 旅行エンティティを一致させるために使用されている上記の戦略についても言及し、この移行ガイドへのリンクを含める必要があります。期限が過ぎたら、フィードから `ADDED` エンティティを削除し、重複した旅行に対して `DUPLICATED` エンティティのみを公開できます。 +既存のコンシューマーに、設定された期限までに重複した便に対する `ADDED` の使用が廃止され、代わりに `DUPLICATED` 便の使用を開始するよう通知することをお勧めします (開発者のメーリング リストなど)。`ADDED` と `DUPLICATED` 便エンティティを一致させるために使用されている上記の戦略についても言及し、この移行ガイドへのリンクを含める必要があります。期限が過ぎたら、フィードから `ADDED` エンティティを削除し、重複した便に対して `DUPLICATED` エンティティのみを公開できます。 #### コンシューマー -前述のように、プロデューサーは、エンティティ間の ID を一致させるために上記の 2 つのオプションのいずれかを使用して、最初に重複した旅行ごとに 2 つのエンティティを公開することで、`ADDED` 列挙から `DUPLICATED` 列挙に移行します。 +前述のように、プロデューサーは、エンティティ間の ID を一致させるために上記の 2 つのオプションのいずれかを使用して、最初に重複した便ごとに 2 つのエンティティを公開することで、`ADDED` 列挙から `DUPLICATED` 列挙に移行します。 -したがって、コンシューマーが `DUPLICATED` 旅行のサポートを実装する場合、コンシューマーが次の点に注意することが重要です: +したがって、コンシューマーが `DUPLICATED` 便のサポートを実装する場合、コンシューマーが次の点に注意することが重要です: -1. `DUPLICATED` 旅行 `trip.trip_id` と同じ `trip.trip_id` を持つ `ADDED` 旅行を無視する +1. `DUPLICATED` 便 `trip.trip_id` と同じ `trip.trip_id` を持つ `ADDED` 便を無視する -1. `DUPLICATED` 旅行 `trip_properties.trip_id` と同じ `trip.trip_id` を持つ `ADDED` 旅行を無視する \ No newline at end of file +1. `DUPLICATED` 便 `trip_properties.trip_id` と同じ `trip.trip_id` を持つ `ADDED` 便を無視する \ No newline at end of file diff --git a/docs/ja/documentation/realtime/examples/trip-updates.md b/docs/ja/documentation/realtime/examples/trip-updates.md index 8e6cd3c6..05eca588 100644 --- a/docs/ja/documentation/realtime/examples/trip-updates.md +++ b/docs/ja/documentation/realtime/examples/trip-updates.md @@ -1,6 +1,6 @@ -# 旅行更新 +# 便更新 -次の例は、完全なデータセットの旅行更新フィードを表すASCII表現です。 +次の例は、完全なデータセットの便更新フィードを表すASCII表現です。 ```python # header information diff --git a/docs/ja/documentation/realtime/feed_entities/overview.md b/docs/ja/documentation/realtime/feed_entities/overview.md index 1b9faed7..7723a665 100644 --- a/docs/ja/documentation/realtime/feed_entities/overview.md +++ b/docs/ja/documentation/realtime/feed_entities/overview.md @@ -39,7 +39,7 @@ GTFS realtime は、単一のリアルタイムフィードに組み合わせる ## ルートの変更 -#### 「これらの旅行は特定の日に迂回する影響を受けます」 +#### 「これらの便は特定の日に迂回する影響を受けます」 ルートの変更は、一連の便に影響する迂回を説明するために使用されます。 diff --git a/docs/ja/documentation/realtime/feed_entities/service-alerts.md b/docs/ja/documentation/realtime/feed_entities/service-alerts.md index c8f00d89..2760ae64 100644 --- a/docs/ja/documentation/realtime/feed_entities/service-alerts.md +++ b/docs/ja/documentation/realtime/feed_entities/service-alerts.md @@ -1,6 +1,6 @@ # サービスアラート -サービスアラートを使用すると、ネットワークに混乱が生じたときに更新情報を提供できます。個々の便の遅延やキャンセルは、通常、[旅行の更新情報](../trip-updates)を使用して通信するするべきである。 +サービスアラートを使用すると、ネットワークに混乱が生じたときに更新情報を提供できます。個々の便の遅延やキャンセルは、通常、[便の更新情報](../trip-updates)を使用して通信するするべきである。 次の情報を提供するオプションがあります: @@ -20,10 +20,10 @@ エンティティは GTFS 識別子を使用して選択され、次のいずれかを選択できます。 -* 機関 - ネットワーク全体に影響します +* 事業者 - ネットワーク全体に影響します * ルート - ルート全体に影響します * ルート タイプ - このタイプのすべてのルートに影響します。例: すべての地下鉄 -* 旅行 - 特定の旅行に影響します +* 便 - 特定の便に影響します * 停留所 - 特定の停留所に影響します 1つの`informed_entity` に、上記のフィールドを複数含めることができます。1つの `informed_entity` に複数のフィールドが含まれている場合、それらは `AND` 論理演算子で結合されていると解釈されます。つまり、アラートは `informed_entity` で提供されるすべてのフィールドを満たすコンテキストでのみ適用する必要があります。たとえば、`route_id: "1"` と `stop_id: "5"` の両方が1つの `informed_entity` に含まれている場合、アラートはルート1の停留所5にのみ適用されます。ルート1の他の停留所には適用しないでください。また、他のルートの停留所5にも適用しないでください。 @@ -53,7 +53,7 @@ * サービスなし * サービス削減 -* 大幅な遅延(軽微な遅延は[旅行の更新](../trip-updates)を通じてのみ提供されするべきである)。 +* 大幅な遅延(軽微な遅延は[便の更新](../trip-updates)を通じてのみ提供されするべきである)。 * 迂回 * 追加サービス * サービス変更: 運行は、乗客が通常期待するものとは異なります。一例として、その曜日の通常のサービスとは異なる今後の休日スケジュールを乗客に通知するアラートが挙げられます。 diff --git a/docs/ja/documentation/realtime/feed_entities/trip-modifications.md b/docs/ja/documentation/realtime/feed_entities/trip-modifications.md index 63c22160..0dc427e6 100644 --- a/docs/ja/documentation/realtime/feed_entities/trip-modifications.md +++ b/docs/ja/documentation/realtime/feed_entities/trip-modifications.md @@ -1,4 +1,4 @@ -# 旅行の変更 +# 便の変更 `TripModifications` メッセージは、迂回などの特定の変更の影響を受ける、(CSV) GTFS からの類似の `trip_ids` のリストを識別します。 @@ -6,38 +6,38 @@ ## SLO: Service-level objective (サービスレベル目標) -データ更新の頻度は、約 1 時間ごと(1 日あたり約24回)になると予想されます。取り込み時間は、影響を受ける旅行の総数によって異なります。消費者は、1つの TripModification を5分以内に、数百の迂回を含むフィードを20分以内に取り込むことが予想されます。 +データ更新の頻度は、約 1 時間ごと(1 日あたり約24回)になると予想されます。取り込み時間は、影響を受ける便の総数によって異なります。消費者は、1つの TripModification を5分以内に、数百の迂回を含むフィードを20分以内に取り込むことが予想されます。 ## TripModifications -`TripModifications` は、フィードから削除されるまで、リストされているすべての service\_dates で有効です。特定のサービス日付では、1 つの旅行を複数の `TripModifications` オブジェクトに割り当てることはできません。 +`TripModifications` は、フィードから削除されるまで、リストされているすべての service\_dates で有効です。特定のサービス日付では、1 つの便を複数の `TripModifications` オブジェクトに割り当てることはできません。 -特定の停車パターンに対して複数の `TripModifications` が存在する場合があります。たとえば、迂回中に `propagated_modification_delay` が大幅に変更された場合など、旅行を複数の変更に分割することが望ましい場合があります。 +特定の停車パターンに対して複数の `TripModifications` が存在する場合があります。たとえば、迂回中に `propagated_modification_delay` が大幅に変更された場合など、便を複数の変更に分割することが望ましい場合があります。 -GTFS-TripModifications を通じて作成された旅行は、指定された各 `trip_id` を変更して置き換えますが、コピーや追加の実行は作成しません。変更は、静的 GTFS (CSV) が変更された場合のように、スケジュール情報に適用されます。 +GTFS-TripModifications を通じて作成された便は、指定された各 `trip_id` を変更して置き換えますが、コピーや追加の実行は作成しません。変更は、静的 GTFS (CSV) が変更された場合のように、スケジュール情報に適用されます。 -各代替旅行の予定停車時刻は、変更にリストされている変更を実行することで、影響を受ける旅行の予定停車時刻から作成されます。すべての停車時刻の `stop_sequence` は、1 から n までの新しい値に置き換えられます。最初の stop_time で 1 から始まり、旅程内の各停車ごとに 1 ずつ増加します。置き換え後の旅程のリアルタイムの到着/出発時刻を公開するには、`TripUpdate` メッセージを指定する必要があります。 +各代替便の予定停車時刻は、変更にリストされている変更を実行することで、影響を受ける便の予定停車時刻から作成されます。すべての停車時刻の `stop_sequence` は、1 から n までの新しい値に置き換えられます。最初の stop_time で 1 から始まり、旅程内の各停車ごとに 1 ずつ増加します。置き換え後の旅程のリアルタイムの到着/出発時刻を公開するには、`TripUpdate` メッセージを指定する必要があります。 ## Linkage to TripUpdates (TripUpdatesへのリンク) * TripUpdate は、TripUpdate の `TripDescriptor` 内の `ModifiedTripSelector` を使用して提供する必要があります。 -* TripUpdate が代替の旅程を参照する場合、消費者は静的 GTFS が TripModifications (代替の停車地の `arrival_time`、`departure_time`、`stop_sequence`、`stop_id` など) で変更されたかのように動作する必要があります。 +* TripUpdate が代替の旅程を参照する場合、消費者は静的 GTFS が TripModifications (代替の停留所の `arrival_time`、`departure_time`、`stop_sequence`、`stop_id` など) で変更されたかのように動作する必要があります。 * `ModifiedTripSelector` を提供する場合、`TripDescriptor` の他のフィールドは空のままにしておく必要があります。これは、`ModifiedTripSelector` 値を探していない消費者による混乱を避けるためです。 -* `ModifiedTripSelector` を使用して更新を提供する TripUpdate フィードには、TripModifications をサポートしていないクライアントを対象とする TripUpdate も含める必要があります。つまり、TripUpdate は 2 つあるはずです。1 つは変更された旅行 (`TripModifications` あり) を持つクライアント用、もう 1 つは変更されていない元の GTFS (`TripModifications` なし) を持つクライアント用です。 +* `ModifiedTripSelector` を使用して更新を提供する TripUpdate フィードには、TripModifications をサポートしていないクライアントを対象とする TripUpdate も含める必要があります。つまり、TripUpdate は 2 つあるはずです。1 つは変更された便 (`TripModifications` あり) を持つクライアント用、もう 1 つは変更されていない元の GTFS (`TripModifications` なし) を持つクライアント用です。 * `ModifiedTripSelector` を含む TripUpdate を提供することが、代替の停留所で予測を作成する唯一の方法です。 -* そのような TripUpdate が見つからない場合、元の `trip_id` の TripUpdate が変更後の旅行に適用されます。 +* そのような TripUpdate が見つからない場合、元の `trip_id` の TripUpdate が変更後の便に適用されます。 * この場合、使用される静的 GTFS 情報は、TripModifications が適用される前の静的 GTFS からのものである必要があります。 -* 以前の旅行と新しい変更後の旅行の間の共通の停留所ではリアルタイム情報を利用できますが、代替の停留所では ETA は利用できません。 +* 以前の便と新しい変更後の便の間の共通の停留所ではリアルタイム情報を利用できますが、代替の停留所では ETA は利用できません。 ## 変更 -`Modification` メッセージは、`start_stop_selector` から始まる、影響を受ける各旅行の変更について説明します。`Modification` によって置き換えられる停留所の時間は、0、1、または 1 個以上である可能性があります。変更の範囲は重複してはなりません。範囲は連続していてはいけません。この場合、2つの変更を1つにマージする必要があります。これらの停車時間は、`replacement_stops` で記述された各代替停車時間の新しい停車時間に置き換えられます。 +`Modification` メッセージは、`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) @@ -55,4 +55,4 @@ _伝播された迂回遅延は、変更の終了後にすべての停車場所 ![](/../assets/first_stop_reference.png) -変更が旅行の最初の停車地に影響する場合、その停車地は変更の参照停車地としても機能します。 \ No newline at end of file +変更が便の最初の停留所に影響する場合、その停留所は変更の参照停留所としても機能します。 \ No newline at end of file diff --git a/docs/ja/documentation/realtime/feed_entities/trip-updates.md b/docs/ja/documentation/realtime/feed_entities/trip-updates.md index 360995af..b0042d0a 100644 --- a/docs/ja/documentation/realtime/feed_entities/trip-updates.md +++ b/docs/ja/documentation/realtime/feed_entities/trip-updates.md @@ -8,8 +8,8 @@ 車両が同じブロック内で複数の便を担当している場合 (便とブロックの詳細については、[GTFS trips.txt](../../../schedule/reference/#tripstxt) を参照してください): -* フィードには、車両が現在提供している旅行の TripUpdate を含める必要があります。プロデューサーは、将来の旅行の予測の品質に自信がある場合は、この車両のブロックに現在の旅行の後の 1 つ以上の旅行の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdate を含めると、車両が 1 つの旅行から別の旅行に移行する際に乗客に予測が「突然表示される」のを回避でき、また、下流の旅行に影響する遅延 (既知の遅延が旅行間の予定の乗り継ぎ時間を超える場合など) を乗客に事前に通知できます。 -* それぞれの TripUpdate エンティティは、ブロックでスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、`trip_ids` が 1、2、3 で、すべて 1 つのブロックに属する旅行があり、車両が旅行 1、旅行 2、旅行 3 の順に移動する場合は、`trip_update` エンティティは任意の順序で表示できます。たとえば、旅行 2、旅行 1、旅行 3 の順で追加できます。 +* フィードには、車両が現在提供している便の TripUpdate を含める必要があります。プロデューサーは、将来の便の予測の品質に自信がある場合は、この車両のブロックに現在の便の後の 1 つ以上の便の TripUpdate を含めることが推奨されます。同じ車両に複数の TripUpdate を含めると、車両が 1 つの便から別の便に移行する際に乗客に予測が「突然表示される」のを回避でき、また、下流の便に影響する遅延 (既知の遅延が便間の予定の乗り継ぎ時間を超える場合など) を乗客に事前に通知できます。 +* それぞれの TripUpdate エンティティは、ブロックでスケジュールされている順序と同じ順序でフィードに追加する必要はありません。たとえば、`trip_ids` が 1、2、3 で、すべて 1 つのブロックに属する便があり、車両が便 1、便 2、便 3 の順に移動する場合は、`trip_update` エンティティは任意の順序で表示できます。たとえば、便 2、便 1、便 3 の順で追加できます。 ## StopTimeUpdate @@ -22,11 +22,11 @@ ...バスが実際に停留所 4 を午前 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 を参照する必要があります。旅行中に同じ stop_id を複数回訪問する場合は、その旅行のその stop_id のすべての StopTimeUpdates で stop_sequence を指定する必要があります。 +各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) は停留所にリンクされています。通常、これは GTFS stop_sequence または GTFS stop_id を使用して行うことができます。ただし、GTFS trip_id のない便の更新を提供する場合は、stop_sequence に値がないため、stop_id を指定する必要があります。stop_id は GTFS の stop_id を参照する必要があります。便中に同じ stop_id を複数回訪問する場合は、その便のその stop_id のすべての StopTimeUpdates で stop_sequence を指定する必要があります。 -更新では、[StopTimeEvent](../../reference/#message-stoptimeevent) を使用して、[StopTimeUpdates](../../reference/#message-stoptimeupdate) の停車地での **到着** および/または **出発** の正確なタイミングを提供できます。これには絶対的な**時間**または**遅延**（つまり、予定時刻からの秒単位のオフセット）のいずれかを含める必要があります。遅延は、運行更新が定期運行の GTFS 運行を参照する場合にのみ使用できます。頻度ベースの運行ではありません。この場合、時間は予定時刻 + 遅延に等しくする必要があります。[StopTimeEvent](../../reference/#message-stoptimeevent) とともに予測の**不確実性** を指定することもできます。これについては、ページの下の [不確実性](#uncertainty) セクションで詳しく説明します。 +更新では、[StopTimeEvent](../../reference/#message-stoptimeevent) を使用して、[StopTimeUpdates](../../reference/#message-stoptimeupdate) の停留所での **到着** および/または **出発** の正確なタイミングを提供できます。これには絶対的な**時間**または**遅延**（つまり、予定時刻からの秒単位のオフセット）のいずれかを含める必要があります。遅延は、運行更新が定期運行の GTFS 運行を参照する場合にのみ使用できます。頻度ベースの運行ではありません。この場合、時間は予定時刻 + 遅延に等しくする必要があります。[StopTimeEvent](../../reference/#message-stoptimeevent) とともに予測の**不確実性** を指定することもできます。これについては、ページの下の [不確実性](#uncertainty) セクションで詳しく説明します。 -各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) のデフォルトのスケジュール関係は**スケジュール** です。（これは、運行のスケジュール関係とは異なることに注意してください）。停車地点で停車しない場合はこれを**スキップ** に変更できます。運行の一部にリアルタイム データしかない場合は**データなし** に変更できます。 +各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) のデフォルトのスケジュール関係は**スケジュール** です。（これは、運行のスケジュール関係とは異なることに注意してください）。停留所点で停車しない場合はこれを**スキップ** に変更できます。運行の一部にリアルタイム データしかない場合は**データなし** に変更できます。 **更新は stop_sequence** (または、旅程内での stop_id の順序) で並べ替える必要があります。 @@ -34,11 +34,11 @@ **例 1** -20 の停車地がある旅行の場合、現在の停車地の stop_sequence の [StopTimeUpdate](../../reference/#message-stoptimeupdate) で到着遅延と出発遅延が 0 ([StopTimeEvents](../../reference/#message-stoptimeevent)) の場合、旅行は正確に時間どおりであることを意味します。 +20 の停留所がある便の場合、現在の停留所の stop_sequence の [StopTimeUpdate](../../reference/#message-stoptimeupdate) で到着遅延と出発遅延が 0 ([StopTimeEvents](../../reference/#message-stoptimeevent)) の場合、便は正確に時間どおりであることを意味します。 **例 2** -同じ旅行インスタンスに対して、3つの [StopTimeUpdates](../../reference/#message-stoptimeupdate) が提供されます: +同じ便インスタンスに対して、3つの [StopTimeUpdates](../../reference/#message-stoptimeupdate) が提供されます: * stop_sequence 3 の遅延は300秒 * stop_sequence 8 の遅延は60秒 @@ -53,14 +53,14 @@ ## TripDescriptor -TripDescriptor によって提供される情報は、更新する旅行のスケジュール関係によって異なります。設定できるオプションは多数あります: +TripDescriptor によって提供される情報は、更新する便のスケジュール関係によって異なります。設定できるオプションは多数あります: |_**値**_|_**コメント**_| |-----------|--------------| -| **Scheduled** | この旅行は GTFS スケジュールに従って実行されているか、またはそれと関連付けられるほど近いです。 | -| **Added** | この旅行はスケジュールされておらず、追加されました。たとえば、需要に対応するため、または故障した車両を交換するためです。 | -| **Unscheduled** | この旅行は実行されており、スケジュールに関連付けられることはありません。たとえば、スケジュールがなく、バスがシャトル サービスで実行される場合などです。 | -| **Canceled** | この旅行はスケジュールされていましたが、現在は削除されています。 | +| **Scheduled** | この便は GTFS スケジュールに従って実行されているか、またはそれと関連付けられるほど近いです。 | +| **Added** | この便はスケジュールされておらず、追加されました。たとえば、需要に対応するため、または故障した車両を交換するためです。 | +| **Unscheduled** | この便は実行されており、スケジュールに関連付けられることはありません。たとえば、スケジュールがなく、バスがシャトル サービスで実行される場合などです。 | +| **Canceled** | この便はスケジュールされていましたが、現在は削除されています。 | | **Duplicated** |この新しい旅程は、サービス開始日時を除いて、静的 GTFS の既存の旅程のコピーです。新しい旅程は、TripProperties で指定されたサービス日時で実行されます。| ほとんどの場合、この更新に関連する GTFS のスケジュールされた旅程の trip_id を指定する必要があります。 @@ -75,18 +75,18 @@ trip_id が重複するシステム (たとえば、frequencies.txt を使用し 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 を提供します。 +たとえば、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 によって一意に識別される場合もあります: +頻度ベースではない便は、次の組み合わせを含む TripDescriptor によって一意に識別される場合もあります: * __route_id__ * __direction_id__ * __start_time__ * __start_date__ -start_time は、静的スケジュールで定義されている予定の開始時刻です。ただし、提供された ID の組み合わせによって一意の旅行が解決される限りです。 +start_time は、静的スケジュールで定義されている予定の開始時刻です。ただし、提供された ID の組み合わせによって一意の便が解決される限りです。 ## 不確実性 diff --git a/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md b/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md index e5cecca2..53f91eb9 100644 --- a/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md +++ b/docs/ja/documentation/realtime/feed_entities/vehicle-positions.md @@ -2,11 +2,11 @@ 車両の位置は、車載 GPS デバイスなどから、車両の位置に関する自動生成された情報を提供するために使用されます。 提供可能なすべての車両に対して、1 つの車両の位置を提供する必要があります。 -車両が現在提供している旅行は、[TripDescriptor](../../reference/#message-tripdescriptor) を通じて提供する必要があります。 また、[VehicleDescriptor](../../reference/#message-vehicledescriptor) を提供することもできます。これは、更新情報を提供する正確な物理的な車両を指定します。 ドキュメントは以下にあります。 +車両が現在提供している便は、[TripDescriptor](../../reference/#message-tripdescriptor) を通じて提供する必要があります。 また、[VehicleDescriptor](../../reference/#message-vehicledescriptor) を提供することもできます。これは、更新情報を提供する正確な物理的な車両を指定します。 ドキュメントは以下にあります。 位置の読み取りが行われた時間を示す **timestamp** を提供できます。 これは、サーバーによってこのメッセージが生成された時間であるフィード ヘッダーのタイムスタンプとは異なることに注意してください。 -**現在の通路** も提供できます (`stop_sequence` または `stop_id` として)。これは、車両が向かっている、またはすでに停止している停車地への参照です。 +**現在の通路** も提供できます (`stop_sequence` または `stop_id` として)。これは、車両が向かっている、またはすでに停止している停留所への参照です。 ## 位置 @@ -20,7 +20,7 @@ ## CongestionLevel -車両位置により、機関は車両が現在経験している混雑レベルを指定することもできます。混雑は次のカテゴリに分類できます。 +車両位置により、事業者は車両が現在経験している混雑レベルを指定することもできます。混雑は次のカテゴリに分類できます。 * Unknown congestion level (混雑レベル不明) * Running smoothly (順調に走行中) @@ -28,11 +28,11 @@ * Congestion (混雑) * Severe congestion (深刻な混雑) -各タイプの混雑として分類するものは、機関によって分類されます。私たちのガイドラインでは、「深刻な渋滞」は、交通が混雑しすぎて人々が車を離れる状況でのみ使用されます。 +各タイプの混雑として分類するものは、事業者によって分類されます。私たちのガイドラインでは、「深刻な渋滞」は、交通が混雑しすぎて人々が車を離れる状況でのみ使用されます。 ## OccupancyStatus -車両の位置により、機関は車両の乗客の乗車率も指定できます。乗車状況は、次のカテゴリに分類できます。 +車両の位置により、事業者は車両の乗客の乗車率も指定できます。乗車状況は、次のカテゴリに分類できます。 * Empty (空席) * Many seats available (座席は多数) diff --git a/docs/ja/documentation/realtime/language-bindings/overview.md b/docs/ja/documentation/realtime/language-bindings/overview.md index dd427fa7..cd14662f 100644 --- a/docs/ja/documentation/realtime/language-bindings/overview.md +++ b/docs/ja/documentation/realtime/language-bindings/overview.md @@ -2,7 +2,7 @@ ## はじめに -[GTFS Realtime](https://github.com/google/transit/tree/master/gtfs-realtime) は、公共交通機関に関するリアルタイム情報を伝達するためのデータ形式です。GTFS 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](https://github.com/google/transit/tree/master/gtfs-realtime) は、公共交通事業者に関するリアルタイム情報を伝達するためのデータ形式です。GTFS 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-realtime データ モデル オブジェクトを構築してバイナリ データとしてシリアル化するために使用したり、逆にバイナリ データをデータ モデル オブジェクトに解析するために使用したりできます。 diff --git a/docs/ja/documentation/realtime/realtime_best_practices.md b/docs/ja/documentation/realtime/realtime_best_practices.md index 957cec6c..9494bc6d 100644 --- a/docs/ja/documentation/realtime/realtime_best_practices.md +++ b/docs/ja/documentation/realtime/realtime_best_practices.md @@ -2,7 +2,7 @@ ## はじめに -これらは、[GTFS realtime](../reference) データ形式でリアルタイムの公共交通機関情報を記述するための推奨プラクティスです。 +これらは、[GTFS realtime](../reference) データ形式でリアルタイムの公共交通事業者情報を記述するための推奨プラクティスです。 ### ドキュメントの構造 @@ -39,14 +39,14 @@ すべてのエンティティは、ユーザーにとって関連性がなくなった場合にのみ、 GTFS realtimeフィードから削除するするべきである。フィードはステートレスであると見なされます。つまり、各フィードは交通システムのリアルタイムの状態全体を反映します。あるフィード インスタンスでエンティティが提供され、その後のフィード更新で削除された場合、そのエンティティにはリアルタイムの情報がないものと見なすするべきである。 | フィールド名 | 推奨事項 | |---|---| -| `id` | 旅行期間全体にわたって安定しているするべきである | +| `id` | 便期間全体にわたって安定しているするべきである | ### TripUpdate -旅行キャンセルに関する一般的なガイドライン: +便キャンセルに関する一般的なガイドライン: -* 数日間にわたる旅行をキャンセルする場合、プロデューサーは、指定された `trip_ids` と `start_dates` を `CANCELED` として参照する TripUpdates と、同じ `trip_ids` と `TimeRange` を参照する `NO_SERVICE` を含む Alert を提供して、乗客にキャンセルの理由 (迂回など) を説明する必要があります。 -* 旅行中に停車地が 1 つも訪問されない場合は、すべての `stop_time_updates` を `SKIPPED` としてマークするのではなく、旅行を `CANCELED` にする必要があります。 +* 数日間にわたる便をキャンセルする場合、プロデューサーは、指定された `trip_ids` と `start_dates` を `CANCELED` として参照する TripUpdates と、同じ `trip_ids` と `TimeRange` を参照する `NO_SERVICE` を含む Alert を提供して、乗客にキャンセルの理由 (迂回など) を説明する必要があります。 +* 便中に停留所が 1 つも訪問されない場合は、すべての `stop_time_updates` を `SKIPPED` としてマークするのではなく、便を `CANCELED` にする必要があります。 | フィールド名 | 推奨事項 | |---|---| @@ -55,8 +55,8 @@ | `vehicle` | [メッセージ VehicleDescriptor](#vehicledescriptor) を参照してください。 | | | `VehiclePosition` フィードと `TripUpdate` フィードが別々に提供される場合、[TripDescriptor](#tripdescriptor) と [VehicleDescriptor](#vehicledescriptor) ID 値のペアリングは 2 つのフィード間で一致する必要があります。

たとえば、`VehiclePosition` エンティティに `vehicle_id:A` と `trip_id:4` がある場合、対応する `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` | この旅行の予測が更新された時刻を反映する必要があります。| +| |便の進行中は、すべての `TripUpdates` に、将来の到着または出発の予測時刻を含む `stop_time_update` が少なくとも 1 つ含まれている必要があります。[GTFS Realtime 仕様](../feed_entities/trip-updates/#stoptimeupdate) では、特定の便で予定到着時刻が将来の停留所を参照している場合 (つまり、車両が予定より早く停留所を通過している場合)、プロデューサーは過去の `StopTimeUpdate` を削除してはならないと規定されています。そうしないと、この停留所の更新がないと判断されます。| +| `timestamp` | この便の予測が更新された時刻を反映する必要があります。| | `delay` | `TripUpdate.delay` はスケジュールの偏差、つまり車両がスケジュールよりどれだけ進んでいるか/遅れているかの過去の観測値を表す必要があります。将来の停留所の予測は、`StopTimeEvent.delay` または `StopTimeEvent.time` を通じて提供される必要があります。| ### TripDescriptor @@ -78,16 +78,16 @@ | フィールド名 | 推奨事項 | |---|---| -| `id` | 旅行期間全体にわたって車両を一意かつ安定的に識別するするべきである | +| `id` | 便期間全体にわたって車両を一意かつ安定的に識別するするべきである | ### StopTimeUpdate | フィールド名 | 推奨事項 | |---|---| -| `stop_sequence` | `stop_sequence` は可能な限り指定します。`stop_id` とは異なり、`stop_times.txt` の GTFS 停車時刻に明確に解決されるためです。`stop_id` は、1 回の旅行で複数回発生することがあります (例: ループ ルート)。 | -| `arrival` | 連続する停車地間の到着時刻は増加する必要があります。同じにしたり、減少したりしないでください。 | -| | 乗り継ぎや停車時間が予想される場合は、到着 `time` ([StopTimeEvent](#stoptimeevent) で指定) は同じ停車地の出発 `time` より前である必要があります。それ以外の場合は、到着 `time` は出発 `time` と同じである必要があります。 | -| `departure` | 連続する停車地間の出発時刻は増加する必要があります。同じにしたり、減少したりしないでください。 | +| `stop_sequence` | `stop_sequence` は可能な限り指定します。`stop_id` とは異なり、`stop_times.txt` の GTFS 停車時刻に明確に解決されるためです。`stop_id` は、1 回の便で複数回発生することがあります (例: ループ ルート)。 | +| `arrival` | 連続する停留所間の到着時刻は増加する必要があります。同じにしたり、減少したりしないでください。 | +| | 乗り継ぎや停車時間が予想される場合は、到着 `time` ([StopTimeEvent](#stoptimeevent) で指定) は同じ停留所の出発 `time` より前である必要があります。それ以外の場合は、到着 `time` は出発 `time` と同じである必要があります。 | +| `departure` | 連続する停留所間の出発時刻は増加する必要があります。同じにしたり、減少したりしないでください。 | | |乗り継ぎ時間や停車時間が予想されない場合は、出発 `time` ([StopTimeEvent](#stoptimeevent) で指定) は同じ停留所の到着 `time` と同じである必要があります。それ以外の場合は、出発 `time` は到着 `time` より後である必要があります。 | ### StopTimeEvent @@ -108,7 +108,7 @@ ### Position -車両のPositionは、この`trip_id`に対して`DETOUR`の効果を持つアラートがない限り、現在の旅行の GTFS `shapes.txt`ら 200メートル以内である必要があります。 +車両のPositionは、この`trip_id`に対して`DETOUR`の効果を持つアラートがない限り、現在の便の GTFS `shapes.txt`ら 200メートル以内である必要があります。 ### アラート @@ -117,7 +117,7 @@ * `trip_id`と`start_time`が`exact_time=1`間隔内にある場合、`start_time` は間隔の開始よりも`headway_secs`の正確な倍数だけ後にするするべきである。 * 数日間にわたって便をキャンセルする場合、運行者は、指定された`trip_ids`と`start_dates` を`CANCELED`る` TripUpdates と、同じ`trip_ids`と`TimeRange`を参照する`NO_SERVICE`の` Alert を提供しするべきである、乗客にキャンセルの理由 (迂回など) を説明できるようにする必要があります。 * アラートが路線のすべての停留所等に影響する場合は、停留所ベースのアラートではなく、路線ベースのアラートを使用します。路線のすべての停留所にアラートを適用しないでください。 -* サービスアラートに文字数制限はありませんが、交通機関の乗客は多くの場合、モバイルデバイスでアラートを表示します。簡潔にしてください。 +* サービスアラートに文字数制限はありませんが、交通事業者の乗客は多くの場合、モバイルデバイスでアラートを表示します。簡潔にしてください。 | フィールド名 | 推奨事項 | |---|---| @@ -139,7 +139,7 @@ ### 目的GTFS realtimeのベスト プラクティスを維持する目的は、次のとおりです。 -* 公共交通機関アプリにおけるエンドユーザーの顧客エクスペリエンスを向上させる +* 公共交通事業者アプリにおけるエンドユーザーの顧客エクスペリエンスを向上させる * ソフトウェア デベロッパーがアプリケーション、製品、サービスを導入および拡張しやすくする ### 公開済みのGTFS realtimeのベスト プラクティスを提案または修正する方法 diff --git a/docs/ja/documentation/realtime/reference.md b/docs/ja/documentation/realtime/reference.md index 78dc3725..d56508c1 100644 --- a/docs/ja/documentation/realtime/reference.md +++ b/docs/ja/documentation/realtime/reference.md @@ -5,7 +5,7 @@ description: GTFS realtimeを詳しく調べて、リファレンス ドキュ # GTFS realtimeリファレンス -GTFSGTFS realtimeフィードを使用すると、交通機関は、サービスへの混乱 (駅の閉鎖、路線の運行停止、重大な遅延など)、車両の位置、到着予定時刻に関するリアルタイム情報を消費者に提供できます。 +GTFSGTFS realtimeフィードを使用すると、交通事業者は、サービスへの混乱 (駅の閉鎖、路線の運行停止、重大な遅延など)、車両の位置、到着予定時刻に関するリアルタイム情報を消費者に提供できます。 フィード仕様のバージョン 2.0 については、このサイトで説明され、ドキュメント化されています。有効なバージョンは`2.0`、`1.0`です。 @@ -13,7 +13,7 @@ GTFSGTFS realtimeフィードを使用すると、交通機関は、サービス ### 必須 -GTFS リアルタイム v2.0 以降では、*必須* 列は、交通機関データが有効で、使用するアプリケーションにとって意味をなすためにプロデューサーが提供するしなければならないフィールドを示します。 +GTFS リアルタイム v2.0 以降では、*必須* 列は、交通事業者データが有効で、使用するアプリケーションにとって意味をなすためにプロデューサーが提供するしなければならないフィールドを示します。 *必須* フィールドでは次の値が使用されます: @@ -131,49 +131,49 @@ GTFS リアルタイム v2.0 以降では、*必須* 列は、交通機関デー |------------------|------------|----------------|-------------------|-------------------| | **id** | [string](https://protobuf.dev/programming-guides/proto2/#scalar) | 必須 | 1つ | このエンティティのフィード固有の識別子。ID はIncrementalityサポートを提供するためだけに使用されます。フィードによって参照される実際のエンティティは、明示的なセレクターによって指定するしなければならない(詳細については、以下のEntitySelector を参照してください)。| | **is_deleted** | [bool](https://protobuf.dev/programming-guides/proto2/#scalar) | 任意 | 1つ | このエンティティを削除するかどうか。Incrementalityが DIFFERENTIAL のフィードに対してのみ指定する必要がするべきである。このフィールドは、Incrementalityが FULL_DATASET のフィードには指定するべきではない。 | -| **trip_update** | [TripUpdate](#message-tripupdate) | 条件付きで必須 | 1つ | 旅行の出発遅延に関するリアルタイムのデータ。trip_update、vehicle、alert、または shape のフィールドのうち少なくとも 1つを指定するしなければならない。これらのフィールドすべてを空にすることはできません。 | +| **trip_update** | [TripUpdate](#message-tripupdate) | 条件付きで必須 | 1つ | 便の出発遅延に関するリアルタイムのデータ。trip_update、vehicle、alert、または shape のフィールドのうち少なくとも 1つを指定するしなければならない。これらのフィールドすべてを空にすることはできません。 | | **vehicle** | [VehiclePosition](#message-vehicleposition) | 条件付きで必須 | 1つ | 車両のリアルタイムのPositionに関するデータ。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つを指定するしなければならない。これらのフィールドすべてを空にすることはできません。

**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来、正式に採用されるしてもよいがあります。 | +| **shape** | [形状](#message-shape) | 条件付きで必須 | 1つ | 迂回路などのリアルタイムで追加されたルート形状に関するデータ。trip_update、vehicle、alert、shape のフィールドのうち少なくとも 1つを指定するしなければならない。これらのフィールドすべてを空にすることはできません。

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

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

**注意:** このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 | +| **delay** | [int32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 便の現在のスケジュールの偏差。遅延は、予測が GTFS の既存のスケジュールと比較して指定される場合にのみ指定するするべきである。
遅延 (秒単位) は、正 (車両が遅れていることを意味する) または負 (車両が予定より進んでいることを意味する) になります。遅延が 0 の場合、車両は正確に時間通りであることを意味します。
StopTimeUpdates の遅延情報は、便レベルの遅延情報よりも優先されるため、便レベルの遅延は、 StopTimeUpdate遅延値が指定された便の次の停留所までのみ伝播されます。
フィード プロバイダーは、データの鮮度を評価するために、遅延値が最後に更新された日時を示すTripUpdate.timestamp 値を提供することを強くお勧めします。

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

**注意:** このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 | ### _message_ StopTimeEvent 単一の予測イベント (到着または出発) のタイミング情報。タイミングは、遅延および/または推定時間、および不確実性で構成されます。 * 遅延は、GTFS の既存のスケジュールを基準にして予測が示される場合に使用するべきである。 -* 時間は、予測スケジュールがあるかどうかに関係なく指定するするべきである。時間と遅延の両方が指定されている場合は、時間が優先されます (ただし、通常、スケジュールされた旅行に対して時間が指定されている場合は、GTFS のスケジュールされた時間 + 遅延に等しくするするべきである)。 +* 時間は、予測スケジュールがあるかどうかに関係なく指定するするべきである。時間と遅延の両方が指定されている場合は、時間が優先されます (ただし、通常、スケジュールされた便に対して時間が指定されている場合は、GTFS のスケジュールされた時間 + 遅延に等しくするするべきである)。 不確実性は、時間と遅延の両方に等しく適用されます。不確実性は、実際の遅延の予想される誤差を大まかに指定します (ただし、その正確な統計的意味はまだ定義されていません)。たとえば、コンピューターのタイミング制御下で運転される列車の場合、不確実性が 0 になることがあります。 @@ -187,10 +187,10 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき ### _message_ StopTimeUpdate -旅行中の特定の停車地の到着イベントや出発イベントのリアルタイム更新。[TripDescriptor](#message-tripdescriptor) および [旅行更新エンティティ](../../../documentation/realtime/feed_entities/trip-updates) ドキュメントの停車時間更新に関する一般的な説明も参照してください。 +便中の特定の停留所の到着イベントや出発イベントのリアルタイム更新。[TripDescriptor](#message-tripdescriptor) および [便更新エンティティ](../../../documentation/realtime/feed_entities/trip-updates) ドキュメントの停車時間更新に関する一般的な説明も参照してください。 過去と未来の両方のイベントの更新を提供できます。プロデューサーは過去のイベントを削除できますが、必須ではありません。 -更新はstop_sequenceまたは stop_id のいずれかを介して特定の停車地にリンクされるため、これらのフィールドのいずれかが必ず設定されているしなければならないます。1つの旅程で同じ stop_id を複数回訪れる場合は、その旅程のその stop_id のすべての StopTimeUpdates でstop_sequence を指定するするべきである。 +更新はstop_sequenceまたは stop_id のいずれかを介して特定の停留所にリンクされるため、これらのフィールドのいずれかが必ず設定されているしなければならないます。1つの旅程で同じ stop_id を複数回訪れる場合は、その旅程のその stop_id のすべての StopTimeUpdates でstop_sequence を指定するするべきである。 **フィールド** @@ -213,8 +213,8 @@ ScheduleRelationship の値に応じて、TripUpdate では以下を指定でき | _**値**_ | _**コメント**_ | |-------------|---------------| |**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 が設定されている場合は、到着も出発も指定しないでするべきである。| +|**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 @@ -230,7 +230,7 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア ### _message_ TripProperties -旅行の更新されたプロパティを定義します +便の更新されたプロパティを定義します **注意:** このmessageはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。
. @@ -238,9 +238,9 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|---------------------------|----------------|-------------------|-------------------| -|**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://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 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`の場合に必須。それ以外の場合、このフィールドに値を入力するしてはいけない、消費者によって無視されます。

**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 | +|**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://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 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 @@ -251,17 +251,17 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|---------------------------|----------------|-------------------|-------------------| -|**trip**| [TripDescriptor](#message-tripdescriptor) |任意| 1つ | この車両がサービスを提供している旅行。特定の旅行インスタンスで車両を識別できない場合は、空または一部にすることができます。| -|**vehicle**| [VehicleDescriptor](#message-vehicledescriptor) |任意| 1つ | この旅行を提供している車両に関する追加情報。各エントリには、**一意の**車両IDがするべきである。| +|**trip**| [TripDescriptor](#message-tripdescriptor) |任意| 1つ | この車両がサービスを提供している便。特定の便インスタンスで車両を識別できない場合は、空または一部にすることができます。| +|**vehicle**| [VehicleDescriptor](#message-vehicledescriptor) |任意| 1つ | この便を提供している車両に関する追加情報。各エントリには、**一意の**車両IDがするべきである。| |**position**| [Position](#message-position) |任意| 1つ | この車両の現在のPosition。| -|**current_stop_sequence**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 現在の停車地の停車シーケンス インデックス。current_stop_sequence の意味 (つまり、それが参照する停車地) は、current_status によって決まります。current_status が指定されていない場合は、IN_TRANSIT_TO が指定されたものとみなされます。| -|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 現在の停車地を識別します。値は、対応する GTFS フィード内のstops.txtの値と同じであるしなければならない。`StopTimeProperties.assigned_stop_id` を使用して`StopTimeProperties.assigned_stop_id` `stop_id` を割り当てる場合、このフィールドも`stop_id`の変更を反映するするべきである。| +|**current_stop_sequence**| [uint32](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 現在の停留所の停車シーケンス インデックス。current_stop_sequence の意味 (つまり、それが参照する停留所) は、current_status によって決まります。current_status が指定されていない場合は、IN_TRANSIT_TO が指定されたものとみなされます。| +|**stop_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | 現在の停留所を識別します。値は、対応する GTFS フィード内のstops.txtの値と同じであるしなければならない。`StopTimeProperties.assigned_stop_id` を使用して`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つ | 車両のPositionが測定された瞬間。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 フィールドの出現回数は、車両の客車数を表します。また、機関車、保守用車両など、乗客がプラットフォームのどこに立つべきかに関する貴重な情報を提供する、乗車できない車両も含まれます。

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

**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 | ### _enum_ VehicleStopStatus @@ -330,7 +330,7 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア ### _message_ Alert -公共交通機関ネットワークで何らかのインシデントが発生したことを示すアラート。 +公共交通事業者ネットワークで何らかのインシデントが発生したことを示すアラート。 **フィールド** @@ -339,9 +339,9 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア |**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 も含めるしなければならない。

**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。 +|**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 も含めるしなければならない。

**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよい性があります。 +|**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は、アラートの本文としてフォーマットされます (または、ユーザーによる明示的な`展開`要求で表示されます)。説明の情報は、ヘッダーの情報に追加されるするべきである。| @@ -435,17 +435,17 @@ GTFS stop_times.txt内で定義されている特定のプロパティのリア ### _message_ TripDescriptor -GTFS 旅行の単一のインスタンスを識別する記述子。 +GTFS 便の単一のインスタンスを識別する記述子。 -単一の旅行インスタンスを指定するには、多くの場合、`trip_id`だけで十分です。ただし、次の場合には、単一の旅行インスタンスを解決するために追加の情報が必要です: +単一の便インスタンスを指定するには、多くの場合、`trip_id`だけで十分です。ただし、次の場合には、単一の便インスタンスを解決するために追加の情報が必要です: * frequencies.txtで定義されている便の場合、`trip_id`に加えて`start_date`と`start_time`が必須。 -* 旅行が 24 時間以上続く場合、または翌日の予定旅行と重なるように遅れる場合は、`trip_id`に加えて`start_date`が必須です。 +* 便が 24 時間以上続く場合、または翌日の予定便と重なるように遅れる場合は、`trip_id`に加えて`start_date`が必須です。 * `trip_id`フィールドを指定できない場合は、`route_id`、`direction_id`、`start_date`、および`start_time` をすべて指定するしなければならない。 -すべての場合において、`trip_id`に加えて`trip_id` `route_id`を指定する場合、`route_id`は` GTFS trips.txtで特定の旅行に割り当てられた`route_id`と同じであるしなければならないがあります。 +すべての場合において、`trip_id`に加えて`trip_id` `route_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` フィールドは、単独でも、または次のフィールドと組み合わせても、他の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を使用してください。 @@ -458,11 +458,11 @@ trip_idが不明な場合は、 TripUpdateの駅シーケンス 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://protobuf.dev/programming-guides/proto2/#scalar) |条件付きで必須| 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`フィールドはコンシューマーによって無視されます。 +|**schedule_relationship**| [ScheduleRelationship](#enum-schedulerelationship_1) |任意| 1つ | この便と静的スケジュールの関係。TripDescriptorがAlert `EntitySelector`で指定されている場合、一致する便インスタンスを識別するときに、`schedule_relationship`フィールドはコンシューマーによって無視されます。 ### _enum_ ScheduleRelationship -この旅行と静的スケジュールの関係。旅程が GTFS に反映されていない臨時スケジュールに従って行われる場合、SCHEDULED ではなく ADDED としてマークする必要があります。 +この便と静的スケジュールの関係。旅程が GTFS に反映されていない臨時スケジュールに従って行われる場合、SCHEDULED ではなく ADDED としてマークする必要があります。 **値** @@ -473,11 +473,11 @@ trip_idが不明な場合は、 TripUpdateの駅シーケンス ID では不十 | **UNSCHEDULED** | スケジュールが関連付けられていない運行中の旅程 - この値は、GTFS frequencies.txt で exact_times = 0 に定義されている旅程を識別するために使用されます。GTFS frequencies.txt で定義されていない旅程や、GTFS frequencies.txt で exact_times = 1 に定義されている旅程を説明するために使用しないでください。`schedule_relationship: UNSCHEDULED` の旅程では、すべての StopTimeUpdates も `schedule_relationship: UNSCHEDULED` に設定する必要があります。| | **CANCELED** | スケジュールに存在していたが削除された旅程。| | **DUPLICATED** | サービス開始日時を除き、既存のスケジュールされた旅程と同じ新しい旅程。 `TripUpdate.TripProperties.trip_id`、`TripUpdate.TripProperties.start_date`、および `TripUpdate.TripProperties.start_time` と一緒に使用して、静的 GTFS から既存の旅程をコピーしますが、開始日は異なるサービス日付および/または時刻にします。(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 を使用する必要があります。たとえば、旅行が別の旅行に完全に置き換えられる場合などです。この指定は、複数の旅行がキャンセルされ、代替サービスに置き換えられる場合に特に重要になります。消費者がキャンセルに関する明確な情報を表示すると、より重要なリアルタイム予測が妨げられます。

**注意:** このフィールドはまだ **実験的** であり、変更される可能性があります。将来正式に採用される可能性があります。| +| **DELETED** | スケジュールに存在していたが削除された旅程で、ユーザーに表示してはいけません。

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

**注意:** このフィールドはまだ **実験的** であり、変更される可能性があります。将来正式に採用される可能性があります。| ### _message_ VehicleDescriptor -旅行を実行する車両の識別情報。 +便を実行する車両の識別情報。 **フィールド** @@ -490,16 +490,16 @@ trip_idが不明な場合は、 TripUpdateの駅シーケンス ID では不十 ### _enum_ WheelchairAccessible -特定の旅行が車椅子でアクセス可能かどうか。利用可能な場合、この値は静的 GTFS の _wheelchair_accessible_ 値を上書きするべきである。 +特定の便が車椅子でアクセス可能かどうか。利用可能な場合、この値は静的 GTFS の _wheelchair_accessible_ 値を上書きするべきである。 **値** | _**値**_ | _**コメント**_ | |-------------|---------------| -| **NO_VALUE** | 旅行には車椅子でのアクセスに関する情報がありません。これは**デフォルト**の動作です。静的 GTFS に _wheelchair_accessible_ 値が含まれている場合、上書きされません。| -| **UNKNOWN** | 旅行にはアクセシビリティ値がありません。この値により、GTFS の値が上書きされます。| -| **WHEELCHAIR_ACCESSIBLE** | 旅行には車椅子でアクセスできます。この値により、GTFS の値が上書きされます。| -| **WHEELCHAIR_INACCESSIBLE** | 旅行には車椅子でアクセスできません。この値により、GTFS の値が上書きされます。| +| **NO_VALUE** | 便には車椅子でのアクセスに関する情報がありません。これは**デフォルト**の動作です。静的 GTFS に _wheelchair_accessible_ 値が含まれている場合、上書きされません。| +| **UNKNOWN** | 便にはアクセシビリティ値がありません。この値により、GTFS の値が上書きされます。| +| **WHEELCHAIR_ACCESSIBLE** | 便には車椅子でアクセスできます。この値により、GTFS の値が上書きされます。| +| **WHEELCHAIR_INACCESSIBLE** | 便には車椅子でアクセスできません。この値により、GTFS の値が上書きされます。| ### _message_ EntitySelector @@ -561,7 +561,7 @@ Textのスニペットまたは URL の言語別バージョンを含む国際 ### _message_ Shape -シェイプが (CSV) GTFS の一部ではない場合 (アドホック迂回など) に車両がたどる物理的な経路を説明します。ルート形状は便に属し、より効率的な送信のためにエンコードされたポリラインで構成されます。ルート形状は停留所等の位置を正確に横切る必要はありませんが、トリップ上のすべての停留所等は、そのトリップのシェイプからわずかな距離内、つまりシェイプ ポイントを結ぶ直線セグメントの近くに配置するするべきである。 +形状が (CSV) GTFS の一部ではない場合 (アドホック迂回など) に車両がたどる物理的な経路を説明します。ルート形状は便に属し、より効率的な送信のためにエンコードされたポリラインで構成されます。ルート形状は停留所等の位置を正確に横切る必要はありませんが、トリップ上のすべての停留所等は、そのトリップの形状からわずかな距離内、つまり形状 ポイントを結ぶ直線セグメントの近くに配置するするべきである。 **注意:** このmessageはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 @@ -569,8 +569,8 @@ Textのスニペットまたは URL の言語別バージョンを含む国際 | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|------------|----------------|-------------------|-------------------| -|**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 をご覧ください。

**注意:** このフィールドはまだ**試験的**であり、変更される可能性があります。将来正式に採用されるしてもよい。| +|**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_ Stop @@ -609,43 +609,43 @@ Textのスニペットまたは URL の言語別バージョンを含む国際 ### _message_ TripModifications -「TripModifications」メッセージは、迂回などの特定の変更によって影響を受ける類似の旅行のリストを識別します。 +「TripModifications」メッセージは、迂回などの特定の変更によって影響を受ける類似の便のリストを識別します。 **注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 -[旅行の変更についての詳細...](../../../documentation/realtime/feed_entities/trip-modifications) +[便の変更についての詳細...](../../../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) |必須| 多数 |Modificationが発生する日付 (YYYYMMDD 形式)。trip_idは、特定のサービスdateに実行される場合にのみ変更されます。旅行はすべての運行日に実行する必須はありません。プロデューサーは、次の 1 週間以内に発生する迂回のみを送信する必要がするべきである。提供された日付は、ユーザー向けの情報として使用しするべきではない。ユーザー向けの開始日と終了dateを提供する必要がある場合は、リンクされたサービスアラートで `service_alert_id` を使用して提供できます。 | +|**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) |必須| 多数 |Modificationが発生する日付 (YYYYMMDD 形式)。trip_idは、特定のサービスdateに実行される場合にのみ変更されます。便はすべての運行日に実行する必須はありません。プロデューサーは、次の 1 週間以内に発生する迂回のみを送信する必要がするべきである。提供された日付は、ユーザー向けの情報として使用しするべきではない。ユーザー向けの開始日と終了dateを提供する必要がある場合は、リンクされたサービスアラートで `service_alert_id` を使用して提供できます。 | |**modifications**| [Modification](#message-modification) |必須| 多数 | 影響を受ける便に適用する変更のリスト。 | ### _message_ Modification -`Modification`メッセージは、`start_stop_selector` から始まる、影響を受ける各旅行に対する変更を説明します。 +`Modification`メッセージは、`start_stop_selector` から始まる、影響を受ける各便に対する変更を説明します。 **注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 -特定の旅行に対するModificationの効果を示す例。このModificationは、他のいくつかの便にも適用されるしてもよい。_ +特定の便に対するModificationの効果を示す例。このModificationは、他のいくつかの便にも適用されるしてもよい。_ -伝播された迂回遅延は、Modificationの終了後にすべての停留所等に影響します。旅行に複数の変更がある場合、遅延は累積されます。 +伝播された迂回遅延は、Modificationの終了後にすべての停留所等に影響します。便に複数の変更がある場合、遅延は累積されます。 **フィールド** | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|------------|----------------|-------------------|-------------------| -|**start_stop_selector**| [StopSelector](#message-stopselector) |必須| 1つ | このModificationによって影響を受ける元の旅行の最初の停車地の停車地セレクター。`end_stop_selector` と組み合わせて使用​​します。`start_stop_selector` は必須であり、`travel_time_to_stop` で使用される参照停車地を定義するために使用されます。詳細については、[`travel_time_to_stop`](#message-replacementstop) を参照してください | -|**end_stop_selector**| [StopSelector](#message-stopselector) |条件付きで必須| 1つ | このModificationによって影響を受ける元の旅行の最後の停車地の停車地セレクター。選択は包括的であるため、そのModificationによって 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つ |Modificationによって挿入された最後の停車地の後のすべての出発時刻と到着時刻に追加する遅延の秒数。Modificationがシェイプのみに影響する場合 (つまり、`end_stop_selector` も `replacement_stops` も指定されていない場合)、遅延の伝播は `start_stop_selector` の後続の停車地で始まります。正または負の数値を指定できます。同じ旅行に複数の変更が適用されると、旅行が進むにつれて遅延が蓄積されます。

値が指定されていない場合、コンシューマーは他のデータに基づいて `propagated_modification_delay` を補間または推測するしてもよいがあります。 | -|**replacement_stops**| [ReplacementStop](#message-replacementstop) |任意| 複数 | 元の旅行の停留所を置き換える、代替の停留所等のリスト。新しい停車時刻の長さは、置き換えられた停車時刻の数よりも短くなったり、同じになったり、長くなったりするしてもよい。 | +|**start_stop_selector**| [StopSelector](#message-stopselector) |必須| 1つ | このModificationによって影響を受ける元の便の最初の停留所の停留所セレクター。`end_stop_selector` と組み合わせて使用​​します。`start_stop_selector` は必須であり、`travel_time_to_stop` で使用される参照停留所を定義するために使用されます。詳細については、[`travel_time_to_stop`](#message-replacementstop) を参照してください | +|**end_stop_selector**| [StopSelector](#message-stopselector) |条件付きで必須| 1つ | このModificationによって影響を受ける元の便の最後の停留所の停留所セレクター。選択は包括的であるため、そのModificationによって 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つ |Modificationによって挿入された最後の停留所の後のすべての出発時刻と到着時刻に追加する遅延の秒数。Modificationが形状のみに影響する場合 (つまり、`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つ |このタイムスタンプは、Modificationが最後に行われた瞬間を識別します。POSIX 時間 (つまり、1970 年 1 月 1 日 00:00:00 UTC からの秒数) です。| @@ -664,7 +664,7 @@ Textのスニペットまたは URL の言語別バージョンを含む国際 ### _message_ SelectedTrips -関連するシェイプを持つ選択された便のリスト。 +関連する形状を持つ選択された便のリスト。

**注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 @@ -673,21 +673,21 @@ Textのスニペットまたは URL の言語別バージョンを含む国際 | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|------------|----------------|-------------------|-------------------| |**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で定義されている既存のシェイプを参照するしてもよいます。| +|**shape_id**| [string](https://protobuf.dev/programming-guides/proto2/#scalar) |必須| 1つ |このSelectedTripsで変更された便の新しい形状のID-RT Shapemessageを使用して追加された新しい形状、または GTFS-Static フィードのshapes.txtで定義されている既存の形状を参照するしてもよいます。| ### _message_ ReplacementStop -各 `ReplacementStop` メッセージは、旅行で訪問する停留所を定義し、オプションで停留所までの推定移動時間を指定します。 +各 `ReplacementStop` メッセージは、便で訪問する停留所を定義し、オプションで停留所までの推定移動時間を指定します。 **注意:** このフィールドはまだ**実験的**であり、変更される可能性があります。将来正式に採用されるしてもよいがあります。 -Modificationが旅程の最初の停車地に影響する場合、その停車地はModificationの参照停車地としても機能します。 +Modificationが旅程の最初の停留所に影響する場合、その停留所はModificationの参照停留所としても機能します。 **フィールド** | _**フィールド名**_ | _**タイプ**_ | _**必須**_ | _**カーディナリティ**_ | _**説明**_ | |------------------|------------|----------------|-------------------|-------------------| -|**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://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | この停留所への到着時間と参照停留所への到着時間の差 (秒単位)。参照停留所は、`start_stop_selector` の前の停留所です。Modificationが旅行の最初の停留所で開始される場合、旅行の最初の停留所が参照停留所になります。

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

値が指定されていない場合、消費者は他のデータに基づいて `travel_time_to_stop` を補間または推測するしてもよい。| \ No newline at end of file +|**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://protobuf.dev/programming-guides/proto2/#scalar) |任意| 1つ | この停留所への到着時間と参照停留所への到着時間の差 (秒単位)。参照停留所は、`start_stop_selector` の前の停留所です。Modificationが便の最初の停留所で開始される場合、便の最初の停留所が参照停留所になります。

この値は単調に増加するしなければならないがあり、元の便の最初の停留所が参照停留所である場合にのみ負の数になるしてもよい。

値が指定されていない場合、消費者は他のデータに基づいて `travel_time_to_stop` を補間または推測するしてもよい。| \ No newline at end of file diff --git a/docs/ja/documentation/schedule/change_history/recent_additions.md b/docs/ja/documentation/schedule/change_history/recent_additions.md index 44ff9486..b58ae33f 100644 --- a/docs/ja/documentation/schedule/change_history/recent_additions.md +++ b/docs/ja/documentation/schedule/change_history/recent_additions.md @@ -1,6 +1,6 @@ # GTFS scheduleの変更 -GTFS スケジュール リファレンスは、固定されたものではありません。GTFS を使用する交通機関、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 +GTFS スケジュール リファレンスは、固定されたものではありません。GTFS を使用する交通事業者、開発者、その他の関係者のコミュニティによって開発および保守されているオープン仕様です。GTFS データのプロデューサーとコンシューマーのこのコミュニティは、新しい機能を有効にするために仕様を拡張するための提案をすることが期待されています。 GTFS に貢献するには、[GTFS スケジュール修正プロセス](../../../../community/governance/gtfs_schedule_amendment_process) を読み、GTFS Github リポジトリ (google/transit) のオープンな 問題 と プル リクエスト での議論に従ってください。 ![](../../../assets/mark-github.svg) @@ -31,7 +31,7 @@ GTFS に貢献するには、[GTFS スケジュール修正プロセス](../../.
@@ -101,8 +101,8 @@ GTFS に貢献するには、[GTFS スケジュール修正プロセス](../../. diff --git a/docs/ja/documentation/schedule/change_history/revision_history.md b/docs/ja/documentation/schedule/change_history/revision_history.md index e4fab58e..bf0eead3 100644 --- a/docs/ja/documentation/schedule/change_history/revision_history.md +++ b/docs/ja/documentation/schedule/change_history/revision_history.md @@ -7,20 +7,20 @@ * GeoJSON ファイルのポリゴンの有効性ルールを追加しました。[ディスカッション](https://github.com/google/transit/pull/476) を参照してください。 #### 2024年8月 -* 需要対応型サービスのため、stops.txt の存在を変更します。[ディスカッション](https://github.com/google/transit/pull/472) を参照してください。 +* デマンドサービスのため、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) を参照してください。 +* 形状を含める必要があることを追加しました。[ディスカッション](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) を参照してください。 +* チケット商品の定義を明確にしました。[ディスカッション](https://github.com/google/transit/pull/426) を参照してください。 #### 2024年3月 * GTFS Flex を追加しました。[ディスカッション](https://github.com/google/transit/pull/433) をご覧ください。 @@ -36,7 +36,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) を参照してください。 +* 停車時刻を指定します。shape_dist_traveled は、トリップ 形状の最大距離を超えてはいけません。[ディスカッション](https://github.com/google/transit/pull/380) を参照してください。 * ベスト プラクティス: 推奨プレゼンスを追加します。[ディスカッション](https://github.com/google/transit/pull/386) を参照してください。 #### 2023年3月14日 @@ -122,7 +122,7 @@ #### 2019年6月25日 -* シェイプ ポイントと停留所の関係を明確にしました。[ディスカッション](https://github.com/google/transit/pull/39) を参照してください。 +* 形状 ポイントと停留所の関係を明確にしました。[ディスカッション](https://github.com/google/transit/pull/39) を参照してください。 #### 2019年4月4日 @@ -226,7 +226,7 @@ #### 2009年3月30日 -* 交通機関フィードを一般公開するための新しいセクション。これは、データの解釈方法や記述方法に厳密に変更を加えるものではないため、これまでグループで議論されていませんでした。ただし、GTFS 形式のデータを使用できるアプリケーションが増えているため、Google 以外の GTFS の使用に関する議論を含めることが有益であると考える Google スタッフもいました。 +* 交通事業者フィードを一般公開するための新しいセクション。これは、データの解釈方法や記述方法に厳密に変更を加えるものではないため、これまでグループで議論されていませんでした。ただし、GTFS 形式のデータを使用できるアプリケーションが増えているため、Google 以外の GTFS の使用に関する議論を含めることが有益であると考える Google スタッフもいました。 * CSV 形式の明確化: [ディスカッション](https://groups.google.com/forum/#!topic/gtfs-changes/03qz5aTA2mk)。 * route_color フィールドと route_text_color フィールドの説明で対照的な色を選択する方法に関する追加のガイダンス。 * trip_short_name。これらのスレッドで提案され、テストされたとおり: a および b。 @@ -249,7 +249,7 @@ #### 2008年8月6日 * transfers.txt ファイルを追加しました。フィード パブリッシャーが望ましい乗り換え動作に関するヒントを提供できるようにしました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/cL1E4oKKpKw)) -* stops.txt に location_type および parent_station フィールドを追加しました。これにより、停車地点を駅にグループ化できるようになりました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/ScGAyZ9a_yw)) +* stops.txt に location_type および parent_station フィールドを追加しました。これにより、停留所点を駅にグループ化できるようになりました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/ScGAyZ9a_yw)) * 代理店の音声電話番号を提供する agency_phone フィールドを追加しました ([元の提案](https://groups.google.com/forum/#!topic/gtfs-changes/ScGAyZ9a_yw))提案](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 についての説明を追加 @@ -267,9 +267,9 @@ #### 2007年11月20日 * block_id の説明を明確化 -* 言語を変更して Google Transit を強調しないようにしました (Google 以外のアプリケーションは GTFS を使用しており、交通機関のルーティングは Google マップの統合機能になったため)。また、さまざまなタイプミスを修正しました +* 言語を変更して Google Transit を強調しないようにしました (Google 以外のアプリケーションは GTFS を使用しており、交通事業者のルーティングは Google マップの統合機能になったため)。また、さまざまなタイプミスを修正しました * 現在の Google マップ UI での GTFS フィールドの表示を反映するようにサンプルのスクリーンショットを更新しました -* 交通機関データ プロバイダの Google 連絡先メール アドレスを更新しました +* 交通事業者データ プロバイダの Google 連絡先メール アドレスを更新しました * 書式を更新しました #### 2007年10月5日 @@ -286,9 +286,9 @@ #### 2007年4月9日 * に関するセクションを追加しました[フィードの送信](https://developers.google.com/transit/google-transit#SubmitFeedToGoogle)。 -* [デモ交通機関フィードの例](https://developers.google.com/transit/gtfs/examples/gtfs-feed)を追加しました。 +* [デモ交通事業者フィードの例](https://developers.google.com/transit/gtfs/examples/gtfs-feed)を追加しました。 * すべてのサービス日付がcalendar_dates.txtで定義されている場合はcalendar.txtを省略できるという注記を追加しました。 -* agency_idフィールドを1つの機関のみを含むフィードでオプションにしました。これにより、agency_idのない既存のフィードを有効なままにすることができます。 +* agency_idフィールドを1つの事業者のみを含むフィードでオプションにしました。これにより、agency_idのない既存のフィードを有効なままにすることができます。 * agency_url、stop_url、route_urlのより完全な仕様と、これらのフィールドの追加のサンプル値を追加しました。 * 有効なroute_type値として6 (ゴンドラ)と7 (ケーブルカー)を追加しました。 @@ -304,9 +304,9 @@ * ヘッドウェイ ベースのスケジュールをサポートするために frequencies.txt を追加しました。 -* 同じフィードで複数の機関が許可されるようになりました。また、agencys.txt とroutes.txt の両方に新しい agency_id フィールドが追加され、どのルートをどの機関が運行するかを指定できるようになりました。 +* 同じフィードで複数の事業者が許可されるようになりました。また、agencys.txt とroutes.txt の両方に新しい agency_id フィールドが追加され、どのルートをどの事業者が運行するかを指定できるようになりました。 -* ルートごとおよび停車地ごとの URL を追加しました。 +* ルートごとおよび停留所ごとの URL を追加しました。 * trips.txt に direction_id フィールドを追加しました。 @@ -314,13 +314,13 @@ * オプションの route_color と route_text_color をroutes.txt に追加して、ルートの色をサポートしました。 -* 住所を使用して停車地を指定する機能を削除しました。以前のバージョンの仕様では、stop_street、stop_city、stop_region、stop_postcode、stop_country の各フィールドで住所を使用して交通機関の停留所の場所を指定できました。現在は、緯度には stop_lat、経度には stop_lon を使用して停留所の場所を指定する必要があります。これは、ほとんどのアプリケーションでより便利です。 +* 住所を使用して停留所を指定する機能を削除しました。以前のバージョンの仕様では、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 によるトリップ シェイプ情報のサポートを追加 +* shapes.txt によるトリップ 形状情報のサポートを追加 * stop_sequence の定義を明確化 * pickup_type と drop_off_type をオプションとしてマーク diff --git a/docs/ja/documentation/schedule/examples/attributions.md b/docs/ja/documentation/schedule/examples/attributions.md index 6937a618..d018f41e 100644 --- a/docs/ja/documentation/schedule/examples/attributions.md +++ b/docs/ja/documentation/schedule/examples/attributions.md @@ -2,9 +2,9 @@ ## 集約された GTFS データセットでデータをデータ プロデューサーに帰属させる -一部の GTFS データセットには、同じ管轄区域にサービスを提供する異なるサービス プロバイダーなど、複数のソースから集約されたデータが含まれています。場合によっては、[agency.txt](../../reference/#agencytxt) にリストされている機関をプロデューサー、オペレーター、または当局として分類する必要があります。 +一部の GTFS データセットには、同じ管轄区域にサービスを提供する異なるサービス プロバイダーなど、複数のソースから集約されたデータが含まれています。場合によっては、[agency.txt](../../reference/#agencytxt) にリストされている事業者をプロデューサー、オペレーター、または当局として分類する必要があります。 -たとえば、Rejseplanen はデンマークの鉄道およびバス サービスの検索エンジンです。この会社は、以下の [agency.txt](../../reference/#agencytxt) に示すように、複数の機関とプロバイダーからのデータを含む GTFS データセットを公開しています。 +たとえば、Rejseplanen はデンマークの鉄道およびバス サービスの検索エンジンです。この会社は、以下の [agency.txt](../../reference/#agencytxt) に示すように、複数の事業者とプロバイダーからのデータを含む GTFS データセットを公開しています。 [**Agency.txt**](../../reference/#agencytxt) diff --git a/docs/ja/documentation/schedule/examples/continuous-stops.md b/docs/ja/documentation/schedule/examples/continuous-stops.md index 175fffef..adee217f 100644 --- a/docs/ja/documentation/schedule/examples/continuous-stops.md +++ b/docs/ja/documentation/schedule/examples/continuous-stops.md @@ -2,7 +2,7 @@ ## どこでも乗降可能 -交通機関 The Current (ロッキンガム、米国バーモント州) は、ルート 2、53、55 に連続停車ポリシーを適用しています。バスが安全に停車できる場所がある限り、ルート上の予定停車所間で乗客の乗降が可能です。 +交通事業者 The Current (ロッキンガム、米国バーモント州) は、ルート 2、53、55 に連続停車ポリシーを適用しています。バスが安全に停車できる場所がある限り、ルート上の予定停車所間で乗客の乗降が可能です。 ファイル [routes.txt](../../reference/#routestxt) は、`continuous_pickup` および `continuous_drop_off` フィールドを使用してこのサービスを説明するために使用されます。これらのフィールドは、連続した乗降が許可されていることを示すために `0` に設定されています。 @@ -43,7 +43,7 @@ E,Oro Grande Post Office,34.599292,-117.334452 F,Silver Lakes Market,34.744662,-117.335407 ``` -[stop_times.txt](../../reference/#stop_timestxt) では、特定の旅行について次のようになります。 +[stop_times.txt](../../reference/#stop_timestxt) では、特定の便について次のようになります。 - `continuous_pickup=0` のレコードは、その停留所から次の停留所まで連続乗車が許可されていることを示します。 - `continuous_pickup=1` のレコードは、連続乗車が許可されていないことを示します。次の停留所までその停留所から立ち入り禁止 diff --git a/docs/ja/documentation/schedule/examples/fares-v1.md b/docs/ja/documentation/schedule/examples/fares-v1.md index 64183af4..0e31ab25 100644 --- a/docs/ja/documentation/schedule/examples/fares-v1.md +++ b/docs/ja/documentation/schedule/examples/fares-v1.md @@ -1,13 +1,13 @@ # Fares V1 -[fare_attributes.txt](../../reference/#fare_attributestxt) と [fare_rules.txt](../../reference/#fare_rulestxt) で構成される運賃V1 は、歴史的に GTFS で運賃情報を記述するための公式の方法でした。しかし、2 つのファイルは、効率的に記述できる要素の幅が限られており、実装があいまいです。 +[fare_attributes.txt](../../reference/#fare_attributestxt) と [fare_rules.txt](../../reference/#fare_rulestxt) で構成されるFares v1 は、歴史的に GTFS で運賃情報を記述するための公式の方法でした。しかし、2 つのファイルは、効率的に記述できる要素の幅が限られており、実装があいまいです。 [Fares v2](../../examples/fares-v2/) は現在開発中の拡張プロジェクトで、運賃 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_rules.txt](../../reference/#fare_rulestxt)、および [transfers.txt](../../reference/#transferstxt) ファイルを使用して表すことができます。最初のファイル [fare_attributes.txt](../../reference/#fare_attributestxt) には、交通事業者の運賃が記載されています。以下は、プレスト運賃の例です。 [**fare_attributes.txt**](../../reference/#fare_attributestxt) diff --git a/docs/ja/documentation/schedule/examples/fares-v2.md b/docs/ja/documentation/schedule/examples/fares-v2.md index 379f35b1..88cb34b9 100644 --- a/docs/ja/documentation/schedule/examples/fares-v2.md +++ b/docs/ja/documentation/schedule/examples/fares-v2.md @@ -1,6 +1,6 @@ # Fares v2 -Fares v2 は、Fares v1 の制限に対処することを目的とした GTFS 拡張プロジェクトです。この拡張プロジェクトは、段階的に採用されています。以下の例では、運賃製品や乗客が運賃を乗り換えに使用する方法など、基本概念をモデル化する方法の概要を示します。[Fares v2 拡張プロジェクトの詳細については、こちら](../../../../community/extensions/fares-v2) を参照してください。 +Fares v2 は、Fares v1 の制限に対処することを目的とした GTFS 拡張プロジェクトです。この拡張プロジェクトは、段階的に採用されています。以下の例では、チケット商品や乗客が運賃を乗り換えに使用する方法など、基本概念をモデル化する方法の概要を示します。[Fares v2 拡張プロジェクトの詳細については、こちら](../../../../community/extensions/fares-v2) を参照してください。 当面の間、プロデューサーは Fares v2 を Fares v1 の実装と並行して同じデータセットに実装できます。両者の間に技術的な競合はありません。消費者は、他の実装とは独立してどちらの実装を使用するかを選択できます。 @@ -19,7 +19,7 @@ GTFS Fares-v2 を使い始めるには、これらの 4 つのビデオ チュ - [動画 3](https://share.mobilitydata.org/faresv2-creating-and-maintaining-data): GTFS Fares-v2: データの作成と維持 - [動画 4](https://share.mobilitydata.org/faresv2-exporting-and-publishing): GTFS Fares-v2 のエクスポートと公開 -これらは、交通機関が GTFS-Fares v2 の目的と、Google スプレッドシートを使用して GTFS-Fares v2 データを作成、編集、アップロードする方法を理解できるように作成されています。 +これらは、交通事業者が GTFS-Fares v2 の目的と、Google スプレッドシートを使用して GTFS-Fares v2 データを作成、編集、アップロードする方法を理解できるように作成されています。 この [Fares v2 template](https://share.mobilitydata.org/faresv2-template) は、必要な運賃ファイルを最初から作成するために使用できます。 @@ -34,7 +34,7 @@ GTFS Fares-v2 を使い始めるには、これらの 4 つのビデオ チュ - 1 週間パス (22 米ドル) - 1 か月パス (77 米ドル) -交通チケットまたは運賃は、GTFS では運賃商品と呼ばれます。これらは、[fare_products.txt](../../reference/#fare_productstxt) ファイルを使用して記述できます。各エントリは特定の運賃に対応します。 +交通チケットまたは運賃は、GTFS ではチケット商品と呼ばれます。これらは、[fare_products.txt](../../reference/#fare_productstxt) ファイルを使用して記述できます。各エントリは特定の運賃に対応します。 [**fare_products.txt**](../../reference/#fare_productstxt) @@ -51,9 +51,9 @@ GTFS Fares-v2 を使い始めるには、これらの 4 つのビデオ チュ ### 単一区間の旅程のルールを作成する -GTFS では、運賃区間は、乗客が異なるモード、ルート・路線系統、ネットワーク、または機関間で乗り換えを行わずに行う旅行に対応します。メリーランド州交通局のフィードでは、単一運賃で、乗客は BaltimoreLink バス、Light RailLink、および Metro SubwayLinkルート・路線系統の `core` ネットワーク内にある任意の停留所等と地下鉄駅のペア内を移動できます。 +GTFS では、運賃区間は、乗客が異なるモード、ルート・路線系統、ネットワーク、または事業者間で乗り換えを行わずに行う便に対応します。メリーランド州交通局のフィードでは、単一運賃で、乗客は BaltimoreLink バス、Light RailLink、および Metro SubwayLinkルート・路線系統の `core` ネットワーク内にある任意の停留所等と地下鉄駅のペア内を移動できます。 -区間グループは、ネットワーク内の出発地から目的地 (または、エリア ID がグループ化された停留所等に対応している場合は、出発地のセットから目的地のセット) への便を定義します。以下のファイルには、メリーランド州交通局のコア ネットワーク内の任意の場所を移動するためのルールが記述されています。各ルールは、[交通機関の運賃の定義例](#define-a-transit-fare) の通常チケット商品の 1 つに対応します。 +区間グループは、ネットワーク内の出発地から目的地 (または、エリア ID がグループ化された停留所等に対応している場合は、出発地のセットから目的地のセット) への便を定義します。以下のファイルには、メリーランド州交通局のコア ネットワーク内の任意の場所を移動するためのルールが記述されています。各ルールは、[交通事業者の運賃の定義例](#define-a-transit-fare) の通常チケット商品の 1 つに対応します。 [**fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) @@ -81,14 +81,14 @@ BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLi 上記のファイルは、次のフィールドを使用して GTFS でこれを表しています: -- 片道旅行 (`core_local_one_way_trip`) の区間への乗り換えが可能です +- 片道便 (`core_local_one_way_trip`) の区間への乗り換えが可能です - 許可される乗り換え回数に制限がないため、`transfer_count` は `-1` に設定されています - `duration_limit` は `5400` 秒に設定されており、これは 90 分に相当します - 乗り換え時間は、乗客が `core_local_one_way_trip` 運賃区間のいずれかのルートで出発したときに開始され、別の運賃区間で出発したときに終了するため、`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 からの例です。 +料金を定義し、適切な `fare_leg_rule` を作成し、`fare_transfer_rule` を定義すると、2.00 USD の `core_local_oneway_fare` が便プランナーに表示されます。以下は Transit からの例です。
fare of $2 USD @@ -98,7 +98,7 @@ BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLi ### 同じ運賃ゾーン内のサービス場所を説明する -一部の交通機関は、ゾーンベースの運賃体系を運用しています。運賃ゾーンは、異なる運賃価格に関連付けられた地理的エリアに分割されています。ベイエリアの BART システムでは、出発地と目的地によって運賃が異なり (BART 運賃の違い)、交通機関の利用者は正しい運賃を知る必要があります。運賃エリアは [stops_areas.txt](../../reference/#stop_areastxt) ファイルを使用して記述できます。このファイルでは、[stops.txt](../../reference/#stopstxt) から [areas.txt](../../reference/#areastxt) に停車駅が割り当てられます。 +一部の交通事業者は、ゾーンベースの運賃体系を運用しています。運賃ゾーンは、異なる運賃価格に関連付けられた地理的エリアに分割されています。ベイエリアの 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` があります。 @@ -122,11 +122,11 @@ BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLi | GLEN | GLEN | | OAKL | OAKL | -`fare_leg_rules.txt` では、出発地と到着地に応じて異なる運賃商品を識別できます。たとえば、最初のエントリは次のようになります: +`fare_leg_rules.txt` では、出発地と到着地に応じて異なるチケット商品を識別できます。たとえば、最初のエントリは次のようになります: * 出発地は `ASHB` です * 到着地は `GLEN` です -* 出発/到着地の運賃商品は `BA:matrix:ASHB-GLEN` です +* 出発/到着地のチケット商品は `BA:matrix:ASHB-GLEN` です [**fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) @@ -173,9 +173,9 @@ BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLi サンフランシスコ ベイエリア地域フィードをご覧ください -さらに、物理的なチケットをチケットメディアとして記述したいプロデューサーは、`fare_media_type=1` を使用できます。 +さらに、物理的なチケットを運賃メディアとして記述したいプロデューサーは、`fare_media_type=1` を使用できます。 -マサチューセッツ湾交通局 (MBTA)では、CharlieTicket と呼ばれる物理的な紙のチケットを使用して、ユーザーが便やパスの料金を支払うことを許可しています。これを反映するために、MBTA のフィードには `fare_media_type=1` の `charlieticket`チケットメディアがあります。 +マサチューセッツ湾交通局 (MBTA)では、CharlieTicket と呼ばれる物理的な紙のチケットを使用して、ユーザーが便やパスの料金を支払うことを許可しています。これを反映するために、MBTA のフィードには `fare_media_type=1` の `charlieticket`運賃メディアがあります。 [**fare_media.txt**](../../reference/#fare_mediatxt) @@ -187,11 +187,11 @@ BaltimoreLink のローカル バス、Metro SubwayLink、または Light RailLi マサチューセッツ湾交通局フィードを参照してください -###チケットメディアに基づいて価格差を定義する +###運賃メディアに基づいて価格差を定義する -Muni の運賃は、乗客が使用するチケットメディアによって異なります。この例では、現金または Clipper カードを使用した場合に大人のローカル運賃がどのように変わるかについて説明します。現金で支払う大人のローカル運賃は 3 米ドルですが、同じ運賃を Clipper カードで支払うと 50 セント安い 2.50 米ドルになります。 +Muni の運賃は、乗客が使用する運賃メディアによって異なります。この例では、現金または Clipper カードを使用した場合に大人のローカル運賃がどのように変わるかについて説明します。現金で支払う大人のローカル運賃は 3 米ドルですが、同じ運賃を Clipper カードで支払うと 50 セント安い 2.50 米ドルになります。 -以下の各エントリはチケットメディアについて説明しています。 +以下の各エントリは運賃メディアについて説明しています。 [**fare_media.txt**](../../reference/#fare_mediatxt) @@ -200,7 +200,7 @@ Muni の運賃は、乗客が使用するチケットメディアによって異 | clipper | Clipper | 2 | | cas​​h | Cash | 0 | -以下の`fare_products.txt`ル` スニペットは、乗客が使用するチケットメディアに応じて `i` シングル ローカル運賃` 商品の金額がどのように変化するかを示しています。 +以下の`fare_products.txt`ル` スニペットは、乗客が使用する運賃メディアに応じて `i` シングル ローカル運賃` 商品の金額がどのように変化するかを示しています。 [**fare_products.txt**](../../reference/#fare_productstxt) @@ -219,17 +219,17 @@ Apple マップでは、乗客は運賃がどのように変化するかを確 サンフランシスコ ベイエリア地域フィードを参照してください -### 非接触型チケットメディアオプションについて説明します +### 非接触型運賃メディアオプションについて説明します サンタバーバラ郡北部の Clean Air Express では、クレジットカード、Google Pay、 Apple Payによる非接触型支払いが受け付けられます。 -Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard、Visa) オプションであるため、`fare_media_type=3` の `tap_to_ride`チケットメディアがあります。 +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 ドル安くなります。 +以下に示す 1 回の乗車チケット商品には、`cash` と `tap-to-ride` の両方の運賃メディアオプションがあります。 1 回の乗車料金を`タップして乗車`運賃メディアで支払うと、1 ドル安くなります。 [**fare_products.txt**](../../reference/#fare_productstxt) @@ -241,11 +241,11 @@ Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard Clean Air Express フィードをダウンロードする -### 時間と旅行日に基づいて価格差を定義する +### 時間と便日に基づいて価格差を定義する -一部の交通機関は、時間や曜日に基づいて運賃を変更します。つまり、運賃は、ピーク時、オフピーク時、週末など、旅行が行われる時間帯に関連付けられます。 +一部の交通事業者は、時間や曜日に基づいて運賃を変更します。つまり、運賃は、ピーク時、オフピーク時、週末など、便が行われる時間帯に関連付けられます。 -ワシントン DC のメトロレールの運賃は、旅行の日時など、複数の要因によって異なります。GTFS の可変時間運賃は、`timeframes.txtを使用して定義できます。このファイルでは、特定の時間帯を指定して、それを`fare_leg_rules.txt`で関連付け、旅行が行われる時間に対応する適用可能な運賃商品を割り当てることができます。以下は、2023 年春現在の WMATA の運賃に基づいた架空の例です。 +ワシントン DC のメトロレールの運賃は、便の日時など、複数の要因によって異なります。GTFS の可変時間運賃は、`timeframes.txtを使用して定義できます。このファイルでは、特定の時間帯を指定して、それを`fare_leg_rules.txt`で関連付け、便が行われる時間に対応する適用可能なチケット商品を割り当てることができます。以下は、2023 年春現在の WMATA の運賃に基づいた架空の例です。 まず、サービス日は`calendar.txt`を使用して定義されます。 @@ -296,15 +296,15 @@ Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard | 1 | peak_fare | weekday_peak | | | 1 | regular_fare | weekday_offpeak | | -`network_id` は外部 ID `networks.network_id` または `routes.network_id` を参照し、各旅行の正しい運賃商品の選択は、`stop_times.txt` の到着時間と出発時間と、`timeframes.txt` で定義された時間の組み合わせになることに注意してください。 +`network_id` は外部 ID `networks.network_id` または `routes.network_id` を参照し、各便の正しいチケット商品の選択は、`stop_times.txt` の到着時間と出発時間と、`timeframes.txt` で定義された時間の組み合わせになることに注意してください。 -この場合、午前 7:30 に出発する旅行の料金を支払うユーザーは 5.00 USD (ピーク料金) を支払う必要がありますが、午前 11:30 に出発する別のユーザーは 3.00 USD (オフピーク料金) のみを支払う必要があります。 +この場合、午前 7:30 に出発する便の料金を支払うユーザーは 5.00 USD (ピーク料金) を支払う必要がありますが、午前 11:30 に出発する別のユーザーは 3.00 USD (オフピーク料金) のみを支払う必要があります。 ### 時間変動運賃とゾーンベース運賃を定義する -ニューヨークの MTA メトロノース鉄道網では、運賃は旅行の時間帯と出発地および目的地の両方に基づいて異なります。次の例は、グランド セントラル駅からコールド スプリング (米国ニューヨーク州) への旅行に適用される運賃規則を示しています。 +ニューヨークの MTA メトロノース鉄道網では、運賃は便の時間帯と出発地および目的地の両方に基づいて異なります。次の例は、グランド セントラル駅からコールド スプリング (米国ニューヨーク州) への便に適用される運賃規則を示しています。 -この例は、ITO World が作成した データセット に基づいており、6 つの異なるエリアに分散した 10 の停留所を利用する旅行を取り上げています。 +この例は、ITO World が作成した データセット に基づいており、6 つの異なるエリアに分散した 10 の停留所を利用する便を取り上げています。 [**stops.txt**](../../reference/#stopstxt) @@ -388,7 +388,7 @@ Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard | mnr_notam2pmpeak | 20:00:00 | 24:00:00 | weekdays | -各運賃商品は`fare_products.txt`で定義されています。Cold Spring はゾーン 7 にあるため、この例ではゾーン 1 と7. の間の便をリストしています。完全なデータセットには、時間とゾーンの組み合わせで定義された各価格のレコードが含まれます。また、この例では 1 つのチケットメディア(`paper`) のみが表示されていますが、チケットメディアによって価格も異なる場合は、追加の組み合わせを作成できます。. +各チケット商品は`fare_products.txt`で定義されています。Cold Spring はゾーン 7 にあるため、この例ではゾーン 1 と7. の間の便をリストしています。完全なデータセットには、時間とゾーンの組み合わせで定義された各価格のレコードが含まれます。また、この例では 1 つの運賃メディア(`paper`) のみが表示されていますが、運賃メディアによって価格も異なる場合は、追加の組み合わせを作成できます。. [**fare_products.txt**](../../reference/#fare_productstxt) @@ -400,7 +400,7 @@ Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard | mnr_HUD-7:1_adult | Inbound Adult Off Peak Zonal Fare | 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`の対応するチケット商品に関連付けられます。ここで、ピーク時にゾーン 1 (つまり `area_id=mnr_1`) から出発または到着する便には、便の到着ゾーンと出発ゾーンに対応する特定のピーク料金 (つまり `fare_product_id=mnr_1:HUD-7_adult_peak`) が適用されます。 [**fare_leg_rules.txt**](../../reference/#fare_leg_rulestxt) @@ -414,9 +414,9 @@ Clean Air Express フィードには、cEMV (非接触型 Europay、Mastercard | mnr_hudson | mnr_HUD-7 | mnr_1 | mnr_HUD-7:1_adult_peak | weekdays | mnr_ampeak | -このデータセットを使用すると、グランド セントラル (ゾーン `mnr_1`) を午後 6:45 に出発する予定の列車 #869 (`service_id=3`) に乗車するユーザーは、旅行が `mnr_am2pmpeak` 期間に開始され、`zone mnr_1` から始まるため、アウトバウンド大人ピーク ゾーン料金 20.00 USD を支払う必要があります。 +このデータセットを使用すると、グランド セントラル (ゾーン `mnr_1`) を午後 6:45 に出発する予定の列車 #869 (`service_id=3`) に乗車するユーザーは、便が `mnr_am2pmpeak` 期間に開始され、`zone mnr_1` から始まるため、アウトバウンド大人ピーク ゾーン料金 20.00 USD を支払う必要があります。 -または、列車 #883 (`service_id=13`) で旅行するユーザーは、この列車がグランド セントラル (ゾーン `mnr_1`) を午後 9:04 に出発する予定であるため、アウトバウンド大人オフピーク ゾーン料金 15.00 USD のみを支払う必要があります。 +または、列車 #883 (`service_id=13`) で便するユーザーは、この列車がグランド セントラル (ゾーン `mnr_1`) を午後 9:04 に出発する予定であるため、アウトバウンド大人オフピーク ゾーン料金 15.00 USD のみを支払う必要があります。 Apple マップ では、乗客は料金がどのように変化するかを確認し、列車の予定出発時刻の横にある料金を比較できます。 diff --git a/docs/ja/documentation/schedule/examples/feed-info.md b/docs/ja/documentation/schedule/examples/feed-info.md index 17b37c5e..591be8fd 100644 --- a/docs/ja/documentation/schedule/examples/feed-info.md +++ b/docs/ja/documentation/schedule/examples/feed-info.md @@ -2,7 +2,7 @@ ## GTFS データセットに関する情報を提供する -機関とそのサービスに関する情報を提供するだけでなく、[feed_info.txt](../../reference/#feed_infotxt) ファイルを使用して GTFS データセットに関する情報を提供することもできます。これには以下が含まれます: +事業者とそのサービスに関する情報を提供するだけでなく、[feed_info.txt](../../reference/#feed_infotxt) ファイルを使用して GTFS データセットに関する情報を提供することもできます。これには以下が含まれます: - パブリッシャーの詳細 - フィード言語 diff --git a/docs/ja/documentation/schedule/examples/flex.md b/docs/ja/documentation/schedule/examples/flex.md index e4a418c3..22b07089 100644 --- a/docs/ja/documentation/schedule/examples/flex.md +++ b/docs/ja/documentation/schedule/examples/flex.md @@ -3,7 +3,7 @@ GTFS Flex は、2024 年 3 月に GTFS 仕様に正式に採用された GTFS 拡張プロジェクトであり、デマンド レスポンシブ交通 (DRT) サービスの検出可能性を高めることを目的としています。 デマンド レスポンシブ サービスには、世界の地域に基づいて異なる用語が存在することに注意してください。詳細については、[用語集](#glossary) を参照してください。 -次の例は、Flex を使用してさまざまなデマンド レスポンシブ サービスのユース ケースをモデル化する方法を示しています。**次の例は、必ずしも機関のサービスを正確にまたは完全に表しているわけではないことに注意してください。** +次の例は、Flex を使用してさまざまなデマンド レスポンシブ サービスのユース ケースをモデル化する方法を示しています。**次の例は、必ずしも事業者のサービスを正確にまたは完全に表しているわけではないことに注意してください。** ## 単一ゾーン内のオンデマンド サービス @@ -11,7 +11,7 @@ GTFS Flex は、2024 年 3 月に GTFS 仕様に正式に採用された GTFS [Heartland Express サンプル データセットをダウンロード](../../../assets/on-demand_services_within_a_single_zone.zip) -### 旅行の定義 +### 便の定義 Heartland Express のサービス時間は次のとおりです。 @@ -87,7 +87,7 @@ Heartland Express サービスすべてに適用される予約ルールは次 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###停車時刻の定義 +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 つのレコードが必要です。 @@ -267,7 +267,7 @@ 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 を考慮に入れないでください。 +消費者は、Zone1 から Zone3 への便のルートや移動時間を指定する際に、Zone2 を考慮に入れないでください。 ### ゾーン重複制約 @@ -320,7 +320,7 @@ tripA | vancouver | 3 | 1 | 2 | 10:00:00 | 14:00:00 📲 ダイアル ア ライドは、ヨーロッパ全土で使用されている複数の用語のバリエーションです。 -🇨🇭 スイスでは、Rufbus / オンコール バスという用語に該当します。[PostAuto の PubliCar システム](https://www.postauto.ch/en/timetable-and-network/publicar) も利用できます。この提案では、PubliCar アプリとサービスは、ユーザーが好む旅行プランナー アプリで見つけられるようになります。 +🇨🇭 スイスでは、Rufbus / オンコール バスという用語に該当します。[PostAuto の PubliCar システム](https://www.postauto.ch/en/timetable-and-network/publicar) も利用できます。この提案では、PubliCar アプリとサービスは、ユーザーが好む便プランナー アプリで見つけられるようになります。 🇦🇹 オーストリアでは、ダイアル ア ライドは Rufbus でもあり、Bedarfsverkehr (Demand Responsive Transport) と Mikro-ÖV (Microtransit) というより大きな傘下になります。 diff --git a/docs/ja/documentation/schedule/examples/frequencies.md b/docs/ja/documentation/schedule/examples/frequencies.md index 33579994..7367330d 100644 --- a/docs/ja/documentation/schedule/examples/frequencies.md +++ b/docs/ja/documentation/schedule/examples/frequencies.md @@ -2,7 +2,7 @@ ## 頻度ベースのサービスを説明する -モントリオール交通局はモントリオールで交通サービスを運営しており、地下鉄路線で頻度ベースのサービスを提供しています。したがって、GTFS データセットで到着時間と出発時間を含むスケジュールを提供する代わりに、ファイル [frequencies.txt](../../reference/#frequenciestxt) を使用して、サービス期間全体にわたるサービス頻度を説明します。旅行の繰り返しは、停留所等間のタイミングがすべての停留所等で一貫している場合にのみ機能します。頻度ベースのサービスをモデル化する場合、 stop_times.txt (@TODO リンク) には、乗客に表示される時間を決定するために、停留所等間の相対時間が含まれます。 +モントリオール交通局はモントリオールで交通サービスを運営しており、地下鉄路線で頻度ベースのサービスを提供しています。したがって、GTFS データセットで到着時間と出発時間を含むスケジュールを提供する代わりに、ファイル [frequencies.txt](../../reference/#frequenciestxt) を使用して、サービス期間全体にわたるサービス頻度を説明します。便の繰り返しは、停留所等間のタイミングがすべての停留所等で一貫している場合にのみ機能します。頻度ベースのサービスをモデル化する場合、 stop_times.txt (@TODO リンク) には、乗客に表示される時間を決定するために、停留所等間の相対時間が含まれます。 [**frequencies.txt**](../../reference/#frequenciestxt) @@ -12,6 +12,6 @@ trip_id,start_time,end_time,headway_secs 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 秒間隔で運行していることを示しています。 +上記では、`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 index 5238c08f..978e4bf2 100644 --- a/docs/ja/documentation/schedule/examples/pathways.md +++ b/docs/ja/documentation/schedule/examples/pathways.md @@ -2,9 +2,9 @@ ## アクセシビリティ情報を表示する理由 -**人口の大部分に影響:** 世界保健機関は、[世界中の 16% の人が障害を抱えている](https://www.who.int/news-room/fact-sheets/detail/disability-and-health)と推定しており、障害のある人は「障害のない人よりもアクセスできない、または手頃でない交通手段を 15 倍も利用しにくい」としています。また、障害のある人は、医療やサービスへのアクセスが制限されることもあって、[新しい健康状態になる割合が高い](https://www.who.int/publications/i/item/9789240063600)です。 +**人口の大部分に影響:** 世界保健事業者は、[世界中の 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 Specific (GTFS) を使用しています。アクセシビリティを必要とする乗客にとって、停車地や車両のアクセシビリティを知ることは、場所を知ることと同じくらい重要です。これらの乗客は、どこかで立ち往生したり、最終停車地に到着できないことに気付くのが遅すぎたりしないように、旅行のあらゆる部分について知っておく必要があります。 +**障害者にとって重要:** 乗客は、交通手段の選択肢に関する最新かつ正確な情報を必要としています。多くの事業者は、乗客が便を計画し、選択肢を理解する上で重要なルート、スケジュール、停留所の場所情報を表すために、すでに General Transit Feed Specific (GTFS) を使用しています。アクセシビリティを必要とする乗客にとって、停留所や車両のアクセシビリティを知ることは、場所を知ることと同じくらい重要です。これらの乗客は、どこかで立ち往生したり、最終停留所に到着できないことに気付くのが遅すぎたりしないように、便のあらゆる部分について知っておく必要があります。 **法律で定められている場合もあります:** 場所によっては、地方または国の法律で、障害のある人に平等なアクセスと機会を提供することが義務付けられている場合があります。以下に、検討したい情報源をいくつか示します。 @@ -19,7 +19,7 @@ * ステップ 1: `stops.txt`に車椅子のアクセシビリティ情報を追加する * ステップ 2: `trips.txt`に車椅子のアクセシビリティ情報を追加する * ステップ 3: `stops.txt`に音声ナビゲーション情報を追加する -* ステップ 4: GTFS 構内通路を使用して交通機関の駅に関する物理的なアクセシビリティ情報を追加する +* ステップ 4: GTFS 構内通路を使用して交通事業者の駅に関する物理的なアクセシビリティ情報を追加する ## GTFS に車椅子のアクセシビリティを追加する @@ -30,14 +30,14 @@ GTFS の構造は一連の .txt ファイルとして既によく知られてい [参照:stops.txt](../../reference/#stopstxt) -このフィールドが空のままの場合、アクセシビリティ情報は表示されません。これにより、乗客はアクセシビリティについて確信が持てず、車椅子で乗車できないのか、それとも情報が不足しているのか判断できなくなります。車椅子で乗車できない場合でも、その情報を入力して乗客に明確にし、正確な情報で旅行を計画できるようにするのが最善です。 +このフィールドが空のままの場合、アクセシビリティ情報は表示されません。これにより、乗客はアクセシビリティについて確信が持てず、車椅子で乗車できないのか、それとも情報が不足しているのか判断できなくなります。車椅子で乗車できない場合でも、その情報を入力して乗客に明確にし、正確な情報で便を計画できるようにするのが最善です。 **trips.txt の車椅子アクセシビリティ** -`trips.txt` のフィールド `wheelchair_accessible` を使用すると、特定の旅行に使用されている車両が車椅子に対応しているかどうかを示すことができます。 +`trips.txt` のフィールド `wheelchair_accessible` を使用すると、特定の便に使用されている車両が車椅子に対応しているかどうかを示すことができます。 [参照: trips.txt](../../reference/#tripstxt) -`wheelchair_boarding` と同様に、このフィールドが空のままの場合、アクセシビリティ情報は表示されません。車両が車椅子に対応していない場合でも、乗客に明確に伝え、正確な情報で旅行を計画できるように、その情報を入力することをお勧めします。 +`wheelchair_boarding` と同様に、このフィールドが空のままの場合、アクセシビリティ情報は表示されません。車両が車椅子に対応していない場合でも、乗客に明確に伝え、正確な情報で便を計画できるように、その情報を入力することをお勧めします。 ## オーディオ ナビゲーション補助の追加 @@ -51,7 +51,7 @@ GTFS の構造は一連の .txt ファイルとして既によく知られてい ## 駅に関する物理的なアクセシビリティ情報の追加 -GTFS-Pathways は、交通機関の駅の詳細を表す GTFS のコンポーネントです。これにより、乗客は交通機関の駅で必要な乗り換えができるかどうかを把握できます。 +GTFS-Pathways は、交通事業者の駅の詳細を表す GTFS のコンポーネントです。これにより、乗客は交通事業者の駅で必要な乗り換えができるかどうかを把握できます。 GTFS-Pathways は、`pathways.txt` および `levels.txt` ファイルを追加するほか、`stops.txt` に `location_type` フィールドを追加して、`pathways.txt` で説明されている情報をリンクします。 diff --git a/docs/ja/documentation/schedule/examples/routes-stops-trips.md b/docs/ja/documentation/schedule/examples/routes-stops-trips.md index 0cd2fdbb..00c3830a 100644 --- a/docs/ja/documentation/schedule/examples/routes-stops-trips.md +++ b/docs/ja/documentation/schedule/examples/routes-stops-trips.md @@ -13,7 +13,7 @@ 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と、人間が読みやすいように短い名前と長い名前が割り当てられます。 +Calgary Transit は、アルバータ州カルガリーで LRT、BRT、定期バス サービス、準交通事業者、オンデマンド交通を運営しています。この例では、2 つのルート・路線系統が定義されており、1 つ目はバス、2 つ目は LRT です。ファイル [routes.txt](../../reference/#routestxt) を使用して、各ルートにユニーク IDと、人間が読みやすいように短い名前と長い名前が割り当てられます。 [**routes.txt**](../../reference/#routestxt) @@ -29,7 +29,7 @@ CT,202-20666,202,Blue Line - Saddletowne/69 Street CTrain,0,www.calgarytransit.c - 2番目は LRT なので、`route_type=0` です。 - `route_type` の値の完全なリストは、[こちら](../../reference/#routestxt) にあります。 -残りのフィールドには、ルート固有の URL や、地図上でサービスを表す機関固有の色などの追加情報が含まれます。 +残りのフィールドには、ルート固有の URL や、地図上でサービスを表す事業者固有の色などの追加情報が含まれます。
@@ -57,7 +57,7 @@ stop_id,stop_code,stop_name,stop_lat,stop_lon,location_type ## 便 -機関のルート・路線系統を記述した後、各ルートで提供される便を記述できるようになります。 +事業者のルート・路線系統を記述した後、各ルートで提供される便を記述できるようになります。 まず、[calendar.txt](../../reference/#calendartxt) を使用してサービスの範囲を定義する必要があります。 @@ -83,13 +83,13 @@ route_id,service_id,trip_id,trip_headsign,direction_id,shape_id - MAX Orange に対応する [routes.txt](../../reference/#routestxt) の `route_id` がリストされます - 週末に対応する [calendar.txt](../../reference/#calendartxt) の `service_id` がリストされます -- 各レコードには、各旅行の一意の ID が含まれます。 +- 各レコードには、各便の一意の ID が含まれます。 ヘッドサイン テキストが提供されます。これは、通常、バスの内外の標識に表示されます -- フィールド `direction_id` を使用すると、同じルートの異なる方向への旅行を区別できます。たとえば、インバウンド旅行とアウトバウンド旅行、または南行き旅行と北行き旅行を区別できます。 -- この場合、Saddletowne への旅行には `direction_id=0` があり、Brentwood への旅行には `direction_id=1` があります。 direction_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 に対応しています。以下のファイルには、旅行の概要を示すポイントに関する情報と、各ポイントと旅行の開始点の間の距離が含まれています。この情報を使用して、旅行計画や分析の目的でルートをマップ上にプロットすることができます。 +`shape_id=3030026` は、サドルタウン行きの MAX Orange に対応しています。以下のファイルには、便の概要を示すポイントに関する情報と、各ポイントと便の開始点の間の距離が含まれています。この情報を使用して、便計画や分析の目的でルートをマップ上にプロットすることができます。 [**shapes.txt**](../../reference/#shapestxt) diff --git a/docs/ja/documentation/schedule/examples/transfers.md b/docs/ja/documentation/schedule/examples/transfers.md index 80251af0..7c769017 100644 --- a/docs/ja/documentation/schedule/examples/transfers.md +++ b/docs/ja/documentation/schedule/examples/transfers.md @@ -2,13 +2,13 @@ ## ブロックトランスファー -ブロックトランスファー(座席内トランスファーとも呼ばれる) は、一連の旅行が次の条件を満たす場合に利用できます。 +ブロックトランスファー(座席内トランスファーとも呼ばれる) は、一連の便が次の条件を満たす場合に利用できます。 -1. 旅行が連続している。 +1. 便が連続している。 -2. 両方の旅行を同じ車両が運行している。 +2. 両方の便を同じ車両が運行している。 -3. 旅行は、交通フィードの [trips.txt](../../reference/#tripstxt) ファイルで同じ `block_id` 値を使用してプロビジョニングされている。 +3. 便は、交通フィードの [trips.txt](../../reference/#tripstxt) ファイルで同じ `block_id` 値を使用してプロビジョニングされている。 ### ブロックトランスファーを有効にするには `block_id` を使用します @@ -38,8 +38,8 @@ - 停留所 A から停留所 E までのルートを検索するユーザーは、ルート A の 12:00 に停留所 A で乗車し、`RouteATrip1` の終了後に停留所 C に到着したら車両にとどまるように指示されます。これは、同じ車両がルート B の `RouteBTrip1` を運行しているためです。 - `RouteATrip1` に乗っていて、`RouteBTrip1` の停留所まで進みたい乗客は、この乗り換えの間、車両にとどまることができます。 -- 同じルートを他の車両で移動する他の旅行の乗客は、旅行ごとに異なる車両を使用するため、このオプションはありません。 +- 同じルートを他の車両で移動する他の便の乗客は、便ごとに異なる車両を使用するため、このオプションはありません。 ### ループ ラインでのブロック トランスファー -ループ ラインでは、旅行の最初の停留所と最後の停留所は同じで、同じ `stop_id` を持ちます。連続するループ旅行の `block_id` が同じであれば、ブロック トランスファーまたは座席内トランスファーが有効になり、最初の旅行の乗客は車両に留まり、次のループに進むことができます。 \ No newline at end of file +ループ ラインでは、便の最初の停留所と最後の停留所は同じで、同じ `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 index 3487994f..3208fad1 100644 --- a/docs/ja/documentation/schedule/examples/translations.md +++ b/docs/ja/documentation/schedule/examples/translations.md @@ -2,7 +2,7 @@ ## 駅名を翻訳する -一部の交通機関プロバイダーは複数の言語でサービスを提供しています。その 1 つがベルギー国鉄 (現地では NMBS/SNCB、オランダ語では Nationale Maatschappij der Belgische Spoorwegen、フランス語では Société nationale des chemins de fer belges として知られています) です。同社は駅名を複数の言語で提供しており、ユーザーの言語と場所の設定に応じて表示されます。 +一部の交通事業者プロバイダーは複数の言語でサービスを提供しています。その 1 つがベルギー国鉄 (現地では NMBS/SNCB、オランダ語では Nationale Maatschappij der Belgische Spoorwegen、フランス語では Société nationale des chemins de fer belges として知られています) です。同社は駅名を複数の言語で提供しており、ユーザーの言語と場所の設定に応じて表示されます。 NMBS/SNCB は、以下のファイルに示すように、GTFS データをフランス語で公開しています。 diff --git a/docs/ja/documentation/schedule/reference.md b/docs/ja/documentation/schedule/reference.md index 8604bc53..37771c45 100644 --- a/docs/ja/documentation/schedule/reference.md +++ b/docs/ja/documentation/schedule/reference.md @@ -60,10 +60,10 @@ description: GTFS scheduleの詳細を確認し、リファレンス ドキュ * **フィールド値** - フィールド内の個々のエントリ。表では 1 つのセルとして表されます。 * **サービス日** - サービス日は、ルートのスケジュールを示すために使用される期間です。サービス日の正確な定義は事業者によって異なりますが、サービス日は暦日と一致しないことがよくありしてもよい。たとえば、金曜日の 08:00:00 から土曜日の 02:00:00 まで実行されるサービスは、1つのサービス日に 08:00:00 から 26:00:00 まで実行されると示される場合があります。 * **テキスト読み上げフィールド** - このフィールドには、親フィールドと同じ情報が含まれている必要があります (親フィールドが空の場合は、親フィールドが参照されます)。このフィールドは、テキスト読み上げを目的としているため、省略形は削除するか (「St」は「Street」または「Saint」と読み上げます。「Elizabeth I」は「Elizabeth the first」と読み上げます)、そのまま読み上げます (「JFK Airport」は省略形として読み上げます)。 -* **区間** - 乗客が旅行中の 2 つの連続する場所の間で乗降する旅行。 -* **旅程** - 出発地から目的地までの全体的な旅行で、途中のすべての区間と乗り換えが含まれます。 +* **区間** - 乗客が便中の 2 つの連続する場所の間で乗降する便。 +* **旅程** - 出発地から目的地までの全体的な便で、途中のすべての区間と乗り換えが含まれます。 * **サブ旅程** - 旅程のサブセットを構成する 2 つ以上の区間。 -* **運賃商品** - 旅行の支払いや検証に使用できる購入可能なチケット商品。 +* **チケット商品** - 便の支払いや検証に使用できる購入可能なチケット商品。 ### 存在 フィールドとファイルに適用可能な存在条件: @@ -115,20 +115,20 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | ファイル名 | 存在 | 説明 | |------|------|------| -| [agency.txt](#agencytxt) |**必須**| このデータセットで表されるサービスを提供する交通機関。| +| [agency.txt](#agencytxt) |**必須**| このデータセットで表されるサービスを提供する交通事業者。| | [stops.txt](#stopstxt) |**条件付きで必須**| 車両が乗客を乗降させる停留所等。駅と駅の入口も定義します。

条件付きで必須:
- [locations.geojson](#locationsgeojson ) で需要対応ゾーンが定義されている場合は任意。
-**それ以外の場合は必須**。 | | [routes.txt](#routestxt) |**必須**| 交通ルート・路線系統。ルートは、乗客に単一のサービスとして表示される便のグループです。 | -| [trips.txt](#tripstxt) |**必須**| 各ルートの便。旅行とは、特定の期間内に発生する 2 つ以上の停留所等のシーケンスです。 | -| [stop_times.txt](#stop_timestxt) |**必須**| 各旅行で車両が停留所等に到着および出発する時刻。 | +| [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_attributes.txt](#fare_attributestxt) |任意| 交通事業者のルート・路線系統の運賃情報。 | | [fare_rules.txt](#fare_rulestxt) |任意| 旅程に運賃を適用するルール。 | | [timeframes.txt](#timeframestxt) |任意|dateと時間の要素に依存する運賃の運賃ルールで使用する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_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) とは完全に別です。 | +| [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) | **条件付きで禁止** | ルートのネットワーク グループ化。

条件付きで禁止:
- `network_id` が [routes.txt](#routestxt) に存在する場合は **禁止**。
- それ以外の場合はオプション。| @@ -168,13 +168,13 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti ## データセットの公開と一般的なプラクティス * データセットは、zip ファイル名を含むパブリックの永続的な URL で公開するするべきである。(例: www.agency.org/gtfs/gtfs.zip) 理想的には、使用ソフトウェア アプリケーションによるダウンロードを容易にするために、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできるするべきである。 GTFS データセットはオープンにダウンロード可能にすることが推奨（最も一般的な方法）が、データ プロバイダーがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することが推奨。 -* GTFS データは、安定した場所にある 1 つのファイルに、交通事業者（または複数の交通機関）のサービスの最新の公式説明が常に含まれるように、反復して公開するするべきであるがあります。 +* GTFS データは、安定した場所にある 1 つのファイルに、交通事業者（または複数の交通事業者）のサービスの最新の公式説明が常に含まれるように、反復して公開するするべきであるがあります。 * データセットは、可能な限り、データの反復をまたいで`stop_id`、 `route_id`、および`agency_id`の永続的な識別子（ IDフィールド）を維持するするべきである。 * 1 つの GTFS データセットには、現在のサービスと今後のサービス（`マージされた`データセットと呼ばれることもあります）を含める必要がするべきである。 2 つの異なる GTFS フィードから結合されたデータセットを作成するために使用できる [マージ ツール](../../../リソース/gtfs/#gtfs-merge-tools) が複数あります。 * 公開された GTFS データセットは、いつでも少なくとも今後 7 日間は有効であるするべきである。理想的には、運行会社がスケジュールが継続して運用されると確信している限り有効です。 * 可能であれば、GTFS データセットは少なくとも今後 30 日間のサービスをカバーするするべきである。 * 古いサービス (期限切れのカレンダー) はフィードから削除するするべきである。 - * サービスのModificationが7 日以内に有効になる場合は、このサービスの変更は、静的な GTFS データセットではなく、GTFS リアルタイム フィード (サービス アドバイザリまたは旅行更新) を通じて表現するするべきである。 + * サービスのModificationが7 日以内に有効になる場合は、このサービスの変更は、静的な GTFS データセットではなく、GTFS リアルタイム フィード (サービス アドバイザリまたは便更新) を通じて表現するするべきである。 * GTFS データをホストする Web サーバーは、ファイル Modificationdate を正しく報告するように構成するするべきである([HTTP/1.1 - Request for Comments 2616, under Section 14.29](https://tools.ietf.org/html/rfc2616#section-14.29)). ## フィールド定義 @@ -187,14 +187,14 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | フィールド名 | タイプ | 存在 | 説明 | |------|------|------|------| -| `agency_id` |ユニーク ID |**条件付きで必須**| 交通事業者と同義であることが多い交通ブランドを識別します。 1 つの事業者が複数の個別のサービスを運営している場合など、機関とブランドは異なる場合があることに注意してください。 このドキュメントでは、`ブランド`の代わりに`事業者`という用語を使用します。 データセットには、複数の機関のデータが含まれるしてもよい。

条件付きで必須:
- データセットに複数の交通機関のデータが含まれている場合は**必須**です。
- それ以外の場合は推奨。 | +| `agency_id` |ユニーク ID |**条件付きで必須**| 交通事業者と同義であることが多い交通ブランドを識別します。 1 つの事業者が複数の個別のサービスを運営している場合など、事業者とブランドは異なる場合があることに注意してください。 このドキュメントでは、`ブランド`の代わりに`事業者`という用語を使用します。 データセットには、複数の事業者のデータが含まれるしてもよい。

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

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

複数のルートで同じ `stop_id` を使用できます。| | `stop_code` | テキスト | オプション | 乗客の場所を識別する短いテキストまたは番号。これらのコードは、電話ベースの交通情報システムで使用されることが多く、乗客が特定の場所の情報を簡単に入手できるようにするために標識に印刷されます。`stop_code` は、一般向けである場合は `stop_id` と同じになることがあります。乗客にコードが提示されない場所では、このフィールドは空白のままにしてください。 | -| `stop_name` | テキスト | **条件付きで必須** | 場所の名前。`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`) の場所の場合はオプションです。| +| `stop_name` | テキスト | **条件付きで必須** | 場所の名前。`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` | テキスト | オプション | `stop_name` の読み取り可能なバージョンです。詳細については、[用語の定義](#term-definitions) の「音声合成フィールド」を参照してください。| | `stop_desc` | テキスト | オプション | 有用で質の高い情報を提供する場所の説明。 `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`) の場所の場合はオプションです。| +| `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` 内で定義されている場合はプラットフォームと呼ばれます。
`1` - **駅**。1 つ以上のプラットフォームを含む物理的な構造またはエリア。
`2` - **入口/出口**。乗客が通りから駅に出入りできる場所です。入口/出口が複数の駅に属している場合、経路によって両方にリンクできますが、データ プロバイダーはそのうちの 1 つを親として選択する必要があります。
`3` - **汎用ノード**。駅内の場所。他の `location_type` に一致せず、[pathways.txt](#pathwaystxt) で定義されている経路をリンクするために使用できます。
`4` - **乗車エリア**。プラットフォーム上の特定の場所で、乗客が車両に乗ったり降車したりすることができます。| +| `location_type` | 列挙型 | オプション | 場所の種類。有効なオプションは次のとおりです:

`0` (または空白) - **停留所** (または **プラットフォーム**)。乗客が交通事業者の車両に乗降する場所です。`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` フィールドに駅 (`location_type=1`) の ID が含まれます。
- **乗車エリア** (`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` で指定されたタイムゾーンです。これにより、旅行がどのタイムゾーンを通過するかに関係なく、旅行の途中で旅行の時間値が常に増加することが保証されます。| +| `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` | テキスト | オプション | プラットフォーム ストップ (駅に属するストップ) のプラットフォーム識別子。これは、プラットフォーム識別子のみである必要があります (例: "G" または "3")。「プラットフォーム」や「トラック」などの単語 (またはフィードの言語固有の同等語) は含めないでください。これにより、フィード コンシューマーは、プラットフォーム識別子を他の言語に国際化およびローカライズしやすくなります。| @@ -230,17 +230,17 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | フィールド名 | タイプ | 存在 | 説明 | | ------ | ------ | ------ | ------ | | `route_id` | 一意の ID | **必須** | ルートを識別します。 | -| `agency_id` | `agency.agency_id` を参照する外部 ID | **条件付きで必須** | 指定されたルートの機関。

条件付きで必須:
- [agency.txt](#agencytxt) で複数の機関が定義されている場合は **必須**。
- それ以外の場合は推奨。 | +| `agency_id` | `agency.agency_id` を参照する外部 ID | **条件付きで必須** | 指定されたルートの事業者。

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

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

条件付きで必須:
- `routes.route_short_name` が空の場合は **必須** です。
- それ以外の場合はオプションです。| +| `route_long_name` | テキスト | **条件付きで必須** | ルートの完全な名前。この名前は通常、`route_short_name` よりも説明的で、ルートの目的地または停留所が含まれることがよくあります。`route_short_name` と `route_long_name` の両方を定義できます。

条件付きで必須:
- `routes.route_short_name` が空の場合は **必須** です。
- それ以外の場合はオプションです。| | `route_desc` | テキスト |オプション | 有用で質の高い情報を提供するルートの説明。`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` | 列挙型 | **必須** | ルートで使用される交通機関の種類を示します。有効なオプションは次のとおりです:

`0` - 路面電車、路面電車、ライトレール。大都市圏内のライトレールまたはストリート レベルのシステム。
`1` - 地下鉄、メトロ。大都市圏内の地下鉄システム。
`2` - 鉄道。都市間または長距離の移動に使用します。
`3` - バス。短距離および長距離のバス路線に使用します。
`4` - フェリー。短距離および長距離の船便に使用します。
`5` - ケーブル トラム。ケーブルが車両の下を走る路面電車に使用します (例: サンフランシスコのケーブル カー)。
`6` - 空中リフト、吊り下げ式ケーブル カー (例: ゴンドラ リフト、空中トラムウェイ)。1 つ以上のケーブルを使用して、キャビン、車両、ゴンドラ、またはオープン チェアが吊り下げられているケーブル輸送。
`7` - ケーブルカー。急勾配用に設計された鉄道システム。
`11` - トロリーバス。ポールを使用して頭上の電線から電力を引き出す電気バス。
`12` - モノレール。線路が単一のレールまたはビームで構成されている鉄道。| +| `route_type` | 列挙型 | **必須** | ルートで使用される交通事業者の種類を示します。有効なオプションは次のとおりです:

`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` の色の違いは、白黒画面で表示したときに十分なコントラストを提供する必要があります。| | `route_text_color` | 色 | オプション | `route_color` の背景に描画されるテキストに使用する判読可能な色。省略または空白のままにした場合、デフォルトで黒 (`000000`) になります。`route_color` と `route_text_color` の色の違いは、白黒画面で表示したときに十分なコントラストを提供する必要があります。| | `route_sort_order` | 負でない整数 | オプション | 顧客へのプレゼンテーションに最適な方法でルートを順序付けます。 `route_sort_order` 値が小さいルートが最初に表示されます。 | -| `continuous_pickup` | 列挙型 | **条件付きで禁止** | ルートのすべての旅行で、[shapes.txt](#shapestxt) で説明されているように、乗客が車両の移動経路に沿った任意の地点で交通機関の車両に乗車できることを示します。有効なオプションは次のとおりです:

`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` が定義されている場合。
- それ以外の場合はオプションです。| +| `continuous_pickup` | 列挙型 | **条件付きで禁止** | ルートのすべての便で、[shapes.txt](#shapestxt) で説明されているように、乗客が車両の移動経路に沿った任意の地点で交通事業者の車両に乗車できることを示します。有効なオプションは次のとおりです:

`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 @@ -253,14 +253,14 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | ------ | ------ | ------ | ------ | | `route_id` | `routes.route_id` を参照する外部 ID | **必須** | ルートを識別します。 | | `service_id` | `calendar.service_id` または `calendar_dates.service_id` を参照する外部 ID | **必須** | 1 つ以上のルートでサービスが利用可能な日付のセットを識別します。 | -| `trip_id` | 一意の ID | **必須** | 旅行を識別します。 | -| `trip_headsign` | テキスト | オプション | 旅行の目的地を乗客に示す標識に表示されるテキスト。このフィールドは、ルート内の旅行を区別するために使用できる、車両にヘッドサイン テキストが表示されるすべてのサービスに推奨されます。

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

`0` - 一方向への移動 (例: 往路)。
`1` - 反対方向への移動 (例: 復路)。
*例: `trip_headsign` フィールドと `direction_id` フィールドを一緒に使用して、一連の旅行の各方向への移動に名前を割り当てることができます。[trips.txt](#tripstxt) ファイルには、時刻表で使用するために次のレコードを含めることができます:*
`trip_id,...,trip_headsign,direction_id`
`1234,...,Airport,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` | Enum | オプション | 自転車が許可されているかどうかを示します。有効なオプションは次のとおりです:

`0` または空 - 旅行の自転車情報がありません。
`1` - この特定の旅行で使用される車両には、少なくとも 1 台の自転車を収容できます。
`2` - この旅行では、自転車は許可されていません。| +| `trip_id` | 一意の ID | **必須** | 便を識別します。 | +| `trip_headsign` | テキスト | オプション | 便の目的地を乗客に示す標識に表示されるテキスト。このフィールドは、ルート内の便を区別するために使用できる、車両にヘッドサイン テキストが表示されるすべてのサービスに推奨されます。

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

`0` - 一方向への移動 (例: 往路)。
`1` - 反対方向への移動 (例: 復路)。
*例: `trip_headsign` フィールドと `direction_id` フィールドを一緒に使用して、一連の便の各方向への移動に名前を割り当てることができます。[trips.txt](#tripstxt) ファイルには、時刻表で使用するために次のレコードを含めることができます:*
`trip_id,...,trip_headsign,direction_id`
`1234,...,Airport,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` | Enum | オプション | 自転車が許可されているかどうかを示します。有効なオプションは次のとおりです:

`0` または空 - 便の自転車情報がありません。
`1` - この特定の便で使用される車両には、少なくとも 1 台の自転車を収容できます。
`2` - この便では、自転車は許可されていません。| #### 例: ブロックとサービス日 @@ -287,21 +287,21 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | フィールド名 | タイプ | 存在 | 説明 | | ------ | ------ | ------ | ------ | -| `trip_id` | `trips.trip_id` を参照する外部 ID | **必須** | 旅行を識別します。 | -| `arrival_time` | 時間 | **条件付きで必須** | `stops.stop_timezone` ではなく `agency.agency_timezone` で指定されたタイム ゾーンでの、特定の旅行 (`stop_times.trip_id` で定義) の停留所 (`stop_times.stop_id` で定義) への到着時刻。

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

運行日の深夜 0 時以降の時刻については、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` が定義されている場合は **禁止** です。
- それ以外の場合はオプションです。| +| `trip_id` | `trips.trip_id` を参照する外部 ID | **必須** | 便を識別します。 | +| `arrival_time` | 時間 | **条件付きで必須** | `stops.stop_timezone` ではなく `agency.agency_timezone` で指定されたタイム ゾーンでの、特定の便 (`stop_times.trip_id` で定義) の停留所 (`stop_times.stop_id` で定義) への到着時刻。

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

運行日の深夜 0 時以降の時刻については、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` で定義) の停留所 (`stop_times.stop_id` で定義) からの出発時刻。

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

運行日の深夜 0 時以降の時刻については、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` または空である必要があります。同じ旅程で 1 つの停留所が複数回サービスされる場合があり、複数の旅程とルートが同じ停留所にサービスを提供する場合があります。

停留所を使用するオンデマンド サービスは、それらの停留所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 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` | テキスト | オプション | 乗客に旅行の目的地を示す標識に表示されるテキスト。このフィールドは、停車地間でヘッドサインが変わる場合にデフォルトの `trips.trip_headsign` を上書きします。行程全体でヘッドサインが表示される場合は、代わりに `trips.trip_headsign` を使用する必要があります。

1 つの `stop_time` に指定された `stop_headsign` 値は、同じ行程内の後続の `stop_time` には適用されません。同じ行程内の複数の `stop_time` に対して `trip_headsign` をオーバーライドする場合は、各 `stop_time` 行で `stop_headsign` 値を繰り返す必要があります。| +| `stop_id` | `stops.stop_id` を参照する外部 ID | **条件付きで必須** | 運行される停留所を識別します。運行中に運行されるすべての停留所は、[stop_times.txt](#stop_timestxt) に記録されている必要があります。参照される場所は停留所/プラットフォームである必要があります。つまり、`stops.location_type` 値は `0` または空である必要があります。同じ旅程で 1 つの停留所が複数回サービスされる場合があり、複数の旅程とルートが同じ停留所にサービスを提供する場合があります。

停留所を使用するオンデマンド サービスは、それらの停留所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 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` | テキスト | オプション | 乗客に便の目的地を示す標識に表示されるテキスト。このフィールドは、停留所間でヘッドサインが変わる場合にデフォルトの `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` - ピックアップを手配するにはドライバーと調整する必要があります。

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

`0` または空 - 定期的に予定されている降車。
`1` - 降車はありません。
`2` - 降車を手配するには代理店に電話する必要があります。
`3` - 降車を手配するには運転手と調整する必要があります。

**条件付きで禁止**:
- `start_pickup_drop_off_window` または `end_pickup_drop_off_window` が定義されている場合は `drop_off_type=0` **禁止**。
- それ以外の場合はオプション。| -| `continuous_pickup` | Enum | **条件付きで禁止** | 乗客は、[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` | 負でない浮動小数点数 | オプション | 関連するシェイプに沿って、最初の停車地からこのレコードで指定された停車地まで実際に移動した距離。このフィールドは、旅行中に任意の 2 つの停車地の間にシェイプをどれだけ描画するかを指定します。[shapes.txt](#shapestxt) で使用されているのと同じ単位にする必要があります。`shape_dist_traveled` に使用する値は、`stop_sequence` とともに増加する必要があります。ルートに沿った逆方向の移動を示すために使用しないでください。

ループまたはインライン (車両が 1 回の移動で同じ部分の線形を横切ったり移動したりする) があるルートに推奨されます。[`shapes.shape_dist_traveled`](#shapestxt) を参照してください。
*例: バスがシェイプの開始から停留所まで 5.25 キロメートルの距離を移動する場合、`shape_dist_traveled`=`5.25`。*| +| `continuous_pickup` | Enum | **条件付きで禁止** | 乗客は、[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` | 負でない浮動小数点数 | オプション | 関連する形状に沿って、最初の停留所からこのレコードで指定された停留所まで実際に移動した距離。このフィールドは、便中に任意の 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` の場合に推奨されます。 | @@ -344,7 +344,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | ------ | ------ | ------ | ------ | | `service_id` | `calendar.service_id` または ID を参照する外部 ID | **必須** | 1 つ以上のルートでサービス例外が発生する日付のセットを識別します。[calendar.txt](#calendartxt) と [calendar_dates.txt](#calendar_datestxt) を併用する場合、各 (`service_id`、`date`) ペアは [calendar_dates.txt](#calendar_datestxt) に 1 回だけ出現できます。 `service_id` 値が [calendar.txt](#calendartxt) と [calendar_dates.txt](#calendar_datestxt) の両方に出現する場合、[calendar_dates.txt](#calendar_datestxt) の情報によって [calendar.txt](#calendartxt) で指定されたサービス情報が変更されます。 | | `date` | 日付 | **必須** | サービス例外が発生した日付。 | -| `exception_type` | 列挙型 | **必須** | 日付フィールドで指定された日付にサービスが利用可能かどうかを示します。有効なオプションは次のとおりです:

`1` - 指定された日付にサービスが追加されました。
`2` - 指定された日付にサービスが削除されました。
*例: ルートに休日に利用可能な旅行セットと、他のすべての日に利用可能な旅行セットがあるとします。 1 つの `service_id` は通常のサービス スケジュールに対応し、別の `service_id` は休日スケジュールに対応します。特定の休日については、[calendar_dates.txt](#calendar_datestxt) ファイルを使用して休日を休日 `service_id` に追加したり、通常の `service_id` スケジュールから休日を削除したりできます。* | +| `exception_type` | 列挙型 | **必須** | 日付フィールドで指定された日付にサービスが利用可能かどうかを示します。有効なオプションは次のとおりです:

`1` - 指定された日付にサービスが追加されました。
`2` - 指定された日付にサービスが削除されました。
*例: ルートに休日に利用可能な便セットと、他のすべての日に利用可能な便セットがあるとします。 1 つの `service_id` は通常のサービス スケジュールに対応し、別の `service_id` は休日スケジュールに対応します。特定の休日については、[calendar_dates.txt](#calendar_datestxt) ファイルを使用して休日を休日 `service_id` に追加したり、通常の `service_id` スケジュールから休日を削除したりできます。* | ### fare_attributes.txt @@ -353,7 +353,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`fare_id`) **バージョン**
-運賃を記述するためのモデリング オプションは 2 つあります。GTFS-Fares V1 は、最小限の運賃情報を記述するための従来のオプションです。GTFS-Fares V2 は、交通機関の運賃構造をより詳細に説明できる更新された方法です。データセットには両方の方法を使用できますが、特定のデータセットに対してデータ コンシューマーが使用できる方法は 1 つだけです。GTFS-Fares V2 を GTFS-Fares V1 よりも優先することをお勧めします。

GTFS-Fares V1 に関連付けられているファイルは次のとおりです:
- [fare_attributes.txt](#fare_attributestxt)
- [fare_rules.txt](#fare_rulestxt)

GTFS-Fares V2 に関連付けられているファイルは次のとおりです:
- [fare_media.txt](#fare_mediatxt)
- [fare_products.txt](#fare_productstxt)
- [fare_leg_rules.txt](#fare_leg_rulestxt)
- [fare_transfer_rules.txt](#fare_transfer_rulestxt) +運賃を記述するためのモデリング オプションは 2 つあります。GTFS-Fares V1 は、最小限の運賃情報を記述するための従来のオプションです。GTFS-Fares V2 は、交通事業者の運賃構造をより詳細に説明できる更新された方法です。データセットには両方の方法を使用できますが、特定のデータセットに対してデータ コンシューマーが使用できる方法は 1 つだけです。GTFS-Fares V2 を GTFS-Fares V1 よりも優先することをお勧めします。

GTFS-Fares V1 に関連付けられているファイルは次のとおりです:
- [fare_attributes.txt](#fare_attributestxt)
- [fare_rules.txt](#fare_rulestxt)

GTFS-Fares V2 に関連付けられているファイルは次のとおりです:
- [fare_media.txt](#fare_mediatxt)
- [fare_products.txt](#fare_productstxt)
- [fare_leg_rules.txt](#fare_leg_rulestxt)
- [fare_transfer_rules.txt](#fare_transfer_rulestxt)
@@ -385,9 +385,9 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | ------ | ------ | ------ | ------ | | `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) ファイルには運賃クラスに関する次のレコードが含まれます:*
` fare_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) ファイルには運賃クラスの次のレコードが含まれます:*
`fare_id,...,origin_id`
`b,...,2`
`b,...,8` | +| `origin_id` | `stops.zone_id` を参照する外部 ID | オプション | 出発地ゾーンを識別します。運賃クラスに複数の出発地ゾーンがある場合は、[fare_rules.txt](#fare_rulestxt) に各 `origin_id` のレコードを作成します。
*例: 運賃クラス "b" がゾーン "2" またはゾーン "8" のいずれかから出発するすべての便に有効な場合、[fare_rules.txt](#fare_rulestxt) ファイルには運賃クラスの次のレコードが含まれます:*
`fare_id,...,origin_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) ファイルには運賃クラスの次のレコードが含まれます:*
`fare_id,...,origin_id,destination_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) をご覧ください。* | +| `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 @@ -395,7 +395,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`*`) -時間帯、曜日、または特定の日に基づいて変動する運賃を説明するために使用されます。時間枠は、[fare_leg_rules.txt](#fare_leg_rulestxt) で運賃商品に関連付けることができます。
+時間帯、曜日、または特定の日に基づいて変動する運賃を説明するために使用されます。時間枠は、[fare_leg_rules.txt](#fare_leg_rulestxt) でチケット商品に関連付けることができます。
同じ `timeframe_group_id` 値と `service_id` 値に重複する時間間隔があってはなりません。 | フィールド名 | タイプ | 存在 | 説明 | @@ -407,7 +407,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti #### タイムフレームのローカル時間セマンティクス - 運賃イベントの時間を [timeframes.txt](#timeframestxt) に対して評価する場合、イベント時間は、運賃イベントの停車駅または親駅の `stop_timezone` (指定されている場合) によって決定されるローカル タイムゾーンを使用してローカル時間で計算されます。指定されていない場合は、フィードの事業者のタイムゾーンを代わりに使用するするべきである。 -- `現在の日`は、ローカル タイムゾーンを基準に計算された運賃イベントの時間の現在のdateです。`現在の日`は、特に深夜を過ぎる便の場合、運賃区間の旅行のサービス日とは異なるしてもよい。 +- `現在の日`は、ローカル タイムゾーンを基準に計算された運賃イベントの時間の現在のdateです。`現在の日`は、特に深夜を過ぎる便の場合、運賃区間の便のサービス日とは異なるしてもよい。 - 運賃イベントの`時刻`は、GTFS 時間フィールドタイプのセマンティクスを使用して、`現在の日`を基準にして計算されます。 ### fare_media.txt @@ -416,13 +416,13 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`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_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 @@ -434,11 +434,11 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | フィールド名 | タイプ | 存在 | 説明 | |------|------|------|------| -| `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_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 @@ -447,13 +447,13 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`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) は、旅行の特性を定義するフィールドでフィルタリングするしなければならない。これらのフィールドは次のとおりです: +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` @@ -461,7 +461,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti - `fare_leg_rules.to_timeframe_group_id`
-2. 旅行の特性に基づいて、区間が [fare_leg_rules.txt](#fare_leg_rulestxt) のレコードと完全に一致する場合、そのレコードを処理して区間のコストを決定するしなければならない。このファイルは、空のエントリを 2 つの方法で処理します: 空のセマンティクスまたはルールの優先順位。 +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`の空のエントリをチェックして、区間のコストを処理するしなければならない。 @@ -489,7 +489,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | `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 | **必須** | 区間を移動するために必要な運賃商品。 | +| `fare_product_id` | `fare_products.fare_product_id` を参照する外部 ID | **必須** | 区間を移動するために必要なチケット商品。 | | `rule_priority` | 負でない整数 | オプション | マッチング ルールが区間に適用される優先順位を定義し、特定のルールを他のルールよりも優先できるようにします。`fare_leg_rules.txt` 内の複数のエントリが一致する場合、`rule_priority` の値が最も高いルールまたはルール セットが選択されます。

`rule_priority` の値が空の場合、ゼロとして扱われます。 | ### fare_transfer_rules.txt @@ -498,11 +498,11 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`from_leg_group_id, to_leg_group_id, fare_product_id, transfer_count, duration_limit`) -[`fare_leg_rules.txt`](#fare_leg_rulestxt) で定義された旅行区間間の乗り換えの運賃規則。 +[`fare_leg_rules.txt`](#fare_leg_rulestxt) で定義された便区間間の乗り換えの運賃規則。 複数区間の旅程の費用を処理するには: -1. `fare_leg_rules.txt`で定義された適用可能な運賃区間グループは、乗客の旅程に基づいて、すべての個々の旅行区間に対して決定するするべきである。 +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`
@@ -524,7 +524,7 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | `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 です。| +| `fare_product_id` | `fare_products.fare_product_id`部` ID |任意| 2 つの運賃区間間の乗り換えに必須チケット商品。空の場合、乗り換えルールのコストは 0 です。| ### areas.txt @@ -585,15 +585,15 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 主キー(`shape_id`、 `shape_pt_sequence`) -ルート形状は、車両がルート線形に沿って移動するパスを説明し、ファイルshapes.txtで定義されます。ルート形状は便に関連付けられ、車両が順番に通過する一連のポイントで構成されます。ルート形状は停留所等の位置を正確にインターセプトする必要はありませんが、トリップのすべての停留所等は、そのトリップのシェイプからわずかな距離内、つまりシェイプポイントを接続する直線セグメントの近くに配置するするべきであるがあります。 shapes.txtファイルは、すべてのルートベースのサービス (ゾーンベースのデマンドレスポンシブサービスではありません) に含めるするべきである。 +ルート形状は、車両がルート線形に沿って移動するパスを説明し、ファイル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` | 非負の浮動小数点数 | オプション | 最初のシェイプ ポイントからこのレコードで指定されたポイントまでのシェイプに沿って実際に移動した距離。旅行プランナーがマップ上にシェイプの正しい部分を表示するために使用します。値は `shape_pt_sequence` とともに増加する必要があり、ルートに沿った逆方向の移動を示すために使用してはなりません。距離の単位は、[stop_times.txt](#stop_timestxt) で使用されている単位と一致している必要があります。

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

車両が移動中にポイントでルート線形をたどったり横断したりする場合、[shapes.txt](#shapestxt) のポイントの一部が [stop_times.txt](#stop_timestxt) のレコードとどのように対応しているかを明確にするために、`shape_dist_traveled` が重要です。
*例: バスが上記で 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` | +| `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` | 非負の浮動小数点数 | オプション | 最初の形状 ポイントからこのレコードで指定されたポイントまでの形状に沿って実際に移動した距離。便プランナーがマップ上に形状の正しい部分を表示するために使用します。値は `shape_pt_sequence` とともに増加する必要があり、ルートに沿った逆方向の移動を示すために使用してはなりません。距離の単位は、[stop_times.txt](#stop_timestxt) で使用されている単位と一致している必要があります。

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

車両が移動中にポイントでルート線形をたどったり横断したりする場合、[shapes.txt](#shapestxt) のポイントの一部が [stop_times.txt](#stop_timestxt) のレコードとどのように対応しているかを明確にするために、`shape_dist_traveled` が重要です。
*例: バスが上記で 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 @@ -609,11 +609,11 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti | フィールド名 |タイプ | 存在 | 説明 | |------|------|------|------| -| `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`より小さくするしなければならない。| +| `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 @@ -630,19 +630,19 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti 3. 1つの`trip_id`が定義されています: `from_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` が定義されています: ルートまたは旅行関連のフィールドは設定されていません。 + 6. `from_stop_id`および`to_stop_id` が定義されています: ルートまたは便関連のフィールドは設定されていません。 -到着旅行と出発旅行の順序付けられたペアが指定されている場合、これら 2 つの便間に適用される最も詳細度の高い乗り換えが選択されます。どの便のペアにも、適用可能な最大詳細度が同等の 2 つの乗り換えが存在することはするべきではない +到着便と出発便の順序付けられたペアが指定されている場合、これら 2 つの便間に適用される最も詳細度の高い乗り換えが選択されます。どの便のペアにも、適用可能な最大詳細度が同等の 2 つの乗り換えが存在することはするべきではない | フィールド名 | タイプ | 存在 | 説明 | |------|------|------|------| | `from_stop_id` | `stops.stop_id` を参照する外部 ID |**条件付きで必須**|ルート・路線系統間の接続が開始される停留所または駅を識別します。このフィールドが駅を参照する場合、乗り換えルールはそのすべての子の停留所等に適用されます。`transfer_types` 4 および5.では駅の参照は禁止されています。| | `transfer_types` `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` が優先されます。 | +| `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)を参照してください。 | +| `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 つの停留所等間を移動するのに十分な時間であるするべきである。 | #### リンクされた便 @@ -653,14 +653,14 @@ _例: `trip_id` フィールドと `stop_sequence` フィールドは、[stop_ti リンクされた便転送と block_id の両方が提供され、矛盾する結果が生成される場合は、リンクされた便転送を使用する必要がありしなければならない。 -`from_trip_id` の最後の停車地は、 `to_trip_id`の最初の停車地に地理的に近い必要がするべきである、 `from_trip_id`の`from_trip_id` `to_trip_id`の最後の到着時刻は、 `to_trip_id` `to_trip_id`の最初の出発時刻より後になる場合がしてもよい。 +`from_trip_id` の最後の停留所は、 `to_trip_id`の最初の停留所に地理的に近い必要がするべきである、 `from_trip_id`の`from_trip_id` `to_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` がどのサービス日でも重複してはならないという条件で、複数の異なる継続の一部として旅行をリンクできます。 +- `trip.service_id` がどのサービス日でも重複してはならないという条件で、複数の異なる継続の一部として便をリンクできます。 
 Trip A
@@ -780,12 +780,12 @@ Trip B              /
 | ------ | ------ | ------ | ------ |
 | `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_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` | テキスト | オプション | オンデマンドのピックアップとドロップオフを予約するときに、`stop_time` でサービスを利用する乗客へのメッセージ。ユーザー インターフェイス内で送信される、サービスを利用するために乗客が実行する必要があるアクションに関する最小限の情報を提供することを目的としています。|
 | `pickup_message` | テキスト | オプション | `message` と同じように機能しますが、乗客がオンデマンドのピックアップのみを利用する場合に使用されます。|
@@ -800,7 +800,7 @@ Trip B              /
 
 主キー(`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`) で提供される翻訳が優先されます。
 
@@ -820,7 +820,7 @@ Trip B              /
 
 主キー（なし）
 
-ファイルには、データセットが記述するサービスではなく、データセット自体に関する情報が含まれます。場合によっては、データセットの発行者が機関とは異なるエンティティであることがあります。
+ファイルには、データセットが記述するサービスではなく、データセット自体に関する情報が含まれます。場合によっては、データセットの発行者が事業者とは異なるエンティティであることがあります。
 
 | フィールド名 | タイプ | 存在 | 説明 |
 |------|------|------|------|
@@ -845,9 +845,9 @@ Trip B              /
 | フィールド名 | タイプ | 存在 | 説明 |
 | ------ | ------ | ------ | ------ |
 | `attribution_id` | 一意の ID | オプション | データセットまたはそのサブセットの属性を識別します。これは主に翻訳に役立ちます。 |
-| `agency_id` | `agency.agency_id` を参照する外部 ID | オプション | 属性が適用される機関。

`agency_id`、`route_id`、または `trip_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` と同じように機能しますが、帰属が旅行に適用されます。同じ旅行に複数の帰属が適用される場合があります。 |
+| `trip_id` | `trips.trip_id` を参照する外部 ID | オプション | `agency_id` と同じように機能しますが、帰属が便に適用されます。同じ便に複数の帰属が適用される場合があります。 |
 | `organization_name` | テキスト | **必須** | データセットの帰属先となる組織の名前。 |
 | `is_producer` | 列挙型 | オプション | 組織の役割はプロデューサーです。有効なオプションは次のとおりです:

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

`is_producer`、`is_operator`、または `is_authority` のフィールドの少なくとも 1 つを `1` に設定する必要があります。 |
 | `is_operator` | 列挙型 | オプション | 組織の役割がオペレーターであることを除いて、`is_producer` と同じように機能します。 |
diff --git a/docs/ja/documentation/schedule/schedule_best_practices.md b/docs/ja/documentation/schedule/schedule_best_practices.md
index ba27b887..964dd7e1 100644
--- a/docs/ja/documentation/schedule/schedule_best_practices.md
+++ b/docs/ja/documentation/schedule/schedule_best_practices.md
@@ -1,6 +1,6 @@
 # GTFS スケジュールのベスト プラクティス
 
-これらは、[General Transit Feed Specific (GTFS)](../reference) で公共交通機関のサービスを記述するための推奨プラクティスです。これらのプラクティスは、[GTFS ベスト プラクティス ワーキング グループ](#gtfs-best-practices-working-group) メンバーの経験と [アプリケーション固有の GTFS プラクティス推奨事項](http://www.transitwiki.org/TransitWiki/index.php/Best_practices_for_creating_GTFS) からまとめられたものです。
+これらは、[General Transit Feed Specific (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) を参照してください。
 
@@ -15,13 +15,13 @@
 ## データセットの公開と一般的な実践
 
 * データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります (例: www.agency.org/gtfs/gtfs.zip)。理想的には、ソフトウェア アプリケーションを使用するダウンロードを容易にするために、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできる必要があります。 GTFS データセットはオープンにダウンロード可能にすることが推奨されています (最も一般的な方法) が、データ プロバイダがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することをお勧めします。
-* GTFS データは反復的に公開されるため、安定した場所にある 1 つのファイルには常に、交通機関 (または複数の機関) のサービスの最新の公式説明が含まれます。
+* 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) フィード (サービス アドバイザリまたは旅行更新) を通じてこのサービスの変更を表現します。
+* サービスの変更が 7 日以内に有効になる場合は、静的な GTFS データセットではなく、[GTFS-realtime](../../realtime/reference) フィード (サービス アドバイザリまたは便更新) を通じてこのサービスの変更を表現します。
 * GTFS データをホストする Web サーバーは、ファイル変更日を正しく報告するように構成する必要があります ([HTTP/1.1 - Request for Comments 2616](https://tools.ietf.org/html/rfc2616#section-14.29) のセクション 14.29 を参照)。
 
 ## ファイル別にまとめた実践推奨事項
@@ -45,7 +45,7 @@
 |---|---|
 | `agency_phone` | そのようなカスタマー サービス電話番号が存在しない限り、含めるするべきである。 |
 | `agency_email` | そのようなカスタマー サービス メールが存在しない限り、含めるするべきであるます。 |
-| `agency_fare_url` | 完全に無料の旅行事業者でない限り、含めるするべきである。 |
+| `agency_fare_url` | 完全に無料の便事業者でない限り、含めるするべきである。 |
 
 __例:__
 
@@ -61,42 +61,42 @@ __例:__
 | | デフォルトでは、`stop_name` に `Station` や `Stop` などの一般的な単語や冗長な単語を含めするべきではない。ただし、一部の例外は許可されます。 |
 | `stop_lat` と `stop_lon` | 停留所の位置はできる限り正確であるするべきである。実際の停留所Positionと比較して、停留所の位置の誤差は 4 メートル以内であるするべきである。 |
 | | 停留所の位置は、乗客が乗車する歩行者通行権のすぐ近く (つまり、道路の正しい側) に配置するするべきである。 |
-| | 停留所の位置が別のデータ フィード間で共有されている場合 (つまり、2 つの機関がまったく同じ停留所/乗車施設を使用している場合)、両方の停留所等にまったく同じ `stop_lat` と `stop_lon` を使用して、停留所が共有されていることを示します。 |
+| | 停留所の位置が別のデータ フィード間で共有されている場合 (つまり、2 つの事業者がまったく同じ停留所/乗車施設を使用している場合)、両方の停留所等にまったく同じ `stop_lat` と `stop_lon` を使用して、停留所が共有されていることを示します。 |
 | `parent_station` と `location_type` | 多くの駅やターミナルには複数の乗車施設があります (モードに応じて、バス停、プラットフォーム、埠頭、ゲートなどと呼ばれる場合があります)。このような場合、フィード作成者は駅、乗車施設 (子停留所等とも呼ばれます)、およびそれらの関係を説明するするべきである。 |
-| | 駅や子供用停留所等に名前を付ける場合は、乗客によく知られ、乗客が駅や乗車施設（バス停、プラットホーム、埠頭、ゲートなど）を識別できるような名前を付けてください。
親ステーション名子の停留所名
シカゴ ユニオン駅シカゴ ユニオン駅 19番線
サンフランシスコフェリービルディングターミナルサンフランシスコフェリービルターミナルゲートE
ダウンタウン トランジット センターダウンタウン トランジット センター ベイ B
 |
+| | 駅や子停留所等に名前を付ける場合は、乗客によく知られ、乗客が駅や乗車施設（バス停、プラットホーム、埠頭、ゲートなど）を識別できるような名前を付けてください。
親ステーション名子の停留所名
シカゴ ユニオン駅シカゴ ユニオン駅 19番線
サンフランシスコフェリービルディングターミナルサンフランシスコフェリービルターミナルゲートE
ダウンタウン トランジット センターダウンタウン トランジット センター ベイ B
 |
 
 ### routes.txt 
 | フィールド名 | 推奨事項 |
 | --- | --- |
-| `route_long_name` | 仕様リファレンスの定義: この名前は一般に route_short_name よりも説明的であり、多くの場合、ルートの目的地または停車地が含まれます。route_short_name または route_long_name の少なくとも 1 つを指定する必要があります。適切な場合は両方を指定することもできます。ルートに長い名前がない場合は、route_short_name を指定し、このフィールドの値として空の文字列を使用してください。
長い名前の種類の例を以下に示します。
主要な移動経路または回廊
ルート名フォーム機関
“N”/“Judah”route_short_name/
route_long_name		Muni、サンフランシスコフランシスコ
“6“/“ML King Jr Blvd“route_short_name/
route_long_name		TriMet、オレゴン州ポートランド
“6”/“Nation - Étoile”route_short_name/
route_long_name		RATP、 
“U2”-“Pankow – Ruhleben”route_short_name-
route_long_name		BVG、ドイツ、ベルリン
サービスの説明
“Hartwell Area Shuttle“

+| `route_long_name` | 仕様リファレンスの定義: この名前は一般に route_short_name よりも説明的であり、多くの場合、ルートの目的地または停留所が含まれます。route_short_name または route_long_name の少なくとも 1 つを指定する必要があります。適切な場合は両方を指定することもできます。ルートに長い名前がない場合は、route_short_name を指定し、このフィールドの値として空の文字列を使用してください。
長い名前の種類の例を以下に示します。
主要な移動経路または回廊
ルート名フォーム事業者
“N”/“Judah”route_short_name/
route_long_name		Muni、サンフランシスコフランシスコ
“6“/“ML King Jr Blvd“route_short_name/
route_long_name		TriMet、オレゴン州ポートランド
“6”/“Nation - Étoile”route_short_name/
route_long_name		RATP、 
“U2”-“Pankow – Ruhleben”route_short_name-
route_long_name		BVG、ドイツ、ベルリン
サービスの説明
“Hartwell Area Shuttle“

 | | `route_long_name` には `route_short_name` を含めないでください。|
 | | `route_long_name` を入力するときは、サービス ID を含む完全な指定を含めてください。例:
サービス ID推奨事項例
"MAX Light Rail"
オレゴン州ポートランドの TriMet		route_long_name には、ブランド (MAX) と特定のルート指定を含める必要があります"MAX Red Line" "MAX Blue Line"
"Rapid Ride"
ニューメキシコ州アルバカーキの ABQ Ride		route_long_name には、ブランド (Rapid Ride) と特定のルート指定を含める必要があります"Rapid Ride Red Line"
"Rapid Ride Blue Line"

-| `route_id` |特定の名前付きルートのすべての旅行は、同じ `route_id` を参照する必要があります。
  • ルートの異なる方向を、異なる `route_id` 値に分割しないでください。
  • ルートの異なる運行区間を、異なる `route_id` 値に分割しないでください。つまり、`routes.txt` で「Downtown AM」サービスと「Downtown PM」サービスに異なるレコードを作成しないでください。
    •  |
+| `route_id` |特定の名前付きルートのすべての便は、同じ `route_id` を参照する必要があります。
  • ルートの異なる方向を、異なる `route_id` 値に分割しないでください。
  • ルートの異なる運行区間を、異なる `route_id` 値に分割しないでください。つまり、`routes.txt` で「Downtown AM」サービスと「Downtown PM」サービスに異なるレコードを作成しないでください。
    •  |
 | | ルート グループに明確に名前が付けられたブランチ (例: 1A と 1B) が含まれている場合は、ルート [branches](#branches) ケースの推奨事項に従って、`route_short_name` と `route_long_name` を決定します。 |
 | `route_color` と `route_text_color` | 標識、印刷された顧客情報、オンラインの顧客情報と一致している必要があります (他の場所に存在しない場合は含まれません)。 |
 
 ### trips.txt 
 
-* __ループルート・路線系統の特殊なケースを参照してください :__ ループルート・路線系統は、2 つの異なる終点がある線形ルート・路線系統とは対照的に、便が同じ停留所で開始および終了する場合です。ループルート・路線系統は、特定のプラクティスに従って記述するしなければならない。[ループ ルートのケースを参照してください。](#loop-routes)
-* __ラッソルート・路線系統の特殊なケースを参照してください :__ ラッソルート・路線系統は、線形ジオメトリとループ ジオメトリのハイブリッドであり、車両はルートの一部のみをループして移動します。 Lassoルート・路線系統は、特定のプラクティスに従って記述するしなければならない。[Lasso ルートのケースを参照してください。](#lasso-routes)
+* __環状ルート・路線系統の特殊なケースを参照してください :__ 環状ルート・路線系統は、2 つの異なる終点がある線形ルート・路線系統とは対照的に、便が同じ停留所で開始および終了する場合です。環状ルート・路線系統は、特定のプラクティスに従って記述するしなければならない。[ループ ルートのケースを参照してください。](#loop-routes)
+* __投げ縄状ルート・路線系統の特殊なケースを参照してください :__ 投げ縄状ルート・路線系統は、線形ジオメトリとループ ジオメトリのハイブリッドであり、車両はルートの一部のみをループして移動します。 Lassoルート・路線系統は、特定のプラクティスに従って記述するしなければならない。[Lasso ルートのケースを参照してください。](#lasso-routes)
 
 | フィールド名 | 推奨事項 |
 | --- | --- |
 | `trip_headsign` | `trip_headsign` または `stop_headsign` フィールドにルート名 (`route_short_name` および `route_long_name` に一致するもの) を指定しないでください。 |
-| | ルート内の旅行を区別するために使用できる、車両のヘッドサインに表示される目的地、方向、およびその他の旅行指定テキストを含める必要があります。車両に表示される方向情報との一貫性は、GTFS データセットで提供されるヘッドサインを決定するための主要かつ最優先の目標です。その他の情報は、この主要目標を損なわない場合にのみ含める必要があります。旅行中にヘッドサインが変わる場合は、`trip_headsign` を `stop_times.stop_headsign` で上書きします。以下に、考えられるいくつかのケースに対する推奨事項を示します。 |
+| | ルート内の便を区別するために使用できる、車両のヘッドサインに表示される目的地、方向、およびその他の便指定テキストを含める必要があります。車両に表示される方向情報との一貫性は、GTFS データセットで提供されるヘッドサインを決定するための主要かつ最優先の目標です。その他の情報は、この主要目標を損なわない場合にのみ含める必要があります。便中にヘッドサインが変わる場合は、`trip_headsign` を `stop_times.stop_headsign` で上書きします。以下に、考えられるいくつかのケースに対する推奨事項を示します。 |
 | | 
    ルートの説明推奨事項
    2A.目的地のみ終点の目的地を指定します。例: 「Transit Center」、「Portland City Center」、または「Jantzen Beach」> 
    2B. ウェイポイントのある目的地<destination> via <waypoint> 「Highgate via Charing Cross」。車両がウェイポイントを通過した後に、乗客に表示されるヘッドサインからウェイポイントが削除された場合は、stop_times.stop_headsign を使用して更新されたヘッドサインを設定します。> 
    2C. ローカル停留所のある地域の地名目的地の都市または自治区内に複数の停留所がある場合は、目的地の都市に到着したら stop_times.stop_headsign を使用します。> 
    2D.方向のみ「北行き」、「内行き」、「時計回り」などの用語を使用して示します。
    2E. 目的地を含む方向<direction> から <terminus name> へ。例: 「南行き、サンノゼ行き」
    2F. 目的地とウェイポイントを含む方向<direction> から <waypoint> へ (「北行き、チャリング クロス経由、ハイゲート行き」)。
     |
 | | ヘッドサインの先頭に「To」または「Towards」という語句を使用しないでください。 |
 | `direction_id` | データセット全体で一貫して 0 と 1 の値を使用します。つまり、 |
-| `bikes_allowed` | フェリー旅行の場合、自転車が許可されている (または許可されていない) ことを明示的に示してください。データが欠落しているためにフェリー旅行を避けると、通常、大きな迂回につながります。 |
+| `bikes_allowed` | フェリー便の場合、自転車が許可されている (または許可されていない) ことを明示的に示してください。データが欠落しているためにフェリー便を避けると、通常、大きな迂回につながります。 |
 
 ### stop_times.txt 
 
-ループルート・路線系統: ループルート・路線系統では、特別な`stop_times`の考慮が必要です。(参照: [ループ ルートのケース](#loop-routes))
+環状ルート・路線系統: 環状ルート・路線系統では、特別な`stop_times`の考慮が必要です。(参照: [ループ ルートのケース](#loop-routes))
 
 | フィールド名 | 推奨事項 |
 | --- | --- |
-| `pickup_type` および `drop_off_type` | 乗客サービスを提供しない非収益 (回送) の旅行は、すべての `stop_times` 行で `pickup_type` および `drop_off_type` の値を `1` としてマークする必要があります。
-| | 収益旅行では、運用パフォーマンスを監視するための内部の「タイミング ポイント」や、乗客が乗車できないガレージなどの場所は、`pickup_type = 1` (ピックアップなし) および `drop_off_type = 1` (ドロップオフなし) としてマークする必要があります。 |
+| `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` |一般的に、ヘッドサインの値も駅の標識に対応している必要があります。

    以下の場合、「南行き」は駅の標識では使用されていないため、お客様に誤解を与える可能性があります。
 | | 
    ニューヨーク市では、南行きの 2 路線について:
    stop_times.txt 行の場合:stop_headsign 値を使用します:
    マンハッタンに到着するまでマンハッタン & ブルックリン
    ダウンタウンに到着するまでダウンタウン & ブルックリン
    ブルックリンに到着するまでブルックリン
    ブルックリンに到着したらブルックリン (New Lots Av)
     |
@@ -134,14 +134,14 @@ __例:__
 | --- | --- |
 | すべてのフィールド | 理想的には、共有されている線形 (つまり、ルート 1 と 2 が同じ道路または線路のセグメントで動作している場合) の場合、共有されている線形部分は完全に一致する必要があります。これにより、高品質の交通地図作成が容易になります。
 | | 線形は、車両が走行する道路の中心線に従う必要があります。これは、指定車線がない場合は道路の中心線、または車両が移動する方向の道路の側の中心線のいずれかになります。

    線形は、縁石の停止、プラットフォーム、または乗車場所に対して「ギザギザ」になってはなりません。 |
-| `shape_dist_traveled` | `shape_dist_traveled` フィールドを使用すると、機関は `stop_times.txt` ファイル内の停止がそれぞれの形状にどのように適合するかを正確に指定できます。 `shape_dist_traveled` フィールドに使用する一般的な値は、車両が移動した形状の開始点からの距離です (走行距離計の読み取り値のようなものと考えてください)。
  • ルートの配置 (`shapes.txt` 内) は、旅行がサービスを提供する停止場所から 100 メートル以内である必要があります。
  • 配置を簡素化して、shapes.txt に余分なポイントが含まれないようにします (つまり、直線セグメント上の余分なポイントを削除します。線の簡素化の問題に関する説明を参照してください)。
    •  |
+| `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` | 頻度ベースの旅行に提供できます。 |
+| すべてのフィールド | `frequencies.txt` で参照される便では実際の停車時間は無視されます。頻度ベースの便では、停車間の移動時間間隔のみが重要です。明確さと読みやすさのために、`frequencies.txt` で参照される便の最初の停車時間は 00:00:00 (最初の `arrival_time` 値が 00:00:00) から開始することをお勧めします。 |
+| `block_id` | 頻度ベースの便に提供できます。 |
 
 ### transfers.txt 
 
@@ -153,26 +153,26 @@ __例:__
 | | 1: これは、2 つのルート間の時間指定乗換ポイントです。出発車両は、乗客がルート間を乗り換えるのに十分な時間、到着車両を待つことが期待されます。
    この乗換タイプは、確実に乗り換えを行うために必要な間隔をオーバーライドします。たとえば、Google マップでは、乗客が安全に乗り換えるのに 3 分かかると想定しています。他のアプリケーションでは、他のデフォルトが想定される場合があります。 |
 | | 2: この乗り換えでは、接続を確実にするために、到着から出発までの間に最小限の時間が必要です。乗り換えに必要な時間は、min_transfer_time で指定します。
    障害物やその他の要因により停留所間の移動時間が長くなる場合は、最小乗り換え時間を指定します。 |
 | | 3: この場所ではルート間の乗り換えはできません。
    物理的な障壁のために乗り換えができない場合、または難しい道路横断や歩行者ネットワークの隙間によって乗り換えが安全でなかったり複雑になったりする場合は、この値を指定します。 |
-| | 旅行間で座席内 (ブロック) 乗り換えが許可されている場合、到着旅行の最後の停留所は、出発旅行の最初の停留所と同じである必要があります。 |
+| | 便間で座席内 (ブロック) 乗り換えが許可されている場合、到着便の最後の停留所は、出発便の最初の停留所と同じである必要があります。 |
 
 
 ## 事例別に整理された実践推奨事項
 
 このセクションでは、ファイルやフィールド全体に影響を与える特定の事例について説明します。
 
-### ループルート・路線系統
+### 環状ルート・路線系統
 
-ループルート・路線系統では、車両の便は同じ場所 (場合によってはトランジット センターまたは乗り換えセンター) で始まり、終わります。車両は通常、連続的に運行し、車両がループを続ける間、乗客は車内にとどまることができます。
+環状ルート・路線系統では、車両の便は同じ場所 (場合によってはトランジット センターまたは乗り換えセンター) で始まり、終わります。車両は通常、連続的に運行し、車両がループを続ける間、乗客は車内にとどまることができます。
 
  
 
-したがって、乗客に車両の進行方向を示すために、行先表示の推奨事項を適用するするべきである移動方向の変更を示すには、 `stop_times.txt`ファイルに`stop_headsigns` を`stop_headsign`します。`stop_headsign` は、定義されている停留所から出発する便の方向を説明します。旅行の各停留所に`stop_headsigns` を追加すると、旅行中のヘッドサイン情報を変更できます。
+したがって、乗客に車両の進行方向を示すために、行先表示の推奨事項を適用するするべきである移動方向の変更を示すには、 `stop_times.txt`ファイルに`stop_headsigns` を`stop_headsign`します。`stop_headsign` は、定義されている停留所から出発する便の方向を説明します。便の各停留所に`stop_headsigns` を追加すると、便中のヘッドサイン情報を変更できます。
 
-2つのエンドポイント間で動作するルート (同じバスが往復する場合など) に対して、 stop_times.txtファイルで 1 つの循環旅行を定義しないでください。代わりに、旅行を 2 つの別々の旅行方向に分割します。
+2つのエンドポイント間で動作するルート (同じバスが往復する場合など) に対して、 stop_times.txtファイルで 1 つの循環便を定義しないでください。代わりに、便を 2 つの別々の便方向に分割します。
 
-__循環旅行のモデリングの例:__
+__循環便のモデリングの例:__
 
-- 停留所ごとにヘッドサインが変化する循環旅行à
+- 停留所ごとにヘッドサインが変化する循環便à
 
 | trip_id | arrival_time | departure_time | stop_id | stop_sequence | stop_headsign |
 |---------|--------------|----------------|---------|---------------|---------------|
@@ -183,7 +183,7 @@ __循環旅行のモデリングの例:__
 | trip_1  | 06:30:00     | 06:30:00       | stop_E  | 5             | "A"           |
 | trip_1  | 06:35:00     | 06:35:00       | stop_A  | 6             | ""            |
 
-- 2つの行先表示がある循環旅行 
+- 2つの行先表示がある循環便 
 
 | trip_id | arrival_time | departure_time | stop_id | stop_sequence | stop_headsign |
 |---------|--------------|----------------|---------|---------------|---------------|
@@ -197,14 +197,14 @@ __循環旅行のモデリングの例:__
 
 | フィールド名 | 推奨事項 |
 | --- | --- |
-| `trips.trip_id `| ループの完全な往復を 1 回の旅行でモデル化します。 |
-| `stop_times.stop_id` | ループである旅行の場合は、`stop_times.txt` に最初/最後の停留所を 2 回含めます。以下に例を示します。多くの場合、ループ ルートには、ループ全体を移動しない最初と最後の旅行が含まれます。これらの旅行も含めます。 
    trip_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
     |
+| `trips.trip_id `| ループの完全な往復を 1 回の便でモデル化します。 |
+| `stop_times.stop_id` | ループである便の場合は、`stop_times.txt` に最初/最後の停留所を 2 回含めます。以下に例を示します。多くの場合、ループ ルートには、ループ全体を移動しない最初と最後の便が含まれます。これらの便も含めます。 
    trip_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
     |
 | `trips.direction_id` |ループが反対方向 (時計回りと反時計回り) に動作する場合は、`direction_id` を `0` または `1` に指定します。|
 | `trips.block_id` | 同じ `block_id` で連続ループ トリップを示します。|
 
 ### Lasso Routes
 
-Lasso routes は、ループルートと方向ルートの側面を組み合わせたものです。
+Lasso routes は、環状ルートと方向ルートの側面を組み合わせたものです。
 
   
 
@@ -217,12 +217,12 @@ Lasso routes は、ループルートと方向ルートの側面を組み合わ
 | フィールド名 | 推奨事項 |
 | --- | --- |
 | `trips.trip_id` | 「車両の往復」の全範囲 ([上記](#lasso-routes) の図を参照) は、A から B、B、そして A に戻る移動で構成されます。車両の往復全体は、次のように表現できます。
  • `trips.txt` 内の __single__ `trip_id` 値/レコード
  • `trips.txt` 内の__Multiple__ `trip_id` 値/レコード。連続した移動は `block_id` で示されます。
    •  |
-| `stop_times.stop_headsign` | A-B セクションに沿った停留所は、両方向で通過します。`stop_headsign` により、移動方向の区別が容易になります。したがって、これらの旅行には `stop_headsign` を提供することをお勧めします。example_table: 
     
    例:
    "A via B"
    "A"
    シカゴ交通局の パープル ライン
    "Southbound to Loop"
    "Northbound via Loop"
    "Northbound to Linden"
    エドモントン交通サービス バス路線、こちら 39
    "Rutherford"
    "Century Park"
    
-| `trip.trip_headsign` | 旅行のヘッドサインは、スケジュールに表示されるような旅行の全体的な説明である必要があります。「Linden から Linden 経由 Loop」(シカゴの例) または「A から A 経由 B」(一般的な例) などです。|
+| `stop_times.stop_headsign` | A-B セクションに沿った停留所は、両方向で通過します。`stop_headsign` により、移動方向の区別が容易になります。したがって、これらの便には `stop_headsign` を提供することをお勧めします。example_table: 
     
    例:
    "A via B"
    "A"
    シカゴ交通局の パープル ライン
    "Southbound to Loop"
    "Northbound via Loop"
    "Northbound to Linden"
    エドモントン交通サービス バス路線、こちら 39
    "Rutherford"
    "Century Park"
    
+| `trip.trip_headsign` | 便のヘッドサインは、スケジュールに表示されるような便の全体的な説明である必要があります。「Linden から Linden 経由 Loop」(シカゴの例) または「A から A 経由 B」(一般的な例) などです。|
 
 ### 分岐
 
-一部のルート・路線系統には分岐が含まれるしてもよい。これらの分岐間では配置と停留所等が共有されますが、それぞれが異なる停留所等と配置セクションも提供します。分岐間の関係は、以下の追加のガイドラインを使用して、ルート名、行先表示、旅行の短縮名で示すことがしてもよい。
+一部のルート・路線系統には分岐が含まれるしてもよい。これらの分岐間では配置と停留所等が共有されますが、それぞれが異なる停留所等と配置セクションも提供します。分岐間の関係は、以下の追加のガイドラインを使用して、ルート名、行先表示、便の短縮名で示すことがしてもよい。
 
   
 
@@ -230,7 +230,7 @@ Lasso routes は、ループルートと方向ルートの側面を組み合わ
 | --- | --- |
 | すべてのフィールド | 分岐ルートの命名では、他の乗客向け情報資料に従うことをお勧めします。以下は、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) は、ルートの大部分で共通の配置を共有していますが、いくつかの異なる側面で異なります。  |
-| | 機関が提供する情報で、分岐が同じ名前のルートとして説明されている場合は、`trips.trip_headsign`、`stop_times.stop_headsign`、および/または `trips.trip_short_name` フィールドを使用します。例: GoTriangle [ルート 300](https://gotriangle.org/sites/default/files/route_300_v.1.19.pdf) は、時間帯によって異なる場所に移動します。通勤ラッシュ時には、市内に出入りする労働者に対応するために、標準ルートに追加の区間が追加されます。 |
+| | 事業者が提供する情報で、分岐が同じ名前のルートとして説明されている場合は、`trips.trip_headsign`、`stop_times.stop_headsign`、および/または `trips.trip_short_name` フィールドを使用します。例: GoTriangle [ルート 300](https://gotriangle.org/sites/default/files/route_300_v.1.19.pdf) は、時間帯によって異なる場所に移動します。通勤ラッシュ時には、市内に出入りする労働者に対応するために、標準ルートに追加の区間が追加されます。 |
 
 ## よくある質問（FAQ）
 
@@ -238,15 +238,15 @@ Lasso routes は、ループルートと方向ルートの側面を組み合わ
 
 GTFS ベスト プラクティスの目的は次のとおりです。
 
-* 公共交通機関アプリにおけるエンドユーザーのカスタマー エクスペリエンスを向上させる
+* 公共交通事業者アプリにおけるエンドユーザーのカスタマー エクスペリエンスを向上させる
 * 幅広いデータの相互運用性をサポートし、ソフトウェア開発者がアプリケーション、製品、サービスを導入および拡張しやすくする
-* さまざまなアプリケーション カテゴリで GTFS の使用を促進する（旅行計画という当初の重点を超えて）
+* さまざまなアプリケーション カテゴリで GTFS の使用を促進する（便計画という当初の重点を超えて）
 
 GTFS ベスト プラクティスが調整されていないと、GTFS を利用するさまざまなアプリケーションが、調整されていない方法で要件と期待を確立するしてもよい。その結果、要件とアプリケーション固有のデータセットが分散し、相互運用性が低下します。ベスト プラクティスがリリースされる前は、正しい形式の GTFS データを構成する要素について、より大きな曖昧さと意見の不一致がありました。
 
 ### これらはどのように開発されたのですか？誰が開発しましたか?
 
-これらのベスト プラクティスは、GTFS に深く関わっているアプリ プロバイダーとデータ コンシューマー、交通機関プロバイダー、コンサルタントなど、GTFS に関わる 17 の組織からなるワーキング グループによって開発されました。ワーキング グループは [Rocky Mountain Institute](http://www.rmi.org/mobility) によって招集され、運営されました。
+これらのベスト プラクティスは、GTFS に深く関わっているアプリ プロバイダーとデータ コンシューマー、交通事業者プロバイダー、コンサルタントなど、GTFS に関わる 17 の組織からなるワーキング グループによって開発されました。ワーキング グループは [Rocky Mountain Institute](http://www.rmi.org/mobility) によって招集され、運営されました。
 
 ワーキング グループのメンバーは、各ベスト プラクティスに投票しました。ほとんどのベスト プラクティスは満場一致で承認されました。少数のケースでは、ベスト プラクティスが組織の大多数で承認されました。
 
@@ -278,9 +278,9 @@ Canonical GTFS schedule Validator は、これらのベスト プラクティス
 GTFS ベスト プラクティスを維持する目的は次のとおりです。
 
 * 交通データの相互運用性の向上をサポートする
-* 公共交通機関アプリにおけるエンド ユーザーの顧客エクスペリエンスを向上させる
+* 公共交通事業者アプリにおけるエンド ユーザーの顧客エクスペリエンスを向上させる
 * ソフトウェア開発者がアプリケーション、製品、およびサービスを導入および拡張しやすくする
-* さまざまなアプリケーション カテゴリで GTFS の使用を促進する（当初の重点である旅行計画を超えて）
+* さまざまなアプリケーション カテゴリで GTFS の使用を促進する（当初の重点である便計画を超えて）
 
 ### 公開されている GTFS ベスト プラクティスを提案または修正する方法
 
@@ -294,7 +294,7 @@ GTFS を利用するアプリケーションが、ここで説明されていな
 
 ### GTFS ベスト プラクティス ワーキング グループ
 
-GTFS ベスト プラクティス ワーキング グループは、2016 ～ 2017 年に [Rocky Mountain Institute](http:) によって招集され、公共交通機関、GTFS を利用するアプリケーションの開発者、コンサルタント、学術機関で構成され、GTFS データに関する一般的な取り扱いと期待を定義します。 
+GTFS ベスト プラクティス ワーキング グループは、2016 ～ 2017 年に [Rocky Mountain Institute](http:) によって招集され、公共交通事業者、GTFS を利用するアプリケーションの開発者、コンサルタント、学術事業者で構成され、GTFS データに関する一般的な取り扱いと期待を定義します。 
 このワーキンググループのメンバーは次のとおりです:
 
 * [Cambridge Systematics](https://www.camsys.com/)
diff --git a/docs/ja/getting_started/create.md b/docs/ja/getting_started/create.md
index 358c7e15..68130542 100644
--- a/docs/ja/getting_started/create.md
+++ b/docs/ja/getting_started/create.md
@@ -5,17 +5,17 @@
 
  
 
-各ファイルは、複数の情報フィールドを持つ複数のレコード（データ行）のリストで構成されています。たとえば、[routes.txt](../../documentation/schedule/reference/#routestxt) にリストされている各行は公共交通機関のルートを表し、そのフィールドはルートの名前、説明、運行事業者など、ルートの複数の要素を記述します。
+各ファイルは、複数の情報フィールドを持つ複数のレコード（データ行）のリストで構成されています。たとえば、[routes.txt](../../documentation/schedule/reference/#routestxt) にリストされている各行は公共交通事業者のルートを表し、そのフィールドはルートの名前、説明、運行事業者など、ルートの複数の要素を記述します。
 
  
 
-GTFS データセットのベースファイルは、次のように記述できます。GTFSGTFS scheduleデータセットには 1 つ以上のルート・路線系統([routes.txt](../../documentation/schedule/reference/#routestxt)) が含まれ、各ルートには 1 つ以上の便([trips.txt](../../documentation/schedule/reference/#tripstxt)) が含まれ、各旅行は指定された時間 ([stops.txt](../../documentation/schedule/reference/#stop_timestxt)) に一連の停留所等([stop_times.txt](../../documentation/schedule/reference/#stopstxt)) を訪問します。便と停車時刻には時刻情報のみが含まれます。カレンダーは、特定の旅行が実行される日を決定するために使用されます ([calendar.txt](../../documentation/schedule/reference/#calendartxt) および [calendar_dates.txt](../../documentation/schedule/reference/#calendar_datestxt))。さらに、複数の機関 ([agency.txt](../../documentation/schedule/reference/#agencytxt)) が複数のルート・路線系統を運行できます。これらのファイルは、相互参照されるフィールドによって互いにリンクされています。
+GTFS データセットのベースファイルは、次のように記述できます。GTFSGTFS scheduleデータセットには 1 つ以上のルート・路線系統([routes.txt](../../documentation/schedule/reference/#routestxt)) が含まれ、各ルートには 1 つ以上の便([trips.txt](../../documentation/schedule/reference/#tripstxt)) が含まれ、各便は指定された時間 ([stops.txt](../../documentation/schedule/reference/#stop_timestxt)) に一連の停留所等([stop_times.txt](../../documentation/schedule/reference/#stopstxt)) を訪問します。便と停車時刻には時刻情報のみが含まれます。カレンダーは、特定の便が実行される日を決定するために使用されます ([calendar.txt](../../documentation/schedule/reference/#calendartxt) および [calendar_dates.txt](../../documentation/schedule/reference/#calendar_datestxt))。さらに、複数の事業者 ([agency.txt](../../documentation/schedule/reference/#agencytxt)) が複数のルート・路線系統を運行できます。これらのファイルは、相互参照されるフィールドによって互いにリンクされています。
 
  
 
-これらのファイルを設定し、基本的な GTFS データセットを作成したら、その他の機能や交通機関とベンダー間の特定のニーズに対応するために、追加の (任意) ファイルを追加できます。これらのファイルの例としては、次のようなものがあります。
+これらのファイルを設定し、基本的な GTFS データセットを作成したら、その他の機能や交通事業者とベンダー間の特定のニーズに対応するために、追加の (任意) ファイルを追加できます。これらのファイルの例としては、次のようなものがあります。
 
-- [shapes.txt](../../documentation/schedule/reference/#shapestxt) は、旅行の経路をグラフィカルに表現できます。
+- [shapes.txt](../../documentation/schedule/reference/#shapestxt) は、便の経路をグラフィカルに表現できます。
 - [pathways.txt](../../documentation/schedule/reference/#pathwaystxt) は、ユーザーが駅をナビゲートするのに役立つ道順を生成するための情報を提供します。
 - [frequencies.txt](../../documentation/schedule/reference/#frequenciestxt) は、停車時刻を指定するための別の方法を提供します。
 
@@ -33,9 +33,9 @@ GTFS realtimeフィードは、HTTP 経由で提供され、頻繁に更新さ
 
 システムの規模と複雑さに応じて、社内でデータを作成するか、外部の GTFS ベンダーに依頼してデータを GTFS 形式に変換するかを選択できます。
 
-場合によっては、ルート・路線系統が少数しかない小規模な機関が、スプレッドシートやTextエディタなどの一般に入手可能なソフトウェアを使用して自分でデータを作成します。
+場合によっては、ルート・路線系統が少数しかない小規模な事業者が、スプレッドシートやTextエディタなどの一般に入手可能なソフトウェアを使用して自分でデータを作成します。
 
-より大規模なシステム範囲を扱う場合、ほとんどの機関は専門のベンダーから専用の GTFS 管理ソフトウェアを購入しますが、独自の社内ツールを開発することを選択する機関もあります。最後に、システムの特性上、機関が独自にデータセットを作成することが難しいことが判明した場合は、GTFS データの作成を専門とする企業に完全に外注することができます
+より大規模なシステム範囲を扱う場合、ほとんどの事業者は専門のベンダーから専用の GTFS 管理ソフトウェアを購入しますが、独自の社内ツールを開発することを選択する事業者もあります。最後に、システムの特性上、事業者が独自にデータセットを作成することが難しいことが判明した場合は、GTFS データの作成を専門とする企業に完全に外注することができます
 
 。Icons created by Freepik- Flaticon 
 
diff --git a/docs/ja/getting_started/features/accessibility.md b/docs/ja/getting_started/features/accessibility.md
index 9bb37994..bf2cfd38 100644
--- a/docs/ja/getting_started/features/accessibility.md
+++ b/docs/ja/getting_started/features/accessibility.md
@@ -30,7 +30,7 @@
 
 ## 便車椅子でのアクセシビリティ
 
-便車椅子でのアクセシビリティでは、車両が車椅子を使用する乗客に対応できるかどうかを示すことができます。車椅子を使用する乗客のサービスを提供するためには、車両が車椅子を使用する乗客に対応できることを指定することは、車両が対応できないことを指定するのと同じくらい重要です。乗客が特定の停留所で旅行にアクセスできるようにするには、停留所と旅行の両方が車椅子でアクセス可能でしなければならない 
+便車椅子でのアクセシビリティでは、車両が車椅子を使用する乗客に対応できるかどうかを示すことができます。車椅子を使用する乗客のサービスを提供するためには、車両が車椅子を使用する乗客に対応できることを指定することは、車両が対応できないことを指定するのと同じくらい重要です。乗客が特定の停留所で便にアクセスできるようにするには、停留所と便の両方が車椅子でアクセス可能でしなければならない 
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-----------------------------------|
@@ -43,7 +43,7 @@
 ??? note "サンプル データ"
 
     
    
-    次のサンプルは、旅行 `AWE1` で使用される車両には少なくとも1台の車椅子を収容できる装備があり、旅行 `AWE2` で使用される車両にはそれがないことを示しています。
+    次のサンプルは、便 `AWE1` で使用される車両には少なくとも1台の車椅子を収容できる装備があり、便 `AWE2` で使用される車両にはそれがないことを示しています。
     
    
     !!! note ""
         
    
diff --git a/docs/ja/getting_started/features/base.md b/docs/ja/getting_started/features/base.md
index c224f9ee..ad034c65 100644
--- a/docs/ja/getting_started/features/base.md
+++ b/docs/ja/getting_started/features/base.md
@@ -2,7 +2,7 @@
 以下の機能は、 GTFS が交通サービスを表すために必要な最も基本的かつ重要な要素を提供します。GTFS はルート・路線系統で構成され、各ルートには関連する便があります。これらの便は、特定の時間に 1 つ以上の停留所等を訪れます。便には時刻情報のみが含まれ、運行日はカレンダーによって決定されます。
 GTFS フィードを機能させるには、これらすべての機能を同時に実装する必要がしなければならない##事業者
 
-機関には、名前、ウェブサイトの URL、サービスが運行される言語とタイムゾーンなど、交通サービスを担当する機関に関する基本情報が含まれます。これにより、特定のサービスを対応する事業者と一致させることができます。
+事業者には、名前、ウェブサイトの URL、サービスが運行される言語とタイムゾーンなど、交通サービスを担当する事業者に関する基本情報が含まれます。これにより、特定のサービスを対応する事業者と一致させることができます。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -27,7 +27,7 @@ GTFS フィードを機能させるには、これらすべての機能を同時
 
 ## 停留所等
 
-停留所等は、交通サービスが乗客を乗降させる場所を識別するために使用される基本要素を表します。地下鉄の駅やバス停などです。各停留所には、他の属性とともに、地図上で位置を正確に示すための地理座標や、機関の乗客向け資料と一致する名前があります。停留所等は停車時刻 を使用して便に関連付けられます。
+停留所等は、交通サービスが乗客を乗降させる場所を識別するために使用される基本要素を表します。地下鉄の駅やバス停などです。各停留所には、他の属性とともに、地図上で位置を正確に示すための地理座標や、事業者の乗客向け資料と一致する名前があります。停留所等は停車時刻 を使用して便に関連付けられます。
 GTFS では、[構内通路](/getting_started/機能/構内通路) を使用して、鉄道駅やバス停などの大きな駅の内部を記述することもできます。
 
 | 含まれるファイル                      | 含まれるフィールド   |
@@ -54,7 +54,7 @@ GTFS では、[構内通路](/getting_started/機能/構内通路) を使用し
 
 ## ルート・路線系統
 
-ルートとは、同じブランドの下にある便のグループで、乗客には単一のサービスとして表示されます。各ルートには、他の属性の中でも、機関の乗客向け資料に一致する名前と、表されるサービスの種類 (バス、地下鉄、フェリーなど) があります。
+ルートとは、同じブランドの下にある便のグループで、乗客には単一のサービスとして表示されます。各ルートには、他の属性の中でも、事業者の乗客向け資料に一致する名前と、表されるサービスの種類 (バス、地下鉄、フェリーなど) があります。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -146,7 +146,7 @@ GTFS では、[構内通路](/getting_started/機能/構内通路) を使用し
 
 ## 停車時刻
 
-停車時刻は、各旅行の個々の停車地の到着時刻と出発時刻を表すために使用され、乗客はバス、電車、フェリーが特定の場所に到着および出発する時刻を正確に知ることができます。`stop_times.txt` ファイルは通常、`STOP_TIMES.TXT` フィード内で最も大きくなります。 
+停車時刻は、各便の個々の停留所の到着時刻と出発時刻を表すために使用され、乗客はバス、電車、フェリーが特定の場所に到着および出発する時刻を正確に知ることができます。`stop_times.txt` ファイルは通常、`STOP_TIMES.TXT` フィード内で最も大きくなります。 
 特定のサービスは、特定の到着時間と出発時間を持つのではなく、一定の頻度で運行されます (例: 5 分間隔で運行する地下鉄路線)。これは、[頻度`、`のサービス](../base_add-ons/#frequency-based-service) を使用してモデル化でき、 `stop_times.txt`と組み合わせてモデル化できます。
 
 | 含まれるファイル                   | 含まれるフィールド   |
@@ -160,7 +160,7 @@ GTFS では、[構内通路](/getting_started/機能/構内通路) を使用し
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、5 つの停留所等での旅行のスケジュールを定義します。
+    次のサンプルは、5 つの停留所等での便のスケジュールを定義します。
     
    
     !!! note ""
         
    
diff --git a/docs/ja/getting_started/features/base_add-ons.md b/docs/ja/getting_started/features/base_add-ons.md
index 13424112..bcbda3eb 100644
--- a/docs/ja/getting_started/features/base_add-ons.md
+++ b/docs/ja/getting_started/features/base_add-ons.md
@@ -1,5 +1,5 @@
 # :material-plus-box-multiple-outline: ベースアドオン
-これらの機能は、 ベースで説明されている機能を拡張し、GTFS データセットの包括性を高めて乗客の体験を向上させるか、機関、データベンダー、およびデータ再利用者間のコラボレーションを促進します。これらの機能強化には、 ベースで説明されているファイル内に新しいフィールドを導入するか、新しいファイルを作成することが必要になるしてもよい。
+これらの機能は、 ベースで説明されている機能を拡張し、GTFS データセットの包括性を高めて乗客の体験を向上させるか、事業者、データベンダー、およびデータ再利用者間のコラボレーションを促進します。これらの機能強化には、 ベースで説明されているファイル内に新しいフィールドを導入するか、新しいファイルを作成することが必要になるしてもよい。
 
 ## フィード情報
 
@@ -27,7 +27,7 @@
         | Greater Region Transport | https://www.gra1.org | en        | en           |        20240101 |      20241231 |          3.1 | support@gra1.org   | https://www.gra1.org/support |
 
 ## ルート形状
-ルート形状を定義して便に関連付けることができるため、旅行計画アプリケーションで地図上に便を表示し、乗客に公共交通機関の車両で移動する必要がある距離を通知できます。 `shape_dist_traveled`フィールドは、ライダーに地図を表示するときにどの程度のシェイプを描画するかをプログラムで決定するために使用されます。
+ルート形状を定義して便に関連付けることができるため、便計画アプリケーションで地図上に便を表示し、乗客に公共交通事業者の車両で移動する必要がある距離を通知できます。 `shape_dist_traveled`フィールドは、ライダーに地図を表示するときにどの程度の形状を描画するかをプログラムで決定するために使用されます。
 ルート形状を定義するときは、その詳細レベル (道路の正確な曲率に沿うなど) と必要な情報のみを効率的に伝えることのバランスを取ります。
 
 |含まれるファイル                            |含まれるフィールド            |
@@ -43,7 +43,7 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、TriMet GTFSフィード（ダウンロードはこちら）から取得したシェイプの一部を示しています。ここ。
+    次のサンプルは、TriMet GTFSフィード（ダウンロードはこちら）から取得した形状の一部を示しています。ここ。
     
    
 
     !!! note ""
@@ -81,7 +81,7 @@
 
 ## 路線系統色
 
-路線系統色を使用すると、機関の設計ガイドラインによって特定のルート・路線系統に割り当てられた配色を正確に表現および伝えることができます。これにより、ユーザーは公式の色で交通サービスを簡単に識別できます。
+路線系統色を使用すると、事業者の設計ガイドラインによって特定のルート・路線系統に割り当てられた配色を正確に表現および伝えることができます。これにより、ユーザーは公式の色で交通サービスを簡単に識別できます。
 
 | 含まれるファイル                   |含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -120,7 +120,7 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルでは、​​旅行 `AWE1` で使用される車両には少なくとも 1 台の自転車を搭載できること (`bikes_allowed=1`)、旅行 `AWE2` で使用される車両には搭載できないこと (`bikes_allowed=2`) を指定しています。
+    次のサンプルでは、​​便 `AWE1` で使用される車両には少なくとも 1 台の自転車を搭載できること (`bikes_allowed=1`)、便 `AWE2` で使用される車両には搭載できないこと (`bikes_allowed=2`) を指定しています。
     
    
     !!! note ""
         
    
@@ -134,7 +134,7 @@
 
 ## 行先表示
 
-行先表示を使用すると、旅行の目的地を示すために車両が使用する標識を伝えることができ、ユーザーが正しい交通サービスを識別しやすくなります。この機能は、特定のルートに沿ったヘッドサインの変更をサポートします。
+行先表示を使用すると、便の目的地を示すために車両が使用する標識を伝えることができ、ユーザーが正しい交通サービスを識別しやすくなります。この機能は、特定のルートに沿ったヘッドサインの変更をサポートします。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -176,7 +176,7 @@
 
 ## 停留所等の種別
 
-停留所等の種別は、出入口、ノード、搭乗エリアなどの交通機関の駅内の主要なエリアとそれらの関係を分類するために使用されます。停留所等の種別は、 構内通路 を使用して交通機関の駅をモデル化するための基礎として機能します。
+停留所等の種別は、出入口、ノード、搭乗エリアなどの交通事業者の駅内の主要なエリアとそれらの関係を分類するために使用されます。停留所等の種別は、 構内通路 を使用して交通事業者の駅をモデル化するための基礎として機能します。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -189,7 +189,7 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、`stops.txt`内の交通機関の駅内の複数の場所を示しています。主要な場所を表す親駅と、プラットフォーム、出入口/出口、一般的なノードなどの子の場所です。
+    次のサンプルは、`stops.txt`内の交通事業者の駅内の複数の場所を示しています。主要な場所を表す親駅と、プラットフォーム、出入口/出口、一般的なノードなどの子の場所です。
     
    
     !!! note ""
         
    
@@ -227,11 +227,11 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、30 分ごとに実行される旅行「AWE1」(`headway_secs=1800`) と、15 分ごとに実行される旅行「AWE2」(`headway_secs=900`) という 2 つの異なる旅行を示しています。 
+    次のサンプルは、30 分ごとに実行される便「AWE1」(`headway_secs=1800`) と、15 分ごとに実行される便「AWE2」(`headway_secs=900`) という 2 つの異なる便を示しています。 
     
    
     `exact_times` フィールドは、スケジュールが 'start_time' フィールドに入力された正確な開始時刻に従うかどうかを示します:
-    - 旅行 `AWE1` は、午前 6:10 から午後 12:00 まで 30 分ごとに出発します。
-    - 旅行 `AW2` は、午前 6:00、午前 6:15、午前 6:30 などに出発します。
+    - 便 `AWE1` は、午前 6:10 から午後 12:00 まで 30 分ごとに出発します。
+    - 便 `AW2` は、午前 6:00、午前 6:15、午前 6:30 などに出発します。
     
    
     !!! note ""
         
    
@@ -245,7 +245,7 @@
 
 ## 乗り換え
 
-乗り換えでは、異なる旅行セグメント (または区間) 間の遷移に関する詳細が提供され、旅行計画者は乗り換えを含む旅程の実現可能性を判断できます。乗り換えを指定しても、乗客が他の場所に乗り換えることができないことを意味するわけではなく、特定の乗り換えが不可能であるか、乗り換えに最小限の時間が必要であるかを示すだけです。
+乗り換えでは、異なる便セグメント (または区間) 間の遷移に関する詳細が提供され、便計画者は乗り換えを含む旅程の実現可能性を判断できます。乗り換えを指定しても、乗客が他の場所に乗り換えることができないことを意味するわけではなく、特定の乗り換えが不可能であるか、乗り換えに最小限の時間が必要であるかを示すだけです。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-----------------------------------|
@@ -273,7 +273,7 @@
 
 ## 翻訳
 
-翻訳により、駅名などのサービス情報を複数の言語で提供できるため、旅行プランナーはユーザーの言語と場所の設定に応じて、特定の言語で情報を表示できます。
+翻訳により、駅名などのサービス情報を複数の言語で提供できるため、便プランナーはユーザーの言語と場所の設定に応じて、特定の言語で情報を表示できます。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
diff --git a/docs/ja/getting_started/features/fares.md b/docs/ja/getting_started/features/fares.md
index 5c39b486..d7ccbfc9 100644
--- a/docs/ja/getting_started/features/fares.md
+++ b/docs/ja/getting_started/features/fares.md
@@ -1,10 +1,10 @@
 # :material-cash: 運賃
 
-GTFS では、世界中のさまざまな交通機関が使用する、ゾーン別、移動距離別、または時間帯別の運賃など、さまざまな運賃体系を正確にモデル化できます。GTFS運賃は、旅行に適用される価格と、支払いに使用できる媒体を乗客に通知します。
+GTFS では、世界中のさまざまな交通事業者が使用する、ゾーン別、移動距離別、または時間帯別の運賃など、さまざまな運賃体系を正確にモデル化できます。GTFS運賃は、便に適用される価格と、支払いに使用できる媒体を乗客に通知します。
 
 ## チケット商品
 
-チケット商品には、交通事業者がサービスにアクセスするために提供するチケットまたは運賃の種類 (つまり、片道運賃、月間パス、乗り換え料金など) がリストされます。チケット商品は、機関の運賃構造をモデル化するための基礎として機能し、 `fare_leg_rules.txt`で概説されているメカニズムを通じて交通サービスにリンクされます。チケット商品をルート・路線系統、エリア、時間などのさまざまな旅行条件に関連付けることで、個々の旅行区間と乗り換えの運賃コストが決まります。
+チケット商品には、交通事業者がサービスにアクセスするために提供するチケットまたは運賃の種類 (つまり、片道運賃、月間パス、乗り換え料金など) がリストされます。チケット商品は、事業者の運賃構造をモデル化するための基礎として機能し、 `fare_leg_rules.txt`で概説されているメカニズムを通じて交通サービスにリンクされます。チケット商品をルート・路線系統、エリア、時間などのさまざまな便条件に関連付けることで、個々の便区間と乗り換えの運賃コストが決まります。
 
 | 含まれるファイル                   |含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -18,7 +18,7 @@ GTFS では、世界中のさまざまな交通機関が使用する、ゾーン
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、単純な運賃商品 (片道 2.75 米ドル) を示しています。
+    次のサンプルは、単純なチケット商品 (片道 2.75 米ドル) を示しています。
     
    
     !!! note ""
         
    
@@ -38,9 +38,9 @@ GTFS では、世界中のさまざまな交通機関が使用する、ゾーン
         |------------------|
         | single_ride |
 
-## チケットメディア
+## 運賃メディア
 
-チケットメディアは、運賃商品の保持や検証に使用できるサポートされているメディアを定義します。これは、紙のチケット、再チャージ可能な交通カード、さらにはクレジットカードやスマートフォンによる非接触型決済などの物理または仮想のコンテナーを指します。
+運賃メディアは、チケット商品の保持や検証に使用できるサポートされているメディアを定義します。これは、紙のチケット、再チャージ可能な交通カード、さらにはクレジットカードやスマートフォンによる非接触型決済などの物理または仮想のコンテナーを指します。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -54,7 +54,7 @@ GTFS では、世界中のさまざまな交通機関が使用する、ゾーン
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、サンフランシスコ ベイエリアのさまざまなチケットメディアのスニペットを示しています。`Clipper` は、`fare_media_type=2` の物理的な交通カードとして記述されています。`A` Munimobile` は、`fare_media_type=2` のモバイル アプリとして記述されています。チケットなしで運転手に直接渡される `Cash` は、`fare_media_type=0` です。
+    次のサンプルは、サンフランシスコ ベイエリアのさまざまな運賃メディアのスニペットを示しています。`Clipper` は、`fare_media_type=2` の物理的な交通カードとして記述されています。`A` Munimobile` は、`fare_media_type=2` のモバイル アプリとして記述されています。チケットなしで運転手に直接渡される `Cash` は、`fare_media_type=0` です。
     
    
     !!! note ""
         
    
@@ -248,7 +248,7 @@ GTFS では、世界中のさまざまな交通機関が使用する、ゾーン
 
 ## 運賃の乗り換え
 
-運賃の乗り換えは、区間（または個々の旅行セグメント）間の乗り換え時に適用されるルールを定義するために使用されます。これにより、特定の時間制限での無料乗り換えや、すでに旅行した区間に基づいた運賃割引の適用など、特別な乗り換えポリシーを考慮して、複数区間の旅行の総コストをモデル化できます。
+運賃の乗り換えは、区間（または個々の便セグメント）間の乗り換え時に適用されるルールを定義するために使用されます。これにより、特定の時間制限での無料乗り換えや、すでに便した区間に基づいた運賃割引の適用など、特別な乗り換えポリシーを考慮して、複数区間の便の総コストをモデル化できます。
 
 | 含まれるファイル                      | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -285,7 +285,7 @@ GTFS では、世界中のさまざまな交通機関が使用する、ゾーン
 
 ## Fares V1 
 
- 運賃V1 は、上で説明した他の運賃機能の従来の代替手段です。`fare_rules.txt` および `fare_attributes.txt` ファイルを使用して、`fare_rules.txt` 設定、支払い方法の乗り換え、ゾーンベースの運賃などの基本的な運賃情報をモデル化できます。作成は簡単ですが、より複雑な運賃構造をモデル化する能力が低く、他の運賃機能( Fares v2と呼ばれる機能の一部) の十分な承認があれば廃止されるしてもよい。
+ Fares v1 は、上で説明した他の運賃機能の従来の代替手段です。`fare_rules.txt` および `fare_attributes.txt` ファイルを使用して、`fare_rules.txt` 設定、支払い方法の乗り換え、ゾーンベースの運賃などの基本的な運賃情報をモデル化できます。作成は簡単ですが、より複雑な運賃構造をモデル化する能力が低く、他の運賃機能( Fares v2と呼ばれる機能の一部) の十分な承認があれば廃止されるしてもよい。
 
 | 含まれるファイル                   | 含まれるフィールド   |
 |----------------------------------|-----------------------------------|
diff --git a/docs/ja/getting_started/features/flexible_services.md b/docs/ja/getting_started/features/flexible_services.md
index b5f348b2..abf55edd 100644
--- a/docs/ja/getting_started/features/flexible_services.md
+++ b/docs/ja/getting_started/features/flexible_services.md
@@ -4,7 +4,7 @@
 ##連続した停留所等
 
 連続した停留所等は、スケジュールされた停留所等間で乗客を乗降させることができる場合に使用されます。 
-これは、ルートのすべての旅行で車両の移動経路に沿った任意のポイントで乗客を乗降させることができることを示す `routes.txt` で指定するか、ルートの特定のセクションの `stop_times.txt` で指定できます。 
+これは、ルートのすべての便で車両の移動経路に沿った任意のポイントで乗客を乗降させることができることを示す `routes.txt` で指定するか、ルートの特定のセクションの `stop_times.txt` で指定できます。 
 
 | 含まれるファイル                      | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -54,7 +54,7 @@
 
 ## 予約ルール
 
-予約ルールを使用すると、ユーザーは需要に応じたサービスで旅行を予約できます。これらのルールは、予約を正常に行うために必要な前提条件を概説し、ユーザーが旅行を予約できる連絡先情報を提供します。この機能は、[偏差付き定義するべきであるルート・路線系統](#predefined-routes-with-deviation)、[ゾーンベースのデマンドサービス](#zone-based-demand-responsive-services)、[固定停留所型のデマンドサービス](#fixed-stops-demand-responsive-services)機能と組み合わせて使用​​する必要があります (これらのサービスで予約が必要な場合)。
+予約ルールを使用すると、ユーザーは需要に応じたサービスで便を予約できます。これらのルールは、予約を正常に行うために必要な前提条件を概説し、ユーザーが便を予約できる連絡先情報を提供します。この機能は、[偏差付き定義するべきであるルート・路線系統](#predefined-routes-with-deviation)、[ゾーンベースのデマンドサービス](#zone-based-demand-responsive-services)、[固定停留所型のデマンドサービス](#fixed-stops-demand-responsive-services)機能と組み合わせて使用​​する必要があります (これらのサービスで予約が必要な場合)。
 
 | 含まれるファイル                   |含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -67,7 +67,7 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、2つの異なる予約ルールセットを示しています。1 つ目は、少なくとも 1 日前 (午後 1 時前) から 14 日前までに予約するしなければならない便用であり、2つ目は、少なくとも旅行の 45 分前から 5 時間前までに予約できる便用です。
+    次のサンプルは、2つの異なる予約ルールセットを示しています。1 つ目は、少なくとも 1 日前 (午後 1 時前) から 14 日前までに予約するしなければならない便用であり、2つ目は、少なくとも便の 45 分前から 5 時間前までに予約できる便用です。
 
     
    
     !!! note ""
@@ -82,7 +82,7 @@
 
 ## 偏差付き定義済みルート・路線系統
 
-偏差付き定義済みルート・路線系統は、車両が特定のルートから一時的に逸脱して、ルート沿いの特定のエリア内で旅行を予約したユーザーをピックアップできるフレキシブルサービスをモデル化するために使用できます。これは、従来の停留所等(通常のスケジュールされたサービスなど) と`locations.geojson`を使用したゾーンの組み合わせを使用します。
+偏差付き定義済みルート・路線系統は、車両が特定のルートから一時的に逸脱して、ルート沿いの特定のエリア内で便を予約したユーザーをピックアップできるフレキシブルサービスをモデル化するために使用できます。これは、従来の停留所等(通常のスケジュールされたサービスなど) と`locations.geojson`を使用したゾーンの組み合わせを使用します。
 
 | 含まれるファイル                      | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -97,7 +97,7 @@
 ??? note "サンプルデータ"
 
     
    
-    次のサンプルは、3 つの固定停留所等を含む旅行を示しています。この旅行では、固定停留所等間で定義された特定のエリア内の任意の場所で乗客を降ろすこともできます。
+    次のサンプルは、3 つの固定停留所等を含む便を示しています。この便では、固定停留所等間で定義された特定のエリア内の任意の場所で乗客を降ろすこともできます。
     
    
     !!! note ""
         
    
@@ -177,7 +177,7 @@
 
 ## ゾーンベースのデマンドサービス
 
-ゾーンベースのデマンドサービスは、サービスをモデル化するために使用されます旅行を予約したユーザーが特定のエリア内の任意の場所で乗車および/または降車できるようにするものです。これらのエリアは`locations.geojson`を使用して定義されるため、 `stops.txt`や `stop_times.arrival_time` および `stop_times.departure_time` を使用する必要はありません。
+ゾーンベースのデマンドサービスは、サービスをモデル化するために使用されます便を予約したユーザーが特定のエリア内の任意の場所で乗車および/または降車できるようにするものです。これらのエリアは`locations.geojson`を使用して定義されるため、 `stops.txt`や `stop_times.arrival_time` および `stop_times.departure_time` を使用する必要はありません。
 
 | 含まれるファイル                      | 含まれるフィールド   |
 |----------------------------------|-------------------|
@@ -244,7 +244,7 @@
         ~~~
 
 ## 固定停留所型のデマンドサービス
-固定停留所型のデマンドサービスは、旅行を予約したユーザーに対して、定義済みの停留所等のグループ内の任意の場所での乗車および/または降車を許可するサービスをモデル化するために使用されます。これらの停留所等のグループは、`location_groups.txt` および `location_group_stops.txt` を使用して定義されます。
+固定停留所型のデマンドサービスは、便を予約したユーザーに対して、定義済みの停留所等のグループ内の任意の場所での乗車および/または降車を許可するサービスをモデル化するために使用されます。これらの停留所等のグループは、`location_groups.txt` および `location_group_stops.txt` を使用して定義されます。
 
 | 含まれるファイル                   |含まれるフィールド   |
 |----------------------------------|-------------------|
diff --git a/docs/ja/getting_started/features/overview.md b/docs/ja/getting_started/features/overview.md
index 5ba2ff1c..808b0bab 100644
--- a/docs/ja/getting_started/features/overview.md
+++ b/docs/ja/getting_started/features/overview.md
@@ -5,7 +5,7 @@ description: GTFS schedule の機能について理解を深め、その機能
 
 # GTFS Schedule Features
 
-GTFS リファレンス フォーマットは、交通システムの現在のニーズを満たすために進化しており、その機能はますます複雑になる可能性があります。**GTFS Schedule Features** は、GTFS リファレンス フォーマットによって実現される機能について明確かつ明確な説明を提供することを目的としています。これにより、交通機関、ベンダー、消費者、研究者は GTFS の機能を理解し、「**GTFS で何ができるのか?」という質問に答えることができます。
+GTFS リファレンス フォーマットは、交通システムの現在のニーズを満たすために進化しており、その機能はますます複雑になる可能性があります。**GTFS Schedule Features** は、GTFS リファレンス フォーマットによって実現される機能について明確かつ明確な説明を提供することを目的としています。これにより、交通事業者、ベンダー、消費者、研究者は GTFS の機能を理解し、「**GTFS で何ができるのか?」という質問に答えることができます。
 
 次の機能グループでは、各機能の目的と、それに関連付けられているファイルとフィールドについて説明しており、特定の機能をサポートするためにどのデータが必要かをユーザーが理解するのに役立ちます。
 
@@ -13,7 +13,7 @@ GTFS リファレンス フォーマットは、交通システムの現在の
 
 - :material-subway-variant:{ .lg.middle } __事業者__ 
 
-    交通サービスを担当する機関についての詳細を伝えます。
+    交通サービスを担当する事業者についての詳細を伝えます。
     
     [:octicons-arrow-right-24: 詳細はこちら](../ベース/# 事業者)
 
@@ -37,20 +37,20 @@ GTFS リファレンス フォーマットは、交通システムの現在の
 
 - :material-subway-variant:{ .lg.middle } __便__ 
 
-    定義されたルートに沿ってスケジュールされた時間に移動する交通機関の車両を表します。
+    定義されたルートに沿ってスケジュールされた時間に移動する交通事業者の車両を表します。
 
     [:octicons-arrow-right-24: 詳細](../ベース/# 便)
 
 -   :material-subway-variant:{ .lg.middle } __停車時刻__ 
 
-    各停車地の各旅行の到着時刻と出発時刻を定義します。
+    各停留所の各便の到着時刻と出発時刻を定義します。
 
     [:octicons-arrow-right-24: 詳細](../ベース/#stop-times)
    ## ベースアドオン -これらの機能はGTFS データセットを強化し、乗客のエクスペリエンスを向上させ、機関、ベンダー、データ再利用者間のコラボレーションを促進します。既存のファイルに新しいフィールドを追加したり、新しいファイルを作成したりすることがしてもよい。 +これらの機能はGTFS データセットを強化し、乗客のエクスペリエンスを向上させ、事業者、ベンダー、データ再利用者間のコラボレーションを促進します。既存のファイルに新しいフィールドを追加したり、新しいファイルを作成したりすることがしてもよい。
    @@ -80,13 +80,13 @@ GTFS リファレンス フォーマットは、交通システムの現在の - :material-plus-box-multiple-outline:{ .lg.middle } __行先表示__ - 車両が旅行の目的地を示すために使用する標識を伝えます。 + 車両が便の目的地を示すために使用する標識を伝えます。 [:octicons-arrow-right-24: 詳しくはこちら](../base_add-ons/#headsigns) - :material-plus-box-multiple-outline:{ .lg.middle } __停留所等の種別__ - 交通機関の駅内の入口や出口などの主要エリアを分類します。終了します。 + 交通事業者の駅内の入口や出口などの主要エリアを分類します。終了します。 [:octicons-arrow-right-24: 詳細はこちら](../base_add-ons/#location-types) @@ -154,9 +154,9 @@ GTFS は、ゾーン、距離、時間帯に基づく運賃など、さまざま [:octicons-arrow-right-24: 詳細はこちら](../fares/#fare-products) -- :material-cash:{ .lg.middle } __チケットメディア____ +- :material-cash:{ .lg.middle } __運賃メディア____ - 運賃商品の保持や検証に使用できるメディアを定義します。 + チケット商品の保持や検証に使用できるメディアを定義します。 [:octicons-arrow-right-24: 詳細はこちら](../fares/#fare-media) @@ -174,17 +174,17 @@ GTFS は、ゾーン、距離、時間帯に基づく運賃など、さまざま - :material-cash:{ .lg.middle } __ゾーンベースの運賃__ - あるエリアから別のエリアに旅行するときに異なる運賃について説明します。 + あるエリアから別のエリアに便するときに異なる運賃について説明します。 [:octicons-arrow-right-24: 詳細はこちら](../fares/#zone-based-fares) - :material-cash:{ .lg.middle } __運賃の乗り換え__ - 旅行の 1 つの区間から別の区間に乗り換えるときに適用される料金を定義します。 + 便の 1 つの区間から別の区間に乗り換えるときに適用される料金を定義します。 [:octicons-arrow-right-24: 詳細はこちら](../fares/#fares-transfers) -- :material-cash:{ .lg.middle } __運賃V1__ +- :material-cash:{ .lg.middle } __Fares v1__ 運賃情報をよりシンプルに表現できるレガシー機能。 @@ -195,13 +195,13 @@ GTFS は、ゾーン、距離、時間帯に基づく運賃など、さまざま ##構内通路 -構内通路機能を使用すると、大規模な交通機関の駅をモデル化して、乗客を入口から乗車エリアまで誘導することができます。経路の詳細、推定ナビゲーション時間、および道案内システムが提供されます。 +構内通路機能を使用すると、大規模な交通事業者の駅をモデル化して、乗客を入口から乗車エリアまで誘導することができます。経路の詳細、推定ナビゲーション時間、および道案内システムが提供されます。
    - :material-escalator:{ .lg.middle } __構内通路の接続__ - 交通機関の駅内の関連ポイントを接続する経路をモデル化します。 + 交通事業者の駅内の関連ポイントを接続する経路をモデル化します。 [:octicons-arrow-right-24: 詳細はこちら](../pathways/#pathway-connections) @@ -213,7 +213,7 @@ GTFS は、ゾーン、距離、時間帯に基づく運賃など、さまざま - :material-escalator:{ .lg.middle } __階・フロア__ - 交通機関の駅内のすべての異なる階・フロアについて説明し、リストします。 + 交通事業者の駅内のすべての異なる階・フロアについて説明し、リストします。 [:octicons-arrow-right-24: 詳細はこちら](../pathways/#levels) @@ -244,7 +244,7 @@ GTFS は、ゾーン、距離、時間帯に基づく運賃など、さまざま - :material-transit-detour:{ .lg.middle } __予約ルール__ - ユーザーがデマンド応答型サービスで旅行を予約できるかどうかを示します。 + ユーザーがデマンド応答型サービスで便を予約できるかどうかを示します。 [:octicons-arrow-right-24: 詳細はこちら](../flexible_services/#booking-rules) diff --git a/docs/ja/getting_started/features/pathways.md b/docs/ja/getting_started/features/pathways.md index 20b5f1a4..72d54f47 100644 --- a/docs/ja/getting_started/features/pathways.md +++ b/docs/ja/getting_started/features/pathways.md @@ -1,10 +1,10 @@ # :material-escalator: 構内通路 -構内通路機能は、大規模な交通機関の駅をモデル化し、駅の入口や出口から、交通機関の車両に乗車または降車する場所まで乗客を誘導することができます。これらの機能の一部は、経路の物理的特性と推定ナビゲーション時間、および駅で採用されている実際の道案内システムを伝えることを可能にします。 +構内通路機能は、大規模な交通事業者の駅をモデル化し、駅の入口や出口から、交通事業者の車両に乗車または降車する場所まで乗客を誘導することができます。これらの機能の一部は、経路の物理的特性と推定ナビゲーション時間、および駅で採用されている実際の道案内システムを伝えることを可能にします。 ## 構内通路の接続 -基礎レベルでは、構内通路は、駅内の停留所等の種別で定義された主要なエリアを接続するための基本機能を提供します。これらの接続は構内通路を形成し、ユーザーが正確な方向 (入口から乗車エリアまでなど) を取得できるようにします。これは、大規模で複雑な交通機関の駅をナビゲートする際に特に役立ちます。 +基礎レベルでは、構内通路は、駅内の停留所等の種別で定義された主要なエリアを接続するための基本機能を提供します。これらの接続は構内通路を形成し、ユーザーが正確な方向 (入口から乗車エリアまでなど) を取得できるようにします。これは、大規模で複雑な交通事業者の駅をナビゲートする際に特に役立ちます。 | 含まれるファイル | 含まれるフィールド | |----------------------------------|-------------------| @@ -163,7 +163,7 @@ ## 通路標識 -通路標識は、旅行計画者に表示される情報と現実世界の標識を結び付けることができます。これがフィードで表現されている場合、旅行計画者は`標識に従ってください`などの道順を提供できます。 +通路標識は、便計画者に表示される情報と現実世界の標識を結び付けることができます。これがフィードで表現されている場合、便計画者は`標識に従ってください`などの道順を提供できます。 | 含まれるファイル | 含まれるフィールド | |----------------------------------|-----------------------------------| diff --git a/docs/ja/getting_started/publish.md b/docs/ja/getting_started/publish.md index 808eb19b..3616fbbd 100644 --- a/docs/ja/getting_started/publish.md +++ b/docs/ja/getting_started/publish.md @@ -2,19 +2,19 @@ ## GTFS を共有するメリット -GTFS データはさまざまな方法で利用できます。交通機関の GTFS データを一般公開すると、乗客と交通事業者全体に多くのメリットがもたらされます。メリットには次のものが含まれます。 +GTFS データはさまざまな方法で利用できます。交通事業者の GTFS データを一般公開すると、乗客と交通事業者全体に多くのメリットがもたらされます。メリットには次のものが含まれます。 -- フィードをモバイルおよびウェブベースの旅行計画アプリケーションに統合し、乗客がシステムで便を計画できるようにする +- フィードをモバイルおよびウェブベースの便計画アプリケーションに統合し、乗客がシステムで便を計画できるようにする - Mobility Database などの GTFS アグリゲータにフィードを送信すると、より多くのユーザーが利用し、事業者の知名度が向上する - 地理情報システム (GIS) やその他の地図ベースの分析プログラムで GTFS データを視覚化および分析できるツールを使用する -###旅行計画アプリ +###便計画アプリ -交通機関の GTFS データが公開されると、Google マップに加えてさまざまな旅行計画アプリケーションでそのデータを利用できるようになります。これらには、Bing マップ、Apple マップなどの他のナビゲーション アプリや、Transit、Moovit、Transportr、Citymapper などの交通機関専用プラットフォームが含まれます。さらに、オープン フィード データにアクセスすることで、開発者は特定の地域向けのアプリを作成したり、Vamos (カリフォルニア州サンホアキン郡およびスタニスラウス郡)、MetroHero (ワシントン DC エリア)、Entur (ノルウェー) などの標準の旅行計画者に含まれていない機能を備えたアプリを作成したりできます。 +交通事業者の GTFS データが公開されると、Google マップに加えてさまざまな便計画アプリケーションでそのデータを利用できるようになります。これらには、Bing マップ、Apple マップなどの他のナビゲーション アプリや、Transit、Moovit、Transportr、Citymapper などの交通事業者専用プラットフォームが含まれます。さらに、オープン フィード データにアクセスすることで、開発者は特定の地域向けのアプリを作成したり、Vamos (カリフォルニア州サンホアキン郡およびスタニスラウス郡)、MetroHero (ワシントン DC エリア)、Entur (ノルウェー) などの標準の便計画者に含まれていない機能を備えたアプリを作成したりできます。 ### フィード アグリゲーター -GTFS データを共有すると、GTFS フィード アグリゲーション プラットフォームによってインデックス付けされることも可能になります。これには、GTFS フィードの州レベルまたは地域レベルのディレクトリや、[Mobility Database](https://database.mobilitydata.org/) や [Transitland](https://www.transit.land/) などの国際的なフィード アグリゲーターが含まれます (その他のフィード アグリゲーターについては、[こちら](../../resources/data) を参照してください)。フィード アグリゲータにインデックス登録されると、機関の可視性が高まり、開発者、研究者、その他の関係者が、新しいアプリケーションの開発など、さまざまな目的で機関のデータに簡単にアクセスできるようになります。 +GTFS データを共有すると、GTFS フィード アグリゲーション プラットフォームによってインデックス付けされることも可能になります。これには、GTFS フィードの州レベルまたは地域レベルのディレクトリや、[Mobility Database](https://database.mobilitydata.org/) や [Transitland](https://www.transit.land/) などの国際的なフィード アグリゲーターが含まれます (その他のフィード アグリゲーターについては、[こちら](../../resources/data) を参照してください)。フィード アグリゲータにインデックス登録されると、事業者の可視性が高まり、開発者、研究者、その他の関係者が、新しいアプリケーションの開発など、さまざまな目的で事業者のデータに簡単にアクセスできるようになります。 ### GIS、分析、その他のプラットフォームやツールとの統合 @@ -27,17 +27,17 @@ GTFS データは、さまざまな地理空間分析プラットフォームに その他のプラットフォームでは、GTFS データを独自の方法で視覚化および分析できます: - [Conveyal](https://conveyal.com/) は、ユーザーが GTFS データをインポートしてスケジュール、ルート・路線系統、パターンを視覚化し、潜在的なサービス変更の影響を分析できるオープンソース プログラムです。また、ユーザーは人口統計データをインポートして操作し、たとえば、さまざまなルート・路線系統やスケジュールが特定の都市部での職場へのアクセスにどのように影響するかを分析できます。 -- [GTFS to HTML](https://gtfstohtml.com/) は、GTFS scheduleデータを HTML 時刻表に変換できるオープンソース ツールです。これにより、交通機関はスクリーン リーダーでも読み取れる形式でウェブサイトにスケジュールを自動的に公開および更新できるため、視覚障害のある人もデータにアクセスできます。 +- [GTFS to HTML](https://gtfstohtml.com/) は、GTFS scheduleデータを HTML 時刻表に変換できるオープンソース ツールです。これにより、交通事業者はスクリーン リーダーでも読み取れる形式でウェブサイトにスケジュールを自動的に公開および更新できるため、視覚障害のある人もデータにアクセスできます。 ## データの共有: ヒントとベスト プラクティス ### 永続的な取得リンクを作成して維持する -取得リンクは、交通機関のGTFS scheduleファイルが保存される永続的な URL です。通常、フェッチ リンクは交通機関のウェブサイトでホストされるか、GTFS 制作のためにベンダーと契約している場合はベンダーによってホストされます。これは、Google マップなどの旅行計画アプリがデータにアクセスする方法です。GTFS scheduleファイルは、ログインを必要とせずにこの URL から直接ダウンロードするべきであるのが理想的です。ただし、ライセンスの制限によりこれが実現できない場合は、事業者がAPI キーを使用してデータのユーザーに発行することで、データへのアクセスを制御できます。 +取得リンクは、交通事業者のGTFS scheduleファイルが保存される永続的な URL です。通常、フェッチ リンクは交通事業者のウェブサイトでホストされるか、GTFS 制作のためにベンダーと契約している場合はベンダーによってホストされます。これは、Google マップなどの便計画アプリがデータにアクセスする方法です。GTFS scheduleファイルは、ログインを必要とせずにこの URL から直接ダウンロードするべきであるのが理想的です。ただし、ライセンスの制限によりこれが実現できない場合は、事業者がAPI キーを使用してデータのユーザーに発行することで、データへのアクセスを制御できます。 ### URL とファイル名 -一貫した取得リンクと GTFS ファイル名は、フィード データへのアクセスを保証するために不可欠です。事業者がデータに一貫した URL とファイル名を使用しないと、旅行計画アプリ、フィード アグリゲータ、およびその他のユーザーが最も正確で最新のデータを取得できず、長期的には問題が発生することになります。 +一貫した取得リンクと GTFS ファイル名は、フィード データへのアクセスを保証するために不可欠です。事業者がデータに一貫した URL とファイル名を使用しないと、便計画アプリ、フィード アグリゲータ、およびその他のユーザーが最も正確で最新のデータを取得できず、長期的には問題が発生することになります。 永続的な取得リンクの URL を設定したら、それを変更しないでください。つまり、ファイル自体が更新された場合でも、URL 名は一貫性を保つするべきである。そのため、URL はできる限りシンプルで汎用的なままにして、日付やバージョン番号が含まれる URL は使用しないようにしてください。 @@ -63,6 +63,6 @@ Your GTFS は、相互に接続された複数のTextファイル (.txt) を含 ### その他の考慮事項 -複数の機関が異なる名前やコードで同じ停留所を共有している場合、Google マップなどのアプリケーションでは1つを選択する必要がある場合があります。混乱を避けるために、他の機関と調整して名前とコードについて合意してください。これにより、異なる GTFS データセット間の競合が最小限に抑えられます。 +複数の事業者が異なる名前やコードで同じ停留所を共有している場合、Google マップなどのアプリケーションでは1つを選択する必要がある場合があります。混乱を避けるために、他の事業者と調整して名前とコードについて合意してください。これにより、異なる GTFS データセット間の競合が最小限に抑えられます。 複数の GTFS データセットを利用できる場合 (通常は、1つは Transit App などのパブリック アプリケーション用に作成され、もう1つは社内の運用 CAD/AVL システム用に作成された結果)、公開する GTFS としてどれを使用するかを決定する必要がしてもよい。乗客向けの情報を最も多く含むフィードを宣伝することを推奨。可能な限り、GTFS データセットが一致するように ( 停留所等や便などの ID が同じになるように) してください。そうすることで、社内のデータセットがパブリックのデータセットと競合することがなくなり、GTFS-RT などの他のフィードを統合できるようになります。 diff --git a/docs/ja/getting_started/validate.md b/docs/ja/getting_started/validate.md index 70091521..28b16206 100644 --- a/docs/ja/getting_started/validate.md +++ b/docs/ja/getting_started/validate.md @@ -8,13 +8,13 @@ ## 正確なデータ -正確なデータは、信頼性が高くユーザーフレンドリーな交通体験を公共交通機関の利用者に提供するために不可欠です。データにエラーがあると、データセットの一部または全部が使用できなくなる可能性があります。 +正確なデータは、信頼性が高くユーザーフレンドリーな交通体験を公共交通事業者の利用者に提供するために不可欠です。データにエラーがあると、データセットの一部または全部が使用できなくなる可能性があります。 ## 最新のデータ -データが古いと、フィードが利用できないよりも問題になることがあります。情報を公開するだけでは不十分で、乗客が目にし、体験するものと一致している必要があります。最大規模の交通機関の中には、GTFS を毎週、あるいは毎日更新しているところもありますが、ほとんどの交通機関は数か月ごと、またはサービスの変更があったときに年に数回、GTFS を更新する必要があります。これには、新しいルート・路線系統や停留所等、時刻表の変更、運賃体系の更新などが含まれます。 +データが古いと、フィードが利用できないよりも問題になることがあります。情報を公開するだけでは不十分で、乗客が目にし、体験するものと一致している必要があります。最大規模の交通事業者の中には、GTFS を毎週、あるいは毎日更新しているところもありますが、ほとんどの交通事業者は数か月ごと、またはサービスの変更があったときに年に数回、GTFS を更新する必要があります。これには、新しいルート・路線系統や停留所等、時刻表の変更、運賃体系の更新などが含まれます。 -多くの交通機関は、GTFS の作成と管理をベンダーに依頼しています。サービスの変更について積極的に問い合わせてくるベンダーしてもよいが、今後のサービスの変更について交通機関がベンダーとコミュニケーションを取ることが重要です。サービスの変更を事前に GTFS に反映させることで、交通機関、ベンダー、旅行計画者、乗客など、すべての人にとって移行がスムーズに進むようにすることができます。 +多くの交通事業者は、GTFS の作成と管理をベンダーに依頼しています。サービスの変更について積極的に問い合わせてくるベンダーしてもよいが、今後のサービスの変更について交通事業者がベンダーとコミュニケーションを取ることが重要です。サービスの変更を事前に GTFS に反映させることで、交通事業者、ベンダー、便計画者、乗客など、すべての人にとって移行がスムーズに進むようにすることができます。 ## 公式検証ツールの使用 diff --git a/docs/ja/getting_started/what_is_GTFS.md b/docs/ja/getting_started/what_is_GTFS.md index 58a11d1b..6543121c 100644 --- a/docs/ja/getting_started/what_is_GTFS.md +++ b/docs/ja/getting_started/what_is_GTFS.md @@ -3,17 +3,17 @@ title: 始めに description: GTFS の基本、重要性、作成方法、主な機能について説明します。 --- -# GTFS: 公共交通機関のデータを誰でもアクセス可能にする +# GTFS: 公共交通事業者のデータを誰でもアクセス可能にする -## 交通機関の乗客情報のオープン データ標準 +## 交通事業者の乗客情報のオープン データ標準 GTFS とも呼ばれるGeneral Transit Feed Specification は、公共交通事業者がスケジュール、停留所等、運賃などのサービスの詳細を記述するための構造を提供する標準化されたデータ形式です。 -これにより、公共交通事業者は、さまざまなソフトウェア アプリケーション (最も一般的なのは旅行計画者)で使用できる形式で交通データを公開できます。つまり、ユーザーはスマートフォンなどのデバイスを使用して、公共交通機関のサービスにアクセスするための移動情報を簡単に入手できます。 +これにより、公共交通事業者は、さまざまなソフトウェア アプリケーション (最も一般的なのは便計画者)で使用できる形式で交通データを公開できます。つまり、ユーザーはスマートフォンなどのデバイスを使用して、公共交通事業者のサービスにアクセスするための移動情報を簡単に入手できます。 -今日、GTFS は世界中の何千もの公共交通機関にとって頼りになる [オープン スタンダード](https://www.interoperablemobility.org/definitions/#open_standard) です。一部の機関は独自にこのデータを作成しますが、他の機関はベンダーにデータの作成と管理を委託しています。 +今日、GTFS は世界中の何千もの公共交通事業者にとって頼りになる [オープン スタンダード](https://www.interoperablemobility.org/definitions/#open_standard) です。一部の事業者は独自にこのデータを作成しますが、他の事業者はベンダーにデータの作成と管理を委託しています。 ## 静的データと動的データのサポート @@ -21,9 +21,9 @@ GTFS は、[GTFS schedule](../../documentation/schedule/reference) と [GTFS rea -GTFS schedule には、ルート・路線系統、スケジュール、運賃、地理的な交通機関の詳細など、さまざまな機能に関する情報が含まれており、シンプルなTextファイル [^1] で提供されます。このわかりやすい形式により、複雑なソフトウェアや独自のソフトウェアに頼ることなく、簡単に作成および保守できます。 +GTFS schedule には、ルート・路線系統、スケジュール、運賃、地理的な交通事業者の詳細など、さまざまな機能に関する情報が含まれており、シンプルなTextファイル [^1] で提供されます。このわかりやすい形式により、複雑なソフトウェアや独自のソフトウェアに頼ることなく、簡単に作成および保守できます。 -GTFS realtimeには、[プロトコル バッファ](https://developers.google.com/protocol-buffers/) 形式を使用した、旅行の更新、車両の位置、サービス アラートが含まれています。GTFS のこの部分は、 GTFS scheduleと連携して、乗客にサービスの中断や到着時刻の更新を通知します。 +GTFS realtimeには、[プロトコル バッファ](https://developers.google.com/protocol-buffers/) 形式を使用した、便の更新、車両の位置、サービス アラートが含まれています。GTFS のこの部分は、 GTFS scheduleと連携して、乗客にサービスの中断や到着時刻の更新を通知します。 GTFS GTFS scheduleとGTFS realtime のリファレンス ドキュメントは、[技術ドキュメント セクション](../../documentation/overview) で入手できます。 diff --git a/docs/ja/getting_started/why_use_GTFS.md b/docs/ja/getting_started/why_use_GTFS.md index 5d6638bf..b61204cc 100644 --- a/docs/ja/getting_started/why_use_GTFS.md +++ b/docs/ja/getting_started/why_use_GTFS.md @@ -1,12 +1,12 @@ -# GTFS でより多くの乗客にリーチし、公共交通機関を改善しましょう -GTFS は現代の交通システムのバックボーンとして機能し、機関が正確で最新の情報を乗客、アプリ開発者、政策立案者に提供できるようにします。以下では、GTFS のさまざまな利点と、それが世界中の公共交通機関をどのように強化するかについて説明します。 +# GTFS でより多くの乗客にリーチし、公共交通事業者を改善しましょう +GTFS は現代の交通システムのバックボーンとして機能し、事業者が正確で最新の情報を乗客、アプリ開発者、政策立案者に提供できるようにします。以下では、GTFS のさまざまな利点と、それが世界中の公共交通事業者をどのように強化するかについて説明します。 ## 広く使用され、世界中で採用されています -100 か国以上の 10,000 を超える機関が GTFS を使用しており、複数事業者を跨ぐ旅程でデータの一貫性を確保し、地域間の移動を簡素化しています。 GTFS が世界規模での利用とシームレスな便を実現する仕組みは次のとおりです。 +100 か国以上の 10,000 を超える事業者が GTFS を使用しており、複数事業者を跨ぐ旅程でデータの一貫性を確保し、地域間の移動を簡素化しています。 GTFS が世界規模での利用とシームレスな便を実現する仕組みは次のとおりです。 -- **標準化されたデータ:**GTFS は交通データの標準化された形式を提供し、機関や地域間での一貫性を確保して、利用者の移動計画を簡素化します。 -- **複数事業者を跨ぐ旅程:**GTFS を使用すると、機関は一貫性のある信頼性の高いデータを共有できるため、複数の交通システムを移動する利用者にとってシームレスな移動体験が実現します。 +- **標準化されたデータ:**GTFS は交通データの標準化された形式を提供し、事業者や地域間での一貫性を確保して、利用者の移動計画を簡素化します。 +- **複数事業者を跨ぐ旅程:**GTFS を使用すると、事業者は一貫性のある信頼性の高いデータを共有できるため、複数の交通システムを移動する利用者にとってシームレスな移動体験が実現します。 ## コミュニティ主導の開発と自由にアクセス可能 @@ -22,9 +22,9 @@ GTFS はコミュニティのコラボレーションによって発展し、継 ## シンプルで使いやすい -GTFS は、データ交換を容易にし、サービスの統合をスムーズにし、情報共有を促進することで、交通機関間の連携を促進します。 GTFS がデータ共有を簡素化する方法は次のとおりです。 +GTFS は、データ交換を容易にし、サービスの統合をスムーズにし、情報共有を促進することで、交通事業者間の連携を促進します。 GTFS がデータ共有を簡素化する方法は次のとおりです。 -- **統合の容易さ:** GTFS を使用すると、 .txtや GeoJSON などの一般的なファイル形式を使用して、機関がシンプルなデータ構造で簡単に開始できるため、コラボレーションと相互運用性が促進されます。 +- **統合の容易さ:** GTFS を使用すると、 .txtや GeoJSON などの一般的なファイル形式を使用して、事業者がシンプルなデータ構造で簡単に開始できるため、コラボレーションと相互運用性が促進されます。 - **下位互換性:** 仕様を更新しても、既存のフィードは有効なままで、既存のパーサーとの互換性が維持されます。 ## GTFS はおそらくあなたが思っている以上のことを行うことができます @@ -33,7 +33,7 @@ GTFS は、データ交換を容易にし、サービスの統合をスムーズ - **運賃:** GTFS には、ルート・路線系統や移動オプション全体の正確なコストの内訳を示す運賃情報を含めることができます。 - **フレキシブルサービス:** GTFS では、ダイヤル ア ライド、ルートの変更、およびスケジュールされたサービスや固定サービスの一般的な動作に従わないその他のサービスなど、需要に応じたオプションを記述できます。 -- **構内通路:** GTFS では、大規模な交通機関の駅をモデル化できるため、乗客は駅の出入り口から目的の場所まで移動できます。公共交通機関の車両に乗車または降車します。 +- **構内通路:** GTFS では、大規模な交通事業者の駅をモデル化できるため、乗客は駅の出入り口から目的の場所まで移動できます。公共交通事業者の車両に乗車または降車します。 [:octicons-search-16: GTFS機能の詳細](../features/overview){ .md-button .md-button--primary } @@ -46,7 +46,7 @@ GTFS が乗客を支援し、エクスペリエンスを向上させる仕組み ## 幅広いアプリケーションへのアクセス -GTFS を採用することで、標準化されたデータ形式を利用する膨大な数のアプリ開発者を通じて、機関はより幅広いユーザーにリーチできます。 GTFS がアプリやサービスのユーザーベースを拡大する方法は次のとおりです。 +GTFS を採用することで、標準化されたデータ形式を利用する膨大な数のアプリ開発者を通じて、事業者はより幅広いユーザーにリーチできます。 GTFS がアプリやサービスのユーザーベースを拡大する方法は次のとおりです。 -- **アプリのリーチの拡大:** GTFS データにアクセスすることで、アプリ開発者はより幅広い交通機関の利用者にリーチできるようになり、交通アプリの使いやすさと機能性が向上します。 -- **相互運用性:** オープン スタンダードにより、交通機関とアプリ開発者間のシームレスなデータ交換が可能になり、相互運用性とコラボレーションが促進されます。 +- **アプリのリーチの拡大:** GTFS データにアクセスすることで、アプリ開発者はより幅広い交通事業者の利用者にリーチできるようになり、交通アプリの使いやすさと機能性が向上します。 +- **相互運用性:** オープン スタンダードにより、交通事業者とアプリ開発者間のシームレスなデータ交換が可能になり、相互運用性とコラボレーションが促進されます。