Measured Benefits of One Bus Away

52 Replies to “Measured Benefits of One Bus Away”

1. Metro should actually fund keeping OBA up to date and reliable. A power outage in someone’s office shouldn’t take down a web service – it should all be hosted in a place with power backup, and it should be actively developed.

   1. Yeah right. That means one agency will have to take responsibility and spend their own money. It’s easier to keep bickering while singing OBA’s benefits and letting the UW foot the bill. I can see it now:
      ST: More Metro riders utilize OBA, so Metro should pay for it.
      CT: We don’t need OBA. We have nice maps at our stops and our buses run on time.
      PT: We love it but we’re really broke.
      Metro: OBA is regional thus ST’s problem, and they have all the money.
      WSDOT: Let’s study it for 5 years then say no.
      Seattle: How will running these OBA computers contribute to climate change?
      ET: What’s “One Bus Away”?

      This could become a bad sitcom!

   2. Ben, this is 2012, it doesn’t need its own server. AWS is the right spot for it.

      1. well, Ben might be partial to Azure. But perhaps Brian could provide a Google Cloud resource?

      2. Do we really need to have a debate about which cloud service is appropriate for OBA?

      3. Yes, Kyle, we do.

   3. Or it could be put on a cloud server, like Amazon’s.

2. Is the OBA data accurate again?

   1. Not completely… Arrival times for my 249 still sucks.

      1. Yeah, several times lately it has told me that I’ve missed my 226 by a 2-3 mintues, and then lo-and-behold, 3-5 minutes later, there’s my bus. Luckily, I can see the bus stop for at least 5 minutes before I reach it, so I know the bus hasn’t come yet.

3. I heart that app. Yesterday I was waiting quite a while downtown for a 358 and saw on OBA that there were 2 358’s about to arrive, one just a couple minutes after the first. Of course a LOT of people got on the first one, since there hadn’t been a 358 that had come by in a while, so I waited for the second one. Had a seat all to myself and a very pleasant ride home compared to what I’m sure was a stuffy, crowded, unpleasant ride on that first bus.

4. Do we have wifi hotspots yet in all the ST tunnel stations? Because last night there were problems with the #316 and everyone was just standing around on the station looking completely lost.

   Certainly wifi hotspots in all the underground stations would be easy to accomplish. You might even get a vendor to provide such a thing for free in exchange for certain advertizing rights.

   I’m just saying…

   1. I can see WiFi, although I think we should just skip that and get the cell providers to extend service into the tunnel.

      Also I’ve been known to hop on a bus and go to convention place/international district station to get to cell service to check on OBA.

      1. Is it the cell providers’ fault, or is it the design of the stations themselves?

   2. In a city with competent transit agencies, those fancy variable message signs in the tunnel would tell you when your bus was coming.

      1. But I often want to check on a connecting bus but with no signal in the Tunnel, I have to wait until ID or Stadium to do it.

         It should be easy to extend the Seattle municipal WIFI into the tunnels. However that service is currently pretty unreliable.

   3. Ideally, the tunnel stations would be getting the highest priority for real-time arrival signs. You’ve got the combination of lots of riders and lack of cell-phone reception for the regular OneBusAway service. However, when I last checked, the freeway station at 520/Overlake TC got one, but the downtown tunnel stations didn’t. Go figure.

5. OBA has had many troubles lately. I’ve given up on the android app and now use a weblink to access vehicle status for the route and bus I’m expecting to take. This works, most of the time…just wish the vehicle status was accessable on OBA mobile and in addition to showing the times of the next arrival, show the location of all busses on that route ala MyBus (which sorely needs an update)

   1. Lately, OBA has been unreliable for the 132. On several occasions it has reported the bus 20 mins or more delayed, then the bus shows up on time. I never had this issue with the 54. I wonder if it is an OBA software flaw in routes that change from one to the other on 2nd vs 3rd (24-132/131, 5-54/55) or a lack of transmission points on 2nd vs 3rd.

      1. I’ve noticed the same thing on 4th – too often only the scheduled time is listed for the 24 and 33.

         Overall, OBA has saved me a lot of time, but I’ve learned not to rely on it too much. Sometimes common sense prevails.

      2. Its with many routes. I know they are having difficulties and of course we appreciate their work, but its difficult to trust it now. For instance, yesterday the 556 was reported as 37 minutes late, yet it arrived at Bellevue Transit Center, on time. When I looked up the vehicle number using a vehicle-status query in the browser version, it showed the bus on the 520 floating bridge…something is off. Am trying a different software starting today but I will compare OBA’s numbers to the metro MyBus info and see if there is a problem between the two.

      3. I noticed this awhile back when I was on the 28. It said 20 minutes late, and since I was only going a mile, I figured I could walk that easily in that time.

         Needless to say, I only got to the next stop when it showed up. I saw that it had a GPS locator on top of the bus and assumed that some of the buses that get switched over to GPS have trouble communicating their location, which gets translated by Metro servers to a time estimate.

      4. yes, as its been stated before, since the older system is not necessarily forward compatible, GPS data has to be “downgraded” to work with the older system. At least this is what I’ve heard, I may be off base here.

      5. Read all about it here.

         Short answer: things will get better once all the buses have GPS, which should be by the end of the year.

   2. As great as OBA could “potentially” be — at this point it’s worse than the Metro schedules. Real time data implies trust. And my personal experiences with OBA make me not trust it per se…to many times waiting for “phantom” buses. To much confusing noise in the display ( -3 minutes — what does that means ?!)

      I actually would prefer a Metro app with the fixed-time schedules that was easy to read and search on an Android. Right now I use my browser and have to zoom around to read all the tiny text. Just a simple couple of drop down boxes, or text entries for route and station. And then a listing of the expected times.

      Right now OBA is GIGO — until each and every bus gets a real time GPS.

6. on the past two Sunday Evenings … OBA didn’t even bother to show the Rt.60 (north or southbound) even though there were at least 5 more scheduled runs for the night

7. I often use OBA, but I find the information to be wrong a fair amount of the time. Also, the other day on KUOW I heard the director of KC Metro say that once the buses are all outfitted with GPS that the technology will not be used for OBA. I am curious why they would continue to use timetable data instead of GPS.

   1. Why wouldn’t the open-source community just request access to the new GPS data and program a widget or whatever that uses google maps to live-track all the buses in the city? Just hard to believe a better data set would lead to a worse end product…

8. It bears repeating that OneBusAway relies on arrival data provided by the transit agency. The information OBA provides is only as good as the data it receives from KCM, ST, etc. Of course OBA itself occasionally has problems, but when it says a bus is 20 minutes late and the bus rolls up on time, its likely not OBA’s fault.

   1. I think there are cases where OBA should be able to guess that the data is probably wrong and default back to the schedule. I was waiting at NE 65th/42nd for a westbound #30 last night. OBA said it was on-time, then changed its mind and said it had departed 30 minutes early. If the data says the bus is 30 minutes early, it’s a lot more likely that the data is wrong than that the bus is actually 30 minutes early (in reality the bus was about 10 minutes late).

      There are also “phantom buses” in OBA; I see phantom 255s often along 6th St S in Kirkland. Even if the phantom bus readings come directly from the transit agency, they follow certain patterns, and it should be possible to filter them out.

      1. The problem with the schedule is that it’s not totally obvious at first that “scheduled departure time” doesn’t mean “on time” instead of “no data available”, which is just straight-up bad user experience.

      2. The filtering to try to figure out what data is wrong and what data is right is probably a horrendous task. Efforts would be much better spent by actually figuring out how to clean up the data in the first place.

         (One of the spots where I think data can be cleaned up is when drivers log in as starting their run early, but don’t actually start driving, this is something that could easily be handled in a programatic way.)

      3. I am a software guy, though I don’t know what OBA’s code looks like. Certain kinds of filtering (like getting rid of ghost buses) might be hard (either in developer time or CPU time or memory) depending on the characteristics of the problem, what the existing software does, etc. But it can’t possibly be hard to revert to the schedule when the bus is more than 10 minutes early. Buses just don’t arrive that early! The drivers wait! There will always be glitches in the data, half the point of software is to handle glitches.

      4. Al – the code is open source. I know they were on google projects for a while, but I think they migrated to github.

      5. One common case where OneBusAways screws up is where buses are sitting in layover before they even get to their first stop. If the bus is sitting in its terminal and it’s not time to go yet, the bus is, by definition, always on time, yet I’ve OneBusAway claim such buses to be anywhere from 20 minutes early to 20 minutes late. This case ought to be work-around-able on the software side, even if the root cause is the underlying data feed.

   2. That’s not always true. I’ve seen plenty of instances where Metro’s tracker shows an accurate arrival time while OBA doesn’t. There is a lot going on in the background that is complicated by the fact that Metro still has 2 bus location systems (OBS & AVL). I’m *hoping* this all gets cleaned up when the OBS conversion is done but the lack of solid funding / ownership of OBA has me concerned. I used to love OBA but find it very frustrating to use these days.

9. I believe Kari deserves most of the credit for getting this particular research result.

   1. Yeah, yeah, Alan “Dorning” and I are used to you getting all the credit. ;-)

      For others interested in this kind of “impact of real-time” research, see our website http://www.onebusaway.org/p/Research.action. I’m trying to do more of this kind of work in my new role at Georgia Tech.

10. Until leaving the OBA/Seattle region, I never realized how great OBA was. The app really is incredibly useful and powerful. It really boosts the usability of transit and starts to give it that car-like feeling of freedom. If this app went nation-wide, it really change the way our country looks at transit.

    Here in SD, we have OBAlite. The transit agency itself put together the app. Sadly, you have to know the stop ID to actually use it. And it doesn’t store previously-viewed stop ID’s. So either you have to have them posted on your wall (like I do), look at a schedule, or stand next to the stop. With their idea of frequent service being every 15 minutes, real time info is critical to making the system usable. Happily, MTS has excellent integration with Google Maps so it provides some relief when trying to transfer.
    http://www.sdmts.com/go_app.asp

11. App is great. However, I may be an outlier on the study. I have found that my annoyance of the near universal lateness of the 18 and the 18X during rush hour has only grown.

12. Prior to One Bus Away I’d ride the bus maybe eight or ten times a year. I’d typically wind up walking because I didn’t feel like waiting for what could be two minutes or forty minutes. Now that I have the app on my phone, I probably take the bus more like eight or ten times a week. I’ve gone from spending twenty bucks a year on the bus, to something closer to four hundred a year, and I love it!

    I can’t be the only one with an experience along those lines.

13. I’ve seen some wacky results from OBA like many people above. But I can’t tell you enough about the joy I feel when OBA says my bus is arriving NOW and I look up and the bus is coming around the bend. Thank you Dr. Ferris and team for creating this truly wonderful and useful tool.

14. One of my rules is if all the routes on a stop are listed as On Time, then totally distrust all the shown data.

15. I echo the negative effect that the GPS change-over seems to be having on OBA. And if it starts to become notoriously inaccurate, then folks will just stop using it.

16. A few comments on the current status of OneBusAway may be helpful here.

    OneBusAway yet lives on because of funding from three local agencies: King County Metro, Pierce Transit, and Sound Transit. In my view, that’s an impressive commitment to customer service, particularly when budgets and in some cases service levels have been cut. That funding pays part of my salary, so I have a bit of bias.

    OneBusAway infrastructure consists primarily of a number of server-class computers in a machine room on the UW campus- not, say, a desktop box in a corner of somebody’s closet. It’s true that the service went down during the power failure this week. Such failures are rare- this was reportedly the worst in fifteen years. The service also depends upon data fed from machine-room computers run by the UW ITS research group and upon data from equipment, in the case of agencies that provide real-time data, in machine rooms hosted by the agencies. Last week’s other power failure took out some functionality for a bit.

    We are aware of the issues with ghost buses, some missing trips, and inaccurate arrival predictions. Some of those problems are due to incomplete schedule data from agencies, and some, less well understood, are expected to lessen as the transition to GPS-based real-time data from King County Metro is completed late this summer or early this Autumn.

    We depend heavily upon customer reports to help us detect and correct errors. We read if not relish or respond to every one we get. contact@onebusaway.org.

    1. Glad to know my bus reports are useful to OBA staff.

17. While my overall experience with OneBusAway has been great, one thing I have learned with time is that it can’t work magic and any OneBusAway information is only as reliable as the path of the bus between where it is now and where I’m getting on it.

    With reliable routes, OneBusAway says “10 minutes” and 10 minutes later, the bus comes. With unreliable routes, when OneBusAway says “10 minutes”, the actual arrival time can be anywhere from 10 minutes to 20 minutes, sometimes even long. I can recall a few particularly bad incidents where OneBusAway claimed the bus was 5 minutes away, only to see 2-3 minutes of wall-clock time tick off for each minute closer the bus got to my stop.

    To help people who don’t know which routes are reliable and which routes aren’t make informed choices, it might be useful if OneBusAway listed arrival times as a range, rather than an absolute time number. For example, if OneBusAway says “5-8 minutes”, this would mean that, based on historical travel times (controlling for peak/midday/evening/weekend), 95% of the time, a bus of this route at its current known location right now will reach your stop between 5 and 8 minutes from now.

    Information on reliability would be particularly helpful in deciding whether it’s worth walking a little bit further to get a faster or more reliable bus.

    Another feature that would also be nice for freeway-running buses would be to incorporate real-time traffic information into the arrival forecasts.

18. I’ve never had it explained what the difference between “arriving in” and “scheduled in”. It’s sure not explained on the OBA site.

    1. As far as I know, “Arriving In” means that OBA is receiving location updates for the vehicle, and as such can estimate the arrival time. In other words, “Arriving In” = Real Time Data.

       “Scheduled In” means OBA isn’t receiving real-time data for that coach/route/run, but is using the schedule data provided by the agency operating the route. Some agencies, like Community Transit, don’t provide a real-time data feed, so their routes always show the schedule data.

19. I’ve had some bad experiences with OBA with the #26 at 40th and Wallingford. The worst one was when OBA said “NOW” and there was no bus for 40 minutes. It would go in and out of “NOW” and then “five minutes” and then “NOW” and then it would disappear altogether.

    I’ve also been at 3rd and Union when OBA said there were five buses “NOW” and there was not a visible bus northbound on Third either to the north or south.

    Before I had an OBA-available phone, I’d ordinarily take the first bus heading in my direction (16, 26, 28) and either walk from where the 16 dropped me off or transfer at Fremont if I took the 28. I started to change my behavior with the advent of OBA, but then I got burned a few times so I’m basically back to where I was.

20. Thanks Scott for coming to KCM, ST & PT’s rescue. The agencies are doing their best to keep OneBusAway up & running temporarily at UW. We are running on limited resources though. In the meantime, we are looking for a more permanent solution. Here’s a question for active STBers (especially coders): if you knew OneBusAway could be more accurate by you volunteering your time, would you do so? Would you donate 1, 2 or even 5 hours per week to identifying & consolidating holes in the data?

    1. What language is oba written in? I would like to help out if it’s one I know.

Comments are closed.