Add cars_allowed field to trips.txt

[VillePihlava]

Summary

This PR proposes adding a cars_allowed field to trips.txt. There was a lot of discussion in issue #466 about how to add car information for ferries to GTFS. The discussion was centered around whether to use an approach with stop_times.txt or trips.txt. A recent PR #533 related to the topic generated discussion about bikes_allowed.

Because Digitransit will soon use the cars_allowed field in production through OTP and because of the discussion in #533, I thought that it would be a good idea to create this proposal. It would be interesting to see if there is interest in this.

Proposal

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:

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.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1210563235088114

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[leonardehrenfried]

We have discussed the more complicated stop_times-based approach for a while but no producer has actually published any data for it or even just vaguely committed to do so.

For this reason alone I'm leaning towards @VillePihlava's proposal.

[felixguendling]

Thank you for the proposal! I think this is something we can implement quite quickly in MOTIS as it's just mirroring bikes_allowed. I don't think that a stop-based approach is necessary because in the rare case that cars are only allowed on parts of the trip, the trip can be split and rejoined with block_id / transfer type 4 in order to achieve the same result.

[miklcct]

Thank you for the proposal! I think this is something we can implement quite quickly in MOTIS as it's just mirroring bikes_allowed. I don't think that a stop-based approach is necessary because in the rare case that cars are only allowed on parts of the trip, the trip can be split and rejoined with block_id / transfer type 4 in order to achieve the same result.

Please do not do this in your dataset as it will just confuse riders on the departure boards and stop lists shown on the app.

block_id is a field solely used for operational purpose. It does nothing to the rider's experience. It is very common for two trips on the same block, where customers can't continue on the vehicle even if the final stop of the incoming trip and the initial stop of the outgoing trip is the same, and have to alight and reboard the same vehicle.

transfer_type = 4 will give the rider an impression that they are actually travelling on two trips. The most common example is that the bus runs on one route, then through runs into another route where the riders can stay on board, or a circular tram service where there is a single terminus on the loop and where riders can stay on the tram.

[felixguendling]

block_id is a field solely used for operational purpose

I guess you have a misunderstanding here. Please check the landing page of gtfs.org where it says:

GTFS is a community-driven open standard for rider-facing transit information

So by definition, all information is purely rider-facing. There are other standards for operational data.

Your interpretation is not backed up by anything in the GTFS standard and would artificially limit the expressiveness of the standard without a good reason.

[miklcct]

block_id is a field solely used for operational purpose

I guess you have a misunderstanding here. Please check the landing page of gtfs.org where it says:

GTFS is a community-driven open standard for rider-facing transit information

So by definition, all information is purely rider-facing. There are other standards for operational data.

Your interpretation is not backed up by anything in the GTFS standard and would artificially limit the expressiveness of the standard without a good reason.

Sorry I may have a misunderstanding, but how is the block id relevant to the fact that the rider can stay on board?

The block id, when used for passenger information purpose, can be used for a passenger to guess if delays will be propagated through trips, or to follow a vehicle throughout the day, but it does nothing to tell if a transfer must be made by alighting or boarding the same vehicle, or by staying seated on the vehicle (which is what transfer_type = 4 will do, but it is still a transfer between two distinct trips, not applicable to the case when a trip has different properties throughout its journey).

[gcamp]

@miklcct Read the first post of #303 to get a history of block_id, it used to represent in-seat transfer and still is used like this in a lot of places

[VillePihlava]

I'm working towards signing the CLA and making the post to gtfs-changes@googlegroups.com. I currently don't have a google account from the company I work at, which makes things difficult :)

[felixguendling]

We added support for cars_allowed to MOTIS. The feature should be available soon on transitous.org.

This allows the usage of ferries and trains where cars can be transported.

[leonardehrenfried]

Does Switzerland already include this in their data?

[felixguendling]

Does Switzerland already include this in their data?

No. MOTIS supports setting the default value in case the attribute is not available. So we set the default value for route type ship to true to be able to test how it works.

There is a problem with this attribute in Switzerland: as I understand it (didn't ask an expert though) there are some trains that transport cars and people but there are also those that do only transport cars (people stay inside the car). So if you don't have a car, you can't use the train. Including these trains in the dataset can be misleading because the train would also show up without car search. An enum value would make sense to distinguish between:

• trains that transport people
• trains that transport cars (not people without cars)
• trains that transport cars and people (without cars)

[miklcct]

Does Switzerland already include this in their data?

No. MOTIS supports setting the default value in case the attribute is not available. So we set the default value for route type ship to true to be able to test how it works.

There is a problem with this attribute in Switzerland: as I understand it (didn't ask an expert though) there are some trains that transport cars and people but there are also those that do only transport cars (people stay inside the car). So if you don't have a car, you can't use the train. Including these trains in the dataset can be misleading because the train would also show up without car search. An enum value would make sense to distinguish between:

• trains that transport people
• trains that transport cars (not people without cars)
• trains that transport cars and people (without cars)

This is the problem I intend to solve in #533 and I am looking for a sponsor for that.

cars_allowed can still be used for the first and the last case though.

[felixguendling]

I think this proposal could easily be extended to cover this edge case by adding one more enum value:

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.
3 - Only cars allowed (no people transport)

[felixguendling]

But since additional enum values can be added later on, this edge case (of trains that only transport cars) should not block merging this PR. It provides value on its own by solving a lot of use cases where ferries and trains transport people and cars.

[miklcct]

I think this proposal could easily be extended to cover this edge case by adding one more enum value:

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. 3 - Only cars allowed (no people transport)

This new value makes the proposal not backward compatible as consumers who don't process cars_allowed will then show journeys to passengers.

But since additional enum values can be added later on, this edge case (of trains that only transport cars) should not block merging this PR. It provides value on its own by solving a lot of use cases where ferries and trains transport people and cars.

I will not block this PR but I will not hesitate to block any PR which will result in the Silvertown Cycle Shuttle shown to passengers.

[ue71603]

We don't have it in GTFS for now, but we do have car transporting rail and ferries in HRDF.
Our OJP implementation can use it.

[VillePihlava]

I finally got the CLA signed, so this can finally move forwards!

[VillePihlava]

@felixguendling do I understand correctly that you are not interested in adding your suggestion in this PR, but possibly doing it at a later date?

[felixguendling]

I am open for both options - also for supporting the "only cars" option in MOTIS. But I think since @miklcct (and maybe others as well?) is strictly opposing my suggestion, we should merge it now as it is and not delay by opening a completely new discussion about backward compatibility of GTFS in general.

Adding the enum value after a discussion about "how backward compatible does GTFS have to be" (in general and in this particular case) is still possible.

[skinkie]

@felixguendling in favor of your suggestion. This is the forward thinking we require.

[VillePihlava]

I am open for both options - also for supporting the "only cars" option in MOTIS. But I think since @miklcct (and maybe others as well?) is strictly opposing my suggestion, we should merge it now as it is and not delay by opening a completely new discussion about backward compatibility of GTFS in general.

I also don't have a strong preference on whether to have the discussion here. I guess as it can be discussed as a separate topic, maybe it does make sense to separate the 3 - Only cars allowed (no people transport) case and related topics into their own discussion/suggestion.

[VillePihlava]

Because this PR has been open for a while and the discussion seems to have stopped, I will call for a vote soon after the 7 day waiting period has ended unless new relevant discussion comes up.

GTFS producer: https://mobility.mobility-database.fintraffic.fi/static/ferries_cars.zip
GTFS consumer: https://opas.matka.fi/

For example, if the car transport mode is selected in settings (off by default) this route should provide car ferry results: https://opas.matka.fi/reitti/Valittu%20sijainti%3A%3A60.212713338813785%2C22.073010998873375/Lillm%C3%A4l%C3%B6n%20kyl%C3%A4tie%206%2C%20Parainen%3A%3A60.24200644651938%2C22.171054368352866?locale=en&setTime=true&time=1748422800

[VillePihlava]

I'm calling for a vote for the proposal described in this PR.

GTFS producer: https://mobility.mobility-database.fintraffic.fi/static/ferries_cars.zip
GTFS consumer: https://opas.matka.fi/, Transitous

The voting ends on June 11th at 23:59:59 UTC.

[felixguendling]

+1 for MOTIS + Transitous (can also be listed as consumer)

[leonardehrenfried]

+1 OpenTripPlanner

[VillePihlava]

The voting period ended yesterday. According to the rules 3 votes are required (and no votes against). Based on this rule, the vote did not pass.

It could be argued whether MOTIS + Transitous counts as 1 or 2 votes. I assume it counts as one vote. Also, the organization I'm doing this for, Digitransit (https://digitransit.fi/), has a pretty wide scope of related organizations from Finland. Depending on whether every single related organization is counted as one (and therefore not eligible to vote as the advocating organization) or many, this would also affect the vote.

In any case, it looks like another vote would be needed to get this to pass. @eliasmbd can you clarify what counts as an individual organization? Based on the reply I would know how to proceed with this.

[eliasmbd]

The voting period ended yesterday. According to the rules 3 votes are required (and no votes against). Based on this rule, the vote did not pass.

It could be argued whether MOTIS + Transitous counts as 1 or 2 votes. I assume it counts as one vote. Also, the organization I'm doing this for, Digitransit (https://digitransit.fi/), has a pretty wide scope of related organizations from Finland. Depending on whether every single related organization is counted as one (and therefore not eligible to vote as the advocating organization) or many, this would also affect the vote.

In any case, it looks like another vote would be needed to get this to pass. @eliasmbd can you clarify what counts as an individual organization? Based on the reply I would know how to proceed with this.

@VillePihlava Thanks for raising this. Under the current governance model, there are no formal provisions for vote delegation or representation. This is one of the areas we’re aiming to clarify in the new governance proposal.

Based on precedent, this vote unfortunately does not pass due to insufficient participation.

I recommend re-launching the vote and reaching out directly to Transitous to ensure they submit an official vote using their own GitHub account.

Also, please note that the Advocate organization cannot vote on its own proposal. If you're acting as the Advocate on behalf of Digitransit, then Digitransit cannot cast a vote. However, other organizations or agencies affiliated with Digitransit are welcome to vote, and their votes will be counted.

Thank you for reaching and good luck moving forward :)

[ue71603]

+1
Even if the vote is finished: SBB does support it as well. If this helps in your vote count.

[VillePihlava]

I'm calling for a second vote for the proposal described in this PR.

GTFS producer: https://mobility.mobility-database.fintraffic.fi/static/ferries_cars.zip
GTFS consumer: https://matka.fintraffic.fi/, Transitous

The voting ends on June 26th at 23:59:59 UTC.

[felixguendling]

+1 MOTIS

[ue71603]

+1 SBB

[leonardehrenfried]

+1 OpenTripPlanner

[vkrause]

+1 Transitous

[skinkie]

+1 OpenGeo

[Transnnovation-GTFSMgr]

+1 National RTAP (we have ferries in our rural areas that offer car transport) Thank you for reopening this needed feature

[laurentg]

+1 Mecatran. We work with several agencies having ferry which can accommodate car on board where this addition could be useful (especially for one ferry route where two boats operate the same end-points, one with car, one w/o).

[westontrillium]

+1 Trillium

[tsherlockcraig]

+1 WSDOT Public Transportation Division

[VillePihlava]

The voting period ended on June 26th at 23:59:59 UTC.

The result is:
+1 MOTIS
+1 SBB
+1 OpenTripPlanner
+1 Transitous
+1 OpenGeo
+1 National RTAP
+1 Mecatran
+1 Trillium
+1 WSDOT Public Transportation Division

The vote ended with 9 votes in favor and 0 against. Thank you for participating in this PR and the original issue!

[VillePihlava]

I think the next steps for improving information related to cars consist of the following:

• The stop_times.txt based approach discussed in the original issue (Add cars_allowed field to trips.txt #466) would allow for more advanced use cases. There is currently ongoing work related to this in a PR Introduce boarding permissions to specify the carriage of vehicles at per-stop granularity #533.
• Getting information on car boarding ramps (e.g. for ferry stops or train stations) would be useful. This could be handled through OSM or by an addition to stops.txt.
• @felixguendling wanted to extend cars_allowed in trips.txt to allow for more uses cases.

[eliasmbd]

The voting period ended on June 26th at 23:59:59 UTC.

The result is: +1 MOTIS +1 SBB +1 OpenTripPlanner +1 Transitous +1 OpenGeo +1 National RTAP +1 Mecatran +1 Trillium +1 WSDOT Public Transportation Division

The vote ended with 9 votes in favor and 0 against. Thank you for participating in this PR and the original issue!

@VillePihlava Congratulations on getting your vote passed and getting a good diversity of contributors to support your proposal! We will review the changes and merge them to the specification in the coming days.