[GTFS Digest] 2025年2月 - Rider Categories、採択！¶

今月の更新では、GTFS-Fares v2 における rider_categories.txt の採択、現在投票中のデマンド型サービスにおける連続乗降ルールの明確化、そして仕様を形作る新たな議論について取り上げます。コミュニティでは、null の fare_media_id が乗り換えルールにおけるワイルドカードとして機能すべきかどうか、StopTimeEvent の timestamp を int64 から uint64 に変更すべきかどうか、そして GTFS のフィールド名が複数値の関係であっても単数形を使用している理由について議論が行われています。

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

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

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

Max Buchholz
GTFS Realtime の proto ファイルにおけるいくつかの誤字を修正する初めての PRを投稿してくださいました。ご貢献ありがとうございます！

Felix Gündling & Scott Berkley
GTFS コミュニティへようこそ。GTFS Fares に関するご質問やご意見を共有していただきありがとうございます。

Wojciech Kulesza
Fares に大きな関心を寄せていただき、ワーキンググループミーティングにご参加いただきありがとうございます。

Jerome Le Lan & lolpro11
GTFS Github リポジトリに初めての issue を投稿していただきありがとうございます。皆さまのご貢献に感謝いたします！

🗳️ 現在投票中¶

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

🚀 最近採用されたもの¶

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

📂 アクティブな提案¶

gtfs-realtime.proto のタイプミス修正 #541
1Maxnet1 が Realtime 用の Proto ファイルにあるいくつかのタイプミスを指摘し、修正を提案しました。これはドキュメントの保守的な変更であり、マージ前に他のコミュニティメンバーによるレビューが有益となる可能性があります。

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

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

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

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

🔥 最も活発な議論¶

fare_media_id for fare_transfer_rules: ワイルドカードか明示的な列挙か？ #538
Jerome は、fare_products において null の fare_media_id がすべてのチケットメディアに対して自由な乗り換えを許可するワイルドカードとして機能するのか、それとも各チケットメディアごとに明示的に重複を記述する必要があるのかについて明確化を求めています。

GTFS Realtime Stop Time Updates Timestamp 型 #537
lolpro11 は、現在 int64 である StopTimeEvent の time フィールドを、他の GTFS Realtime のタイムスタンプフィールドとの一貫性のために uint64 に変更すべきかどうかを質問しています。

フィールド名の複数形化？ #536
Nina は、GTFS において「複数」の多重度(cardinality)を持つフィールドが、なぜ複数形ではなく単数形の名前を与えられているのかを疑問に思っています。これに対する回答では、CSV の各行には単一の外部キー参照しか含まれないため、列名はコレクションを表すのではなく個々の行に適用されるからだと説明されています。

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

相乗り路線の統合 #430
フランスの National Access Point (NAP) の Aurélien が、バス路線のように正確な停留所等(stop)や目的地を持つ相乗り路線をモデル化する提案について GitHub Issue を立ち上げました。この場合、運転は一般のドライバーが行い、運賃から金銭的なインセンティブを受け取ったり、乗客と費用を分担したりすることができます。議論のために 2 つの異なる潜在的な解決策が提示されています。