GTFS Carriage Position - #650
Conversation
carriage_positions.txt lets producers recommend which carriage a rider should board to minimize walking at their destination, either when transferring to another platform or when leaving the station. Pathways describe navigation once a rider is off the train, but nothing said where to stand on the platform before boarding. Recommendations are relative to the front of the train at the arrival platform while riders board at the departure platform, so station_directions.txt records which side of each platform the front carriage stops at and the mirroring formula trip planners apply when the two platforms disagree.
etienne0101
added
GTFS Schedule
|
@gcamp thank you for raising this proposal. Best carriage information is an important addition to the spec.
|
|
@skalexch thank you for the comments!
👍
👍
I'm mixed on that one. I don't want to complexify the implementation too much, but I see the benefits. I'm going to change but if others think it's too much let me know.
I guess my counter question is why would a consumer care about if the num carriage is true or not in the context of boarding location? If we added a field I'm not sure how we would use it (re guiding principles of speculative features) |
Review feedback on google#650. front_car_position becomes front_carriage_position, matching the "carriage" wording used everywhere else in both files. carriage_positions.txt takes the whole row as its primary key. More than one carriage can be equally good for the same destination — a platform with stairs at both ends leading to the same transfer platform is served just as well by the first or the last carriage — and the old key (stop_id, to_stop_id, via_pathway_mode, carriage_count) left room for only one of them. to_stop_id also accepts generic nodes and boarding areas now; only stations stay forbidden. A junction riders continue through, or a specific boarding area on a transfer platform, are both legitimate destinations for a recommendation, and forbidding them forced producers to point at a coarser location instead. The same-station sentence drops its stops.parent_station reference, which does not hold for boarding areas: their parent is a platform, not a station.
Review feedback on google#650, point 2. recommended_carriage counts carriages from the front of the train, the same frame as GTFS-realtime CarriageDetails.carriage_sequence, so the index does not change along a trip. Mirroring it when the two platforms disagree converts it a second time and sends riders to the opposite end of the train: a recommendation of carriage 1, authored because the exit stairs are at the nose of the train, became carriage 8 whenever the boarding platform's front_carriage_position differed, which is routine for platform pairs that merely differ in track layout. Consumers need front_carriage_position for the boarding platform only, and they need it to render the recommendation at all: a bare carriage index is not something a rider can act on, so the paragraph now shows how the index becomes an end of the platform the rider is standing on. The one case where the front of the train genuinely changes mid-trip is a physical reversal, which front_carriage_position cannot express since it describes platform geometry rather than train orientation.
|
@gcamp thanks for the changes! For the two remaining questions:
As it currently stands, the proposal works 100% clearly and correctly only if the consumer shows a graphic of the relative position of the rider after doing the calculation I like both concepts of being able to show either the actual carriage or a relative position [FRONT, MIDDLE, BACK]. But I think both of them being modelled using the same fields might cause misinterpretation. |
My point is that is not something we want to do. I'm not against this use case, but it's a speculative feature unless somebody else ask. What we could do is rename the field and state that it's only a virtual representation of the carriage length, and keep the door open for an other field in the future. |
3 participants
Summary
This proposal adds two new files,
station_directions.txtandcarriage_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.txtcan 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.txtdefines which side of the platform the front carriage stops at. One record per platform covers all trips, and optionalroute_idanddirection_idrecords take priority over that default so special configurations can be modeled, such as a platform on a bidirectional single-track section. Conditionally Required: required whencarriage_positions.txtis provided, since a recommendation cannot be interpreted without knowing platform orientation.carriage_positions.txtmaps an arrival platform, and optionally a specific transfer platform or station entrance/exit, to the recommended carriage to board. The optionalfacility_type, which reuses thepathways.txtpathway_modevalues 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_carriageis numbered from1for the first carriage in the direction of travel, matching GTFS-realtimeCarriageDetails.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_countis 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=3withrecommended_carriage=1simply means "board near the front".Here is an example of a dataset I made from the Paris GTFS and the open data carriage position CSV they have.
Type of change
GTFS Schedule
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.txtalong with avehicle_classon routes.txt and trips.txt. This proposal does not depend on it and stays usable on its own throughcarriage_count, but if #636 is adopted, an optionalvehicle_classincarriage_positions.txtwould 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
Proposal Update Tracker