https://www.flickr.com/photos/126292912@N04/36819872350/in/pool-seatrans/
Metro has already lapped the field compared to its regional partners in the race for real-time data. They have long exported that data to a multitude of apps (and text services!) and posted it on signs at many of the most important bus stops. However, underlying problems with real-time data have typically limited the usefulness of any platform for that data, public or private, under certain circumstances. In particular, users at the beginning of a route who were not “in the know” were pretty likely to show up absurdly early or late for their bus.
Two weeks ago, Metro announced a fix to that problem.
To fix this problem, Metro has upgraded the underlying data system that drives the transit schedules in a project called “Stop Based Scheduling.” It goes live Saturday, Sept. 23, and it shifts the data that schedules are based on away from key intersections, using key bus stops instead, while also mapping out what buses will do when they’re not in service.
Because of this, customers may notice an improvement in the accuracy of “real time” schedule information if they ride on one of the earlier stops on a particular trip. This transition should be seamless for riders, improving the accuracy of the data Metro collects about its service, specifically around where our buses are and how they’re operating relative to their schedules.
Changes like this dramatically reduce the frustration factor. New users find that schedules often do not reflect reality, and then discover OneBusAway. Then they find that even that data, which has the illusion of accuracy, has deep problems of its own.
These problems are sometimes deceptively hard and/or expensive to solve, but Metro prioritized them and solved them. Perhaps this attitude can filter over to other agencies as well.
Meanwhile community transit STILL has no RTD on external apps.
CT is working on revamping their whole real-time data stuff. I don’t know the precise details but spoke with someone at CT 6 months ago who’s on a team that is currently working to integrate CT’s data with OBA and Google transit. Timeline? Nothing concrete yet.
I’m still seeing buses routinely refuse to transmit their real-time location until they’re 10-15 minutes into their run. For eastbound 255, you usually have no idea where the bus is, until it’s in the middle of the 520 bridge.
The good news there is, it got to the bridge in fifteen minutes!
That’s on a good day. On a bad day, when it takes 30 minutes to get to the bridge, you still don’t usually know where it is until it actually gets there.
I’d be less unhappy with how wrong the timing data on the early stops is if the buses still managed to make their connections, rather than giving you 30 seconds at best to make it from the bus bays at Tukwila up two escalators and a concourse and a half to catch the northbound Link train (thank you for always being 2-5 minutes past your scheduled time, eastbound F-Line.)
Sure it’s only 10 minutes until the next one but that ten minute wait, since I invariably have to make another transfer to get wherever I’m going, means I have to leave 45 minutes to an hour earlier than I could if the connection wasn’t impossible without sprinting.
The most effective solution here would be more frequent trains, then you theoretically would wait less time no matter when the bus arrived. Trying to synchronize a bus with a train sounds like a fool’s errand, especially with those escalators in between. Bus timing is not exact because of traffic, wheelchair lifts, number of riders, and cash-payers. People walk different speeds. So the only way to guarantee that nobody will be left behind is to schedule the bus 5-10 minutes before the train. That means fast walkers on a low-traffic day will have to wait a few minutes anyway to give time for slow walkers and padding.
It may be possible to time some bus routes a few minutes earlier, but remember that a bus can only be synchronized at one point on its route, and it may already be synchronized somewhere else. The F has transfers at Renton TC, Southcenter, TIB, and Burien, so which one should it be timed to another route? If it’s possible to time it at two points on the route, then either you’re very lucky about the exact distance between the stops, or the other routes are smaller than the F so it can dictate to them. But the F connects to the 106, 150, Link, and 120, none of which are small enough for the F to dictate their schedule to.
Best way to work out any bus-location system?
Have LCC call specific drivers, and ask them “Where are you right now, and what’s in your way?” After quick training session to drivers on fast, short answer. “L” (for Location) Third and Madison SB. “T” (for Traffic) Heavy, normal light, or blocked. “P” (for passenger load) Same.
And program system to do exactly the same. Though might be bet and cheapest to call drivers. One word query: “Tell!” Will also give drivers their most important constant subconscious running readout: “Where exactly should the police meet me?”
Mark
Yeah, that’s what operators need: more distractions!
Tim, from what I do remember, and commenters can verify or dispute, is that vast majority of radio problems came from non-existent training on how to use them.
Code system I described would be one syllable answer to question same length. About information that driver should always have “at the ready” no matter what. Especially Route, Run. Coach Number, and Direction of Travel.
The info police need to have before their foot hits their accelerator pedal. In any uniformed service, distraction is minimized by intensive training. Lack of treatable by passengers’ info to their elected officials, and a request or two from ATU Local 587.
Mark Dublin
Everything you described can be (and already is) accomplished by the radio mounted behind the seat. No human intervention required.
Does Metro’s location data and expected real time arrival pull in current traffic conditions, or is it based purely on the run’s current location vs scheduled location (and possibly historical arrival data)?
Also, do any of the apps use current traffic conditions to adjust expected arrival?
Brett, without fully-reserved and signal-preempted bus lanes, accurate arrival times are too much to ask of any automated system. Though app or station video display could have a moving dot to show where the bus is- with other dots showing traffic around it.
But pretty sure video techniques can now get actual real-time video of buses and their surrounding conditions. Panned out to show whole Downtown or freeway segment. Or shifted to cameras aboard buses themselves. With sound. Come to think of it, exactly how average American spends their time. And minds.
Transit passengers will now get to share the personal drama of why their bus is l late, and who to either blame or love when they themselves get on stage, I mean bus. And start yelling “Well if you knew he was cheating on you, why aren’t you cheating back already?!!!”
In first hour, ad revenue will leave every Wrap in Wrags on the curb. Starting with State Lottery Commission. But pretty sure that for a reasonable cut, State gaming commission will pay for every ST- until the world comes home in a barrel. But here’s something more important than destroying North Korea.
Since our whole country is now a Reality TV Show, it is the duty of Seattlite Santuarians to honor everyone who lost a pathetic struggle to stay on the island, and get on the bus instead, even if it never comes. Instead of being a male child of a girl pomeranian and taking either a knee or Lyfft. Or even more Fake and dishonest…LINK!
MARK
Based on my observations, I’m pretty sure they use very naive algorithms. Basically, look at where the bus was at its last known location and assume progress according to the paper schedule since, with a uniform speed between time points on the schedule. When more than 5 minutes has elapsed since a bus has last transmitted its location (which happens way more often than you would think, with modern technology), OneBusAway ignores real-time progress altogether and switches to “scheduled” arrivals.
For instance, if a bus that’s 13 minutes late last transmitted its location 4 minutes 30 seconds ago, OBA might say it’s arriving at your stop in three minutes. Then, when another 30 seconds goes by and the bus fails to transmit, OBA reverts to “schedule” mode, so the bus disappears from the radar. Then, when the bus finally transits a minute later, it re-appears again, this time “arriving in one minute”. To avoid getting tripped by this, it is necessary to view the details and see when the last update was, so that if it’s close to the 5-minute threshold, you can infer where the bus probably will probably be if it “goes grey” on the map. Needless to say, none of this has changed the least since Metro’s latest data update.
There’s another complicating factor too – that OBA sometimes can’t tell the difference between a bus finishing up one trip vs. a bus waiting in layover until it’s time to start a trip going the other direction. From my observations, I believe the trigger is simply a matter of when/if the bus driver decides to turn off the bus and/or change the head sign to point the other direction. For instance, take eastbound route 554 arriving at Issaquah Highlands P&R. If the bus driver leaves the headsign alone until it’s time to begin the westbound trip, the bus will continue to transit its location every few minutes as if it’s still doing the eastbound trip, creating the illusion in OneBusAway of a bus falling further and further behind schedule. Conversely, if the bus driver changes the headsign to “downtown” several minutes before it’s time to leave, OBA thinks the bus is about to leave early, but with the “early” factor decreasing every several minutes as the bus re-transmits (since it hasn’t actually moved anywhere), until eventually, the bus is on-time and leaves its terminal normally. Or, if the bus driver simply turns off the bus, it won’t transmit, and when 5 minutes has elapsed since the last transmission, OBA will revert to “scheduled arrivals” until the driver turns the bus back on and switches the headsign to point the other direction again. Reading Metro’s description, it seems that this is the area they’ve been aiming to fix, although I haven’t had a chance to test it yet.
Ultimately, the OBA prediction algorithms are ok, but very naive, and fail to consider tons of potentially interesting information, such as real-time freeway congestion, event calendars, road construction, coach type (using a bus that’s too small to meet demand, forcing everyone to squeeze), holiday calendars (e.g. Christmas traffic is much lighter than normal Sunday traffic). It should be possible to do quite a bit better than what we have.
If the system is operating normally and there is no reroutes near the terminal that affect its routing, headsigns chsnge automaticallly. Drivers don’t even have to press a button. For instance the 4:50 am 102 going to Seattle automatically switches to “TO TERMINAL” when it arrives at Convention place. Then ten minutes later when it switches to a SB 150 it automatically flashes to “150 To Kent Via Southcenter” and then when it reaches south enter it automatically switches to “150 To Kent”. Very little for the driver to do there.
“Metro prioritized them and solved them.”
Metro doesn’t sound nearly so confident as the writer of this blog.
Is this the reason why OneBusAway’s GPS data is so unreliable for route 28 southbound? It’s by far the fastest bus for me to get downtown (I catch it at either NW 75th or 80th, and the bus starts at NW 100th, so I’m close to the beginning of the route), but because it’s a fairly unreliable 30 minute route and the buses seem to never have GPS data, I rarely take it to get downtown, opting to walk up the hill to catch route 5 (which is, by comparison, extremely reliable, frequent, and seems to always have working GPS data).
Yes, it’s a contributing factor. Though you are somewhat further along the route than at he very beginning, real-time data will likely be more accurate within 5 minutes of the bus actually showing up versus 20 or 30 minutes ahead with other routes… like route 5 that starts around 160th St.
Plus, the fact that the 28 is interlined with the 131/132 and ends up in Burien doesn’t help too.
Isn’t it just a GPS device attached to the bus that’s sending out a position every n-th second? It shouldn’t be that hard. Our mobile phones probably do a better job of sending out our locations to Google/Apple.
Anyway, who controls whether or not the GPS is sending out a signal? It’s weird that, in this day and age, we can’t know exactly (+/- 10m) where the bus is every second it’s operating (outside of tunnels, a few downtown blocks, and maybe some topographically shaded locations). This is not groundbreaking technology (at least anymore).
That being said, the current system does work fairly well with some varying levels of frustration. However, I can’t even imagine using a KC Metro bus without live tracking. It would be next to useless. In the olden days people must have just waited, and waited, and waited without even being sure the bus would show up (like I do now when the time is grayed out with “scheduled” in OBA).
“However, I can’t even imagine using a KC Metro bus without live tracking. It would be next to useless. In the olden days people must have just waited, and waited, and waited without even being sure the bus would show up…”
Lol. Yes, that’s exactly what we did. There weren’t any other options. We couldn’t even call our place of employment to let them know we would be showing up late because, wait for it, we didn’t have cell phones in our pockets back then either!
@Felsen:
Just how long has live tracking been around? Has it been such an appreciable part of your adult life that you can afford to call us “olden days” folks?!
Mostly and no. Just because you know where a bus is doesn’t mean you when it’s going to arrive at some location in the future. Think about it, if I gave you nothing but a a pair of latitude & longitude coordinates, how would you be able to tell me when one will arrive at another?
Isn’t that how the live tracking on Uber/Lyft/UPS/certain food delivery apps works? You can see the little car moving around on the map and also get an estimated arrival which is more often than not accurate…
Personally, I would rather have a live view of where the bus is on the map than seeing an estimated arrival time. The “vessel view” ferry tracker on the WSDOT app is fantastic, and always very accurate.
Anecdotal for me, but OBA seems like it traded 1 problem for another. Previously a bus near its origin (like the Northbound 372 on campus) would show as being very late even though it hadn’t departed yet and would be on time. And then as it left it would jump to showing on time. Currently, the bus just shows up as scheduled until after it’s passed my stop. Either way I just have to assume the bus is on time, since OBA doesn’t give me useful information under either system.
That’s been my limited experience with the 28 SB at 85th (three stops into the route). I often take it south in the afternoons, and it’s highly unreliable–often late or no-show–and OBA doesn’t appear to be any more useful than it was before. In theory, this is exactly the sort of service that shouldn’t necessary at the start of the route, because buses shouldn’t have had a chance to be so late. Why that logic doesn’t seem to apply to the 28, I have no idea. I suppose I should just get used to schlepping over to the 5 or the D, but it’s frustrating to have a bus at my doorstop that isn’t usable. My late afternoon trips aren’t particularly time-sensitive so 30 minute headways doesn’t really make the bus any less useful for me than more frequent ones; the unreliability is the problem.
Hope it works. The SB arrival times for the 3, 4, and 13 in Upper Queen Anne have been sketchy — especially in the a.m. peak — since the restructure that rerouted the 4 awhile back.
And as others have said here (and many of us have said for years), by 2017 we really ought to simply have a real-time view of our actual bus. So much simpler and more reliable.
I laughed once again at this last night as the 11 switched from 6 min late at 9th/Pine to “scheduled” – meaning I had to take the train to Capitol Hill because I had no real idea where it was. It was still on “scheduled” when I was walking towards the stop on 10th…and then switched to 1 min late as the bus pulled up while I was still a block away. Turn around, walk back to John, catch the 8 and walk the last mile and a half home and still beat the next 11, which as usual was 15+ min late. Luckily it was a nice day yesterday.
This is all barely better than useless, at least on some routes. I’ve spoken with people waiting at stops who have told me “that thing doesn’t work” when I ask them if they use OBA. I still find it occasionally useful, mainly as a time point check to see if the bus is catching me as I invariably walk towards home. There has to be a better solution. Back in the day you waited because you had no other option – now that there are supposedly ways to find out where the bus is, people start to take them as reasonable guides as to when to head to the stop. They don’t care one damn about “algorithms” – they do care when they either just miss a bus that they thought they would make, or see a bus they thought they timed get further and further behind. As the weather changes this gets even more infuriating – all they know is that the “transit agency” told them something and then didn’t come through. Sometimes no data is better than giving out bad data.
I have noticed (as Scott seems to imply) that OBA seems to usually work well on some routes, and is nearly useless on some others (the #11 is a prime example of those on which it is pretty futile – and was so even before the current downtown mess in the vicinity of its live loop). The Metro bus tracker seems to have a similar problem.
I have no good theories on why this is the case. If we knew, it might be helpful in fixing the broader problems.
Still noticing a lot of ghost buses on one bus away for the 2, 3, 4, and 48. Recently while waiting for one of the ghosts, grey showing bus has left as per schedule but no real time information, I switched to the the next departure on the trip planner app and it showed the bus as an approximately 3 minutes late, which was close to correct. Also the real time sign for the 48 northbound at 23rd and E. Union has been reading due in 5 minutes for a week. It almost seemed like something broke when they did the update.
I remember asking KCM about how often vehicle position location data was being polled and I was told every 90 seconds but it seems to be upwards of every 2 to 3 minutes. We’re having a similar issue here in Baltimore with position information being polled every 2-3 minutes because they’re using the trunked radio system with data channels on a 20+ year old AVL system. There is a project underway to completely replace the existing AVL system with a newer system that has a cellular network to transmit position information approximately every 30 seconds. Hopefully KCM can look into possibly using a different network medium to provide more accurate position information that can feed both into GTFS-Realtime (whenever that goes public) and OBA.