OneBusAway app screenshot

OneBusAway has become a useful tool to many transit riders but recently the arrival predictions have become more erratic and unreliable since Metro’s program to equip its bus fleet with GPS began. Eastside buses like the 255 have been giving wild estimates like 100+ minute delays or fluctuating between schedule data only and real-time data. And there was a case where the next Route 26 bus was predicted to be over five hours away. Incorrect information is worse than no information since repeated mistakes eventually undermine people’s confidence in real-time information. At the very least it is good for nothing; at the worst it could mislead and create trouble for those who trust it. OneBusAway is only as good as the data provided by the transit agencies.

The problem with King County Metro’s real-time data is a complex one. It involves the combination of two vehicle location systems (the old odometer based system and the new GPS based system) and the translation of data from those systems into a format that OneBusAway understands. I asked OneBusAway’s S. Morris Rose whether the problems would go away once all of Metro’s buses are fitted with GPS. Rose told me that they now think the problem is related to the GPS-equipped buses. Rather than wait for the GPS transition to be completed, work is underway to address the problem with meetings between OneBusAway and Metro engineers. Given their limited resources, I hope that is a sign that Metro is taking data accuracy seriously; if not they really must, because customer trust is hard to win back once it is broken.

76 Replies to “OneBusAway Data Accuracy Matters”

  1. I stopped using OneBusAway a while ago because of this issue. It seems that buses are now more likely to arrive at the scheduled time than whatever time OneBusAway happens to be guessing at the moment, and these guesses fluctuate wildly. I hope they do find a solution soon, it was a really useful tool back when it actually worked.

    1. Yup had to stop using it as it was useless.

      And given that I have a 15-minute walk to my bus stop, too much can change anyway. It’s why I like have a schedule, and none of this “frequent service” BS like on RapidRide.

      1. Yes but 15 mins is not frequent, and most of the RapidRide routes are 15 mins frequency. Even at 10 mins service a schedule is useful since it’s so easy to remember. Once it’s 8 buses/hour or more, then it’s frequent enough that you don’t need the schedule, but I’d say at 10 mins or less, a schedule is useful.

  2. As OneBusAway has gotten less reliable, I take less transit trips – down to about two a week now, from a minimum of two a day previously. With one of my main routes frequently subject to long delays and another that was never correct in the first place no matter how many corrections I tried to submit, I ended up wasting too much time standing around.

    Even with my transit use paid for 100% by my employer, it’s not worth it if I have no idea how long I’ll be waiting around for and it frequently ends up over 10 minutes.

    1. I haven’t cancelled trips thanks to the problems, but I’ve shifted my trips. The 27 is infrequent and unreliable. But a much, much faster way of getting from downtown to 20th than the 14, 7, or 36. With OBA I was able to catch the 27 every time. With OBA failing, I wasted half hour after half hour chasing ghost 27’s that would appear and disappear until I finally gave up. Now I show up for the 27 and if it’s not there I take the first 14, 7, or 36 that arrives and walk further on the tail end.

  3. I still find it valuable, but perhaps that’s because I already know how spotty the data can be and factor that in. I prefer it to no data at all, and appreciate having the schedule info available per-stop even if the arrival data is messed up.

    But this issue is one of the key reasons Metro resisted providing real time arrival data up to now. It takes a lot of work to get it right. Early real-time data at Northgate and other locations were provided by the UW, without a lot of involvement from Metro because of this concern; but as the demand and expectation for this data increases, there’s no putting it off. I’ve always felt its worth the effort and expense, since uncertainty and complication are some of the biggest obstacles to relying on transit – especially for non-work trips.

  4. Besides the problems Oran noted, I’ve also noticed that sometimes buses will “magically” speed up – gaining 3+ minutes relative to their schedules in only 1 minute of real-time. This might have more to do with rounding delays to whole minutes and irregular refresh rates, though, than it does with these data issues.

    Another problem is that rush-hour schedules for many 3rd Avenue buses are not allowing enough time to get through downtown. An “on-time” bus on OBA can easily be 5 minutes late when it gets to Belltown. Unless you are very close to the bus stop, you’re going to leave your origin before the delay is captured by OBA and you’ll be waiting at the stop. This is not OBA’s fault, but Metro’s schedule planning might be a little optimistic. I rarely see “on-time” arriving northbound buses in Belltown when checking OBA at rush-hour

  5. I’m certainly relying on OBA data as much. I’ve had a problem Downtown in the evenings with disappearing 16s. You’ll get a OBA message that it’s later and later and then it just disappears. Not sure if this is a OBA thing or Metro cutting their losses and canceling buses that are overly late but it’s really frustrating as a rider.

  6. Oran:
    I wish you would have also contacted Metro before writing this post, so we could add to the information you got from from One Bus Away. Your explanation above over-simplifies a very complex situation. This is not merely a case of bad data going out from Metro.

    Metro provides data to – and, to the extent possible with available resources, works with – the application developers, but does not control the resulting products or interfaces. Once the data is sent by Metro, the application the public sees is hosted, managed and maintained by the private owners of those systems.

    Given the amount of transit service on the road, the amount of data that is generated and needs to be processed, and the many real disruptions that are constantly occurring, most of these systems work amazingly well much of the time. But, none are 100-percent accurate all of the time.

    Accurate bus tracking depends on both scheduled data that defines where and when the bus should be, and “real time” data that reports where that bus actually is right now. It is a complex equation, even before you take into account the daily disruptions and exceptions that can delay or reroute buses.

    Schedule data is updated several times a year. “Real time” arrival data is updated constantly. Combine these two data types and apply algorithms, and you’ve got an educated guess – or prediction – about when a bus will arrive at a specific location. There can be problems with both data types, as well as with the algorithms, that lead to false predictions. And, even the best predictions can be affected by real world variables such as weather, traffic, equipment malfunction, etc.

    As you noted, Metro is in the process of transitioning from an older locator system to a new GPS-based technology, and is operating with two systems, which complicates the task of data reporting. But, we cannot blame having two streams of data for all the problems users are currently experiencing.

    The types of challenges noted above also apply to Metro’s Tracker program and virtually any other real-time app that is available in our market. No matter how different they may look, all of these programs rely on the same basic data sets and similar functionality.

    We undestand that transit app users are frustrated with the unreliability of the tracking programs, and Metro is working to make its own data and reporting systems better in all its formats; customers’ patience is appreciated during this ongoing process. Improvements to non-Metro systems must be made by those systems’ owners.

    1. [Linda], is there any plan at Metro for supporting a smartphone based application for finding out bus positons? It seems strange such an important feature is left in the hands of what are effectively volunteers.

      1. OBA’s “minutes until bus shows up” is user-friendly, but especially given the issues it’s having, I’d prefer to at least have the option of seeing where it actually is right now and figure it out that way.

    2. Setting up a data feed with an API, managing “volumes” of data from multiple vectors, and wrapping some kind of estimated arrival time in the feed are problems solved by other transit agencies in other states and countries. It is not hard.

      The issue with OBA seems to be less of a problem with technology and more of a problem with priority and funding. Until a mandate exists we will be stuck with a loose collection of tools and feeds that are buggy and inaccurate.

    3. Linda,

      OBA was working reasonably well about a year ago. Has the development team broken OBA or is it that the data feed is different?

    4. All I get from this is that we have a he said/she said. OBA will tell you its due to faulty data from Metro, and Metro will blame OBA.

      So Linda, how long is this “ongoing process” going to take? If it takes a year, there won’t be any users left to worry about.

    5. When will the transition to GPS be complete, and at that point will a real-time bus locator be available? Complicated algorithms to guess-timate arrival time are one thing, but I—and I am sure many others—would be more than happy if we could just see our bus on a map and calculate for ourselves when we need to leave the house or office. The Chicago Transit Authority’s bus tracker does this wonderfully.

      1. OBA’s “minutes until bus shows up” is user-friendly, but especially given the issues it’s having, I’d prefer to at least have the option of seeing where it actually is right now and figure it out that way.

      2. yes, exactly, give me a map that shows my bus!!! and while you’re at it, let me pick points on the map for the trip planner too. !!!

    6. I’m sorry to point a finger, Linda… but this sounds like a typical canned response from a public agency.

      Readers of this blog are much more likely to understand the complexities of setting up this system, and we are all well aware of the staffing transition and limited budgets for this program.

      However, there is simply too much anecdotal evidence from all of us that much of this data corruption has occurred as the GPS-equipped buses hit new routes.

      That suggests either corruption on Metro’s part in the data, or a need to for more efforts on Metro’s part to work out the problems with OBA and other apps.

    7. thanks for the reply Linda … but what about when buses like the 60 simply do not show up at all on OBA on weekend evenings … that would seem to be a problem with Metro’s data feed … not OBA … wouldn’t it?

      1. When I have seen wildly inaccurate data on OneBusAway, and checked Metro’s own tracker, it too is wildly inaccurate. It certainly seems like Metro is producing the bad data.

    8. I have an idea.

      The GPS locates the bus.

      The OBA application shows the movement of a bus on a map.

      The rider sees where the bus is, and knowing the kind of streets, the current traffic conditions, and other factors, is able to estimate the arrival time.

    9. Thanks Linda for the additional information.

      I understand that it’s a very complex issue and I glossed over a lot of details. I simply wanted to make a point on accuracy since many people, myself included, have had trouble with it and report that Metro is working on it, which is appreciated.

      I wish customer information was a higher priority because it is a large part of the riding experience, often being the first contact between Metro and the (potential) transit customer. Appreciate the efforts at improving the website and all but it’s just frustrating to see something that worked well go bad.

  7. I hope metro can wrap their heads around the importance of getting this squared away. You could save countless service hours buy just being more accurate on data issues. for a 400+M annual operating system (500?), this should be able to easily produce millions in value, either in terms of additional revenue generation or in terms of retaining existing users. More importantly, from the standpoint of political support for existing and future tax base, executing on this feature is very importantly for casual users who might be willing to take Metro to a sporting event or shopping downtown. Finally, Metro probably thinks of the commuter population as a captured audience, but many like me choose between modes on a daily basis. If I need to work late and miss the express trips, reliability for route with 30 minute headways is exceptionally important.

  8. From the reported issues, it almost seems like a bug in the GPS implementation. It’s as if the GPS implementation is extrapolating the current speed (such as when it’s stuck in traffic) all the way to the bus stop.

    1. Edit: I didn’t mean the actual GPS, but the software/algorithm that translates GPS data into future predictions.

      1. And is that done at Metro before the data stream gets sent out or is it down at the “private” provider?

      2. @Charles — Thats the most important question, and what I hope Oran and Linda will work to answer. What data does Metro provide to the “private” provider? Then we can start figuring out who to encourage to fix things.

    2. I think it might be a problem with the incredibly low quality of systems they’re installing on the buses.

      I mean, can any of you truthfully say you’ve ridden a GPS-enabled bus with stop announcements where the system worked 100% as intended? I sure as hell haven’t.

      The outside announcements are never working. I’ve heard one maybe a half-dozen times, ever, and never work on a bus I’m actually riding.

      The on-board stop announcements work for less than half the stops. When they do work, the message is often garbled – it begins speaking at a point somewhere in the middle of the stop name, and loops when it reaches the end of normal announcement end to the beginning (resulting in a message something like “Boulevard and Southwest 136th St Ambaum). Or it will just loop a stop name over and over indefinitely. The onboard test message boards will randomly stop updating and then randomly start updating again, but are still more reliable than the audio messages.

      So why should I believe that the location data the system radios back to Metro is of any higher quality than anything else it’s spitting out?

      1. I’ve not ridden too many GPS equipped buses with the announcements and reader boards, but it’s been my experience that all stops are listed on the reader board and only _major_ stops are announced. I also noticed on the several buses I’ve been on with the announcements and reader board that on some buses the announcements are extremely low volume. Does bus operator have control of how loud the announcements are made? Maybe the operator doesn’t like the loud voice repeating constantly during the driver’s shift?

      2. I’ve not ridden too many GPS equipped buses with the announcements and reader boards, but it’s been my experience that all stops are listed on the reader board and only _major_ stops are announced.

        That’s what I thought at first, but the more I ride the more I’ve become convinced it’s simply malfunctioning. Besides, when the human operators were doing the announcements, they were supposed to announce EVERY stop, major or minor, so why wouldn’t they program the machine to do the same thing?

        I’ll ride through a residential area, and it’ll dutifully announce every minor stop for a minute or two, then it’ll stop making announcements entirely and skip a bunch of major stops. Then it’ll garble a couple, skip another bunch, and then resume announcing every minor stop.

        I’ve ridden the same routes a several times on different coaches, and from what I can tell, they always announce completely different sets of stops.

        An easy one for me to recall is the stretch of the #8 between Jackson and Mt. Baker Transit Center, which is my typical link to Link (har har). There’s only 6 stops on that leg, with some distinctive announcements on that leg of the route(Center Park, Lighthouse for the Blind), and I notice when they are missing.

      3. KCM uses Init as the vendor of the positional system. They are a major player in this market. Translink in Vancouver uses them, too. Their stuff isn’t trash.

        Then something is very broken about Metro’s implementation.

        But then, the ORCA system was crap for the first 6 months or so, too, so maybe it’ll just take time.

      4. When the operators announced their own stops they were only required to announce MAJOR stops, not every stop.

  9. The northbound segment of my bus, the 60, has disappeared all together. While Linda’s explanation that “it’s complicated” suggests we should be patient during a transition and hold OBA responsible as well, this kind of error isn’t about 2 systems, it’s about sloppy data. A look at how they handle processing their data would probably reveal a lot about what needs to be fixed to improve this service.

    1. yeah … just mentioned this above … about the 60 disappearing completely from OBA (especially on weekends)

  10. “incorrect information is worse than no information”

    As one who missed an important work meeting last week as the result of trusting OBA, I would like to ask that OBA be taken down until its accuracy is restored. Not being able to time transfers effectively means that I will be unable to trust transit for anything but a one-seat ride commute (since I board at the first stop, it’s almost always on time). Lunch? Work meetings? Errands? Forget it…this problem is so serious that I’m considering getting a car.

    OBA has allowed me to visit other neighborhoods within a reasonable amount of transfer time. Capitol Hill to Ballard is a royal pain in the ass (come on Seattle Subway!), for example, but OBA has made it tolerable, allowing me to check whether or not I should take 8 to 17/18, 43/49 to 17/18, or 43/49 to 44. Without that ability, ZipCar it is.

    I trusted the trolleys on OBA until recently…but I’ve seen at least one trolley with the GPS hat on…grr.

  11. Oran, OBA, Linda: How important is OBA to the general transit riders? In other words, what percent of riders actually rely on OBA for transit decisions? 10%? 50%? (I don’t have a clue, as I’ve never used it, but it sounds worthwhile)
    If a substantial number of riders use this ‘Tool’, then the tool keeper should be Metro, and not a bunch of transit geeks in a UW cubicle somewhere.
    If it’s just a cool-geeky thing for a few people, then that’s a different matter – not worth throwing a bunch of resources at.

    1. The number of daily OBA users that I’ve heard bandied about was about 50,000. So, out of 400,000 Daily metro users that’s about 12.5%. That’s a pretty big chunk of riders to piss off.

    2. I was a rider of ST/KCM/CT for about two years, and I never used OBA. I never used OBA, because I planned out my trips, before leaving home.

      However, if plans changed, I’d call KCM customer service, at 206-553-3000.

  12. Part of my problem with OBA and Metro’s response is that I just spent a week in SF where they have real-time data at every other stop, a smartphone app that works well, and a website where you can track each vehicle (or all the vehicles at once, fun!).
    There was a service interruption while I was there, after a bad accident blocked the roadway. There were updates on the real-time data screen about the cause of the delay, and each stop has a full system map so it was easy to find an alternate.

    All these things make riding easy, which should be what all transit agencies do. I realize some of these items like real-time data at each stop are expensive, but keeping an app like this working should be a no-brainer for Metro. From Linda’s response and the fact that these issues have been going on for some time now, I just don’t think it’s a priority, and that’s a shame.

  13. Would recommend that everyone bookmark the corresponding Metro Bus Tracker page on their smart phone until OBA’s problems are resolved, seems to be more accurate. Just wish there was a smartphone app.

    After comparing OBA vehicle status call pages and the Metro Bus Tracker, it would seems some busses are listing 1 headway behind what they should be (among other problems).

      1. So, about 50,000 daily riders according to the article, or is that 5,000 riders accessing OBA 10x a day? Still, that’s a lot of hits.
        I remember setting up Metro reps with a Sperry Univac GPS doing vehicle tracking and data reporting in 1994 to demo the hardware/software. So, 20 years later were working out the bugs.

  14. Whoa…lots of questions here for Metro. Not surprised though, bus riders love these apps and rightfully so. Maybe Oran, Martin, etc. would consider a guest post from Metro addressing some of the issues of technology and transit? May be an easier way to answer the points raised in this thread.

    1. Linda,

      I would also like to hear about the policy of not publish schedule for Rapid Ride routes when they have 15 min and 10 min frequencies. Even if they are published as “estimated timepoints, bus may proceed early”. Metro’s highest quality service providing riders the lowest information. Makes no sense, especially if it is carded for drivers to operate a schedule

  15. I use OneBusAway on Pierce Transit, and it seems to work fairly well for me most of the time. Just letting you know…

    1. Yes, my experience is the same. PT buses and PT-operated ST seem fine, as do most KCM trolleys. The GPS-fitted Metro diesels are the least reliable. The 560, 255, etc have been particularly awful.

  16. Garbage data is worse than no data.

    Given that, why can’t you simply match any real time arrival with the scheduled data and throw out the extreme outliers.

    For example, I would just dismiss any bus that was more than 5 minutes late.

    Also, get rid of the red minus signed minutes (which I think means the bus just left).

    You could also do this as a set of preference selections, but make them the default.

    X Do not show buses more than ___ late (5 minutes default)
    X Do not show departing buses

    The garbage data is hurting the basically good functionality.

      1. No cell phone providers were interested in paying for the rights because it was such a short trip. Are you suggesting big government should subsidize folks like you, Mr. Republican?

    1. Sometimes, due to inaccuracies in the system, a bus that OBA claims just left is actually still coming. So, showing that bus still has value.

      1. OBA would rarely show data for a mid-day 26 if it were omitting all data on buses more than five minutes late.

      2. Gee, then it’s completely useless!!

        I mean, think of the real world scenarios.

        Say I take a bus on a 30 minute cycle.

        OBA would be very useful to me if accurate because, if it’s a minute or two away I will run to the stop.

        If it just left a minute ago, I will go get a coffee, hang out inside.

        However, if it inaccurately tells me it’s still coming then I use up my time that I would have spent getting my coffee. And if it tells me it left when it’s coming, it makes me miss my bus!!

        It just can’t work unless it’s accurate…

      3. In the wild, the buses I ride are usually plus or minus 15 minutes from the schedule. OBA lets me get it down to a reliable 5 minute window. I would never intentionally try to cut it within 2 minutes. If I get to a stop and OBA says it’s 1 minute away, it’s basically 50/50 chance that it’s already come.

  17. At the cost of repeating my own review of OBA, OBA is an awesome piece of software; well thought out and thorough, integrates very well with GMaps and location, tells you what you need to know in a clear and concise way with easy access to more detail on any piece of info.

    Unfortunately, the app is useless because the data is complete crap. I mean, seeing a bus arriving in 3 minutes, then 6 minutes later the app says it left 3 minutes ago… except you were standing there the whole time with no sight of it… is the epitome of uselessness.

    It’s not OBA’s fault, of course, and I will be thrilled to hear that these data reliability issues have been resolved because I really do appreciate the quality of the app and WANT to be able to use it (effectively) again.

  18. Over the weekend, OBA told me the next 8 at Denny & Aurora was 77 minutes away. This was roughly 10 minutes from the starting point of a route with 15 minute frequency.

  19. It’s 2012 and these fools still don’t have it figured out? Is it any wonder that what passes for a transit system in Seattle engenders so little confidence except among a handful of fetishists and ideologues at blogs like this one?

  20. It seems that not everyone is playing from the same data set. I just used KC Metro to plan a trip and it told me to catch the 532 from Totem Lake Freeway Station at 6:08PM. When I look on the ST website the schedule has the time point at Totem Lake at 6:02PM. If I use the ST trip planner it tells me to catch the same bus at 6:07PM. A six minute difference could make the difference between comfortably arriving in time vs watching the bus pull away just as you get there. Of course the 532/535 never run anywhere close to schedule southbound in the PM so it’s always a crap shoot anyway :-(

  21. Does the problem have to do with OBS and non OBS assigned vehicles working the same route? is the oba system defauling to the one non obs vehicle working an otherwise OBS line which gives you the 5 hour headways (you figure if a coach works a line, than nother line and dosent get back to the origonal line/direction for another 5 hours)

  22. You know what a real bus time arrival system looks like? Visit Portland – every transit stop has a five digit code (like you see above in the screenshot). You text the five digit code to a number posted at the stop, and they text you back the upcoming arrivals at that stop, with times.

    It would of course still be subject to the problems that OneBusAway has – the answer is only as good as the quality of the data. But, it wouldn’t only be available on pricey smartphones – works with any phone that can send and recieve SMS.

    1. OBA has texting too. I don’t know the number to text but each stop has a stop id, you text that and you get the next arrivals.

      1. Text to 41411:

        onebus [stop #]

        “onebus” is case-sensitive, though, so if your phone auto-corrects it to “Onebus” you will get no reply.

        You can also tack a space seperated list of route numbers onto the end, and it will only tell you those routes. That’s very important because of the SMS message size limit – the system won’t break a long list of arrivals into a multi-part message, it’ll just truncate the message, often chopping off your bus. So a practical, usable query is something like:

        onebus 480 3 4 14 27

      2. Hey, thanks, folks – I did not know that existed! Very cool! But, is this publicized anywhere?

    2. Seconded – I’m a dumbphone user who relies on the OBA SMS system. The smartphone apps are no use to me.

  23. “OneBusAway is only as good as the data provided by the transit agencies.” Shame on you. That’s only a part of the larger scope of what makes good transit predictions. This is yet another article depicting OBA as the unfortunate receiver of all that is bad from others. It cannot possibly have anything to do with the staff (Students) that manage OBA, right? This isn’t anything new, OBA is only as good as a number of things:

    • Nominal data obtained from agencies (all regional agencies have this)
    • Real time data obtained from agencies (not all agencies have real time data to share)
    • Cooperative support and understanding between OBA and each agency, not all agencies are the same
    • Support that OBA can offer between periods of turnover and overall interest/motivation each current student is willing to dish out

    OBA is a product that’s been around since the “MyBus” days. Over the years, many who used the application have seen it very accurate and robust as well as left to collect dust when one student graduates and the solicitation for another student to take over is underway. (long sentence sorry) I would like to see agencies develop their own sustainable, supportable platforms for schedules, predictions and other information. Oh wait, some of them already do:

    I probably sound like I am picking on OBA, because I am. OBA is at another finger pointing stage in its life. After what seems to be something like a decade of the product being around in some fashion, it would be nice to not have it feel like it starts over every 3-5 years.

    1. I agree that OBA should become a regionally supported service by the agencies like the trip planner. Do it like NYC Transit, who’s building on top of OBA for their real time info service (and contributing back to the source). I don’t know why I should be ashamed for bringing attention to the issue, as oversimplified my post is.

  24. The real-time signs at RapidRide stations are also inaccurate. I only ride A or B once a month or so on weekends, but several times the B sign has said something like “next bus: 25 minutes” even though it actually comes 10 minutes later and is supposed to come every 15 minutes. Once it happened on Thanksgiving Day so I ended up walking, not knowing if the sign was wrong or there was a holiday reduction I was unaware of, but the bus passed me after 10 minutes, and I saw two buses going the opposite direction on schedule.

    At SeaTac, I’m not sure if I’ve seen the time wrong for the A, but I’ve seen it wrong for the 180, and the 574 was not even shown at all.

    I’m not counting cases where the bus is three minutes early or late; that may be the limit of the system’s accuracy, and can be caused by a single stoplight or wheelchair boarding. But I’m regularly seeing times that are off by 10 minutes or more, or are implausably long given the frequency regime.

  25. Something new that Seattle-based Zonar and Redlans, CA based ESRI have cooked up:

    Zonar, Esri team to offer real-time fleet data mapping

    “A new integration between fleet telematics provider Zonar and geographic information system (GIS) provider Esri delivers real-time fleet data layered with sophisticated geographic map information. The resulting system helps companies determine capacity enhancements, improve fuel efficiency, optimize routes and share interactive transportation maps on the Web.”

  26. Thanks for publishing this Oran. I have been a regular and devoted OBA user for hte past few years. It’s been sad to see the service degrade so much over the past few months. In addition to what you called out, it’s notable that this also coincided with Brian Ferris departure from managing the service. My bet is that he had a big impact on the quality of service…

    I hope that one way or another we can get this service back to a usable quality level soon.

  27. I live on Capital Hill so I mostly ride the trolley routes and none of them have been equipped with GPS and I am guessing they won’t be since they are due to be replaced in the next year or two. So the data accuracy for those routes has been unaffected but I hope Metro resolves this because OneBusAway is too valuable to allow to become useless due to a data issue!

    1. nope … the 40′ ETBs are already getting OBS … at least 3 have it … and the Bredas will be getting OBS next

Comments are closed.