Posts about ART

	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.

One of the main challenges in convincing people to switch to transit is the unpredictability of bus arrivals. If every stop featured a digital screen displaying the number of minutes until each bus arrived, more people would be willing to take the bus.

Outdoor screens, however, are expensive to install, which is why we created this indoor alternative at a fraction of the cost. For the past few months I have been working with Andy Chosak and David Alpert at the Mobility Lab in Arlington to bring this low-cost alternative to fruition.

Screenshot of the Java Shack screen.

Screenshot of the Red Palace screen.

Every 20 seconds, our web server queries each transit agency for the arrival predictions for the stops near both test sites, then relays the data to the screens. The actual unit inside the shops is just a low-cost, barebones Linux system connected to a standard computer monitor and the business's own Wi-Fi and power. We've configured the box to automatically load up the screen when it starts, so there's no need to log in or launch an app after the unit is plugged in.

We are continuing to build the system so it can be deployed quickly and cheaply throughout the region at participating shops, bars, cafes, and restaurants. Ultimately, a business will be able to sign up, type in their address, and get a screen automatically customized with the nearest bus stops, Metro station, and Capital Bikeshare station. And someone with their own computer connected to a standard computer monitor will be able to set up their own screen for free.

This project is only possible thanks to open data from our transit agencies. We can only pull bus and train predictions as well as the status of each CaBi station because the agencies behind these systems have wisely chosen to provide stop locations, route information, and real-time arrival predictions to outside software developers.

If you run a businesses are interested in finding out more about purchasing one of these screens for your location, let us know at screens@mobilitylab.org.

Metrobus routes 7A/C/E/F/Y, 22A, 25A/D and ART route 87 serve the I-395 corridor, connecting downtown Shirlington to the Metrorail network. The 7A and 25A are express, taking 6-9 minutes to travel directly between these two stations. The 22A makes a few stops before getting on I-395, resulting in a travel time of about 12-14 minutes. The ART bus takes a local route that takes about 23-27 minutes, meaning that for Pentagon-bound passengers it is usually advantageous to wait for the next Metrobus than take the ART 87.

At Shirlington the 7 and 25 buses are located at Bus Bay C while the 22A is located at the farthest possible point away, bus bay A:

Because these buses travel through the transit center in opposite directions, it's not possible to locate them all at the same bay. But placing them at adjoining bays A & E or B & C would make a lot more sense. A passenger wanting to go directly to the Pentagon would not have to dash around the station to the far end to catch the other bus.

It would be difficult to arrange the bays any more rationally at Pentagon station. There, four adjoining bays, Upper 3, 4, 5, and 6, serve the Shirlington routes. Riders have to be astute to note the alternate buses arriving and knowledgeable of their various options. ART bus locations are not shown on this map, which appears to be somewhat out of date.

While WMATA posts station bus stop maps for rail stations such as the Pentagon, ART's site had a better graphic and includes the Shirlington transportation center map as well.

Because there are several routes that serve these two points, many riders probably only learn over time that they have several options. There is no combined point-to-point schedule of the 160+ buses per day that would make this information easy for passengers to have, hold and use.

Also, since NextBus treats each bus bay as a separate stop, it doesn't effectively serve these customers, who don't care what bus number they get on—they just want to get between these two points as quickly and easily as possible.

There are other cases where a rearrangement of bus stops at the Pentagon would help riders: e.g., the 29 and 17 buses both serve some of the same parts of Annandale, but are located on separate levels at the Pentagon. Similarly, the 25 and 8 buses share parts of Alexandria, but are located far apart at the Pentagon. Passengers are forced to choose one bay or the other, which may frustrate them if circumstances (like a late bus) work against them.

A programmer could probably create a simple smartphone app using NextBus data that would combine the Shirlington and Pentagon bus stops (or other highly-used point-to-point locations), which would be quite useful to these passengers.

These simple changes and enhancements would cost little or nothing, but would get more riders to their destinations quickly and easily. If transit agency planners and managers were to imagine themselves in the shoes of their customers, these kinds of improvements could be more obvious.

Under the Arlington County Board's recently approved transit fares, if a regional revenue sharing agreement cannot be reached, the County Transit system could withdraw from the regional bus pass and would issue a bus pass of its own. Combined with recent county efforts to replace Metrobus service with ART service, this degrades the value of a Metrobus flash pass, and hurts our regionally integrated transit system.

Board members Peter Benjamin from Maryland and Jim Graham from DC confirmed that those jurisdictions are interested in getting a share of pass revenue for the rides that are provided on local systems. Benjamin stated that the result would be "changing the subsidy level from local to Metro."

While it's true that this is all government money anyway, and any changes would be just payments from one government-subsidized transit system to another, the important thing is the amount of those transfers. Right now, the local governments provide service and get nothing from pass users. But a well-designed revenue sharing system would transfer revenues in a way that's related to how much service people are using, so a jurisdiction that provides service that a lot of riders are using would get a much larger transfer of revenue than one that doesn't provide much service.

Clearly, it would be preferable to maintain our region's interoperable passes, so some sort of revenue sharing needs to be devised. Tomorrow, I'll discuss some options and my recommended plan.