You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While my Transitime instance that's outputting data for a pretty big transit network is working fine (GTFS-RT and SIRI API data is accurate and up to date, avlReports are being read in and saved to database, web interface working etc.), I found something a bit weird when I tried running the ScheduleGenerator for a recent period of time in order to get more accurate static GTFS trip times.
The output arrival and departure times were identical to the scheduled ones and I found the reason in the log:
Reading in a days worth of ARRIVALS data for between Tue Oct 04 00:00:00 EEST 2022 and Wed Oct 05 00:00:00 EEST 2022
Read in total of 0 ARRIVALS
I went in MySQL and confirmed that the ArrivalDeparture table, which currently stands at 31540209 total records, hasn't had a new one inserted for a few months now.
However, no issues seem to appear in the relevant logs:
arrivalDeparture.log
ArrivalDepartureGeneratorDefaultImpl 18:59:35.653 For vehicleId=6451 There was no previous match so in theory could estimate arrivals/departures for the beginning of the assignment. But the vehicle is being reassigned to blockId=TRIP_LV_117_1_139 which probably means that vehicle already had arrivals/departures for the stops. Therefore not estimating arrivals/departures for the early stops.
ArrivalDepartureGeneratorDefaultImpl 18:59:35.658 vehicleId=6523 traversed at least one stop so determining arrival/departure times. oldMatch=TemporalMatch [temporalDifference=-11.0 sec (late), avlTime=10-13-2022 20:59:09.000 EEST, blockId=TRIP_LV_116_0_102, tripIndex=0, gtfsStopSeq=12, stopPathIndex=12, segmentIndex=0, isLayover=false, distanceToSegment=2.86m, distanceAlongSegment=15.04m, distanceAlongStopPath=15.04m, atStop=Indices [blockId=TRIP_LV_116_0_102, tripIndex=0, stopPathIndex=11, stopId=5925], trip=Trip [tripId=TRIP_LV_116_0_102, tripShortName=TRIP_LV_116_0_102, tripPatternId=shape_1160_7440_to_9234_83fa7862, tripIndexInBlock=0, startTime=20:35:00, endTime=21:47:00, headsign="Soseaua Fundeni", directionId=0, routeId=116, routeShortName=282, serviceId=36, blockId=TRIP_LV_116_0_102, shapeId=1160]] newMatch=TemporalMatch [temporalDifference=9.6 sec (early), avlTime=10-13-2022 20:59:31.000 EEST, blockId=TRIP_LV_116_0_102, tripIndex=0, gtfsStopSeq=12, stopPathIndex=12, segmentIndex=0, isLayover=false, distanceToSegment=0.59m, distanceAlongSegment=144.88m, distanceAlongStopPath=144.88m, atStop=null, trip=Trip [tripId=TRIP_LV_116_0_102, tripShortName=TRIP_LV_116_0_102, tripPatternId=shape_1160_7440_to_9234_83fa7862, tripIndexInBlock=0, startTime=20:35:00, endTime=21:47:00, headsign="Soseaua Fundeni", directionId=0, routeId=116, routeShortName=282, serviceId=36, blockId=TRIP_LV_116_0_102, shapeId=1160]]
ArrivalDepartureGeneratorDefaultImpl 18:59:35.658 vehicleId=6523 was at stop Indices [blockId=TRIP_LV_116_0_102, tripIndex=0, stopPathIndex=11, stopId=5925] previous AVL report and departed so determining departure time
core.log
====================================================AvlProcessor processing AvlReport [vehicleId=5333, time=10-13-2022 21:00:01.000 EEST, location=[44.43600, 26.10526], speed=0.0m/s, heading=NaN, source=GTFS-rt, assignmentId=84, assignmentType=ROUTE_ID, licensePlate=5333]
vehicleId=block_TRIP_LV_65_0_198_schedBasedVehicle matched to blockId=TRIP_LV_65_0_198. Vehicle is now predictable. Match=TemporalMatch [temporalDifference=0.0 sec (ontime), avlTime=10-13-2022 21:57:00.000 EEST, blockId=TRIP_LV_65_0_198, tripIndex=0, gtfsStopSeq=0, stopPathIndex=0, segmentIndex=0, isLayover=true, distanceToSegment=0.00m, distanceAlongSegment=0.00m, distanceAlongStopPath=0.00m, atStop=Indices [blockId=TRIP_LV_65_0_198, tripIndex=0, stopPathIndex=0, stopId=3621], trip=Trip [tripId=TRIP_LV_65_0_198, tripShortName=TRIP_LV_65_0_198, tripPatternId=shape_650_3621_to_3172_d3e22abc, tripIndexInBlock=0, startTime=21:57:00, endTime=22:45:00, headsign="Depoul Militari", directionId=0, routeId=65, routeShortName=25, serviceId=36, blockId=TRIP_LV_65_0_198, shapeId=650]]
For vehicleId=5333 match1AfterStop is after match2BeforeStop so returning travel time of 0. match1AfterStop=SpatialMatch [avlTime=10-13-2022 21:00:01.000 EEST, blockId=TRIP_LV_84_0_103, tripIndex=0, gtfsStopSeq=20, stopPathIndex=20, segmentIndex=0, isLayover=false, distanceToSegment=0.87m, distanceAlongSegment=344.55m, distanceAlongStopPath=344.55m, atStop=Indices [blockId=TRIP_LV_84_0_103, tripIndex=0, stopPathIndex=20, stopId=3896], trip=Trip [tripId=TRIP_LV_84_0_103, tripShortName=TRIP_LV_84_0_103, tripPatternId=shape_840_3821_to_3896_6120340c, tripIndexInBlock=0, startTime=20:32:00, endTime=21:00:00, headsign="Piata Rosetti", directionId=0, routeId=84, routeShortName=61, serviceId=36, blockId=TRIP_LV_84_0_103, shapeId=840]], match2BeforeStop=TemporalMatch [temporalDifference=-0.0 sec (late), avlTime=10-13-2022 20:59:41.000 EEST, blockId=TRIP_LV_84_0_103, tripIndex=0, gtfsStopSeq=20, stopPathIndex=20, segmentIndex=0, isLayover=false, distanceToSegment=1.92m, distanceAlongSegment=311.69m, distanceAlongStopPath=311.69m, atStop=Indices [blockId=TRIP_LV_84_0_103, tripIndex=0, stopPathIndex=20, stopId=3896], trip=Trip [tripId=TRIP_LV_84_0_103, tripShortName=TRIP_LV_84_0_103, tripPatternId=shape_840_3821_to_3896_6120340c, tripIndexInBlock=0, startTime=20:32:00, endTime=21:00:00, headsign="Piata Rosetti", directionId=0, routeId=84, routeShortName=61, serviceId=36, blockId=TRIP_LV_84_0_103, shapeId=840]]
For vehicleId=5333 match1AfterStop is after match2BeforeStop so returning travel time of 0. match1AfterStop=SpatialMatch [avlTime=10-13-2022 21:00:01.000 EEST, blockId=TRIP_LV_84_0_103, tripIndex=0, gtfsStopSeq=20, stopPathIndex=20, segmentIndex=0, isLayover=false, distanceToSegment=NaN, distanceAlongSegment=344.55m, distanceAlongStopPath=344.55m, atStop=Indices [blockId=TRIP_LV_84_0_103, tripIndex=0, stopPathIndex=20, stopId=3896], trip=Trip [tripId=TRIP_LV_84_0_103, tripShortName=TRIP_LV_84_0_103, tripPatternId=shape_840_3821_to_3896_6120340c, tripIndexInBlock=0, startTime=20:32:00, endTime=21:00:00, headsign="Piata Rosetti", directionId=0, routeId=84, routeShortName=61, serviceId=36, blockId=TRIP_LV_84_0_103, shapeId=840]], match2BeforeStop=TemporalMatch [temporalDifference=-0.0 sec (late), avlTime=10-13-2022 20:59:41.000 EEST, blockId=TRIP_LV_84_0_103, tripIndex=0, gtfsStopSeq=20, stopPathIndex=20, segmentIndex=0, isLayover=false, distanceToSegment=1.92m, distanceAlongSegment=311.69m, distanceAlongStopPath=311.69m, atStop=Indices [blockId=TRIP_LV_84_0_103, tripIndex=0, stopPathIndex=20, stopId=3896], trip=Trip [tripId=TRIP_LV_84_0_103, tripShortName=TRIP_LV_84_0_103, tripPatternId=shape_840_3821_to_3896_6120340c, tripIndexInBlock=0, startTime=20:32:00, endTime=21:00:00, headsign="Piata Rosetti", directionId=0, routeId=84, routeShortName=61, serviceId=36, blockId=TRIP_LV_84_0_103, shapeId=840]]
For vehicleId=5333 the best match is TemporalMatch [temporalDifference=-4.6 sec (late), avlTime=10-13-2022 21:00:01.000 EEST, blockId=TRIP_LV_84_0_103, tripIndex=0, gtfsStopSeq=20, stopPathIndex=20, segmentIndex=0, isLayover=false, distanceToSegment=NaN, distanceAlongSegment=344.55m, distanceAlongStopPath=344.55m, atStop=Indices [blockId=TRIP_LV_84_0_103, tripIndex=0, stopPathIndex=20, stopId=3896], trip=Trip [tripId=TRIP_LV_84_0_103, tripShortName=TRIP_LV_84_0_103, tripPatternId=shape_840_3821_to_3896_6120340c, tripIndexInBlock=0, startTime=20:32:00, endTime=21:00:00, headsign="Piata Rosetti", directionId=0, routeId=84, routeShortName=61, serviceId=36, blockId=TRIP_LV_84_0_103, shapeId=840]]
Has anyone ran into this kind of issue before and could advise on what to try? Besides restarting the core and looking at the logs I don't really know what to try, and these lead to no progress.
I know the table itself is huge but is nowhere near running out of disk space and adding records manually for testing seems to work. Also other tables are having records added as usual (eg. new GTFS imports or avl reports).
Thanks.
The text was updated successfully, but these errors were encountered:
Hello,
While my Transitime instance that's outputting data for a pretty big transit network is working fine (GTFS-RT and SIRI API data is accurate and up to date, avlReports are being read in and saved to database, web interface working etc.), I found something a bit weird when I tried running the ScheduleGenerator for a recent period of time in order to get more accurate static GTFS trip times.
The output arrival and departure times were identical to the scheduled ones and I found the reason in the log:
I went in MySQL and confirmed that the ArrivalDeparture table, which currently stands at 31540209 total records, hasn't had a new one inserted for a few months now.
However, no issues seem to appear in the relevant logs:
arrivalDeparture.log
core.log
Has anyone ran into this kind of issue before and could advise on what to try? Besides restarting the core and looking at the logs I don't really know what to try, and these lead to no progress.
I know the table itself is huge but is nowhere near running out of disk space and adding records manually for testing seems to work. Also other tables are having records added as usual (eg. new GTFS imports or avl reports).
Thanks.
The text was updated successfully, but these errors were encountered: