Introduce boarding permissions to specify the carriage of vehicles at per-stop granularity

[miklcct]

Previous discussion: #466

The current GTFS specification cannot express if a bike can only be carried on part of the trip, or if it cannot be boarded or alighted at certain stops even if it can be carried on the trip.

This proposal provides a generic solution to specify if any kinds of vehicles can be carried, boarded or alighted on any public transport service at a per-stop granularity, by introducing a new file boarding_permissions.txt, which is referenced from stop_times.txt. The introduction of this new feature does not break any existing compatibility.

Use case: Bikes allowed only on certain part of trip at certain times

London Underground allows the carriage of bikes, but only outside peak hours and outside the deep tube sections. With this proposal, it is possible to assign stop times to either accept bikes outside peak hours (for stops outside the deep tube sections), or to not accept bikes at all (for stops inside the deep tube sections).

Use case: Mandatory bike reservation

On some long distance trains, a bike space must be reserved by the passenger in order for a bike to be carried. By assigning the stop times for the whole trip to a boarding permission which requires bike reservation, the journey planner can tell the passenger that a bike space must be reserved.

Use case: Staff assistance required for wheelchair boarding

On some National Rail journeys, wheelchair can board trains unassisted at some stations, but assistance is required at other stations. By assigning the stop times to appropriate boarding permissions, accurate instructions can be given to the user if assistance needs to be arranged.

Use case: Service which requires the carriage of vehicle

The Silvertown tunnel bike shuttle requires passengers to carry a bike to use the service. By setting pickup_type and drop_off_type = 1 in stop_times.txt and assigning positive bike boarding permission for the stop times, consumers which understand this proposal can route bike passengers onto the shuttle, while the service won't be suggested by legacy consumers which don't understand bikes.

[paulswartz]

Love this idea! It would definitely help with an issue we see with the data @mbta.

[paulswartz]

question: should this have a different name? at the moment, everything in GTFS/GTFS-RT which uses vehicle is a transit vehicle (bus/train/&c).

[miklcct]

Can you make a suggestion of a name to use?

[paulswartz]

cargo_vehicle perhaps?

[paulswartz]

question: is it worth distinguishing between "Bike" and "Folding Bike"? For @mbta, general bikes are restricted, but folding bikes (when folded) are always allowed: https://www.mbta.com/bikes

[miklcct]

Yes, I will add a clarification for this such that the value only applies to full sized bikes. I don't want to define folded bikes for now as they are commonly considered luggage.

[jspetrak]

How does it compare to feature earlier described here? #117

[miklcct]

How does it compare to feature earlier described here? #117

That's irrelevant. #117 is to prohibit legs between certain pairs of stops on a trip, not to allow / prohibit carrying of vehicles.

[miklcct]

I now think that this proposal can be extended to other kinds of special luggage, such as pets and surfboards, therefore the term vehicle may not be appropriate. Can anyone suggest me a new name for the field, or an improvement to the proposal which can define behaviour for arbitrary kinds of luggage?

[felixguendling]

I don't have an opinion about the proposal as it is.

Just factually, this is wrong:

The current GTFS specification cannot express if a bike can only be carried on part of the trip

It is possible to split a trip into two trips where one part has bikes allowed an the other part does not have bikes allowed. Then after that just rejoin the trip using a stay seated transfer or block_id and you have exactly what you need. So just to achieve this behavior (bike allowed for parts of the trip or specific times) the GTFS standard does not have to change.

MOTIS for example supports this information for the search option to travel with your bike in public transport.

---

For boarding assistance times: this usually depends not just on the time+station but also the trip. But the trip only has wheelchair_accessible which refers to the vehicle itself being able to carry a wheelchair. So to actually know if a wheelchair user can take a trip more conditions have to hold:

• Entry/Exit:
  • Either the vehicle (bus, train, etc.) has the entry on the same height as the ground of the stop
  • or the station provides a lift to lift the wheelchair into the vehicle (which might be time dependent because the staff operating the lift is only available at certain times)
• Trip: has to have sufficient places
  • for long distance trips this is tracked in the reservation system, so this would be updated in real-time
  • for short distance trips there's usually no reservation system, so it only depends on the trip itself

For example for the option lift is provided or not, I translated this PDF to this CSV using OpenStreetMap opening hours format. This is now supported in MOTIS in order to find the best journeys considering that long distance trains in Germany require that the wheelchair user is lifted. The OSM opening hours format is convenient for users and developers alike (at least OTP and MOTIS can both parse this format as far as I know).

---

I'm not opposing this PR (I don't have an opinion). Just wanted to add some information that might be relevant.

[miklcct]

I don't have an opinion about the proposal as it is.

Just factually, this is wrong:

The current GTFS specification cannot express if a bike can only be carried on part of the trip

It is possible to split a trip into two trips where one part has bikes allowed an the other part does not have bikes allowed. Then after that just rejoin the trip using a stay seated transfer or block_id and you have exactly what you need. So just to achieve this behavior (bike allowed for parts of the trip or specific times) the GTFS standard does not have to change.

MOTIS for example supports this information for the search option to travel with your bike in public transport.

Your modelling is distorting the reality when it is factually one trip on the ground. The trip information will be totally wrong if you do so. There is a very obvious distinction if the vehicle is making one trip, or is making two trips where passengers can stay aboard. In the latter, the stop list shown on the bus will not contain the second trip while the bus is running on the first trip, and the timetable will have special indication that they are two different trips where the passenger can stay on board, rather than one single trip.

For boarding assistance times: this usually depends not just on the time+station but also the trip. But the trip only has wheelchair_accessible which refers to the vehicle itself being able to carry a wheelchair. So to actually know if a wheelchair user can take a trip more conditions have to hold:

* Entry/Exit:
  
  * Either the vehicle (bus, train, etc.) has the entry on the same height as the ground of the stop
  * or the station provides a lift to lift the wheelchair into the vehicle (which might be time dependent because the staff operating the lift is only available at certain times)

* Trip: has to have sufficient places
  
  * for long distance trips this is tracked in the reservation system, so this would be updated in real-time
  * for short distance trips there's usually no reservation system, so it only depends on the trip itself

For example for the option lift is provided or not, I translated this PDF to this CSV using OpenStreetMap opening hours format. This is now supported in MOTIS in order to find the best journeys considering that long distance trains in Germany require that the wheelchair user is lifted. The OSM opening hours format is convenient for users and developers alike (at least OTP and MOTIS can both parse this format as far as I know).

I'm not opposing this PR (I don't have an opinion). Just wanted to add some information that might be relevant.

This proposal can represent all of the above, except the real-time update of places (this will require another proposal w.r.t. to reservation availability in general for all trips which require rebooking).

[felixguendling]

Your modelling is distorting the reality when it is factually one trip on the ground. The trip information will be totally wrong if you do so. There is a very obvious distinction if the vehicle is making one trip, or is making two trips where passengers can stay aboard. In the latter, the stop list shown on the bus will not contain the second trip while the bus is running on the first trip, and the timetable will have special indication that they are two different trips where the passenger can stay on board, rather than one single trip.

I guess this is your interpretation of the GTFS standard? As far as I know, the standard itself does not state anything of this. Can you point me to a quote from the standard that supports your view?

I have seen trips being split into several trips for several (valid IMO) reasons, none of them would affect what's shown on the stop list in the vehicle:

• Split for agency change. This sometimes happens at the border between countries.
• Split for route type change. There are some cases where a regional express train ("RE") is changed to an intercity train ("IC") but it's still the same physical vehicle.
• Split for trips running in circles. The next circle often is a new trip. Here, the stop list is "infinite" (scrolling through over again, there should be no "end" and "start").
• Split for train number change (trip_name_short)

The customer will not notice any of those and can just "stay seated".

[miklcct]

Your modelling is distorting the reality when it is factually one trip on the ground. The trip information will be totally wrong if you do so. There is a very obvious distinction if the vehicle is making one trip, or is making two trips where passengers can stay aboard. In the latter, the stop list shown on the bus will not contain the second trip while the bus is running on the first trip, and the timetable will have special indication that they are two different trips where the passenger can stay on board, rather than one single trip.

I guess this is your interpretation of the GTFS standard? As far as I know, the standard itself does not state anything of this. Can you point me to a quote from the standard that supports your view?

I have seen trips being split into several trips for several (valid IMO) reasons, none of them would affect what's shown on the stop list in the vehicle:

In this case, your GTFS-consuming app will show the customer to the fact that they are travelling on two trips, rather than one single trip. The customer will get confused when the apps tell you to have a stay-seated transfer when the vehicle is still operating on the same trip. If you then query the back end of the trip information, the information returned will not match what the customer sees on the vehicle, so this is, again, a distortion of the reality.

* Split for agency change. This sometimes happens at the border between countries.

In such case, it is most likely that they are two different trips just happen to run through, as when the agencies are different, the passenger experience is different.

* Split for route type change. There are some cases where a regional express train ("RE") is changed to an intercity train ("IC") but it's still the same physical vehicle.

Using standard GTFS route types, an RE train and an IC train are both trains, although they can be separated using Google's extended route types. In this case, the train trip is known as a both IC and an RE train, so both should be shown on the route number.

* Split for trips running in circles. The next circle often is a new trip. Here, the stop list is "infinite" (scrolling through over again, there should be no "end" and "start").

I have some examples of circular trips where the passenger can remain on board for another circle, but on those trips

• There is one official terminus, shown on the route map, where all timetables start and end at that terminus
• The headsign always shows that terminus
• The terminus is treated differently from en-route stops, in particular, the headway is regulated only at the terminus, and it is the only stop on the circle where vehicles can be taken out of service or switch to another route
• There is a special announcement on board that the vehicle will start another circle (if appropriate) upon reaching the terminus

In such case, it is appropriate that the information is shown to the passenger that they are travelling on two different trips of the circle with a stay-seated transfer, such that they won't get surprised that the vehicle enters the terminus.

This needs to be clearly distinct from a service which goes round and round and round without a terminus, which the stop list should be listed all over and over and over until the vehicle is taken out of the service.

* Split for train number change (`trip_name_short`)

In China, there are many trains where the train number change en-route. However, on all passenger information systems, all the applicable train numbers are used simultaneously with the stop list shown from the actual origin to the actual destination regardless of how many train numbers it uses, so it is effectively one trip.

The customer will not notice any of those and can just "stay seated".

I have listed some examples above where a customer can just stay seated but clearly travelling on two different trips, which is the literal meaning of stay seated transfers. Stay seated on the same trip through an intermediate stop, and stay seated on two different trips through a terminus, are very different things.

[VillePihlava]

As the original author of #466, something that raised a lot of discussion in that issue was whether to use a stop_times.txt based approach or whether to just add a cars_allowed field to trips.txt.

Although the addition in this PR has a broader scope, would a cars_allowed, bikes_allowed approach be preferrable?

The comment in this PR by @felixguendling caught my eye:

I don't have an opinion about the proposal as it is.
Just factually, this is wrong:

The current GTFS specification cannot express if a bike can only be carried on part of the trip

It is possible to split a trip into two trips where one part has bikes allowed an the other part does not have bikes allowed. Then after that just rejoin the trip using a stay seated transfer or block_id and you have exactly what you need. So just to achieve this behavior (bike allowed for parts of the trip or specific times) the GTFS standard does not have to change.

MOTIS for example supports this information for the search option to travel with your bike in public transport.

If there is interest, I could continue with the original issue to add such an addition to GTFS.

[felixguendling]

If there is interest, I could continue with the original issue to add such an addition to GTFS.

Your initial proposal of having a simple cars_allowed similar to bikes_allowed would be just one more column (with known semantics). This has advantages:

• cars_allowed is probably uncontroversial (as it's just mirroring bikes_allowed).
• For data consumers and producers (and end customers) the added value can be realized fast and with minimal overhead (as everyone who implemented bikes_allowed can just use the same solution to implement cars_allowed).

Since this proposal (boarding permissions) found a way to deal with the "old" columns by making them "Conditionally Forbidden", I would guess there's no problem to deal with cars_allowed in the same way.

[github-actions]

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

[github-actions]

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

[miklcct]

keep open

[miklcct]

We will soon submit a bid for funding with this proposal so we can deliver it in a real-world setting.