by BRIAN FERRIS, creator of onebusaway.org
Last night, King County Metro hosted a Transit Applications and Data Workshop as a kick-off event in their larger effort to support developers doing interesting things with KCM data. I had the opportunity to attend and I wanted to provide a quick summary for those who couldn’t attend and a call to action for those who could.
Workshop Summary
The workshop opened with a few words from King County Metro General Manager Kevin Desmond. It’s clear that Kevin has a lot of enthusiasm for the innovation that 3rd-party transit developers can drive, especially in light of KCM’s very-limited resources with respect to budget and their response to last December’s snow storm.
Kevin opened the floor for a few quick questions, but it was pretty clear that the 40+ people in attendance had a lot on their minds, so moderator Sabra Schneider (you may know her better as @kcnews) cut questions short so we could move on with the agenda. More below the jump.
Bibiana McHugh from TriMet in Portland gave a quick introduction to what TriMet has been doing to encourage 3rd party developers, along with a discussion of both the challenges they’ve faced and the results they’ve enjoyed. TriMet is one of the leaders across the nation in encouraging innovative 3rd party transit development and it shows. From their developer pages to their 3rd party app center, TriMet is an agency to emulate.
A panel discussion including current KCM staff covered what data they currently have available and what they are planning to offer in the future. Stephen Krippner mentioned the current process for getting access to their existing schedule data (send him an email), Tim Moore discussed their ongoing work to provide their schedule data as a GTFS feed (they distributed a CD at the meeting, but there doesn’t seem to be a public url yet). Finally, Beth Somerfield, the new KCM webmaster, introduced herself and briefly mentioned some of her goals in remaking the current KCM website.
At this point, the floor was opened to questions for real and we got down to it. I’m not going to go into a whole lot of detail about specific questions asked, since King County has more extensive documentation about the process that will hopefully be forthcoming. However, I’d like to touch on a few of the common themes:
1) Developers want access to any and all data that KCM can provide.
2) Developers are looking for some sort of public, online forum to kickstart development, share code, and communicate both with KCM and other developers.
Things I found specifically noteworthy:
1) It seems likely that public real-time arrival data for KCM buses won’t be made available until their CAD/AVL upgrade in 2010-2011.
2) Neither staff from KCM nor Sound Transit could provide information about when real-time arrival information would be online for Link and if that data would be made available to developers.
For those tweeting the proceedings, we were encouraged to hashtag comments with #metrodata, so you can go back and get a few more perspectives on the discussion.
We followed up the Q&A session with a short break and then moved into smaller focus groups, where we discussed short-term and long-term goals for KCM and developers. When reporting back to the group, we came back to the larger themes of supporting a developer community in the short-term and making more public data available in the long-term.
I’d definitely encourage those of you who attended the meeting to add your thoughts about the discussion in the comments, since my perspective is just one of many.
A Call to Action
I’d like to thank King County Metro for hosting the workshop. I think it’s a great first step towards harnessing the collective talent of our community to create innovative tools that hopefully improve the usability of public transit.
KCM staff will be the first to admit that government, like any large institution, can be slow to change. While I applaud KCM’s efforts, I don’t think anyone would disagree that there will always be a mismatch between the speed at which developers move at and the speed at which KCM can move.
I’m also a firm believer that we don’t need to wait for KCM. I’ve put that belief into action with OneBusAway and I think their is a real opportunity for developers to build really cutting-edge tools that can fundamentally improve public transit for everyone in our community. While KCM can provide the data, we can provide the rest.
A clear next step is to create some sort of public, online forum to kickstart development, share code, and communicate both with KCM and other developers. That forum could take a lot of different forms: email lists, wikis, blogs, Twitter, Google Code projects, GitHub.
I’d argue that whatever form it takes, it should be larger than King County. When I can travel by King County Metro, Sound Transit, Pierce Transit, Community Transit, Seattle Streetcar, or WA Ferries on any given day, it’s clear that the development issues extend beyond KCM.
As a first step, I’ve created a mailing list: transit-developers-puget-sound. I make no claim that a mailing list should be the definitive online forum for encouraging the local transit developer community. However, I think it’s a good place to start, so that we can continue the discussion about where to go next and build off the momentum in the community.
I didn’t like waiting for the bus, so I did something about it. If we don’t like waiting for change in public transit, let’s do something about it.
Crap, I forgot about this due to work issues. If there’s another one, I’d love to go. Or if someone could share out any slides/apps/source/interface specs that were distributed at the meeting, that would be great too.
No slides, the only thing they gave us was the agenda which was loosely followed. Also, they were distributing the Fall 2009 shakeup in GTFS format. You can still get a copy of the data, contact Stephen Krippner.
I recorded the audio, I just need to edit it down a bit. Will post the link here.
GTFS format? Great! Why isn’t it upload to http://code.google.com/p/googletransitdatafeed/ regularly?
Thanks!
Andy
Regarding accessing realtime AVL data, the consensus was:
– Right now Metro doesn’t publish it themselves
– If you want it, grab it from UW ITS. It’s an old project, but it still works beautifully. It’s also what powers One Bus Away
– It sounded like Metro wanted to publish AVL data once the OBS project is complete. The project isn’t done yet, and they’re working with the vendor on how to publish the information. The vendor has a solution that works with their product, but one of the goals of this meeting was to find out what developers wanted out of the project.
– Don’t expect data from Metro until the OBS project is complete. 2010 at the earliest, 2011 is more likely.
A couple of other points:
The reason why county projects “suck” is because of the processes they are legally bound to. After figuring out what they want, they have to issue a RFP, wait for the bids to come in, wade through them, pick one, develop it, and then test it. It’s a long process. Even if they started today, it might be 3-4 years by the time it’s done, and would be technologically obsolete by then. The private sector doesn’t have this problem because they don’t have to be “fair”.
I didn’t talk to Brian Ferris much as I have a pretty good idea of what he’s up to so I’m not sure how much he was pushing it, but anyone that wants to get started right now should look into the One Bus Away API. Augmenting this with the GTFS data can get you started NOW. Brian has also done a lot of the difficult legwork–the REST API can even give you an encoded poly line for a given route for those wishing to work with mapping.
Perhaps the proper thing to do is rather than using outside vendors and a rather cumbersome RFQ/RFP/bid process is to bring development of strategic applications in-house. Most companies do most of the core work for their web applications internally because it is the only way to deliver high-quality that meets the company needs quickly. Even in the private sector using an external vendor slows things way down and you are more likely to end up with something you can live with rather than what you really wanted.
Another thought would be to treat anything “bleeding edge” as research and fund people at the UW to work on it.
I’d be interested in what other US transit agencies are doing along these lines, since most of them are operating under similar constraints to Metro.