Add cars_allowed field to trips.txt

[VillePihlava]

Describe the problem

Ferries can have the possibility to have cars on board. For these ferries a field indicating whether cars are allowed would be useful.
In addition to car ferries, this can also apply to, for example, trains that can transport cars in a similar way.

Use cases

For example:

• To be able to distinguish car ferries.
• To be able to distinguish trains with car transportation capabilities.

Proposed solution

The trips.txt GTFS file (https://gtfs.org/schedule/reference/#tripstxt) contains the field bikes_allowed
which specifies whether bikes are allowed on board. For car ferries a similar field indicating whether cars are allowed should be added, for example:

cars_allowed - Enum - Optional
Indicates whether cars are allowed. Valid options are:

0 or empty - No car information for the trip.
1 - Vehicle being used on this particular trip can accommodate at least one car.
2 - No cars are allowed on this trip.

Additional information

No response

[eliasmbd]

@VillePihlava Thanks for bringing this up here! This is pretty relatable. When travelling in the Greek islands, some ferries allowed for cars and others didn't. Would have been great to have GTFS information on this.

Also, thank you for posting your first issue on google/transit! Your contributions are always appreciated! 🚀

[VillePihlava]

Another thing that has to be considered related to this is whether a stop has the accommodations for loading cars. The stops.txt GTFS file (https://gtfs.org/schedule/reference/#stopstxt) contains the wheelchair_boarding field. A similar field, such as car_boarding, should be added indicating whether a stop can get cars aboard ferries.

[optionsome]

Support for this information will be implemented in OpenTripPlanner and Fintraffic will produce the data (at least for the ferries in Finland and maybe for trains as well). We have discussed this addition and potential ways it can be modeled in GTFS with some fellow OTP developers.

First alternative we came up with consists of:

1. Add cars_allowed field to trips.txt as suggested by @VillePihlava in Add cars_allowed field to trips.txt #466 (comment).
2. Add cars_allowed to stops.txt as suggested by @VillePihlava in Add cars_allowed field to trips.txt #466 (comment). There are at least trains in Finland which only allow boarding/alighting the vehicle with a car on certain stops that the trains go through.
3. Add car_pickup_type and car_drop_off_type to stop_times.txt. This would be required if there are stops which only allow boarding/alighting vehicle with a car on some trips that allow cars, but not on all. This is somewhat similar to how headsigns can be modeled both in trips.txt and stop_times.txt. In most cases, using the trips.txt would be sufficient. I'm not aware of a real-life example where this would be necessary, but there probably is somewhere in the world.

In this alternative, it would be possible to first add support for only the 1. (and maybe 2.) and later on expand the spec to support for modeling the edge cases. However, if a consumer has only added support for 1., there might be potential issues if 2. and 3. are added later on.

Second alternative:

Create a new file which is meant for modelling where cars are allowed or even something more generic that is not limited to cars as in the future, we might want to model, for example, if scooters are allowed in vehicles. The benefit from this approach would be that only a small percentage of trips/stops allow car boarding and the addition of the new fields in existing files would increase the file sizes just to model these few cases where it's possible to board/alight with a car. The downside of this approach would be that it's slightly unusual compared to how most things in GTFS are currently modeled.

[miklcct]

The same improvement should also be applied to bike and wheelchair as well

[optionsome]

Should we also consider the need to book in advance vs ad hoc boarding with cars? This could be tackled with more enum values. However, this same problem is currently unsolved for bikes and wheelchairs.

[miklcct]

Shall we then deprecate the current bikes_allowed and wheelchair_allowed field? Because bike support can be any of the following:

• (Cars / bikes / motorcycles / wheelchairs) can be carried on (the whole of / part of / no section) of the service
• (Cars / bikes / motorcycles / wheelchairs) can be carried (walk-on / reservation)
• (Cars / bikes / motorcycles / wheelchairs) (can / cannot) (board / alight) at a station for a service which can carry then, where (no action / booking / notifying the driver) is needed to do so.

I think a new table is needed to properly encode all of the above.

I hope I can add support to my journey planner for taking bikes onto the tube / train but it is impossible to encode the rules in the current GTFS spec.

[VillePihlava]

I think the proposal of adding a new file/table mentioned by @optionsome and @miklcct would be a good idea. Designing the proposal for the new file requires some work though. I can look more into this in ~1 month if this issue hasn't progressed in other directions by then.

[leonardehrenfried]

I'm not aware of GTFS having two ways of specifying the same thing or using a deprecation strategy so I think you will have to convince the community that it's worth doing it.

[VillePihlava]

Based on the comment of @leonardehrenfried maybe the original approach would instead be better. If there is no deprecation strategy, maybe adding a new field with enough enum values would work?

[skinkie]

There are existing file formats that allow specifying this at the level of stop_times.txt, hence from sequence_n to sequence_m you are allowed to do something. The something is an attribute which is defined in another file.

[VillePihlava]

@skinkie can you give/link to the file formats you are referencing? I would be interested in looking at them