Community Transit has joined the real time rider information party, although the data is as yet only available through their own website, not OneBusAway:
Customers can access BusFinder at www.mybusfinder.org on their computer or mobile device, or by calling Community Transit’s customer service phone line at (425) 353-7433 (RIDE) and selecting Option 1.
Mobile device users will be redirected to a mobile version of BusFinder. The mobile version is a web-based application, not an app that needs to be downloaded.
BusFinder works best by entering the bus stop number found at all Community Transit bus stops. Users can also enter a stop name, which is the primary street of the bus stop followed by the nearest cross street. The program is intuitive, so entering a primary street will create a list of options from which you can choose your stop.
[…]
Riders catching buses in King County should use the Map or Nearby Stops features to find their stop, as Community Transit stop numbers are not displayed on Metro bus stops. Once a stop is found, it can be saved in Favorites for future use.
CT Spokesman Martin Munguia tells me that publishing a real time feed for consumption by OneBusAway and other apps is on their radar, but as yet has no firm ETA; their team is focused on working out the kinks with their own site first. He also clarified that CT stops in King County transit centers all have CT stop numbers, and alluded unspecifically to “a couple of alternative solutions for King County stops that I hope will be implemented by this summer.”
UPDATE: Apparently, King County transit center signage does not include CT stop numbers, but “We are working on a solution, vague as that may sound. There are options and we are in negotiation on the best and quickest to implement.”
I’m thrilled to see CT make this leap in usability. Real-time arrival data, on all but the highest-frequency routes (few of which really exist in Washington), is something which I can no longer function without, and I know I’m not the only one. Up-to-date confirmation that the bus is on its way is priceless to riders. I will say, though, that the real champagne moment for most riders will be when CT is plumbed into OneBusAway, the de facto virtual transit interface for Puget Sound.
I have questions out to the current OneBusAway maintainers at Sound Transit to see if any other agencies are in the pipeline, but I can separately confirm one: Spokane Transit will launch a public beta of their own real time service late this spring, with a public feed to follow shortly thereafter.
Once CT and STA are on OneBusAway, the five biggest bus agencies in the state will be on a single real time app — a huge measure of convenience for travelers. Next up: Sound Transit needs to get its rail services up to speed with its buses, C-TRAN needs to gets its own real time service (Next Ride) on OneBusAway, and Whatcom Transit needs to get itself a real-time service. I know the latter two can do it, because they’ve been beaten to the punch by smaller-but-scrappy Intercity Transit.
I still don’t understand how this wasn’t first, or at least a concurrent requirement of the development effort. Is getting integrated with OBA so onerous that it simply could not be done with a reasonable budget and time frame? Nobody from CommTrans seems to want to answer and that’s really disappointing from a major Sound Transit partner.
“a major Sound Transit partner” ???
In this case, it’s very clear that the egg comes before the chicken. CT needs a backoffice system to poll vehicles for updates, and interpret the results. Munging and then publishing that data on their own site is somewhat of a proof of concept. Integrating with OBA is an obvious next step, which if done first would have added a lot of unnecessary complexities (e.g. “is this not showing up because a mismatched trip ID or something else?”)
That doesn’t really answer my question, though. (Also, CommTrans is definitely “major” when it comes to Sound Transit; they have 6 Sound Transit routes and multiple facilities that ST uses for service.) If the design spec said “acquire real time information and publish to OneBusAway,” that would have been a goal of the service. Why spend the extra time making and testing the web UI? How is testing the output of their real-time tracking system going into OBA any different or harder than testing that output going into their own custom-written platform? One obvious answer: the custom-written platform is written by, hopefully, the same team, but that still doesn’t remove the question of why write the custom web UI platform in addition to someday maybe hopefully kinda sorta getting OBA integration.
This seems as silly and redundant as Metro busting out its own trip planner app. Acquire the real-time data and feed it into OneBusAway as a first step. Everybody wins.
All I can say is: become a programmer.
However the separate mobile app is politics.
I’m with lakecityrider… Seems GTFS-RT (which feeds OneBusAway) should have come first. In this case not only did they have to get all their data in order, they also had to build a web UI. They could have skipped debugging the web UI and only dealt with debugging data using the proven OBA platform.
It’s because of the huge lag time (e.g. 5-10 years) between when a public agency makes a decision to go do something and when they actually do it. They probably made the decision to publish realtime information before OneBusAway existed, and when OneBusAway came along later, the bureaucracy had too much inertia and could not be changed.
He also clarified that CT stops in King County transit centers all have CT stop numbers, and alluded unspecifically to “a couple of alternative solutions for King County stops that I hope will be implemented by this summer.”
Why don’t all the agencies just agree to a uniform stop numbering system? Seems like pretty low fruit for integration, just need some stickers.
Metro can’t even keep the route IDs consistent.
Also, a numbering system with foreign key constraints is a nightmare across multiple systems, especially when the numeric key is the only identifier. E.g. C123, M456, and P789 would be easy, but letters aren’t allowed for stop IDs in GTFS
Letters also become numbers when you use it with a touch tone phone, so it is a bit less compatible with doing things that way.
Obviously, One Bus Away could deal with characters other than numbers, but down here in TriMet land stop numbers were originally developed for the touch tone phone arrival system that predated the web arrival system.
I’m not sure that C-TRAN will join One Bus Away immediately. I think they are planning to instead become part of the system TriMet developed.
Which is why the OBA system uses all numbers and an underscore. For example, CT’s “stop” at 4th/Pike is internally numbered 29_2976. PT’s is 3_13217. KCM’s is 1_700. Bus routes do the same thing. Sound Transit has system ID 40. Metro has system ID 1. And so on.
As indeed they should.
There are no connections between C-Tran and any other OneBusAway-using system. For Spokane to adopt OBA makes sense; they don’t have connections with a system using a different interface, it works well, and it’s an “in-state project”.
But C-Tran lives and dies in in mid-day based on its connections to MAX. It needs to conform to Portland’s system.
No, those are completely different. I’m pretty sure route IDs could contain any character. Agency identifiers can contain letters (Seattle Children’s agency ID used to be “SCH”).
The agency ID and the route ID are stored separately. They’re just pushed together because of the way Brian designed the RESTful API. Initially OBA was Metro only, so you’d call oba.org/blah/command/1.xml to get details about route 1. He chose to use underscores to separate agency ID and route ID, so Metro’s route 1 is 1_1 (Metro getting ID 1 came from APTA’s database of something). An alternative could have been …command/1.xml?agencyId=1. The underscore method worked well for being able to make other aspects of the webapp multi-agency aware without having to rewrite a lot of the code.
Also, the spec only specifies a uniqueness constraint on stop IDs. If you really wanted to, you could have a stop with an ID
Awww…. my unicode character got dropped.
Well, could you have a stop with ID [empty string]?
I just tried it with the feed validator and it didn’t like empty string. It passed fine with a letter.
When I first read this, I thought “oh that’ll be easy” because I was thinking NextBus which is on ST’s radar
You can see some of SoundTransit’s OBA plans in comments at https://github.com/SoundTransit/soundtransit-rds/issues however they have been reluctant to share a roadmap.
I also wish this would have come to OBA and GTFS-RT (for third party apps) first rather than spending money on custom one off solutions.
In terms of next steps for Sound Transit’s OBA, other than CT, I’d like to see Everett Transit, Seattle Streetcar (NextBus), & WSDOT ferry integration as these agencies already have user accessible realtime data.
Additionally I’d like to see the agencies with GTFS publish the data to Google Maps… In particular CT & Everett Transit could do this today.
Everett, WSDOT, Seattle Streetcar already have real-time data? Where is that published?
Not sure what their various formats are, or their feed for them, but they do all publish the data:
Everett transit does it via text message
Washington State Ferries has a map based service on their website
Seattle Streetcar does it through NextBus
What exactly is the use of getting “the top five transit agencies in the state” on OBA if one of them is clear on the other side of the state from the others and isn’t directly connected to any other agency using it?
@lakecityrider (Wes) It’s called having (the public’s) money to burn, with no accountability for it, as well as being out of touch. Their technology area is also well behind even Everett Transit; they gave up on trying to equalize the sound on their on-board announcements for BRT and were late to the game with “next bus” arrival information (Metro started much later, yet had it first). It is “silly and redundant.” It’s also confusing and customer unfriendly, for those who are savvy and patient enough are forced to jump about, while those who aren’t savvy trust OBA and the others as having real-time information like the other providers.
@asdf2 OBA – or at least its predecessors – have been around since the 1990s. If these agencies are presumably “cooperating,” this would have been on their collective radars.
@Tim is right, it’s politics. It’s also the cost/huge overhead of having multiple transit agencies and no oversight; each agency’s agenda comes first. That’s part of why ORCA was several years behind schedule. If there was one agency in charge, or just one agency, we would have much better transit service…and would be much sooner with new technologies.
transitrider is correct. I’ve asked CT on several occasions over the past two years why they haven’t made their raw data available, or prioritized OBA integration. I never received a reply.
Just this morning I tried to use the “BusFinder Feedback Form” on the commtrans.org web site. Page is hopelessly broken, in both IE and Firefox, and has a bad security certificate to boot, so you can’t even get to the [broken] page without first clicking through a browser warning.
CT has had location data now for what, almost two years? At least, the real-time arrival signs in the Mountlake Terrace parking garage went in sometime around then. Getting the data into the proper format for OBA and other independent apps is not a difficult task, regardless of what the bureaucrats will claim. I work for a company that does product and app development and we could have knocked this out in months or less, not years. Furthermore, it’s always an option to simply not do any work at all, and make the data available to the public in whatever-the-heck the native internal format already is. Then the community could do the work of writing an interface layer to convert it into the desired format, for free. For a public agency to be holding back data when releasing it does not even require an effort is pretty egregious.
I realize it may be counterproductive at this point to take an adversarial stance w.r.t. the developers at CT, but at some point you gotta call a spade a spade. How ridiculous does this situation have to get before someone with clout points out the absurdity of it all?