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.

CLA issue should be fixed now! : 👍

-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.

@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.

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.

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.

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

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.

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.

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.

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

I want to follow up this proposal. We are now planning to have a clean up of OpenTripPlanner real-time data, and missing data are now causing us problems how to fill in the remaining times to satisfy invariants (times must be increasing along the trip).

We should write the best practice of always producing all arrivals / departures for all stops for a trip into the recommendation document, in order to ensure that consumers won't add guesswork.

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.