gtfs-r data issue

[Brandon Perdue]

I'm not sure if this is a OBA issue or not, but trying to fix it is driving me crazy so I thought I'd ask here to see if anybody had any ideas.  We recently made a temporary service change due to some staffing shortages, and ever since we updated our static gtfs data in OBA our realtime data has stopped showing.  The gtfs-r feeds are still live and being updated.  Everything in them looks correct, but in the OBA app we are only seeing scheduled buses. I've restarted the server, tested the access to the gtfs-r files from the server, and re-imported the static gtfs data multiple times.

Nothing in the OBA server setting have changed and it is still accessing the gtfs-r files at the same location.  I've even compared the trip ids in the realtime vehiclepositions file with the static gtfs files.  Every one I test exists in both the static and realtime data.

[Brandon Perdue]

I am seeing the following in the logs:

2022-01-28 12:12:01,807 WARN  [GtfsRealtimeSource.java:780] : Error updating from GTFS-realtime data sources
java.lang.NullPointerException
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.getBlockStartTimeForTripStartTime(GtfsRealtimeTripLibrary.java:461)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.getTripDescriptorAsBlockDescriptor(GtfsRealtimeTripLibrary.java:545)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeTripLibrary.groupTripUpdatesAndVehiclePositions(GtfsRealtimeTripLibrary.java:207)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource.handeUpdates(GtfsRealtimeSource.java:389)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource.refresh(GtfsRealtimeSource.java:368)
        at org.onebusaway.transit_data_federation.impl.realtime.gtfs_realtime.GtfsRealtimeSource$RefreshTask.run(GtfsRealtimeSource.java:777)
        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)

Surrounded by a bunch of warnings like:
2022-01-28 14:44:11,824 WARN  [GtfsRealtimeTripLibrary.java:503] : block STA_1448 does not exist on service date ServiceIdDate(2022-1-28)
2022-01-28 14:44:11,824 WARN  [GtfsRealtimeTripLibrary.java:503] : block STA_1448 does not exist on service date ServiceIdDate(2022-1-28)

[Sheldon A. Brown]

Check your calendar file to make sure those trips are active. The logs hint they aren’t. 

Good luck!

Sent from my mobile device (I'll be brief)

On Jan 28, 2022, at 5:47 PM, Brandon Perdue <brandon...@ziplineinteractive.com> wrote:



--
You received this message because you are subscribed to the Google Groups "onebusaway-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onebusaway-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/onebusaway-developers/f5f366fd-7a70-4338-a098-c5170bb61865n%40googlegroups.com.

[Devin Braun]

I believe that OBA uses block_id to update real-time as well as trip_id.  I've found that when we merge two service periods together, the tool can change the block_ids and this is what has caused real-time data errors in the past.  The other thing you want to check is that your new bundle actually went live.  I'm not sure how you're set up, but sometimes the old information is being served.  If you go to the web interface and view the schedule for a stop, you can see the trip_ids it's using when you click on each time in the schedule.  Then when you click on those, you can see the block_id it's using.

Here's an example.  We don't advertise this site for our customers, but it's there for us to use in testing.

https://realtime.sdmts.com/onebusaway-enterprise-acta-webapp/where/trip;jsessionid=0BDD119E583BDFDA26D9BE311689F477?id=MTS_16041019&serviceDate=1643356800000&stopId=MTS_10772

--

[Brandon Perdue]

Thanks for the input on that.  I'll dig through the data we have and see what I can find.

[Sean Barbeau]

Brandon,

When checking if something is an OBA issue or not you might want to run the data through the GTFS Realtime Validator:

https://github.com/CUTR-at-USF/gtfs-realtime-validator

I actually don't think we currently check for this particular case, though (assuming it's what Sheldon/Devin said), so I opened a new issue for a new rule for this:

https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/408

Sean