Posts about Google

	Schedule data			Real-time data
	Public GTFS	Shapes in GTFS	On Google	Tracking	Tracking API
Metrorail	Here		and Bing		Custom
Metrobus		Most1	and Bing		Custom
Circulator (DC)	WMATA2		WMATA2		Nextbus
ART (Arlington)	Here		In process		Connexionz
DASH (Alexandria)	Via email only3
Ride On (Montgomery)	Old?4				More info
The Bus (Prince George's)					Nextbus
MTA (Maryland) commuter bus	Here
MARC	Confusingly5			Here
Fairfax (County) Connector
CUE (Fairfax City)					Nextbus
Loudoun County Transit				Text/email alerts
PRTC
VRE	Unofficial6			Mix of GPS & manual7

¹ WMATA's GTFS file contains most Metrobus routes, but some paths cut diagonally across the grid over some long sections such as freeway or bridge segments of routes.

² Circulator route and schedule data is included as part of the WMATA GTFS feed. However, there are some quality issues such as route names.

³ DASH feed is not publicly available, but officials can provide it via email.

⁴ Ride On's feed no longer appears to be on their website. GTFS Data Exchange has cached a version from December 2010 which was apparently posted in a news release.

⁵ MARC lines are listed in the MTA Maryland feed as lines 300, 301, and 302, which doesn't very easily differentiate them for someone unfamiliar with their GTFS feed.

⁶ Someone not affiliated with VRE created a GTFS file in 2009, but it hasn't been updated since and VRE does not offer an official one.

⁷ VRE has a page with train status which lists some trains' positions through GPS and some from manual reports from the conductor.

What the columns mean

Creating public GTFS feeds (the 1st column) allows someone who's written an app to easily incorporate schedule and route data for a transit agency. GTFS has emerged as a national standard for representing transit feeds, and there's tremendous value in having as many agencies as possible support the same standard. That way, if someone writes an app in Chicago, they can make it work in Denver, Albany, or Miami at the same time.

Most of the transit agencies' feeds including the paths that the vehicles take, but some do not, like DASH. The 2nd column shows this information. Feeds without paths are still usable, but apps that visualize routes, like Transit Near Me, end up showing unsightly diagonal lines cutting across city blocks.

Agencies can also sign a contract with Google to have their routes and schedules on Google Maps. The 3rd column shows agencies which have done this. Some agencies put out their data files, but aren't willing to sign this contract because of indemnification or other clauses which Google unfortunately insists upon. On the flip side, some agencies sign up with Google but then don't publish the GTFS feed publicly.

The agency might provide it to those who ask, or might not, but this dissuades app creators from including this agency, and makes it harder for them to get regular updates. Every agency should strive to host a public and up-to-date GTFS feed on their site so that anyone building apps can easily incorporate that agency's services into the tool.

The other type of open data is real-time locations or predictions. To make this possible, agencies first have to deploy AVL (Automatic Vehicle Location) technology on their buses or trains (the 4th column). The main obstacle is that this is somewhat expensive; a physical device has to go into each vehicle, and those devices then need some amount of maintenance over time.

Once an agency has tracking, it's relatively simple to offer a computer interface for apps to access and tell riders about this information (the 5th column). Most of the agencies with tracking offer such an interface, but while Ride On, MARC, and Loudoun Transit all have public tracking sites that provide some services to riders, but no way for other apps to tap into the information those sites contain.

What agencies can do

Agencies with red X's on this chart can start thinking about how to provide schedule and/or real-time open data. Creating GTFS files isn't extremely difficult, though it does require some staff time to actually do it. For agencies that use scheduling software, the manufacturers of that software often offer modules to export data as GTFS as well.

Some GTFS feeds could benefit from quality fixes. For example, WMATA's Metrorail GTFS file doesn't show the specific paths trains take, and paths are missing for a few bus routes. The "Transparent Metro Data Sets" Application Programming Interface (API), a special interface WMATA created to offer access to much of its data, does include the correct paths. But many people develop apps to access GTFS files for multiple cities. It's much less likely they will put in extra development effort to specifically pull just these route shapes from this unique API.

The Circulator's routes are part of the WMATA GTFS feed, which makes things even easier for apps than having to download a separate feed. One problem is that the route names are all cryptic: there's "DCDGR" for the Dupont-Georgetown-Rosslyn Circulator, or "DC98" for the route which replaced the former 98 bus. Those are fine for internal systems inside the agencies, but they aren't very clear to riders.

Agencies which have provided their data to Google but don't offer the feeds publicly (like DASH, Ride On, and MARC) should post those feeds on their websites and publicly link to the feeds. They are already creating the GTFS files for Google, so it's a trivial step to also let others download the same files.

WMATA also has much of the route data for other local bus systems in the region as well, which it uses in its trip planner. Agencies which don't have GTFS files can give WMATA permission to include their data in its GTFS feed, as the Circulator does.

Agencies with AVL systems already on their vehicles should set up APIs to give apps access to the locations or predictions, and agencies without AVL can work toward getting the budget necessary to deploy AVL.

What others can do

Transit industry associations and vendors which sell technology to transit agencies can all encourage open data to be part of any contract. Vendors can encourage agencies to open their data and provide services to do so, and associations can encourage agencies to ask their vendors for these services.

The industry can also help move toward a clear standard for bus tracking. GTFS has become a standard for schedule and route data because large numbers of agencies went ahead and offered GTFS files. But there is not yet a consensus around what format to use to offer real-time predictions.

WMATA built its own API which provides the data in a certain format. Circulator, The Bus, and CUE all use Nextbus for tracking, which has its own API. ART uses another service, Connexionz. This unfortunately means that anyone building a real-time application and wants to incorporate multiple services has to support at least 3 different APIs.

There are efforts to create such standards, like GTFS-Realtime, but this hasn't realized the same widespread adoption as GTFS, nor has any other standard.

It's still possible to build apps without a standard, and the Mobility Lab's real-time screen project does connect to all 3 different systems in our region. But that requires extra work, not just for the Mobility Lab but for every other app creator who wants to offer predictions for multiple transit agencies.

The easier we make it to build apps, the more we'll get. Ultimately, it would be great for one standard to emerge, and for the various vendors like Nextbus to agree to all offer data to apps in that same standard format.

Update: Commenter intermodal commuter pointed out the real-time status page for VRE. It combines some train positions from GPS and some from manual reports from conductors. There is not an API to access the data. I've corrected the chart.

Update 2: Commenter Adam noted that MARC is actually contained in the MTA Maryland GTFS file, but listed only as routes 300, 301, and 302, which we didn't realize were not commuter buses upon examining the feed. But you can see the MARC lines on Transit Near Me (for example, center around Union Station).

Also, ACCS Web Manager Joe Chapline posted a status update about ART's efforts to get into Google Transit; according to Chapline, this was delayed for a time due to contract issues, and now is awaiting action by the Google legal department, which I know from past personal experience is often understaffed and backlogged.

The new imagery hasn't been put in Google maps yet, but when it does, you'll be able to catch a glimpse of what it's like to ride a train through the Swiss Alps, from the driver's seat.

Rhaetian Railway partnered with Google to make this happen. The imagery was captured by mounting the Streetview trike on a flatcar. The railway company hopes it will attract riders. And Google has helped to document a UNESCO World Heritage Site.

I tried it on my way to work today. Although the GPS signal did not work underground, when I arrived at Eastern Market I was directed to take "DCN22" (the old name for the Circulator). Following the route on my bicycle, I was notified when I would have reached my stop. During the trip, my phone plotted my location on the map using the familiar blue triangle.

Screenshots of a sample trip with real-time information. Image from Google.

Google is not the only one building tools to notify riders of transit information. Metro itself is working on a system to alert riders when there is a major delay to their line, using emails and text messages, spokesperson Dan Stessel told the Riders' Advisory Council last night. New Jersey Transit has a similar system, set up by the communications people who Richard Sarles has now brought down to Washington.

But Metro can't build everything. An outage notification system is perfect for a transit agency to build, but they're not going to be building the map application installed on everyone's phones. By opening up data publicly for developers, Metro has made it possible for innovations like this to come to millions of residents and tourists.

Most of the region's local transit providers have already released their routing data publicly and are included in Google Maps. The few remaining ones ought to follow as soon as possible.

Bike sharing companies would likely need to put their data in a common format with the key information like hours (or seasons) of operation, precise location, and perhaps station size. Interested companies would put the completed data in a publicly-accessible location and submit the URL to Google or, better yet, a public, common list of feeds like GTFS Data Exchange does for transit data.

Washington isn't the only region that has a bike sharing system. With a common format and a software upgrade, Google could provide bikeshare directions to riders in Paris, London, Montreal, Minneapolis, or Barcelona. Any city that has a bikeshare system based on fixed stations could be included.

And with the feeds publicly accessible, other services like the open source OpenStreetMap and OpenTripPlanner, along with the many availability tracking tools, could build services that simultaneously serve all bike sharing systems.

Surely, there is a Google engineer with some 20% time for this. If you're interested in encouraging Google to add bikeshare directions, you can add a note of encouragement to the Maps discussion page.

WMATA just put out a press release that they and Google "will make a joint announcement about technology improvements that will benefit Metrorail and Metrobus riders" tomorrow. They don't say what the announcement will be, but there happens to be one service WMATA and Google have been working on for a long time now, for which they signed a contract in July and said was "very close" in March... and which has suddenly become available for riders.

The service has also been available on Bing Maps for some time.

Since the MTA Maryland buses and light rail and MARC are all on Google already, you can now also use Google Maps to plan a trip from Baltimore to DC using multiple transit services. Here's a somewhat complex example, with 6 different options; one even uses the Amtrak Northeast Regional.

The DC Circulator and Montgomery County's Ride On are also on Google already.

We're just two days shy of 29 months since Michael Perkins launched our first email petition to ask WMATA to take this step for riders. Michael kept doggedly on the story, FOIAing other cities' agreements to rebut arguments about legal obstacles. There was a lot of resistance from within the agency and from some members of the Board, but other sympathetic staff and Board members pushed this forward, and now it's a reality.

Thanks, WMATA!

Disclosure: I used to work for Google, but had no involvement with Google Maps. I no longer own any Google stock and have no other financial interest in Google.

New Gaithersburg Heights: The blogger behind New Columbia Heights moved to Gaithersburg, learned to walk a dog while driving an SUV, and inaugurated a new feature, Chili's of the Day.

We want 3-D! Wheaton residents are outraged that a proposed plaza for Wheaton looks like a Sketchup model, and started a group "3-DIMBY" to push for a more 3-dimensional plan. (JUTP)

Too many ped-on-ped crashes: The New York DOT was alarmed to discover a high frequency of pedestrian-on-pedestrian crashes. Small children even get into such crashes intentionally. Fortunately, there are very few injuries. (Transportation Nation)

Planjokizen: Ben & Jerry's adds a new flavor, Janette Sadik-Pecan ... LA will add car racks to its buses ... After many Republican governors rejected high-speed rail money, Ray LaHood spent the $2.4 billion on a huge party in Las Vegas. (Planetizen)

Public spaces get better: The Project for Public Spaces, which always does great news coverage at the start of April, revealed that Brooklyn's Prospect Park West will new get new kayak lanes, Arlington, Texas will train riders to use ESP to find out when their bus is coming, a new iPhone app helps starchitects not listen to public input, and a newly-unveiled plan would solve New York congestion by replacing most of Manhattan with freeways. Once upon a time, that last one was not a joke.

I know that technological projects sometimes take longer than expected and problems can crop up. However, WMATA management has continuously remained very tight-lipped about their lack of progress, and did not respond to a request yesterday.

It certainly seems as though this is simply not getting much attention at all. If it is, and there are just unforeseen issues, or if Google is the one being difficult, it would certainly behoove WMATA to explain these facts.

The agreement was signed in July, and the data made high-quality enough to release publicly in the fall. Now, according to Sarles, they are working to prepare the data to upload to Google.

In response to a question from Councilmember Tommy Wells at the oversight hearing this morning, Sarles noted that Metro routes and schedules do appear on Microsoft's Bing. What's so much harder about getting on Google?

A comment from Chris Zimmerman last July continues to seem most prescient. He said this project seemed to be "asymptotically approaching" completion. So far, that's still as true now as it was then.

Disclosure: I used to work for Google, but had no involvement with Google Maps. I no longer own any Google stock and have no other financial interest in Google.

The indemnification paragraph from the boilerplate agreement appears to be missing, which means that WMATA would not be held liable for any mistakes caused by Google and did not agree to legally defend Google if they were sued. This was one of WMATA's biggest objections to signing the boilerplate agreement. We first reported that Chicago was able to remove this indemnification from their agreement.

Either party may terminate the agreement, unlike the boilerplate agreement, which only gives that option to Google. The agreement provides rights to both WMATA and Google where the boilerplate agreement only provides them to Google.

The agreement WMATA got looks like the best they could hope for. It's balanced and removed the features WMATA found most objectionable. WMATA's status as one of the largest transit agencies in the country allowed them to negotiate from a better position than most agencies.

I haven't been able to get an update on the actual Google Transit release date.