[GTFS Digest] 2025年1月 - 乗客カテゴリーに関する投票と相互運用可能な “trip_id” の提案が公開される¶

2025年1月の GTFS Digest では、GTFS-Fares v2 における rider_categories.txt の継続中の投票、agency_fare_url の明確化の採用、original_trip_id による便(trip)参照や boarding_permissions.txt による車両搭載ルールといった提案を取り上げています。議論には、GTFS Realtime のバージョニングや一意な ID のベストプラクティスも含まれています。

GTFS Digest は、MobilityData によって毎月作成されるリソースで、GTFS に関する最新の動向を概観するものです。

私たちは皆さまからのフィードバックを大切にしており、今回の内容についてのご意見を伺いたいと考えています。ぜひこのフォームにご記入いただき、このツールの可能性を最大限に引き出すためにご協力ください。

🏅 コントリビューターへの感謝¶

Harpreetkaur, Laurent, Stephanie Daniels, Wojciech, & Angela Teyvi
GTFS Slack に参加し、貴重なスレッドでコミュニティに貢献してくださりありがとうございます。

David1234
google/transit で初めての Pull Request を投稿してくださり感謝します。今後の展開を楽しみにしています！

Miklcct
投票が不成立となった後も提案を続けてくださったことを称賛します。提案を推進することは難しく、合意形成には多くの忍耐が必要です。

🗳️ 現在投票中¶

[GTFS Fares v2] rider_categories.txt の追加 #511
rider_categories.txt ファイルは GTFS-Fares v2 提案の一部であり、特定の運賃に適用される乗客カテゴリをモデル化することを目的としています。

投票は 2025-02-13 23:59:59 UTC に終了します。

🚀 最近採用されたもの¶

agency_fare_url の使用方法の明確化 #524
このPRは、agency_fare_url の定義を拡張し、チケット購入が可能なページだけでなく、運賃情報を含むURLページも対象に含めるようにしました。

📂 アクティブな提案¶

GTFS Schedule および Realtime に original_trip_id を追加する提案 #534
Davidr1234 は、Google Transit 拡張から original_trip_id を GTFS Schedule と GTFS Realtime の両方に採用することを提案しています。これにより、SIRI や NeTEx など、同様の概念を持つ他の標準との間で便(trip)をシームレスに参照できるようになります。

停留所単位で車両の搭載可否を指定するための boarding permissions の導入 #533
Miklcct は、公共交通サービスにおいて、あらゆる種類の車両を停留所単位で搭載・乗車・降車できるかどうかを指定するための汎用的な解決策を提案しています。これは、新しいファイル boarding_permissions.txt を導入し、stop_times.txt から参照することで実現されます。

booking_rules.txt における continuous pickup/dropoff 値とフィールド型の明確化 #528
この PR は、特にデマンド型サービス(DRT)向けの明確化を導入し、start_pickup_drop_off_window/end_pickup_drop_off_window が指定されている場合に continuous_pickup/continuous_drop_off に値 1 を許可します。また、booking_rules.txt 内の4つのフィールドのデータ型を正の整数に更新します。

event_based_trips.txt の仕様への追加 #527
この PR は #526 に基づいており、イベント後の臨時便であることを利用者や顧客に示すために event_based_trips.txt ファイルを追加することを提案しています。

stops.stop_access フィールドの追加 #515
この PR は、stops.txt に stop_access フィールドを追加し、特定の駅における停留所等(stop)へのアクセス方法を示すものです。詳細についてはこの提案を参照してください。このフィールドの追加は、駅のモデリングを改善するための3段階計画の第1段階でもあります。

TripUpdate.schedule_relationship = ADDED を廃止し、TripUpdate.schedule_relationship = NEW / REPLACEMENT を追加して、GTFS Schedule に存在しない新規便や置換便を指定する #504
この PR の当初の提案は投票で否決されたため変更されました。更新された提案では、GTFS Realtime における TripUpdate.schedule_relationship = ADDED を廃止し、GTFS Schedule に存在しない完全に新しい便を示すために TripUpdate.schedule_relationship = NEW を導入します。この新しい値は実験的としてフラグ付けされます。次回の投票前に、できるだけ多くの人々が議論に参加し、コミュニティ全体で十分に検討されることを期待しています。

その他のオープンな提案:

🔥 最も活発な議論¶

[議論] GTFS Realtime のバージョニング #530
GTFS Realtime に関する最近の議論において、コミュニティは合意形成に困難を抱えているようであり、その結果、最近の PR#504 でバージョニングの話題が取り上げられました。これに対応するため、本 issue を開き、GTFS Realtime のバージョニングについて議論を行います。

GTFS-RT TripUpdates フィードにおける GTFS-Static に存在しない trip_id の利用 #529
Mpaine-act は新しい GTFS-Realtime TripUpdates フィードを構築しており、GTFS-Static に存在しない便(trip)の扱いについて指針を求めています。この issue では、後方互換性のために負の（偽の）trip_id を使用する方法と、trip_id を完全に省略する方法の 2 つのアプローチを比較しています。

GTFS Service Alerts に communication_period と impact_period を追加 #521
GTFS Realtime Alert の active_period フィールドは曖昧であり、アラートの表示期間を意味するのか、障害の継続時間を意味するのかが不明確です。この問題を解決するために、アラートの表示期間を示す communication_period と、障害の時間枠を示す impact_period を追加する提案がなされています。

ベストプラクティス: 一意の ID の妥当な長さ #518
この issue では、GTFS フィードで使用されるあらゆる ID に推奨される文字数制限を設け、値が 36 バイトを超えた場合にバリデータが警告を出すというベストプラクティスを導入することが提案されています。

グローバル trip id #462
SKI+ の David は、NeTEx や HRDF などの他の標準との統合を改善するために、GTFS Schedule および Realtime に新しいフィールド "trip_global_id" を導入することを提案しています。これは 1 日有効な便(trip)識別子の必要性に対応するものであり、このグローバル ID によって異なるデータ形式間での旅行情報のマッピングが容易になります。

提案ベストプラクティス: SCHEDULED trips において TripDescriptor に常に trip_id を含める #465
この提案では、GTFS Realtime において SCHEDULED trips の TripDescriptor に trip_id を必ず使用することを義務付けることを提案しています。これは、複数の識別子を用いる代替手法がしばしば問題を引き起こすため、データ統合を簡素化することを目的としています。