GTFS-realtime TripUpdate.delay field not supported

[kurtraschke]

Expected behavior

GTFS-realtime TripUpdate messages with TripUpdate.delay set are applied to the graph.

Observed behavior

GTFS-realtime TripUpdate messages with TripUpdate.delay set are ignored because they contain zero StopTimeUpdates, and the value in TripUpdate.delay is not applied.

Version of OTP used (exact commit hash or JAR name)

23d3191

Data sets in use (links to GTFS and OSM PBF files)

google_transit.zip

Command line used to start OTP

java -jar otp-1.3.0.jar --build data --inMemory --port 9000 --securePort 9001

Router config and graph build config JSON

router-config.json

Steps to reproduce the problem

1. Configure OTP with a GTFS-realtime TripUpdate source which makes use of the TripUpdate.delay field (and does not provide stop-level delays or timestamps).
2. Observe that warning TripUpdate contains no updates, skipping. is logged, and trips do not reflect real-time status when queried in the OTP UI or API.

[sdjacobs]

How common is this use case? I'm noticing this is actually non-compliant with the spec, which states:

At least one stop_time_update must be provided for the trip unless the trip.schedule_relationship is CANCELED - if the trip is canceled, no stop_time_updates need to be provided.

If this kind of GTFS-RT is common, I don't see any harm in including this code, since it won't affect TripUpdates with do contain StopTimeUpdates, and will improve the handling of TripUpdates without StopTimeUpdates. I might even add code to propagate TripUpdate.delay to StopTimeUpdates which don't contain an arrival or departure time (though again, this would be supporting noncompliant GTFS-RT).

(Kurt - sorry, looking into this more, what I said offline wasn't relevant)

[barbeau]

@sdjacobs The TripUpdate.delay field is experimental and not widely deployed, but it's a legitimate use case. The intention of the field is that no stop_time_updates need to be included when TripUpdate.delay is included. The part of the spec you quoted hasn't caught up with this experimental field yet and needs to be updated - I'll open an issue to update the spec.

Related issue - CUTR-at-USF/gtfs-realtime-validator#329, where based on TransitFeeds.com directory of GTFS-rt feeds we didn't find anyone using TripUpdate.delay in production feeds.

[barbeau]

Also, Google's validator will throw an error on feeds if they contain both stop_time_updates and TripUpdate.delay - TripUpdate.delay is only allowed in feeds if there are no stop_time_updates.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[leonardehrenfried]

I think we want to keep this open as a reminder.

@demory Is this something that IBI would like to use?

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days