It’s official. CCTA is live on Google Transit.
For those who are not aware, Google Transit is an online transit trip planner built into Google Maps. Users request directions from point A to point B and Google provides directions on where bus stops are, which buses to take and what transfers are necessary, if any.
Google Transit is an incredibly powerful tool, especially if one is not familiar with the transit system in the area they are living in. Whenever I travel, one of the first things I do when arriving in a strange city is to take out my phone and pull up transit directions using Google Transit. Even if one is familiar with their local transit, Google Transit provides a nice mobile reference tool for when the next bus will be arriving.
For those who are familiar with Google Transit, the main question may be: what took so long? As it turns out, I happened to be the one who put together CCTA’s Google Transit feed, so here’s the inside story of what it took.
As with anything CCTA related, I want to make it abundantly clear that any views or opinions in my writing are exclusively my own and do not necessarily reflect the views, opinions or positions of my employer.
I first stumbled across Google Transit back in the summer of 2008. A few months before, I walked into CCTA’s offices and pitched myself to be an unpaid intern, intending to get experience in public transit before I packed my bags and moved out to the west coast when I graduated at the end of the year.* The unpaid internship quickly evolved into a paid internship, with the promise of a full time job when I graduated if everything worked out.
Google Transit cost nothing – other than the staff time to implement it – and it was just the sort of project that appealed to me. I pitched it to the higher-ups at CCTA and while there was plenty of support for the idea, there were also numerous concerns. The idea had been looked into a few years before – apparently right around the time that Google Transit came out and some transit agencies had difficulties with implementation and ensuring their data was correct. Additionally, there were tremendous concerns about maintaining the accuracy of the data as CCTA went through schedule and service changes. I was tasked with contacting other transit agencies who had launched on Google Transit and getting feedback on their experience and the challenges of implementation and maintaining data.
I had a handful of conversations that summer and almost everyone told me the same thing: they had few or no problems creating a GTFS feed, but there was a very lengthy wait once they submitted the feed to Google for review. Most agencies told me that the wait was up to six months, though expedited approval sometimes occurred if an agency employed a consultant who had a past history of delivering high quality feeds to Google. Apparently, a number of agencies were all attempting to be listed at the same time and the backlog at Google was just tremendous.
I prepared a memo summarizing my conversations, but it was the end of the summer and I was heading back for my final semester at UVM. From mid August to December, I worked five day, 25 hour weeks for CCTA, squeezing my time at work between the few remaining classes I had to complete. I only had enough time for my core responsibilities at the agency – driver scheduling and maintaining the organization’s IT infrastructure. Google Transit fell by the wayside.
By January of 2009 I was back at CCTA full time – and permanently. Nonetheless, there were still major barriers that stood in the way of Google Transit implementation. Chief among them was that we didn’t have a comprehensive and accurate list of stops and their associated coordinates. The most recent list was several years old and there was some question as to the accuracy of the coordinates. At some point I took a drive with a laptop and a GPS receiver and attempted to log the stops along the Pine St route – but that was a fairly time consuming activity.
By mid-2009 it was becoming clear that we needed to update our internal stop list. A member of the planning staff spent a good amount of time over the course of a month or two driving each route with a member of the operations department and comparing each stop to our existing stop list, as well as making decisions about stops that needed to be removed, added or relocated. We finally had an up to date stop list – but didn’t have accurate coordinates for use with Google Transit. While I attempted to geocode the stops by using Google Street View, the effort was frustrated by a lack of Street View coverage along many routes, as well as the fact that the footage didn’t reflect any changes in the past year or so. Additionally, there was concern about the accuracy of some of the sample coordinates we generated this way.
We ultimately had an individual gather all of the coordinates with a GPS, simply going stop by and stop and then compiling the data in a spreadsheet. With this data in hand, we just needed to get out schedules into GTFS format (GTFS stands for General Transit Feed Specification. Though pioneered by Google, it has become a standard format for the exchange of transit schedule data).
Compiling data into GTFS format is not a tremendous undertaking for large or small transit agencies. Large agencies typically have a tool that can automatically generate a GTFS feed (this is built into most transit scheduling packages) and small agencies don’t have a tremendous amount of data to input. Mid size agencies, like CCTA, are in the uncomfortable middle.
CCTA does have a transit scheduling tool – in fact, it’s the same one that most major transit agencies use (we’re the smallest agency in the world that’s using it). The vendor had introduced GTFS support in 2006 – and we were running the version from 2005. Unlike large agencies, we didn’t have the budget – or the need – to upgrade the software every year or two. Conversations with the vendor about retrofitting our existing package weren’t very hopeful, or affordable.
So I set to work in early 2010 hand-coding our schedule data into GTFS format using Excel. I first had to reformat pre-existing stop lists (a list of all the stops by route variant – i.e. each variation of a route) into a workable format to begin constructing our GTFS files. Then I began to code each trip in, assigning a trip number and crossing it off in a bus map and guide that I was using for a reference.
BM&G used for Google Transit
Just when I felt that efforts to bring Google Transit online were beginning to gain traction, contract negotiations with our drivers’ union began. Driver scheduling issues, for which I am responsible, were a central point of the negotiations, and I spent many long months answering questions, evaluating the potential of proposals and building scenarios to assess the feasibility or demonstrate the merits of particular contract language. There simply was no time to work on Google Transit. Negotiations dragged on for a significant period of time and afterwards I had to rework future schedules to comply with new contract language.
All this time – keep in mind – we had been expanding service, with the largest one-time service expansion in the history of the company in June of 2010 and commuter service to Milton launching, as well as additional trips to Montpelier. I also had other IT initiatives I was pursing, such as equipping the Link Express buses with WiFi. Summer is always a busy time for me, as we have back to back schedule changes due to summer break for Burlington schools, as well as seasonal changes in the College St Shuttle service.
With the summer of 2011 over, things had finally settled enough to allow me to double down on the Google Transit project. Over a period of weeks, I encoded all of our data into GTFS format, then validated it with a handful of tools provided by Google. I then submitted the data in early December – and waited.
Google made contact with my in late February, letting me know that our data had been set up in a private beta, only accessible to those I designated within the agency. Volunteers to test the feed were solicited, bugs were identified and corrected and after several successive feeds, we submitted our final feed to Google to be published.
Two weeks later, Google sent me a lengthy QA document with all sorts corrections they wanted done. They did a remarkably thorough job of comparing our feed to our website and had an extensive list of concerns. In our bus map & guide (posted in PDF form on our website), for instance, we labeled our main bus station as “Cherry Street” It was listed as “Cherry St” in my feed. We had a route map on the site that used colors to indicate the routes – yet we didn’t specify colors in the feed. Many of the stop names I had listed were listed as street intersections, but they conflicted with the names of our time points in the bus map & guide. ”Jolley Short Stop” on Shelburne, for instance, was listed as “Shelburne Rd at X Street.” Google wanted the GTFS data to exactly match the bus map & guide, unless there was a good reason not to.
After these corrections were completed, they approved us for launch, and a week later (last Wednesday), we went live. There was only one problem. In the hours before they compiled last week’s transit data, for some reason their system pulled a copy of our GTFS data off our web server. I had been directly uploading our data – the copy on our web server was from our original feed before we began beta testing. So when our data went live, it had none of the corrections we had made over the past few months.
I quickly uploaded the newest data on our server, as well as directly uploaded the latest data to Google. However, they only compile the data once per week and the new updates take effect on Wednesdays. As a result, we made the decision to wait a week to make a formal announcement. But the fact that our data was live was quickly discovered and shared on Twitter, so our implementation has been an open secret for the last week in many circles.
Even though we’re live, there’s still more to be done. One thing that you’ll notice about our data is that we didn’t include a shape file, so in areas where there are not a tremendous number of stops (such as Link routes), the path of the bus does not accurately follow the roadway. A shape file is definitely coming at some point this summer, I’m just waiting on updated GIS files from which I can generate it. It just wasn’t worth holding up the feed for something that I felt was primarily aesthetic.
You also won’t see all the bus stop icons on Google Maps that you see on other implementations. These are updated in a separate Google process that only occurs every one to two months. They will be coming, at some point in the near future (but that doesn’t effect the working of Google Transit).
We’ll also be releasing our raw GTFS feed on our site in the next few weeks, in case any local developers have an interest in using our data for their own projects. And of course, I’m already make modifications for our upcoming 6/18/12 schedule change.
In the meantime, I hope everyone finds the fruits of our effort useful and that it lowers the barrier to trying transit in Burlington for the first time (or allows existing users to use it more frequently). Google Transit is the first of many future improvements to come.
*At some point, I’ll write an entry about how I came to find myself employed in the field of public transit and how Burlington almost didn’t end up as my long term home.