Required type of transportation at `routes` level may lack flexibility (multi-modal routes)

[barbagus]

The French regional railways TER operates both trains and buses on regular routes all over the country. They do publish a GTFS dataset daily: https://eu.ftp.opendatasoft.com/sncf/gtfs/export-ter-gtfs-last.zip

Some routes are designed to be operated with both trains and buses depending on the trip. You can download a human readable (PDF) schedule for such a route here (fr).
On the schedule table of the first page, the 12:44, 20:28 and 22:00 trips are clearly identified with a blue bus icon () which is defined in the legend as regular trip carried out with bus. I insist, those are not exceptions (that could be handled through GTFS-RT).

In the current GTFS specification, the "type of transportation" is a routes attribute and as such, cannot elegantly handle such use case.

Workarounds

There are few ways around this (that I can think about) but none of them are without drawback (technically or semantically).

1. Route duplication: create one route regrouping the "train trips" and one route the "bus trips". Somehow it is kind of what they are doing in the PDF version of their schedules. If you scroll down to the last pages you will notice that after the general "Route 19" schedule there is a specific section for a "Route 119" that only shows bus trips.
   They do that to precisely explain to the user where the bus stops are relative to the train station. Usually very close (few meters) but sometimes a bit further.
   However they still chose to include the bus trips in the general schedule of "Route 19" because semantically it is the same route and people might not bother scrolling down few pages to find the additional trips.

2. Loose use of routes.route_type (breaking the specs): that's actually what they implement in their GTFS dataset. That particular route is marked with a 2 / Rail value (because it is mostly carried out by trains I suppose) but they do encode the actual type of transportation within their stops.ID pattern. For instance, at the same station, they'd have a StopPoint:OCETrain TER-87182394 stop and a StopPoint:OCECar TER-87182394 stop. Then, as a GTFS consumer, one can infer the type of transportation by checking that all stops along the trip are *OCETrain* or *OCECar* (car means bus in French).
   Note: Although technically, having to read the whole stops sequence to infer transportation type is not ideal, I find it very interesting and somehow legitimate for the type of transportation to be a stops | location_type=0 attribute actually: after all, "train stops" and "bus stops" are very commonly distinguishable entities from the real world.

Suggestions for modification of the specs

• Implement a way to relate routes together, so in this example the "route duplication" workaround could be addressed properly.
• Implement type of transportation overriding scheme at trips level (see #358) or at stops level as in the second workaround. Such a overriding would mean to specify the routes.route_type to be a default value and/or to add a "Mixed" value to the enum and handle the necessary conditional requirements.

[leonardehrenfried]

I think you want to take a look this: #358

Entur (Norway) has the same request.

[barbagus]

I suppose the conversation over there is more about temporary replacements of trains by buses, a related but distinct issue. This use case is about regular routes served by both trains and buses.

[skinkie]

Can you board and alight at the same stops?

[barbagus]

No. Usually the same parent station but, as I mentioned, they do have separate stops, one for trains, one for buses.

[skinkie]

Then I think it is plainly wrong to use the same route. I would also argue that in every other standard TER uses they have to split them in two separate lines, which may for the public share the same public code, but never is this thing combined into one timetable.

[barbagus]

I agree that the "route duplication" is my favourite workaround.
However whether it is wrong for them to do so, it seems that they actually do combine... Upon talking with the administrators of that datasets, they confirmed that the gtfs generation is the end of a very long pipeline using their own information system as a source.
And they do show them combined in one time table (see the linked pdf exemple)

One thing is sure, we might not succeed to have them change their IS... the question is then, as a community standard... should gtfs support this ?

[skinkie]

Can you show me their NeTEx output for this line?

[eliasmbd]

Thank you for bringing this issue to the community's attention. Your contribution is clear and well structured! 🙏

One thing is sure, we might not succeed to have them change their IS... the question is then, as a community standard... should gtfs support this ?

You also ask an essential question here especially for an edge case like this. Have you asked the TER authorities about their thinking behind this case?

[barbagus]

Can you show me their NeTEx output for this line?

I can try, but I am not at all familiar with NeTEx format... I will look it up.

[barbagus]

Have you asked the TER authorities about their thinking behind this case?

Not directly, I did approach them to get confirmation of the fact that their stops.stop_id do follow the pattern I mention in the original issue, i.e. StopPoint:OCECar* means bus and StopPoint:OCETrain* means train (they also have a prefix for Tram..).
Also, I invited them to checkout this issue post.