My friend Kieran, as a result of last year’s TransitCamp, got together with a couple of other transit/technology geeks to create MyTTC, a community-driven site for Toronto transit information that will launch in about two weeks, in time for the next TransitCamp event. They did this in response to the deficiencies of the official TTC website, which is famously bad for providing decent information about actually using the third most heavily used transit system in North America.
MyTTC is focused primarily on routes and schedules, and contains all of the route and schedule data that they’ve gleaned from the TTC site and other sources. Each route is mapped using embedded Google Maps, with individual stops marked and the arrival times expected for surface vehicles at each stop. There’s also transfer information for each stop and route, so that you can see which other routes connect to that route and stop, and other context-sensitive information about stops.
But it’s more than just a static information site; it has a lot of wiki-like aspects for user-generated content (although it’s built on Ruby and Merb rather than a wiki platform). Users can add stops to routes — the TTC routes/schedules only show main stops, not every stop — and the scheduled time for the newly-added stops will be interpolated from the existing data. Users can also add other context-sensitive information about stops, such as typical delays at certain times of day, points of interest, and places to wait out of the weather where you can see the bus/streetcar approaching. Users can also bookmark their favourite stops, which will appear on their personalized home page when they’re logged in.
One of the largest issues that they’ve had, and are likely to continue to have, is getting data from the TTC: many transit authorities are notoriously miserly with their data, in spite of the fact that it’s created mostly with public funding. For MyTTC, they used the route and schedule data that’s available on the TTC site, much of it captured manually (and painfully), but TTC hasn’t been willing to share any data in a more easily-ingestible form, or to share the data that will soon be generated by global positioning systems on surface vehicles. This, of course, is a political problem rather than a technical problem, and likely others will need to be involved to help resolve this.
MyTTC is attempting to create a platform where the data is fully open (although they are not, at this time, making the code open source): they will be providing full XML and JSON APIs, SQL dumps of the data, and GTFS (Google Transit Feed Spec). In fact, their contacts at Google have said that Google Transit will accept their data in place of TTC’s, likely because it’s more accessible and complete. They don’t plan to monetize the APIs, but would rather have other sites export the data and use it for their own purposes directly.
The platform itself is transit system-agnostic, and could be used for any transit system. There’s explicit support for the iPhone, and other mobile platforms such as Blackberry will be tested — in fact, I think that I just volunteered for that. There are plans for some SMS interfaces, such as being able to send an SMS message to the site with your current location and get back related information, and we discussed the use of Twitter including direct access (like the BART experiment last year) and Twitter-based applications (like CommuterFeed). They also want to add a trip planner to MyTTC before the launch.
The wiki page for this session, which includes these notes of mine plus other attendees’ contributions, is here.