Unassigned platform and schedule data: should we assign stop_time on station?

[LeoFrachet]

Some trains are only scheduled to leave from "Main Station", without platform scheduled in advance. The platform is assigned only at the last minute, when the boarding starts.

In GTFS, platforms have location_type=0 and stations have location_type=1. Schedules can only be provided on platforms currently.

=> How should schedules be provided when the platform is not assigned in advance?

(Please note that the proposal GTFS-ServiceChanges v3 (discussed in issue #113 and available at bit.ly/gtfs-service-changes-v3) offers already a way to update platform in real-time. So this part of the conversation should be discussed in #113. This current issue is meant to be about the scheduled representation of unassigned platform, expecting GTFS-TripUpdates to provide the correct information in real-time.)

Option 0: Schedule on any platform, then update in real-time with the right platform.

Pro: It's likely what most data producers already do. Con: The information is non-accurate, since riders might go to a platform (and maybe even board on a train) which is not the good one.

Option 1: Add a "fake" platform, and assign trip on it as long as the platform is not assigned.

Pro: It works with the current spec. Con: This is a hack, and as soon as an agency will use GTFS-Pathways, they will either (i) not link this platform with pathways, leading the trip planner to declare it unaccessible or (ii) link it to everywhere in the station, leading wrong trip planner result.

Option 2: Assign stop times on station, until the platform is assigned

Pro: It is how riders think about it. The train is scheduled from "Main Station", without more indication. Con: Without being strictly speaking non-backward-compatible, it will still require some change on data consumers that expect stop times to always be on platform and not on station.

=> What do you think? Should I open a PR to allow scheduling on station? Should we think about a more complex representation (describing waiting areas in station? Halls?)

Ping Andrew (@abryd) who asked me to open this issue.

Thanks!

[skinkie]

I am for option 2 for another reason. Many historic timetable journey planners work on stop areas instead of stops. This reduces the number of labels inside the planner already by 50%. Providing platform assignment in advance is therefore an attribute in these planner, opposed to a specific label in more current planners. This is in line with the pathways proposal where the parent_station is the centered concept entrances are added to. Why is this important: you can now explain to a novice person that it makes sense to add transfers/pathways within the station to couple stop and assign walking time. If this information is not provided it is quite clear it is missing and distances are estimated. With this proposal also one other thing becomes evident a parent_station is likely to have a single mode, you wouldn't schedule a train to a busstation.

From passenger perspective it would obviously be better that unassigned platform are prevented at all cost, especially if they are in fact scheduled and the information is available. Sometimes a single center platform is used to schedule a train to, but at the last phase of planning is decided if the track left or right is used. The Dutch approach to dynamic assignment is solved via adding an extra stop in the center of the platform.

In The Netherlands center platforms are already split into 6 individial stops, and sometimes 7. This situation will not change, we have the scheduled information. We might just haven't the exact assignment yet.

5, 5a, 5b
6, 6a, 6b
5-6

In other countries I have seen many times that the entire network is known. But stop times are only known at stop area level. For bus stops along the route is is possible to recover this, but for trains it is certainly more challenging.

[LeoFrachet]

Those are good points

Should a station have only one "mode"

Most railway stations I know have at least two route_type: trains (2) and subway (1). But both of them are still rail. So I don't know what kind of safe guard we can build. "Mode" has currently no strict definition in GTFS. Allowing only one route_type by station may be too strict.

Track vs platform, and assigning "temporary" platform until the track is known

The question on incremental precision (in your example, station then platform then track) is a really good one. In some station (e.g. Gare de Lyon in Paris) they are "Halls". The rider will be told to wait in "Hall 1" or "Hall 2" until the track is assigned, depending of where the train will be. In your example the platform "5-6" looks like a in-between assignation until you've got the "5" or "6".

If we want to model that, we could think of an Option 3, which is that we could allow assignation on any generic nodes, which could be a hall (most people are waiting in front of the big departure board for the track to be assigned), then possibly the platform, then if needed the track.

If we want to be more strict than just "any generic node", we could define a specific type of location that we call "waiting area", and producer would be allowed to only assign schedule times on waiting areas and stops. I just don't know if we want to go that far now.

[paulswartz]

@mbta currently does option 1, though we haven't created pathways for those stations which have a generic stop ID for scheduling. Our plan is to have the location of the generic stop ID be the lobby of the station, so that trip plans direct riders to a place inside the station where they can wait to see the track assignment of their train.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[skinkie]

Keep open.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to inactivity. Issues can always be reopened after they have been closed.