Add optional carriage_positions.txt specification

[gcamp]

This proposal adds a new optional file carriage_positions.txt that defines optimal carriage positioning for transfers and platform exit access. It enables trip planners to recommend which carriage passengers should board to minimize walking time at transfer points and alighting stations.

Motivation

There is at least one example of this type of public data in production, but it does not use a standardized format: Île-de-France Mobilités publishes carriage positioning data for the Paris métro, and Transit ingests this information from IDFM.

While pathways.txt handles navigation within stations, it does not address where to stand on the platform before boarding. This file complements pathways by providing carriage-level boarding recommendations, including information about where passengers should board a vehicle to most easily access stairs, escalators, and elevators at transfer points and alighting stations.

Transit also supports displaying this information based upon crowdsourced data collected through its own app. Receiving carriage position information directly from producers in a standardized format within GTFS would improve data reliability and be beneficial to the entire ecosystem.

Proposed Solution

Add a carriage_positions.txt containing the recommended carriage for boarding, based on a carriage count, for each from/to stop id pair.

Type of change

GTFS Schedule Functional Change

Proposed Discussion Period

Testing Details

• Consumer(s):
• Producer(s):
• Estimated Testing Period:

Proposal Update Tracker

Date	Update Description
(YYYY-MM-DD)	(Brief description of the update)

[gregory-pevnev-transit-app]

With this information included in bgtfs-files, I assume that we're going to check whether there is BL recommendations present and use them instead of reaching into the DB (with aggregated RMR-data like for STM / with externally-sourced data like for RATPS_1).

There shouldn't be any issues with that, given that bgtfs-files are already getting retrieved for additional information required for presenting BL recommendations.

A couple of things to note / confirm:

• The terms we currently use in BL data are "end-stop" (station that the train stops on) and "transfer-stop" (either a specific exit or a station on another line that one can transfer to). Are "from-stop" and "to-stop" the same (I read their descriptions and they seem to match, but I just want to be absolutely sure)?
• We always present a card with just 5 cars corresponding to front, middle (varying degrees) and back, so I'm going to map the recommendation-car to it based on the total number of cars specified in the record. For efficiency, I propose we transform the car-number upon writing to bgtfs.
• Currently, the accessibility feature is a binary flag, so I suppose we're going to be mapping elevator (accessible exit) and stairs(non-accessble exit) to that. Once again, I propose making it a flag.

Note: If we do want the bgtfs data to be more extensible, we could store all the data as it is, I'm just stating how it works at the moment.

[gcamp]

Looking a bit deeper on the paris data set, they don't seems to provide the start departure station, just the arrival station + the entrance. Do we really need the data for each pair of data, including the start? I think it won't work for system where you can board the train on both side depending on the station? @gregory-pevnev-transit-app

[gregory-pevnev-transit-app]

Looking a bit deeper on the paris data set, they don't seems to provide the start departure station, just the arrival station + the entrance. Do we really need the data for each pair of data, including the start? I think it won't work for system where you can board the train on both side depending on the station? @gregory-pevnev-transit-app

This is how it currently is though, we only store the arrival station (end_stop) and either the exit or the transfer station (transfer_stop). This is why I was asking about whether from_stop and to_stop were corresponding to them. I'm not sure why you think we need to store the departure station. We DO need it for giving a recommendation for cases where the arrival and departure stations have trains going in different directions / to change the car for boarding, but that's it.

CC @gcamp

[gcamp]

We DO need it for giving a recommendation for cases where the arrival and departure stations have trains going in different directions / to change the car for boarding, but that's it.

Bascally just make the start_station as optional?

[gregory-pevnev-transit-app]

@gcamp and I had a talk. Here's what we've thought about:

• Adding a station-directions files (something like station_directions.txt which specifies whether trains go left or right at each specific station). This makes storing start-stations unnecessary for each recommendation (the whether trains go to the same or different direction at the departure and arrival stations can be found our at runtime with this file).
• Since we don't need to store departure-stations, we only need to store arrival-stations and their transfers / exits instead. We just need to do it once for ever transfer / exit (that we can give information for).
• The information about boarding-locations recommendations and station-directions can be populated into BGTFS files in the USD pipeline either via the corresponding files if they are present or via the crowd-sourced data (already exists and is used by RD-API). However, the API and its load / requests model is going to be very different form the current one, so a new service / API might need to be built for it (or the USD-pipeline could simply reach into the DB directly).