GTFS Carriage Position

[gcamp]

Summary

This proposal adds two new files, station_directions.txt and carriage_positions.txt, that let a feed express which carriage a rider should board to minimize walking at their destination.

Describe the Problem

To speed up their trip, passengers want to know which carriage to board for a fast transfer or a fast exit at their destination. pathways.txt can give a rider turn-by-turn directions inside a station, yet nothing tells them where to stand on the platform before boarding. Agencies often have this information but GTFS has no way to encode it.

Discussion started in #614. Thanks @vikiawv @jfabi for the comments and suggestions!

Proposed Solution

Two new files:

• station_directions.txt defines which side of the platform the front carriage stops at. One record per platform covers all trips, and optional route_id and direction_id records take priority over that default so special configurations can be modeled, such as a platform on a bidirectional single-track section. Conditionally Required: required when carriage_positions.txt is provided, since a recommendation cannot be interpreted without knowing platform orientation.
• carriage_positions.txt maps an arrival platform, and optionally a specific transfer platform or station entrance/exit, to the recommended carriage to board. The optional facility_type, which reuses the pathways.txt pathway_mode values for stairs, escalator and elevator, covers cases where the elevator serving a destination is several carriages away from the stairs serving the same destination, so riders needing step-free access can be sent to a different carriage.

Recommendations are expressed relative to the front of the train at the arrival platform. When the departure platform is oriented the other way, planners mirror the carriage with carriage_count - recommended_carriage + 1, so a single record stays usable regardless of which end of the train the rider boards from.

recommended_carriage is numbered from 1 for the first carriage in the direction of travel, matching GTFS-realtime CarriageDetails.carriage_sequence. Consumers that already show per-carriage occupancy from real-time data can then combine both without translating between two numbering schemes for the same concept, which would be a likely source of off-by-one errors.

carriage_count is part of the primary key, which lets a platform carry different recommendations for trains of different lengths, and producers without exact carriage positions can use logical divisions instead: carriage_count=3 with recommended_carriage=1 simply means "board near the front".

Type of change

GTFS Schedule

• Functional Change

Additional Information

This proposal is deliberately a small subset of what GTFS-VehicleBoardings attempted: it does not model platform sections or train formations, and instead encodes only the boarding recommendation itself.

PR #636 proposes vehicles.txt along with a vehicle_class on routes.txt and trips.txt. This proposal does not depend on it and stays usable on its own through carriage_count, but if #636 is adopted, an optional vehicle_class in carriage_positions.txt would be a natural follow-up to select the right configuration for a trip.

Proposed Discussion Period

I recommend reserving one month for discussion, since this adds two new files and affects station modeling.

Testing Details

• Consumer(s): Transit
• Producer(s): TBD (please mention if you want to produce!)
• Estimated Testing Period: TBD

Proposal Update Tracker

Date	Update Description
July 29 2026	Initial PR submission