trips-for-route

[Michael Frumin]

Brian,

I have a question about the trips-for-route REST API call (context: we know it exists, and I believe you are in the process of adding it to the REST API documentation).

The question is this: is it possible/are there parameters to have it only return trips that are actually active at the moment the call is made? Right now, when I call it (say at 10am) I get back trips that are recently finished (eg at 9:55) or are soon to start (eg at 10:05). Of course I can do this filtration myself if needed, but it seems like the kind thing it would/should have options for.

Note: I am setting includeStatus=false -- I am just using it to query the schedule, aside from whatever realtime buses/trips may or may not actually be happening...

Thanks,
Mike

[Brian Ferris]

I had to go back and look at the source to be sure, but I think the
current behavior you are seeing is because route layovers are also
included in our definition of "active" routes. I think this behavior
was actually a requirement for a use case of the original BusTime UI
for the B63 pilot. Adding a parameter to exclude layovers would be
relatively straightforward, but then you'd need to backport the
functionality into whatever branch of OBA you happen to be running,
since I'm guessing it's not trunk.

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

[Michael Frumin]

Brian, this makes sense, though perhaps I think you mean "trips" rather than "routes", right? Eg the trip is on a layover.

Correct, we are not running trunk right now. Maybe this is just something to think about for longer term development. For now I will filter results on the client side.

But, this does get me back to something we talked about -- having all (or most) OBA Webservice API calls return/include the timestamp on the server when the call is made. The reason I ask is because if I will be filtering trips client side, I would rather not be thrown off by a couple of minutes of clock skew. Obviously it's not a major issue and I'm happy to deal with it for now, but while we're talking longer term stuff...

Thanks,
Mike

[Brian Ferris]

Correct, I meant to say trips.

In terms of adding the current server time in each response, this was
actually implemented as part of the 1.x release. A common
<currentTime/> element is included in each response. You can see an
example here:

http://api.onebusaway.org/api/where/arrivals-and-departures-for-stop/1_18120.xml?key=TEST

Also, check the documentation:

http://developer.onebusaway.org/modules/onebusaway-application-modules/current-SNAPSHOT/api/where/index.html#Response_Element

Thanks,
Brian

[Michael Frumin]

D'oh!

[Michael Frumin]

Brian,

Does trips-for-route have by any chance a hidden 'time' parameter, sort of like arrivals-and-departures-for-stop, that allows you to get query results for times other than now() ?

Thanks,
Mike

[Brian Ferris]

Indeed it does.

[Michael Frumin]

Great news. Sorry to nag, but will this call (and its parameters) go up on the REST API documentation some time soon? It would be helpful to have this reference to share with some folks.

Thanks again for everything,

[Brian Ferris]

Documentation for the trips-for-route call? That's been up since last
week, but maybe I forgot to ping you with the link?

http://developer.onebusaway.org/modules/onebusaway-application-modules/current-SNAPSHOT/api/where/methods/trips-for-route.html

It's only in the current-SNAPSHOT documentation at the moment. I need
to clean up a few other issues before I cut a release.

Brian

[BandonRandon]

I don't know if this is worth adding but I sovled this problem by
saying that if the time was less than the current time then not to
show the result at all. This of course happened AFTER the API call

[Michael Frumin]

Ok, an observation: trips-route returns lots of trips not for the requested route. It includes lots of trips on other routes if they are on a block with trips on the requested route.

I'm sure this is intentional (?) for one reason or another, but it was definitely confusing at first. One can easily filter out using the routeId's in the references, so mostly I'm just curious as to why.

[Brian Ferris]

That is indeed the current behavior, introduced specifically for block
trips. I suppose we could add a flag to filter them out.

Brian