Error with GTFS-RT feed: schedule_relationship: NO_DATA at a stop

14 views
Skip to first unread message

Nicolas Derive

unread,
May 23, 2018, 4:49:58 PM5/23/18
to onebusaw...@googlegroups.com, onebusaway...@googlegroups.com
Using a GTFS-RT feed with OBA (version doesn't matter), I got this error:
2018-05-23 22:44:56,795 WARN  [GtfsRealtimeTripLibrary.java:235] : unknown/total trips= 73/940
2018-05-23 22:44:56,797 WARN  [GtfsRealtimeSource.java:401] : Error updating from GTFS-realtime data sources
java.lang.IllegalStateException: expected at least an arrival or departure time or delay for update: stop_id: "StopPoint:40:47"
schedule_relationship: NO_DATA

        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.getTimeForStopTimeUpdate(GtfsRealtimeTripLibrary.java:534)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.getBlockStopTimeForStopTimeUpdate(GtfsRealtimeTripLibrary.java:492)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.applyTripUpdatesToRecord(GtfsRealtimeTripLibrary.java:411)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.createVehicleLocationRecordForUpdate(GtfsRealtimeTripLibrary.java:158)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource.handleCombinedUpdates(GtfsRealtimeSource.java:275)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource.handeUpdates(GtfsRealtimeSource.java:265)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource.refresh(GtfsRealtimeSource.java:244)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource$RefreshTask.run(GtfsRealtimeSource.java:399)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

But, I think that when schedule_relationship is NO_DATA for a stop, it means that you have no data, so no delay, departure or arrival time to provide, don't you think? Is this really an error regarding GTFS-RT spec?

Thanks for your help.

Nicolas

Sheldon A. Brown

unread,
May 24, 2018, 5:20:29 AM5/24/18
to onebusaw...@googlegroups.com
The log message, especially as you've truncated it, is misleading.
schedule_relationship: NO_DATA is not supported, its quietly ignored.
The code instead is validating that at least something was present in
the update.

However, your comment about version doesn't matter is also incorrect.
In 2.0.0-SNAPSHOT we return a negative error code instead of throwing
an exception so the rest of the feed can be considered:

https://github.com/OneBusAway/onebusaway-application-modules/blob/master/onebusaway-transit-data-federation/src/main/java/org/onebusaway/transit_data_federation/impl/realtime/gtfs_realtime/GtfsRealtimeTripLibrary.java#L840

Sheldon
> --
> You received this message because you are subscribed to the Google Groups
> "onebusaway-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to onebusaway-use...@googlegroups.com.
> To post to this group, send email to onebusaw...@googlegroups.com.
> Visit this group at https://groups.google.com/group/onebusaway-users.
> For more options, visit https://groups.google.com/d/optout.

Nicolas Derive

unread,
May 24, 2018, 2:02:28 PM5/24/18
to onebusaw...@googlegroups.com
Dear Sheldon,

I truncated it because it keeps repeating the same messages each time the feed is retrieved, and I don't know what's relevant or not to analyze the problem.

Sure, for version, I was thinking in terms of stable (released) ones, as I tested multiple ones, sorry. But sure, currently the whole feed is discarded even if it complies with GTFS-RT, which is I think a problem (at least for me).

Would it be possible to backport the behavior from 2.0.0-SNAPSHOT to the latest stable version? It should be safe to do this, and it allows to use feeds that make use of NO_DATA schedule_relationship.

Thanks for your help

Nicolas

Sheldon A. Brown

unread,
May 24, 2018, 6:43:51 PM5/24/18
to onebusaw...@googlegroups.com
Sorry, I was trying to be specific not argumentative. 

In theory that change could be back ported, in practice I’m trying to get 2.0.0 released. 

Depending upon how handy you are you could make the change yourself on a fork/branch or filter out the NO_DATA updates from the feed in the meantime. 

GtfsRealtimeSource and GtfsRealtimeTripLibrary will continue to be a work in progress as the GTFS-RT spec evolves, which is also why I discourage back porting. 

Sorry I can’t be of more help here....
Reply all
Reply to author
Forward
0 new messages