Stop Time Events in the past should be kept

[kylerchin]

Maybe this should be recommended? This is extremely useful because it's helpful to have updates on when the train entered or left the station. Maybe we should state that past events should be the actual time in which the vehicle entered or left the stop.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[kylerchin]

CLA issue should be fixed now! : 👍

[skinkie]

-1 OpenGeo
It uses the wrong wording for what you want. Your intention is to receive information, thats fine. Your implementation an client is to fetch GTFS-RT at a regular interval. It may be that your update interval does not match the producers interval. What you want to describe is some sort of time to live for StopTimeEvents. Recommending to keep all historic StopTimeEvents bloats the GTFS tripUpdates distribution for no good reason, therefore it should not be recommended in the way you do.

[kylerchin]

@skinkie There is good reason IMO to keep previous times, such as if a consumer server cold starts, or if a fault causes a significant loss in the cache data.

[skinkie]

That is not a price to pay for the producer or all other consumers.

All these kinds of things could be fixed by a final implementation for Incrementality=DIFFERENTIAL, that would allow the majority of information be provided in tiny parts and your use case in the FULL_DATASET. Personally I think a HISTORY would be more appropriate.

[miklcct]

I would say that past events should be kept as long as the trip hasn't been completed yet, otherwise consumers may have trouble working on delay propagation.

[gcamp]

Can you explain how delay propagation is hard to do without the full trip?

[miklcct]

If a bus is running early, well ahead of its scheduled time, lacking previous information may well cause the system into impossible state like time running backwards.

For example, OpenTripPlanner allows you to configure an option when such things do happen.

[gcamp]

That's already in the spec :

Producers should not drop a past StopTimeUpdate if it refers to a stop with a scheduled arrival time in the future for the given trip (i.e. the vehicle has passed the stop ahead of schedule), as otherwise it will be concluded that there is no update for this stop.

What is proposed here is that producers should keep all past items regardless of if they are running early or late.

[evansiroky]

I agree that GTFS-RT should be reserved for realtime events only and not need to include historical data. A better way to communicate historical data would be via another standard, such as TIDES.