Stops for "wrapped trips" in stop-level API calls

[Frumin, Michael]

All (cross-posted to transit-developers and siri-developers),

 

We are contemplating some API improvement to the Bus Time API (http://bustime.mta.info/wiki/Developers/SIRIIntro), and there’s an issue with a non-obviously-right answer that we’d like some feedback on if possible.  Unfortunately, it’s hard to ask the question without setting the stage a little (which may ultimately mean that it just doesn’t matter).  The question surrounds what to include in stop-centric API calls about a bus that has not yet started the trip on which it will serve the stop in question.

 

Please consider the following abstracted/idealized example (the discussion below refers to it extensively): https://docs.google.com/drawings/d/1LCbi3GLTPrJVjCslRZXrAJ-1dLp3d5mSNeB9-WiKEZk/edit

 

Currently, we only include information about a bus for its current trip.  In the pictured example, that means that at the moment pictured we would only include the bus when queried for stops on Trip A.  Not until the bus reached the terminal would we include the bus when queried for stops on Trip B.  This discussion is about extending that so that we could include the bus (while still on Trip A) for queries about stops on Trip B. 

 

[TO BE ABSOLUTELY CLEAR: it is *not* that OneBusAway doesn’t handle block associations and link trips together into blocks (it does exactly that in Seattle).  Rather, we have taken a somewhat conservative approach to showing customers information that depends on assumptions about the next trip a bus will make while we grow comfortable with the block assignments that it infers, and how stable those are given our real-world operations that often cause a bus to do something other than what is prescribed by its block.]

 

The basic question is this: when including info for a bus on Trip A in the response to an API call about a stop on Trip B, what would people expect/want to see in terms of the other stops that bus will serve?  It should be noted that no other real-time transit API’s that have queries at the stop level (analog of the SIRI StopMonitoring service we expose) include info about *any* other stops the returned buses will serve.  Maybe there’s a good reason for that…

 

Currently, we use OnwardCall elements to show all other stops that the bus will make on Trip B after the queried stop (i.e. the MonitoredCall).  This is actually not in spec with SIRI, which says that the OnwardCalls should start with the immediate next stops the bus will make (even if they are prior to the MonitoredCall).  We want to improve that, but it’s not totally straightforward when the bus is currently on Trip A but queried for a stop on Trip B.

 

Possible options are:

 

1.       Forget about it – don’t show any OnwardCalls in StopMonitoring at all.

2.       Do not show any OnwardCalls until the bus is on Trip B.

3.       Only show OnwardCalls for Trip B, even when the bus is still on Trip A.

4.       Show a long list of OnwardCalls, starting at the next stop the bus will make on Trip A and going through the last stop on Trip B.  This is weird, because some of the stops will be on a Trip A while the SIRI SM responses will give the bus the trip_id for Trip B (i.e. the one that the bus will be on when it serves the queried stop).

5.       (3) + add an additional MonitoredVehicleJourney for that bus for Trip A, will all remaining stops on Trip A, but with no MonitoredCall.

 

Thoughts?

 

Thanks,

Mike