🐛📄 – GTFS-RT vehicle positions `schedule_relationship` not compatible with TIDES vehicle locations `schedule_relationship`

[lauriemerrell]

Describe the problem

It's a bit strong to call this a bug per se but just noting -- I'm working on a GTFS-RT to TIDES conversion and GTFS-RT's vehicle positions has a schedule_relationship field under the trip message which is incompatible with the TIDES vehicle locations schedule_relationship in two ways:

1. In GTFS-RT it's a trip level indicator but in TIDES it's stop level
2. The enums have different values
   GTFS:

TIDES:

Possible Solutions

Could make TIDES conform to the GTFS-RT definition or could rename to stop_schedule_relationship if it's important that it be stop-level rather than trip level

Additional context

[lauriemerrell]

Per TIDES Contributors discussion today 1/8/26:

• There is a conceptual point here that TIDES vehicle locations might have more information available since it's post-hoc (so different enum values could be appropriate)
• There is a stop level schedule relationship field in GTFS RT but it's not in vehicle positions
• Possibly an opportunity to clarify the TIDES-side documentation about the differences with GTFS-RT. @botanize had a succinct summary that protobuf is not a good format for archiving/analytical use (to with GTFS-RT vehicle positions isn't a straight up replacement for TIDES vehicle locations) and @jlstpaul talked about the idea that GTFS-RT was a jumping off point but that sometimes TIDES needs to differ.

[lauriemerrell]

Discussed at TIDES Contributors call again today 3/12/26. Points raised:

• @jlstpaul noted that while TIDES & GTFS should be related, TIDES does not need to be 100% indexed on compatibility with GTFS -- GTFS is just one touchpoint
• @gabriel-korbato shared some context as to why the trip vs. stop grains might be different between the two -- TIDES needs to support cases where trip identifier changes, trip ID might be less stable (I may be summarizing this incorrectly)
• @CTRAN-Sutinen noted that we need to think about the governance of the interface between GTFS and TIDES and whether we want a dynamic where TIDES is purely downstream of/responsive to changes in GTFS-RT (e.g. if enum values change)
• There was general agreement that we do want to support conversion of archived GTFS-RT data into TIDES (that is a valid/desired use case to support)

Personally, I still think seems suboptimal to have a field with the same name between GTFS-RT and TIDES where the two have different interpretations. At the very least I would advocate that we call out clearly in the docs that the field interpretation is different.

[gabriel-korbato]

TIDES has the scheduled trip ID in at the stop visit level because it is possible for source data systems to update the trip ID in the middle of a trip. This happens more often in rail systems but can also happen on bus. If trip_id_scheduled can change mid-trip, then the relationship of the operated trip to the scheduled trip will change with it. For example, a rail control center might change a trip from run-as-directed (without a trip_id_scheduled) to a scheduled trip, so schedule_relationship would change from Added to Scheduled.

Note that these fields are optional, and they also exist in trips_performed, so a TIDES representation of a capture-and-archive of GTFS-RT's VehiclePosition message could simply populate those fields in trips_performed and not in stop_visits.

It is also worth noting that GTFS-RT also has a StopTimeUpdate message that also has a schedule_relationship field. The enum values valid in that table are SCHEDULED, SKIPPED, NO_DATA, and UNSCHEDULED. NO_DATA matches TIDES's Missing, and UNSCHEDULED matches TIDES's Added, so there is one-to-one relationship. (UNSCHEDULED is experimental and subject to change.) Some (or maybe many/most) agencies or at least captures of GTFS-RT focus on the VehiclePosition message, so this does not decrease the relevance of the issue brought forth by @lauriemerrell .

Anyway, it is apparent that TIDES's enum values are inspired by GTFS-RT (for better or worse), so we could revise them. For example, ADDED is deprecated in GTFS-RT. Generally, some of GTFS's enum values don't make sense for TIDES because the use cases are different. The enum values of GTFS-RT's TripDescriptor message (which @lauriemerrell included in this issue's description) more closely parallel TIDES's enum values for trips_performed, but I would think that we would adapt rather than copy. For example:

• SCHEDULED - keep
• ADDED is deprecated in GTFS-RT, so maybe we should not include it, but as it is I'd say it is synonymous with NEW (below). We currently include this in TIDES.
• UNSCHEDULED - keep
• CANCELED - exclude, because a trip that doesn't operate isn't present in trip_performed or stops_visited.
• REPLACEMENT (experimental) - exclude. A replacement trip could just be coded as SCHEDULED
• DUPLICATED - currently in TIDES but I would propose excluding it as well, and just say SCHEDULED too. If two operated trips have the same trip_id_scheduled, which happens often enough, users will know about the duplication when they see a many-to-one. Otherwise, which of the two (or more) trips are marked as DUPLICATED instead of SCHEDULED, and what business rules would be used to determine that, and to what end?
• NEW - what we currently call ADDED.
• DELETED (experimental) - exclude, because if a trip was removed from the schedule it would just not have a trip_id_scheduled and the relationship could just be marked as ADDED (or NEW if we switch to that).

For what it's worth, I think that the most useful information about the relationship between operated and scheduled trips can be obtained by joining scheduled trips to operated trips, making the field somewhat redundant.

• If a trip appears once on each table, it's a scheduled trip that was operated (SCHEDULED)
• If a trip appears in the operated table but not the schedule, it was ADDED/NEW/UNSCHEDULED
• If a trip appears in the scheduled table but not the operated table, it was CANCELLED.
• If a trip appears multiple times in the operated table with the same scheduled trip ID, it was DUPLICATED.

For this reason, as an implementer or analysis end user, I would not prioritize populating this field.

[botanize]

For what it's worth, I think that the most useful information about the relationship between operated and scheduled trips can be obtained by joining scheduled trips to operated trips, making the field somewhat redundant.

• If a trip appears once on each table, it's a scheduled trip that was operated (SCHEDULED)
• If a trip appears in the operated table but not the schedule, it was ADDED/NEW/UNSCHEDULED
• If a trip appears in the scheduled table but not the operated table, it was CANCELLED.
• If a trip appears multiple times in the operated table with the same scheduled trip ID, it was DUPLICATED.

For this reason, as an implementer or analysis end user, I would not prioritize populating this field.

We often can't tell from data alone whether a scheduled trip wasn't run (canceled) or just didn't report anything. In other words, joining operated and scheduled trips may incorrectly infer that a trip was canceled. It would be nice to have a place to record things we do know positively about a trip, like that it was canceled, and didn't just have malfunctioning hardware.

However, this use case is not currently supported without violating some required constraints. Perhaps making vehicle_id and trip_id_performed conditionally required if trip is not canceled, and trip_id_scheduled required if trip is canceled would solve that problem.

I think I basically agree with @gabriel-korbato though, I probably wouldn't prioritize this field. If anything, I might create an accessory trip_schedule_relationship table with service_date, vehicle_id, trip_id (or route, direction, and start_time if there's no trip_id) and trip schedule relationship, just to have a record somewhere.