First draft of prediction type

[gcamp]

Not in this PR but maybe could be done at the same time: deprecation of uncertainty.

An alternative would be to extend ScheduleRelationship in StopTimeUpdate but that means having SCHEDULED (which means real time data) and IMPRECISE_REALTIME (real time but imprecise) in the same enum but that seemed not clear enough.

We put this value on StopTimeUpdate because the value could potentially change per stop even if most of the time the value will be the same for all StopTimeUpdate in the same TripUpdate.

[mike-swiftly]

I understand the purpose of REALTIME and IMPROVED_SCHEDULE. But I'm not clear on IMPRECISE_REALTIME. I don't think Swiftly currently has a way of detecting lost GPS. Can you try to further explain this value?

Also, I think it would be good to explain in the documentation that IMPROVED_SCHEDULE is often used when the predictions depend on driver behavior, where it is assumed that the driver will start the trip when scheduled. It is to indicate that accuracy of the predictions is not as good since the driver has not yet left the terminal.

[juanborre]

Hi @mike-swiftly ,

The case of IMPRECISE_REALTIME happens when a bus that was tracked and was providing predictions with REALTIME goes dark, meaning that it looses its GPS or the connectivity and thus it is impossible to track it. The real time prediction that the server provides is still better than the scheduled data that was in the static GTFS. It basically means that we provide a better prediction than the static but not as precise as when the value is REALTIME.

As for the IMPROVED_SCHEDULE, there is also another use case. Some AVL providers have two sorts of static data:

• The scheduled => the static GTFS, published every few months normally.
• The applicable schedules => modifications to the static GTFS during the days or hours before the day of operation that have not been published in the GTFS (also because they are different each day). They are still scheduled data, not real time. It is kind of equivalent to re-publishing a GTFS dataset with the modified schedules every day or every few hours, but then the reactivity of the process would be very slow because the consumer would need to pull for new versions of the GTFS data very often.

[LeoFrachet]

*field

[LeoFrachet]

Reading a Pull Request is always hard, because it's the answer to a question, and we have to guess what was the question.

So. Here. What are the cases you want to address? I guess it's something like:

• A: scheduled according to the GTFS.
• B: updated schedule according to some new data.
• C: vehicle has not left the departure, but is planning to. (same than above?)
• D: vehicle position is lost
• E: vehicle is currently broadcasting a position

A and E are already supported, and you want to address the cases B, C and D.

=> Is this the goal of the PR? Am I missing something?

Regarding IMPROVED_SCHEDULE, if you want to address the case of a real-time update of the schedule time, I would maybe call it UPDATED_SCHEDULE (maybe it's just me, but I find it clearer). It would handle the case B, and IMHO it would also handle the case C.

D is tricky. You want to call it IMPRECISE_REALTIME, but which information is such thing giving? If the track has been lost 5s ago, the "imprecision" is really different than having lost it 1min ago, or even 5min ago. If you had the timestamp of the last update, or the delay, would it address your need?

[gcamp]

The base usecase is that producer wants to control if the app will show a real time icon or not. For this usecase we could have done only REALTIME or IMPROVED_SCHEDULE, but from talks with people it seemed that IMPROVED_SCHEDULE doesn't cover all cases where you don't want to show real time indicator. IMPRECISE_REALTIME is there basically for the case where it's real time but not precise enough to be shown with a real time indicator in the app. The actual reason of why it's imprecise doesn't really need to be defined I think.

[gcamp]

@mike-swiftly @LeoFrachet Updated with comments and clarifications.