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

[skinkie]

@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.

[ue71603]

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.

[VillePihlava]

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.

[ue71603]

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).

[VillePihlava]

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:

1. Implement the new features while taking into account all of the requirements that have come up in this issue.
   The old ways of specifying things (e.g. bikes_allowed) should be removed to avoid two ways of specifying the same thing.
2. Implement the new features while taking into account all of the requirements that have come up in this issue.
   The old ways of specifying things should be left as is to ensure backwards compatibility.
3. Implement 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?

[tzujenchanmbd]

@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] [GTFS-Fares v2] Add networks.txt & route_networks.txt #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 :).

[VillePihlava]

Thanks for the answers! I'll start working on a more thorough proposal that roughly follows the 2. of the ways I mentioned

[VillePihlava]

After thinking about this I came up with this approach:

Summary

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.

Non-complete list of requirements based on the discussion in this issue

• Ferries need to have information on whether a car can be on board
• Different types of things/vehicles can be taken on board transport (e.g. cars, bikes, motorcycles, wheelchairs)
• Different stops on a trip can have different information for boarding/alighting with a thing/vehicle.
• There can be interesting edge cases with things/vehicles (e.g. bicycle, motorcycle or car/truck is mandatory on some types of transport)
• Things/vehicles on transportation can be walk-on, reservation-based, (require notifying the driver?)

Additions to 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.

New file 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.

Additions to stop_times.txt

Field Name	Type	Presence	Description
boarding_permission_id	Foreign ID referencing boarding_permissions.boarding_permission_id	Optional	Identifies a boarding_permission.

Non-complete list of possible issues/things that need to be considered

• Should boarding permissions be different for boarding and alighting?
• What enum values are possible for accomodating all possibilities? For example, I can think of these modes for bikes:
  • No bike information
  • Vehicle can accommodate at least one bicycle
  • No bicycles allowed
  • Bicycles mandatory
  • Vehicle can accommodate bicycle but requires reservation
  • Bicycles mandatory and requires reservation
• How should different types of things/vehicles be separated? In this comment I separate 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?
• Should more fields be added to trips.txt for motorcycles and scooters, for example?
• Should more enum values be added to, 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.

[VillePihlava]

@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?

[miklcct]

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

[VillePihlava]

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)?

Additions to 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.

New file 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.

Additions to stop_times.txt

Field Name	Type	Presence	Description
boarding_permission_id	Foreign ID referencing boarding_permissions.boarding_permission_id	Optional	Identifies a boarding_permission.

[eliasmbd]

@VillePihlava Thanks for reaching out and I am glad you are at the point of publishing your PR!

Now:

Quoting the Process, I would focus on points 1 -3 first:

1. Create a git branch
2. Create a PR
3. Post on GTFS Changes
4. Hold discussion for 7 days

1. Create a git branch with update of all relevant parts of protocol definition, specification and documentation files (except for translations).
2. 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.
3. 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.

Next steps:

1. After this, a minimum 7 days discussion period is held. Usually changes like these will have a longer discussion.
2. Then you will need to have one consumer and one producer implement the changes with proof of implementation.

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).

3. Then you can call a vote that will last for 14 days. For the vote to pass, you need a minimum of 3 positive votes. A single negative vote can veto the proposal.
4. The proposal can be merged into the specification.

[miklcct]

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.

[miklcct]

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?

[VillePihlava]

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.

[miklcct]

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.

[VillePihlava]

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.

[eliasmbd]

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.

[miklcct]

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.

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.

[skinkie]

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 would you want to go for a standardised attribute based format, where attributes can be assigned to (parts of) trips?

[VillePihlava]

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.

[skinkie]

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.

This is a fallacy. Reasoning @miklcct made sense.

[miklcct]

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.

This is a fallacy. Reasoning @miklcct made sense.

OK, so my recommendation is to

• leave the existing two fields alone because we can't break compatibility
• add a boarding_permission_id into stop_times.txt
• add a simple yes / no in boarding_permissions.txt, while deferring reservation / mandatory into a later proposal.

So here is what I would like the proposal of @VillePihlava to be

Changes to 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

New file 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.

Additions to 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]

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.

2. 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.

[tsherlockcraig]

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?

[leonardehrenfried]

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.

[VillePihlava]

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.

[leonardehrenfried]

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.

[VillePihlava]

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.