Should Trip.startTime be set to the arrival time of the first stop if it exists?

[nselikoff]

I am working with a route where the first stop of the trip is a "wait stop" (the arrival and departure times are different... e.g. the vehicle arrives at 12:00 and waits for passengers, then leaves at 12:15). Currently the Trip class sets the trip startTime as the departure time of the first stop of the trip:

https://github.com/TheTransitClock/transitime/blob/develop/transitclock/src/main/java/org/transitclock/db/structs/Trip.java#L414

So the trip's startTime in this example is 12:15, and the associated Block's startTime is also 12:15

In our branch we've changed Trip.java to consider both arrival and departure time:

https://github.com/omnimodal/transitime/blob/2a4960dea4e062aeae87346a81617f19b5eefabf/transitclock/src/main/java/org/transitclock/db/structs/Trip.java#L416

which makes it so the block becomes active at 12:00, and the trip's start time is 12:00. But I'm not sure this should be merged into TheTransitClock, because it's a breaking change that requires re-processing the GTFS static feed in order to update the trip and block start times in the database. Thoughts @scrudden?

[scrudden]

Hi Nathan, What information do you wish the passenger to see? By that, I mean what information in relation to this stop/vehicle would the passenger see at 11:55, 12:05, and 12:20? Cheers, Sean.

[nselikoff]

Assuming the vehicle is on time (arrives at the station at 12:00 and departs at 12:15):

At 11:55 there would be no realtime info in the GTFS Realtime feeds, so in consuming apps the passenger would just see schedule information about the upcoming trip.

At 12:05 the GTFS Realtime feeds would be populated with the vehicle's real position, connected to this trip, and with trip updates. All of the time estimates / delays / schedule adherence would be 100% on time at this point, since the vehicle hasn't started moving and the best assumption is that it will leave on time. So in consuming apps the passenger would see the real vehicle position (e.g. in Transit App), and the trip/vehicle would be "on time" (e.g. in Google Maps).

At 12:20 the GTFS Realtime feeds would still be populated, but now the vehicle's schedule adherence and the trip updates would be real predictions based on the movement of the vehicle. The passenger would see the vehicle position (e.g. in Transit App) and the appropriate predictions/status in consuming apps (e.g. in Google Maps, this could be delayed, on time, or early in the context of the trip plan).

[scrudden]

Hi Nathan,

I am wondering would using SchedBasedPredsModule and setting the beforeStartTimeMinutes to 15 provide you with a satisfactory result?

private static final IntegerConfigValue beforeStartTimeMinutes = 
            new IntegerConfigValue(
                    "transitclock.schedBasedPreds.beforeStartTimeMinutes", 60,
                    "How many minutes before a block start time should create "
                    + "a schedule based vehicle for that block.");

I think in this case the customer will see what you describe in each case. At 11:55 no predictions. At 12:05 predictions that match the schedule based on a "schedule based vehicle" and at 12:20, as this "schedule based vehicle" will be replaced by a "regular" vehicle, real predictions.

Cheers,

Sean.

[nselikoff]

Hi @scrudden, I'm going to try this - is it possible to use the SchedBasedPredsModule with the PlaybackModule? When I add it to my config and run playback I see that the module is starting (in my log files) but don't see any other evidence that it's working. I will try with live data as well but was hoping to test it with playback.

[scrudden]

Hi @nselikoff,

I have not done this but I wonder if you set transitclock.avl.playbackRealtime to true it may work. I think it defaults to false and runs as fast as possible. I think this may not be giving the SchedBasedPredsModule time to run.

If you change to true the SchedBasedPredsModule should run every 4 minutes based on transitclock.schedBasedPreds.pollingRateMsec. The first avl read in should then set the clock to the correct time.

If this does not work then we should fix this as it would be useful if it did work.

Cheers,

Sean.

[nselikoff]

Hi @scrudden, good call. Setting playbackRealtime to true is promising... now I can see a schedule based vehicle created, and a bunch of predictions created too. Letting it run for a bit to see the switchover.

[nselikoff]

Hi @scrudden, one minor issue with using SchedBasedPredsModule with PlaybackModule in realtime is that the schedBasedVehicle isn't initially created until the first AVL report is played back (regardless of transitclock.avl.playbackStartTime). Not a big deal, just wanted to note it in this thread.

[scrudden]

Hi Nathan,

It needs the first AVL report to set the clock to the time of the playback so this seems like correct behavior.

We could improve this by having the PlaybackModule set the clock to the start of the playback period. This we could do in the PlayBackModule constructor like this.

Core.getInstance().setSystemTime(parsePlaybackStartTime(getPlaybackStartTimeStr()));

Cheers,

Sean.