API Changes to Support Frequency-Based Service - Looking for Feedback
Brian Ferris
I found out this week that KCM is moving to frequency-based scheduling
for Link Light Rail and Rapid Line A as part of the service change
going into effect on Saturday. That means that instead of providing
scheduled arrival times at stops, these routes are modeled based on
their frequency of service (a bus every 10 minutes, for example).
Unfortunately, OneBusAway currently doesn't have any support for
frequency-based scheduling, but that's clearly going to have to change
asap.
In terms of the api, I haven't completely thought out all the
implications, but lets hit the main one first: the
<arrivalAndDeparture> element returned in the
arrivals-and-departures-for-stop call. My proposal is the following:
1) "scheduledArrivalTime" and "scheduledDepartureTime" become optional
elements, defaulting to 0 when not set.
2) Introduce an optional "headway" element that will measure the
frequency of service in seconds, similar to the "headway_secs" field
defined in the root GTFS.
3) When available, "predictedArrivalTime" and "predictedScheduleTime"
will be set, indicating that real-time data is available for the
vehicle.
Unfortunately, real-time data WON'T be available for either Link Light
Rail or Rapid Ride A any time soon. I'm pushing the agencies as hard
as I can on this, but it's going to take time. I'll leave it up to
you to decide how to ultimately handle the UI presentation of a
scheduled route on a frequency-based schedule.
As I mentioned, OneBusAway currently doesn't have support for
frequency-based service and it realistically won't have it for the
update this weekend, which will keep me busy enough as is. Instead,
I'm proposing a stop-gap solution:
1) I've been given temporary access to the Link Light Rail schedule
data. Even though Link is presented as frequency-based, it's actually
scheduled so I can use that data so that Link Light Rail doesn't drop
off the map this weekend.
2) Rapid Ride A realistically probably isn't going to be included in
the OBA shakeup this weekend.
Once I get some initial support for frequency-based scheduling, I'm
probably going to do a intermediate upgrade to the api where I start
supplying the "headway" element in the <arrivalAndDeparture> element,
but also provide the "scheduledArrivalTime" and
"scheduledDepartureTime", set to x minutes in the future, where x is
the headway of the route. This will allow existing clients to operate
but also allow those of you who have upgraded your apps to use the new
information (basically, if headway is set, you can ignore the
scheduled times if you want). For example, it's going to take at
least 2 weeks for me to get an iPhone update approved (joy!), thus the
backwards compatability.
Ok, so that's a lot to digest. I know these changes have a number of
implications for some of the other api calls (most of the trip
methods, for example), but it's just going to have to wait for now,
especially after I've had some time to ponder how this will all work.
I'm looking for feedback on any and all of this, so let me know what
you're thinking.
Thanks,
Brian
David Robinson
o In a frequency based scheduling the idea that a trip is
Early/Late/OnTime makes little sense. The expectation is that
rider just shows up and and is onboard within N minutes. Any UI
that tries to make a distinction will just be confusing.
o The think your plan to set the scheduledArrivalTime to
be Now+Headway minutes is the best approach.This will work well
with most of the current clients indicating that a trip is always
Headway minutes away. I would add that if you have predicted data
for the trip, set scheduledArrivalTime = predictedArrivalTime. This
would have the nice side effect that any client that attempts to
calculate timeliness based on the difference in times would always
see the trip as OnTime.
o I would not make scheduledArrivalTime optional, but dynamic as
stated above.
o I would expect that even with frequency trips, they would all still
have unique tripId's. Reusing a tripId could have undesirable side
effects.
o In the tripDetails, I hope you can preserve the <schedule>.
Even though the trip is not running against a schedule, it contains
useful information that statically indicates both time and distance
between stops. If a client knows that a trip is at closestStop, it
can
use the schedule to determine the next stop and when it should
arrive. Useful for a UI that is dispayed for riders of a trip. I
would
suggest that you represent the <schedule> as a set of times that
are relative to the first stop. So the initial arrivalTime on a
schedule
is always 0, with each subsequent stop +M seconds. A client can
then use an active tripDetails to determine the actual offset and
calculate the actual schedule.
o Be sure to put <headway> in tripDetails <status>
-David
Brian Ferris
> o In a frequency based scheduling the idea that a trip is
> Early/Late/OnTime makes little sense. The expectation is that
> rider just shows up and and is onboard within N minutes. Any UI
> that tries to make a distinction will just be confusing.
Agreed.
> o The think your plan to set the scheduledArrivalTime to
> be Now+Headway minutes is the best approach.This will work well
> with most of the current clients indicating that a trip is always
> Headway minutes away. I would add that if you have predicted data
> for the trip, set scheduledArrivalTime = predictedArrivalTime. This
> would have the nice side effect that any client that attempts to
> calculate timeliness based on the difference in times would always
> see the trip as OnTime.
> o I would not make scheduledArrivalTime optional, but dynamic as
> stated above.
That seems reasonable as well.
> o I would expect that even with frequency trips, they would all still
> have unique tripId's. Reusing a tripId could have undesirable side
> effects.
Unfortunately, they won't have unique trip ids. If you look at the
GTFS spec, one trip instance is assigned to the entire frequency
block. I plan on handling this in the following way:
1) If no real-time data is available for any of the trips in the
frequency block, we'll return one scheduled frequency result in an
arrivals and departures method.
2) If real-time data is available for any of the trips in the
frequency block, we'll return ONLY trips with real-time data and won't
include the schedule-only frequency result. In addition, we'll add a
vehicle id to the arrivalAndDeparture element.
3) The combination of tripId + serviceDate uniquely identifies a
scheduled trip while the combination of tripId + serviceDate +
vehicleId uniquely identifies a real-time trip. The trip and
trip-details methods will be augmented to support that identification
process.
Thoughts?
> o In the tripDetails, I hope you can preserve the <schedule>.
> Even though the trip is not running against a schedule, it contains
> useful information that statically indicates both time and distance
> between stops. If a client knows that a trip is at closestStop, it
> can
> use the schedule to determine the next stop and when it should
> arrive. Useful for a UI that is dispayed for riders of a trip. I
> would
> suggest that you represent the <schedule> as a set of times that
> are relative to the first stop. So the initial arrivalTime on a
> schedule
> is always 0, with each subsequent stop +M seconds. A client can
> then use an active tripDetails to determine the actual offset and
> calculate the actual schedule.
Yeah, I think something like that is useful. I might have some more
comments on this once I start implementing and have to work out how
it's actually going to work internally.
> o Be sure to put <headway> in tripDetails <status>
Seems reasonable.
Brian
> --
> You received this message because you are subscribed to the Google Groups "OneBusAway API" group.
> To post to this group, send email to onebusa...@googlegroups.com.
> To unsubscribe from this group, send email to onebusaway-ap...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/onebusaway-api?hl=en.
>
>
David Robinson
> > have unique tripId's. Reusing a tripId could have undesirable side
> > effects.
>
> Unfortunately, they won't have unique trip ids. If you look at the
> GTFS spec, one trip instance is assigned to the entire frequency
> block. I plan on handling this in the following way:
>
> 1) If no real-time data is available for any of the trips in the
> frequency block, we'll return one scheduled frequency result in an
> arrivals and departures method.
> 2) If real-time data is available for any of the trips in the
> frequency block, we'll return ONLY trips with real-time data and won't
> include the schedule-only frequency result. In addition, we'll add a
> vehicle id to the arrivalAndDeparture element.
> 3) The combination of tripId + serviceDate uniquely identifies a
> scheduled trip while the combination of tripId + serviceDate +
> vehicleId uniquely identifies a real-time trip. The trip and
> trip-details methods will be augmented to support that identification
> process.
>
> Thoughts?
Having written a bunch of trip caching code that had the assumption
that
the base trip element and details are mostly static, and only the
status was
dynamic, this sort of tripId reuse may be problematic. I could change
the
key in my cache to be the combinations you outline.
As an alternative, you could follow the GTFS model and assign a single
tripId for the headway group. But for its status element never set it
to
have predicted true, and follow the scheduledArrival hack where it
always
equals Now+headway. Then if you have an actual running trip, create a
new
tripId that is "tripId = groupTripId+vehicleId", whose details include
all the predicted data as expected.
With this approach you fit closer into the existing data model,
although
there are some funny looking tripIds. It also allows you the
flexibility to
include include both the generic headway trip as well as active trips
without having to make any complex distinction because there is
always a unique tripId. A simple/legacy client
can just process both using the same code, just the generic trip is
always seen as N minutes away. A more sophisticated client can
choose to not display the generic trip when active trips exist, use an
alternative UI for the generic etc.
-David
cooki...@gmail.com
Manager) said that the coaches using the new radio system--RapidRide
will be the first starting tomorrow--will be patched into the old
tracking system. As more coaches get the upgraded radio system, they'll
be patched into the current tracker to provide (theoretically) seamless
tracking information. When all coaches have had their radios upgraded,
they'll cut over to a new tracking system, which isn't complete yet.
So if all works well, look for route 674 on tracker in about 8 hours.
Also, be aware that Metro is focusing a lot less on schedules and a lot
more about headway with the launch of the A Line. Part of this is due
to the numerous changes over the old 174. Stops have been deleted, 20
intersections will have transit signal priority (TSP), and off-board
payment is available at some locations, and Metro knows these will speed
up the travel time. Off board payment, none of the TSP signals being
online, and the general newness of the service will slow it down.
Whether these cancel each other out or fall on one side Metro won't know
for a few weeks.
And there was something about "calibrating" the tracking system. So
maybe it won't show up tomorrow. Someone (either Dow or Kevin) did
mention that the real time boards at the stations won't be online for a
couple of weeks.
Tim
Brian Ferris
enough, it looks like Metro still included the full schedule for Link
Light Rail and Rapid Ride Line A in their GTFS, even though they also
included the frequencies entries. The upshot is that OBA is still
producing schedule data just like it was yesterday. I'm not sure if
that was intentional on KCM's part, but I know they intend to remove
all schedule info at some point.
Either way, we can still move towards frequency-based scheduling
support in OneBusAway, just without quite so much pressure.
Also to add to Tim's comments, the Rapid Ride Line A is appearing as
scheduled in both the KCM Tracker and MyBus as route 671. However, no
real-time data yet.
Thanks,
Brian