Clarify whether GTFS-RT `VehiclePositions.current_stop_sequence` refers to GTFS Schedule `stop_times.stop_sequence`

[lauriemerrell]

Introduce yourself

I'm asking due to a related questions that has arisen on TIDES: TIDES-transit/TIDES#263.

Ask a question

GTFS-RT VehiclePosition messages have a current_stop_sequence attribute, defined as:

The stop sequence index of the current stop. The meaning of current_stop_sequence (i.e., the stop that it refers to) is determined by current_status. If current_status is missing IN_TRANSIT_TO is assumed.

This documentation is ambiguous as to whether current_stop_sequence is intended to refer to the same thing as StopTimeUpdate.stop_sequence, which is defined as:

Must be the same as in stop_times.txt in the corresponding GTFS feed. Either stop_sequence or stop_id must be provided within a StopTimeUpdate - both fields cannot be empty. stop_sequence is required for trips that visit the same stop_id more than once (e.g., a loop) to disambiguate which stop the prediction is for. If StopTimeProperties.assigned_stop_id is populated, then stop_sequence must be populated. Required if TripUpdate.schedule_relationship is NEW or REPLACEMENT, and the value must be increasing along the trip.

So, the question is -- can VehiclePosition.current_stop_sequence be safely assumed to correspond to StopTimeUpdate.stop_sequence/stop_times.stop_sequence or not?

This is particularly relevant vis a vis relationship to TIDES because TIDES vehicle locations has a distinct trip_stop_sequence field which is specifically defined differently from stop_times.stop_sequence.

[lauriemerrell]

I also raised this question in the MobilityData Slack. In that conversation @paulswartz confirmed that MBTA treats VehiclePosition.current_stop_sequence as linked to StopTimeUpdate.stop_sequence/stop_times.stop_sequence, so in practice in at least one case they are treated as the same, but it was still ambiguous whether that is a spec-level guarantee or just an implementation choice that some producers have made.

[BodoMinea]

I have always implemented and interpreted current_stop_sequence as being in relation to the scheduled stop_sequence in stop_times.txt. I see in the protobuf that it is clearly specified for StopTimeUpdate.stop_sequence (eg. the comment - Must be the same as in stop_times.txt in the corresponding GTFS feed). My use-case is usually to use this field to hide / change the style of stops that the vehicle is confirmed to have passed (for example in the case of a linear stop display).
I guess it would be good to clarify in the documentation as well.

[skinkie]

I don't think this can be assumed in case of a detour being specified as a new sequence.