transfers.txt: Add optional field service_id

[manfredbrandl]

Describe the problem

I suggest adding the optional field service_id to transfers.txt so that secured connections can be restricted to the days on which they are actually secured.

Use cases

Our network has guaranteed connections (transfer_type = 1 with from_trip_id and to_trip_id) between journeys, but not on all days on which these journeys are operated. On days without guaranteed connections, there may be a through connection (block transfer), a guaranteed connection at another stop or – for operational reasons – no guaranteed connection at all.

Proposed solution

Add the optional field service_id to transfers.txt

Additional information

No response

[luca-d-axon]

I support this suggestion, we have similar cases in Switzerland too.
HRDF format correctly maps these cases with a validity (BITFELD) in DURCHBI file.

[felixguendling]

I don't really have an opinion pro/against on this, just want to add that:

• this does not enable a new use case because at the moment you can just split the trip into two trips (one with transfer_type=1 and one with transfer_type=4) and have the same effect
• it would not be downward compatible which is a no-go since GTFS does not have versioning
• when transforming from HRDF you have to build different trips for different track sequences anyway (unrolling track service days), so why not do it for transfers as well
• it would definitely be an advantage to be able make conversion HRDF to GTFS easier and less error prone

[ue71603]

SBB supports the proposal. We agree with @felixguendling that we could do this by splitting trips. We have then trips that we would need to split multiple times for different technical reasons. To remove one of those reasons we believe is helpful for understanding what is happening.
We will also do an implementation for the Swiss data.

[manfredbrandl]

I also agree with @felixguendling that this could be achieved by splitting the journeys.
However, we do not wish to split journeys, as we will be using a global ID for journeys that is used in all formats, including GTFS and GTFS-R, in order to minimise the effort required for quality assurance. We would have to split the journeys not only in GTFS but also in GTFS-R, which is too labour-intensive for us and our software supplier.
@felixguendling Could you please explain in more detail why the extension is not backwards compatible? The proposed additional field is intended to be optional, so existing GTFS data will remain valid with its current meaning.

[felixguendling]

@felixguendling Could you please explain in more detail why the extension is not backwards compatible?

The current primary key is (from_stop_id, to_stop_id, from_trip_id, to_trip_id, from_route_id, to_route_id). In case you have different transfer times for different days, you would create a duplicate primary key (from_stop_id, to_stop_id, assuming only from_stop_id and to_stop_id are used). Therefore, this would lead to errors if a database system (which does not have service_id in its primary key yet) requires a unique primary key (which is usually the case).

I'm not particularly pro or against this proposal but I think it clearly shows the need for proper versioning support in GTFS. Otherwise, the standard will have a hard time to evolve without degrading into a mess. Of course, in this case, you could solve this problem by adding another file service_id_transfers.txt or similar which is only read by new systems that support it and transfers.txt contains the transfers in a backward compatible way. But I don't think it's a good idea to add a new file each time the primary key needs to change.

we do not wish to split journeys

When converting from HRDF to GTFS, you would have to split by track sequence anyway (because track assignments have traffic days assigned as well), so only having service_id for transfers is not sufficient to be able to use HRDF identifiers as trip_id.

[manfredbrandl]

@felixguendling Can you please open a new ticket to discuss the need for versioning support?
Duplicate primary keys are againt the specification anyway. I do not want to provide different transfer times as i want to provide transfers with transfer_type 1 from the feeder (from_stop_id, from_route_id and from_trip_id) to the fetcher (to_stop_id, to_route_id and to_trip_id).

[felixguendling]

from_stop_id,to_stop_id,service_id,transfer_type,min_transfer_time
A,B,Mo-Fr,1,5
A,B,Sa-Su,1,4

In HRDF this would be possible. How would you map this to GTFS without having a duplicate primary key?

---

Edit: there are already several Issues addressing versioning

• Backwards compatibility and versioning #288
• [Discussion] GTFS Realtime Versioning #530

[Leo-Tobias]

What speaks against actually generating a new Trip_id in case of "durchbinung" and then, of course, giving it a validity pattern.