Open VillePihlava opened 4 months ago
@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! 🚀
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.
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.
cars_allowed
field to trips.txt as suggested by @VillePihlava in https://github.com/google/transit/issues/466#issue-2320706816.cars_allowed
to stops.txt as suggested by @VillePihlava in https://github.com/google/transit/issues/466#issuecomment-2138983622. 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.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.
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.
The same improvement should also be applied to bike and wheelchair as well
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.
Shall we then deprecate the current bikes_allowed
and wheelchair_allowed
field? Because bike support can be any of the following:
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.
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.
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.
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?
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.
@skinkie can you give/link to the file formats you are referencing? I would be interested in looking at them
@VillePihlava HAFAS TEXT (Hacon/Siemens Mobility) is the format that generally everyone would reference to as the format having the best in attribute descriptions.
https://opentransportdata.swiss/en/cookbook/hafas-rohdaten-format-hrdf/ https://opentransportdata.swiss/wp-content/uploads/2016/10/hrdf.pdf
Within NeTEx the concept of describing that some part of a trip defined by a start end end stop is a JourneyPart, it can also be used as a restriction on facilities, it that case it would be a RestrictedServiceFacilitySetRef, again allowing a From/To.
Especially for cars it is important that boarding and alighting (pickup/dropoff) is well specified.
In the case of trains: It is also possible that you can't board without having a bicycle, motorcycle or car/truck. E.g. BLS Kandersteg-Lötschberg. So it is not only allowed, but mandated as well.
Maybe the stop_times.txt
approach would be best. In this case, how should possible changes to bikes and wheelchairs be done? The amendment process documentation says that backwards compatibility is important. Having 2 ways of specifying something also doesn't seem like a good idea.
https://gtfs.org/schedule/process/#changes-to-the-spec-should-be-backwards-compatible:
When adding features to the specification, we want to avoid making changes that will make existing feeds invalid. We don't want to create more work for existing feed publishers until they want to add capabilities to their feeds. Also, whenever possible, we want existing parsers to be able to continue to read the older parts of newer feeds.
In addition to @skinkie Transmodel/NeTEx would see this partially also as ACCESS MODE. an ACCESS MODE is defined on a SITE (stop_times is not a bad choice there.
definition: PERSONAL MODE used to access or leave the public transport system (e.g., by foot, by private bicycle, by private car).
There is a lot of good discussion in this issue now, for example, going forward with the stop_times.txt
approach seems like a good idea.
However, as I have not previously contributed to the GTFS standard, the question on deprecation and having two ways of specifying the same thing is an open question for me at least (see the comment from @leonardehrenfried). Before drafting a more thorough proposal it would be nice to know how to deal with a situation like this. I can think of at least three ways:
bikes_allowed
) should be removed to avoid two ways of specifying the same thing.cars_allowed
in a similar way to bikes_allowed
. The other requirements that have come up in this thread could be discussed in another issue (and be implemented through many enum values for example).What would be the best approach? I'm not sure who to direct this question towards. @eliasmbd would you know about this?
@VillePihlava I can provide some points from governance perspective:
So far, GTFS has maintained strict backward compatibility for producers. As far as I know, there has been no historical precedent for deprecating existing fields. Admittedly, once there is consensus within the community, changing this backward compatibility is not entirely impossible. However, I personally believe that convincing the community to break backward compatibility through this change would be very difficult.
GTFS does have precedents for having two ways of specifying the same thing, such as routes.network_id
and [networks.txt
+ route_networks.txt
] https://github.com/google/transit/pull/405. This does not break backward compatibility for producers, as existing data remains valid. As @leonardehrenfried mentioned, the advocate still have to convince the community that it is worth doing this in this case.
This thread already contains some ideas. One possible approach is to first propose including all the needs mentioned in this thread. If the community cannot reach a consensus on the entire proposal, you can modify the scope to vote only on the parts that are likely to achieve consensus. However, you can decide the scope of the proposal yourself for sure :).
Thanks for the answers! I'll start working on a more thorough proposal that roughly follows the 2. of the ways I mentioned
After thinking about this I came up with this approach:
The solution would be to add one field to trips.txt
and to have a more in-depth way of specifying boarding/alighting with things/vehicles in stop_times.txt
. A new file, that could be called boarding_permissions.txt
, would be added to accommodate all necessary detail. This file would be referenced in stop_times.txt
.
The information referenced in stop_times.txt
would take preference over the information in trips.txt
. A new issue should be created to discuss the requirements for the stop_times.txt
and boarding_permissions.txt
files. The changes to trips.txt
could be separated from the other changes and as the original title of this issue suggests the changes to trips.txt
could be discussed here while the other changes could be discussed in the other issue.
trips.txt
Field Name | Type | Presence | Description |
---|---|---|---|
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. |
boarding_permissions.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Unique ID | Required | Identifies a boarding_permission. |
car_mode |
Enum | Optional | Indicates in which way cars can be taken on board. Valid options should be discussed in detail in another issue. |
bike_mode |
Enum | Optional | Indicates in which way bikes can be taken on board. Valid options should be discussed in detail in another issue. |
wheelchair_mode |
Enum | Optional | Indicates in which way wheelchairs can be taken on board. Valid options should be discussed in detail in another issue. |
stop_times.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Foreign ID referencing boarding_permissions.boarding_permission_id |
Optional | Identifies a boarding_permission. |
car_mode
, bike_mode
and wheelchair_mode
. However, should motorcycles and scooters also have enum values? Should they instead be separate? Can they be considered as cars?trips.txt
for motorcycles and scooters, for example?bikes_allowed
in the trips.txt
file for accommodating all possible cases? I think changes to existing enum values are usually not done though, although I could be wrong.@miklcct you listed a lot of things that you wanted to see changed. What do you think of the approach I wrote down in the previous comment?
The boarding permission
should consist of vehicle, trip_id, stop_sequence, pick up permission, drop off permission and carriage permission.
The vehicle is an enum which can be a bike, wheelchair, car, motorcycle, etc.
Carriage permission means if the vehicle can remain on board after departing the stop specified.
For frequency-based trips, a start time and end time can also be specified. Entries with start and end time override entries without.
For example, a London Underground Jubilee line frequency-based service in regard of bike carriage can be specified as Bike, Stanmore, yes (pick up), (drop off), yes (carriage) Bike, Stanmore, no, no, no, 07:30-09:30 Bike, Stanmore, no, no, no, 16:00-19:00 Repeat until Finchley Road Bike, Swiss Cottage, no, no, no (no times here as always banned) Repeat until North Greenwich Bike, Canning Town, yes, yes, yes Bike, Canning Town, no, no, no, 07:30-09:30 Bike, Canning Town, no, no, no, 16:00-19:00 Repeat until Stratford
Similarly, an SWR peak train listed in blue in the timetable can be specified as Bike, Waterloo, yes, , yes Bike, Clapham Junction, no, no, yes Bike, Woking, no, no, yes Bike, Basingstoke, yes, yes, yes Repeat until the destination
To denote that bikes can be carried through intermediate stations but not boarding / alighting there
I like the suggestions by @miklcct. The vehicle enum is a much better choice than having enums for each vehicle. I modeled the modified approach in this comment. I think the trip_id
and stop_sequence
additions would not be necessary in boarding_permissions.txt
because they are present in stop_times.txt
which is linked to boarding_permissions.txt
with the boarding_permission_id
. I also added reservation_required
and vehicle_mandatory
enums. Again, the information referenced in stop_times.txt
would take preference over the information in trips.txt
.
What do you think of this @miklcct? Do you want to create the new issue for discussing this or should I? At least at the moment, the additions to trips.txt
would be sufficient for my purposes and I would not be actively working on the rest, although I can provide feedback.
If splitting the issue (trips.txt
in one issue and stop_times.txt
+ boarding_permissions.txt
in one issue) is fine, would the next step for the changes to trips.txt
be to create a pr @eliasmbd (https://gtfs.org/schedule/process/#specification-amendment-process)?
trips.txt
Field Name | Type | Presence | Description |
---|---|---|---|
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. |
boarding_permissions.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Unique ID | Required | Identifies a boarding_permission. |
vehicle |
Enum | Required | Identifies a vehicle. 0 - Bike. 1 - Car. 2 - Wheelchair. 3 - Motorcycle. |
pickup_permission |
Enum | Optional | Indicates whether pick up is possible for the specified vehicle. 0 or empty - false. 1 - true. |
drop_off_permission |
Enum | Optional | Indicates whether drop off is possible for the specified vehicle. 0 or empty - false. 1 - true. |
carriage_permission |
Enum | Optional | Indicates whether the vehicle can remain on board after departing the specified stop. 0 or empty - false. 1 - true. |
reservation_required |
Enum | Optional | Indicates whether a reservation is required. 0 or empty - false. 1 - true. |
vehicle_mandatory |
Enum | Optional | Indicates whether a vehicle is required on board. 0 or empty - false. 1 - true. |
start_time |
Time | Conditionally Required | Only used with frequency-based trips. Defines the beginning of a timeframe for when this permission is valid. Required if end_time is defined, forbidden otherwise. |
end_time |
Time | Conditionally Required | Only used with frequency-based trips. Defines the end of a timeframe for when this permission is valid. Required if start_time is defined, forbidden otherwise. |
stop_times.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Foreign ID referencing boarding_permissions.boarding_permission_id |
Optional | Identifies a boarding_permission. |
@VillePihlava Thanks for reaching out and I am glad you are at the point of publishing your PR!
Quoting the Process, I would focus on points 1 -3 first:
- Create a git branch with update of all relevant parts of protocol definition, specification and documentation files (except for translations).
- Create pull request on https://github.com/google/transit. Pull request must contain an extended description of the patch. The creator of the pull request becomes the advocate.
- Once pull request is registered, it must be announced by its advocate in the GTFS Changes mailing list, including a link to the pull request. Once announced, the pull request is considered a proposal. The pull request should also be edited to contain a link to the Google Groups announcement so they can easily be cross-referenced.
- Since the advocate is a contributor, they must sign the Contributor License Agreement before pull request can be accepted.
It is expected that the GTFS producer(s) include the change in a public-facing GTFS feed and provide a link to that data within the pull request comments, and that the GTFS consumer(s) provides a link in the pull request comments to an application that is utilizing the change in a non-trivial manner (i.e, it is supporting new or improved functionality).
I would say that reservation required should not be a separate field pick up permission, drop off permission, and carriage permission should have a enum value for reservation required.
For example, 0 - not allowed 1 - allowed without booking 2 - prior booking required
For example, if a wheelchair can be carried on the tube, but prior booking is needed to get on at certain stations, the carriage permission will be 1 and the pick up permission will be 2. In contrast, if a bike reservation is required for part of the trip, but you don't need to inform staff to open the bike storage, carriage permission will be 2 and pick up permission will be 1.
Also I need clarification of vehicle_mandatory
. Is it mandatory to board, to carry or to alight with a vehicle at the stop? It is possible for someone to travel on a service which is not vehicle mandatory, but some stops may be restricted to boarding / alighting with a mandatory car.
If both a bike and a car are listed as mandatory, is carrying any of a bike or a car enough to use the service? In this case, should we disallow the spec to have different values at the same service stop?
Those are good points. @miklcct how do you feel about splitting the issue in the way I mentioned in my previous comment.
What do you think of this @miklcct? Do you want to create the new issue for discussing this or should I? At least at the moment, the additions to trips.txt would be sufficient for my purposes and I would not be actively working on the rest, although I can provide feedback.
I don't think adding car_allowed
is a good idea and we should deprecate the existing field.
We can just add boarding_permission_id
and migrate the existing supported functionalities now while adding car and other vehicle support in your PR, and defer the discussion of mandatory / reservation later.
There was discussion about deprecation in this thread. The conclusion was that essentially deprecation wasn't done in GTFS. However, having 2 ways of specifying things was fine. Because of this, I think the trips.txt
in one issue and stop_times.txt
+ boarding_permissions.txt
in one issue approach would be good.
The trips.txt
solution is fine for more simple use cases (for me this would be sufficient). For a more detailed way of specifying things, stop_times.txt
+ boarding_permissions.txt
is good.
There was discussion about deprecation in this thread. The conclusion was that essentially deprecation wasn't done in GTFS.
@VillePihlava Correct this is what the guiding principles say about backward compatibility:
When adding features to the specification, we want to avoid making changes that will make existing feeds invalid. We don't want to create more work for existing feed publishers until they want to add capabilities to their feeds. Also, whenever possible, we want existing parsers to be able to continue to read the older parts of newer feeds.
There was discussion about deprecation in this thread. The conclusion was that essentially deprecation wasn't done in GTFS. However, having 2 ways of specifying things was fine. Because of this, I think the
trips.txt
in one issue andstop_times.txt
+boarding_permissions.txt
in one issue approach would be good.The
trips.txt
solution is fine for more simple use cases (for me this would be sufficient). For a more detailed way of specifying things,stop_times.txt
+boarding_permissions.txt
is good.
So leave the existing fields alone. If we open a precedent of adding cars_allowed
into trips.txt
, people will then request adding fields of motorcycles_allowed
, scooters_allowed
, etc. ad infinitum.
So leave the existing fields alone. If we open a precedent of adding
cars_allowed
intotrips.txt
, people will then request adding fields ofmotorcycles_allowed
,scooters_allowed
, etc. ad infinitum.
So would you want to go for a standardised attribute based format, where attributes can be assigned to (parts of) trips?
So leave the existing fields alone. If we open a precedent of adding cars_allowed into trips.txt, people will then request adding fields of motorcycles_allowed, scooters_allowed, etc. ad infinitum.
In addition to bikes_allowed
also wheelchair_accessible
exists. It works in the same way. So there are already two different vehicles listed https://gtfs.org/schedule/reference/#tripstxt. In my opinion, adding one more is fine. However, this would of course require votes from other people as well.
In addition to
bikes_allowed
alsowheelchair_accessible
exists. It works in the same way. So there are already two different vehicles listed https://gtfs.org/schedule/reference/#tripstxt. In my opinion, adding one more is fine. However, this would of course require votes from other people as well.
This is a fallacy. Reasoning @miklcct made sense.
In addition to
bikes_allowed
alsowheelchair_accessible
exists. It works in the same way. So there are already two different vehicles listed https://gtfs.org/schedule/reference/#tripstxt. In my opinion, adding one more is fine. However, this would of course require votes from other people as well.This is a fallacy. Reasoning @miklcct made sense.
OK, so my recommendation is to
boarding_permission_id
into stop_times.txt
boarding_permissions.txt
, while deferring reservation / mandatory into a later proposal.So here is what I would like the proposal of @VillePihlava to be
trips.txt
Field Name | Type | Presence | Description |
---|---|---|---|
bikes_allowed |
Enum | Forbidden if boarding_permission_id is defined for any stop time of the trip, optional otherwise |
no change |
wheelchair_accessible |
Enum | Forbidden if boarding_permission_id is defined for any stop time of the trip, optional otherwise |
no change |
boarding_permissions.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Unique ID | Required | Identifies a boarding_permission. |
vehicle |
Enum | Required | Identifies a vehicle. 0 - Bike. 1 - Car. 2 - Wheelchair. 3 - Motorcycle. |
pickup_permission |
Enum | Optional | Indicates whether pick up is possible for the specified vehicle. 0 or empty - false. 1 - true. |
drop_off_permission |
Enum | Optional | Indicates whether drop off is possible for the specified vehicle. 0 or empty - false. 1 - true. |
carriage_permission |
Enum | Optional | Indicates whether the vehicle can remain on board after departing the specified stop. 0 or empty - false. 1 - true. |
start_time |
Time | Conditionally Required | Only used with frequency-based trips. Defines the beginning of a timeframe for when this permission is valid. Required if end_time is defined, forbidden otherwise. |
end_time |
Time | Conditionally Required | Only used with frequency-based trips. Defines the end of a timeframe for when this permission is valid. Required if start_time is defined, forbidden otherwise. |
stop_times.txt
Field Name | Type | Presence | Description |
---|---|---|---|
boarding_permission_id |
Foreign ID referencing boarding_permissions.boarding_permission_id |
Optional Identifies a boarding_permission. |
At least at the moment, for this requirement I would at some point be able to find a consumer/producer for the trips.txt
cars_allowed
changes.
- Then you will need to have one consumer and one producer implement the changes with proof of implementation.
Because the direction in this issue seems to be with not adding this I will not be pushing for the changes. The changes to stop_times.txt
+ boarding_permissions.txt
seem like a good addition though. So at the moment the contents of this issue need to find another person to work on this actively.
Having access to this feature in GTFS (and OTP) would be great for Washington State in the US, where we have a state-operated ferry system.
While the simplicity and utility of adding cars_allowed
to trips.txt
seems fine to me and easiest for producers, I understand the arguments put forth against it and I think that @miklcct 's alternative approach is also reasonably simple and fulfills the need. I would be happy to make a PR in line with that suggestion, and try to work with our ferries program to plan on adding the appropriate boarding_permissions.txt
file to WSDOT's GTFS, if there's a plausible consumer who'd be ready to use the data.
@VillePihlava @leonardehrenfried would it be reasonable to alter the OTP implementation to use boarding_permissions.txt
?
OTP will implement whatever is decided in the spec process. Having to change the implementation is the cost of using an experimental feature.
In other words: If the gtfs community thinks that boarding_permission is the way to go, OTP will follow suit.
As concluded in this thread, the boarding_permissions.txt
changes would be a nice addition. The arguments in this thread centered around adding changes to trips.txt
+ boarding_permissions.txt
or just adding boarding_permissions.txt
alone. If you have the need for it, I suggest you go for it.
If you decide to implement these changes, I suggest you also create an issue for this in OTP.
Having said that, it would be nice to have a shorthand version of saying that cars are allowed to board and alight at every stop of the trip. Basically an equivalent way of saying cars_allowed=true.
I think that this is a very common use case which justifies a bit of special handling.
Also, in some cases having information for vehicle boarding related to stops alone can be useful (as opposed to stop times). For example, if real time information for trips with vehicle transportation capabilities is provided, stops that are not accessible by car in the graph in OTP can not be used for these trips without adding info to the stops (car linking is only done for stops that need it).
This use case might not come up often, but if this issue is active once again, this could be considered as well.
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:
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