Best practices on stop_times.txt about internal timing points

[miklcct]

Introduce yourself

No response

Ask a question

The best practice contains the following statement:

On revenue trips, internal “timing points” for monitoring operational performance and other places such as garages that a passenger cannot board should be marked with pickup_type = 1 (no pickup available) and drop_off_type = 1 (no drop off available).

To my understanding, stop_times.txt should only contain "stops" for the trip. Examples of non-passenger stops include driver change points at service motorways, technical stops for refuelling, passing points on single-track railways, etc. where the service must stop.

I am seeing some GTFS generator / dataset putting some internal "pass points", which serves as timing points (and possibly validates tickets) but the service doesn't stop at all, into the stop_times.txt which has resulted in our frontend applications giving misleading instructions (showing them in the stop list).

I would like a clarification on the above matter.

Is it appropriate to put places, where a service passes through but do not actually stop, into stop_times.txt? Some of these places are relevant to passengers because they validate certain tickets.

[westontrillium]

Should we also look at the implications the existence of TODS may have for this best practice as well?

[miklcct]

Should we also look at the implications the existence of TODS may have for this best practice as well?

What is TODS?

[eliasmbd]

Should we also look at the implications the existence of TODS may have for this best practice as well?

What is TODS?

@miklcct This is TODS:

The Transit Operational Data Standard (TODS) is an open standard for describing how to operate scheduled transit operations which can be used to port scheduled operations between software products (e.g. scheduling systems and CAD/AVL systems), agencies, and more. TODS leverages the existing General Transit Feed Specification (GTFS) and extends it to include information about personnel and non-revenue service.

[miklcct]

OK, so the aim of GTFS is solely to deliver public, passenger information. Where should we draw the boundary between "passenger information" and "operational details"? For example, the use of block_id in trips.txt can be considered as operational details, but it may also be of interest to the passenger to locate where the bus he wants to take is, by tracing back trips with the same block id. Specifying "passing points" in addition to stops is also sometimes required to validate tickets, although the passing points are not listed in the public timetables.

In the "best practice" file, there is also a statement about deadhead trips:

Non-revenue (deadhead) trips that do not provide passenger service should be marked with pickup_type and drop_off_type value of 1 for all stop_times rows.

To be honest, shouldn't these trips be included in the file at all, but only supplemented by TODS instead?

I will have a legitimate use of revenue trips where pickup_type and drop_off_type value of 1 for all stop_times rows, as in the pull request #533 to specify a revenue trip is not for general passenger service, but only for carriages of cars / bikes / wheelchairs / etc.

[felixguendling]

block_id in trips.txt can be considered as operational details

As it is defined now, it's more like an operational detail. However, before transfer_type=4 was introduced, block_id was clearly rider-facing. IMO the change in semantics for block_id when transfer_type=4 was introduced was a backward-incompatible change that was not necessary. Since most feeds I see in practice still use block_id with the initial semantics, I would say that it's still rider-facing (in practice).

Non-revenue (deadhead) trips [...]
To be honest, shouldn't these trips be included in the file at all, but only supplemented by TODS instead?

Showing those trips to customers (even with boarding/alighting forbidden) might be confusing to customers. I would say that the safest option would be to exclude them from GTFS (which has the sole purpose to be rider-facing).

[github-actions]

This issue has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.