ART - Greater Greater Washington

What's up with NextBus, part 2: A pile of APIs

Fri, 18 Jan 2013 11:38:00 EDT

Why do some apps for getting bus predictions work with some DC-area bus services, like WMATA and the Circulator, but not others, like ART and Ride On? Why couldn't the NextBus DC app just use the same data source that other apps do? Why is this all so complicated? The answer lies in APIs—application programming interfaces—and fragmentation.

USB cables are standard; real-time bus APIs need to be. Photo by osde8info on Flickr.

Previously, we talked about how the NextBus DC app went away because they were getting their data from NextBus Information Systems, which lost its relationship with NextBus Inc., the company powering the WMATA bus tracking web and phone tools known as NextBus.

The plethora of things called NextBus aside, my first question when the NextBus DC app went down was, why can't they just reconnect their app to a data source that isn't broken? If the bus locations still exist, and the bus predictions still exist, and there's nothing wrong with the app's code itself, we should look at why it's not easy for them to simply bypass the broken link in the chain.

To understand what's going on, we have to delve a little more into APIs. An API, or application programming interface, is a way for one computer program to contact another computer and get certain information directly, in a structured format, without a human having to be involved.

For example, Twitter has an API, and if you're writing a software program that accesses Twitter, you can have it talk directly to Twitter to post tweets, search tweets, and so on. I put code on the Greater Greater Washington system so that when a post goes live, it also automatically posts a tweet that the author or editor have written ahead of time, without a human having to go onto the website and click around.

Each API has a certain vocabulary. The asking computer users certain terms, and gets back data in a certain format. Other APIs have different words and different formats. If one API breaks but there's one using the same vocabulary and formats on another system, it's trivial to just have the app connect somewhere else. If the API is different, the software writer has to redo the code, maybe just a little, or maybe quite a lot.

NextBus DC app was not using the "official" API

WMATA contracts with NextBus Inc. to run the bus prediction section of wmata.com and a text message and phone service, but not for an API. For other systems that contract with NextBus, it also offers an API for developers as part of its package of services. However, that is not available for WMATA Metrobus predictions.

A few years ago, WMATA embarked on a pretty ambitious project to offer all kinds of data, including bus predictions but also rail predictions, rail station locations, bus stop locations, schedules, elevator outages and more. Because they have this service, said WMATA spokesperson Dan Stessel, they have asked NextBus not to offer its own, different API.

However, that NextBus API is actually what the NextBus DC app was using, because of the legacy agreements between NextBus Inc., NextBus Information Systems, and AppTight. When those expired, that API went away. AppTight could have probably redone its app to use the WMATA API, but that would not have been an easy task.

Is WMATA right not to let NextBus use its own API? There are definitely some valid reasons for this. Stessel explained that if WMATA let app developers use the NextBus API and then WMATA decided to end its contract with NextBus, all of those apps would break. Plus, there is a lot of other information in the WMATA API, so people building apps on the WMATA API would find it very easy to also show next train arrivals, for instance, while anyone using the NextBus API couldn't.

We need standardization

API formats are particularly important because there are a lot of transit agencies, across different cities and even within our region. If they use incompatible APIs, then it's difficult for app writers to support all of them, and smaller bus systems get left out.

The bigger the potential audience who might pay a buck or two for an app, the more app developers will build transit apps. If they can build one app and have it help riders in DC, New York, Chicago, Los Angeles, etc., that's a lot more incentive to build something than if it just works for one city. Small cities especially benefit here, because not as many people will want to build an app for the bus system in Charlottesville, but if the Chicago app works for Charlottesville too, great.

The same logic applies to bus systems here. Some apps work with the WMATA API but don't support any of the regional bus systems. The DC Metro Transit Info app has Metrobus and also supports Circulator, Fairfax CUE and PG The Bus, all of which work with NextBus and support the NextBus API. ART and Ride On have real-time APIs, but they're not the WMATA or NextBus APIs, and the author of DC Metro Transit Info hasn't done the extra work to integrate those as well.

What needs to happen is that all transit agencies and app developers need to coalesce around one API format. WMATA should modify its systems to offer apps the option of making their requests and getting data back in this standard format. So should NextBus. So should ART and its provider, Connexionz, and Ride On, and New York MTA, and Chicago CTA, and everyone else.

It's similar to power chargers for cell phones. Once, every phone had a different plug. You had to use a special charger just for that phone, and if you got a new phone, your old chargers were junk. Now, almost everyone except for Apple use micro-USB, and all the chargers for my 2½-year-old Android phone work on my brand new one as well.

Fortunately, WMATA is open to changing its API to a standard. Stessel said,

Over the course of the next six months, we will be reviewing our API effort in full, and determining ways to improve the service. Standardizing the format is a definite consideration. However, current applications must be taken into consideration... Short answer: Yes, it is something that is being considered.

If WMATA just switched its API, all existing applications would break, just like NextBus DC did. They could simply offer 2 APIs, but for how long? It creates extra work to have to maintain multiple APIs far down the road. They could switch APIs and offer both for a transition period, perhaps a year, but no matter what some apps won't make the switch.

There's a big obstacle to all agencies moving to a standard API, however: it's not yet clear what the standard should be. If the USB of real-time bus data is out there, there isn't the consensus around it. In upcoming parts, we'll talk more about the API standards that exist today.

Plus, having a standard API is great, but it's useless if the actual bus locations are not good, and many say WMATA's data is just not up to snuff. We'll talk about that and their efforts to fix the problems with bus tracking.

21 comments

What's up with NextBus, part 1: The disappearing app (Jan 16, 2013)
Which DC-area transit agencies offer open data? (Jan 12, 2012)
Ride On piloting real-time bus tracking (Nov 1, 2011)
WMATA allowed to release bus prediction API (Feb 3, 2010)
Nextbus IP, Metro data quality dissuades one developer (Aug 13, 2009)

DC transit in Lego

Tue, 13 Nov 2012 14:19:00 EDT

by Dan Malouff

Constantine Hannaher has made a hobby of using Legos to build models of DC-area buses and trains.

Metrorail	VRE	MARC
Metrobus local	Metrobus express	Old style Metrobus

Fairfax Connector	ART	REX
Howard Transit	MTA (Baltimore)	Dash

See more in Hannaher's Lego set on Flickr.

8 comments

Which DC-area transit agencies offer open data? (Jan 12, 2012)
DoD begins encouraging transit for BRAC commuters (Jul 25, 2011)
WMATA directions now on Google Transit! (May 11, 2011)
Fairfax to restore Connector, make room for WMATA (Apr 19, 2010)
Weekend video: Buses and bike racks (Feb 19, 2011)

Consider adoption

Thu, 21 Jun 2012 08:34:00 EDT

by Steven Yates

Arlington is looking for individuals and groups to adopt an ART bus stop by picking up trash, clearing snow, and reporting any problems. (ARLnow)

Comment

Cold weather, lack of plowing affects bike commuting (Jan 21, 2011)
Virginia Republican pursuing vendetta against Arlington for not wanting to be a "giant interchange" (Jan 25, 2011)
Experimental real-time transit screens come to Arlington, DC (Jan 5, 2012)
Bridge sidewalks need to be plowing priority (Jan 28, 2011)
Arlington PD follows up personally with cyclist (Feb 17, 2011)

Which DC-area transit agencies offer open data?

Thu, 12 Jan 2012 10:35:00 EDT

by David Alpert

Projects like the Mobility Lab's real-time screens and Transit Near Me can help riders and boost transit usage, but they can only show information for agencies which provide open data. How do our region's agencies stack up?

Photo by rllayman on Flickr.

The table below lists the many transit agencies in the Washington region and their open data progress. In a nutshell, there are 2 kinds of open data: schedule data and real-time arrival data.

General Transit Feed Specification (GTFS) files list schedules and the locations of stops and routes, powering applications like making maps or trip planners. Real-time arrival data lets applications tell riders how far away the bus actually is, for tools like smartphone apps or digital screens.

	Schedule data			Real-time data
	Public GTFS	Shapes in GTFS	On Google	Tracking	Tracking API
Metrorail	Here		and Bing		Custom
Metrobus		Most¹	and Bing		Custom
Circulator (DC)	WMATA²		WMATA²		Nextbus
ART (Arlington)	Here		In process		Connexionz
DASH (Alexandria)	Via email only³
Ride On (Montgomery)	Old?⁴				More info
The Bus (Prince George's)					Nextbus
MTA (Maryland) commuter bus	Here
MARC	Confusingly⁵			Here
Fairfax (County) Connector
CUE (Fairfax City)					Nextbus
Loudoun County Transit				Text/email alerts
PRTC
VRE	Unofficial⁶			Mix of GPS & manual⁷

¹ 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.

32 comments

Arlington releases open transit data, on Google soon (Apr 13, 2010)
Fairfax County reluctant to release open transit data (Jun 17, 2010)
Metro "punts": Will release transit schedule data for Google and others (Mar 11, 2009)
Transportation contracts should always require open data (Dec 21, 2011)
Ride On piloting real-time bus tracking (Nov 1, 2011)

Experimental real-time transit screens come to Arlington, DC

Thu, 05 Jan 2012 11:16:00 EDT

by Eric Fidler

If you go into the Java Shack coffee shop near Court House in Arlington, or walk past the Red Palace bar on H Street in DC, you will see a new experimental project from the Mobility Lab: Digital screens showing real-time transit arrivals and Capital Bikeshare availability.

Real-time transit screen at Java Shack.

At Java Shack, customers waiting for coffee or sitting at a table can see the next Metrobus, ART, or Orange Line arrivals, and bike availability at the Capital Bikeshare station across the street. The Red Palace screen faces outward onto the sidewalk on H Street, letting passersby see their bus and CaBi options.

Stop by one of these businesses and let us know what you think! This project is still in an early stage, so the screen displays will evolve over time. Moreover, we're hoping to add screens in more businesses soon.

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.

40 comments

Ride On piloting real-time bus tracking (Nov 1, 2011)
Hack with the Mobility Lab for fun and/or profit (Sep 1, 2011)
Transportation contracts should always require open data (Dec 21, 2011)
Transit Near Me shows your transit choices (Dec 5, 2011)
WMATA allowed to release bus prediction API (Feb 3, 2010)

Bus drivers angry

Thu, 23 Jun 2011 08:51:00 EDT

by Eric Fidler

Metrobus drivers are fed up after several were assaulted. Some may refuse to show up for work today in protest. Metro is considering installing plexiglass barriers ... Meanwhile, the contractor that runs ART fired drivers for striking. (Post)

Comment

Bus drivers launch real-time texting traffic service (Apr 1, 2010)
How many non-bus drivers roll through stop signs? (Oct 21, 2009)
Arlington may quit regional bus pass without revenue deal (Jun 23, 2010)

ART strike over sexual harassment, bathrooms

Wed, 15 Jun 2011 08:23:00 EDT

by David Alpert

ART bus operators explain why they struck: they say the bus company ignored sexual harassment complaints, then fired the union leader, and refused to let drivers use the bathroom. (TBD)

Comment

DC2NY says DDOT rules will kill their business (Jun 23, 2008)
Strike two for NoVa transit (Mar 2, 2008)
Greyhound terminal may move to Union Station (May 12, 2008)

Labor dispute delays ART

Tue, 14 Jun 2011 08:41:00 EDT

by David Alpert

Many ART drivers didn't come to work yesterday due to a labor dispute with the private operator, and that's continuing today. All routes but the 61B are still running but there will be delays. (Post)

Comment

Simplify Shirlington-Pentagon bus choices (Apr 13, 2011)
What do you want to do about labor costs? (Mar 3, 2010)
This bus stops here only during full moons and days with an 'r' in the name (Jun 12, 2008)
WMATA plans new X9, Virginia and Greenbelt bus changes (Sep 16, 2010)
Limited Metrobus and Circulator service resume (Feb 11, 2010)

Simplify Shirlington-Pentagon bus choices

Wed, 13 Apr 2011 11:59:00 EDT

by Steve Offutt

On paper, travelers between Shirlington and the Pentagon have more than 160 buses per day in each direction to choose from. In reality, however, it's difficult to know about and take advantage of these options.

Shirlington bus station. Photo from Arlington VA.

The location of the Shirlington Transit Center bus bays and the fact that two separate operators serve the route, without a combined schedule, hinder passengers' full use of the choices available.

A little restructuring can save passengers from having to remember multiple schedules and know which bus bay to go to depending on when they arrive at the transit center.

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.

20 comments

Pocket schedules could make bus riding easier (Aug 21, 2009)
NextBus doesn't handle station bus bays properly (Jul 7, 2010)
Gotta cut bus service? Let's combine and simplify routes (Jan 14, 2009)
Prince George's plans revised bus service in Greenbelt (Oct 11, 2010)
Do Fairfax's higher fare bus lines make a profit? (Sep 1, 2009)

ART to increase connectivity

Tue, 07 Sep 2010 09:15:00 EDT

by Erik Weber

Starting September 27, ART route 75 will expand to include stops at the Shirlington Transit Center and the Virginia Square Metro station. (ART, Gavin)

Comment

ART purchases

Fri, 27 Aug 2010 08:45:00 EDT

by Erik Weber

Arlington is adding 12 new low-floor CNG buses to its routes over the next several months. (CommuterPageBlog, BeyondDC)

Comment

Use creativity, not ART

Wed, 14 Jul 2010 08:56:07 EDT

by David Alpert

A river taxi is exciting, but maybe they can pick an acronym not already taken by a transit system in the region? (BeyondDC)

Comment

ARTful improvements

Mon, 12 Jul 2010 08:38:00 EDT

by David Alpert

ART is adding a route, #45 between Rosslyn, Arlington DHS at Sequoia Plaza, and Columbia Pike at Four Mile Run Drive, beginning July 6, plus a few schedule changes on other lines. They will also post stop numbers at every bus stop so riders can enter them into the real-time location system. (Gavin)

Comment

Arlington may quit regional bus pass without revenue deal

Wed, 23 Jun 2010 12:45:00 EDT

by Michael Perkins

Metrobus pass holders currently enjoy free rides on all the regional bus transit providers, from DASH to Ride-On, Connector to "The Bus." Right now, WMATA does not share any pass revenue with those transit agencies.

Photo by BlindMadDog on Flickr.

This has become a sore point with Arlington's Chris Zimmerman, County Board Member and a member of the WMATA Board of Directors. At a recent committee meeting of the WMATA Board, he said,

The local providers have been honoring Metro's pass and not getting the revenue back that they're owed on the trip taken on their service ... We're having local providers say, "Look, I can't afford this any more." I'm having to look at cutting service because of increasing cost of running Metro anyway, and now we're losing hundreds of thousands of dollars.

According to Zimmerman, the regional operators agreed to honor the passes "more than a decade ago" under the belief that the paper flash passes would quickly switch to SmarTrip, allowing Metro to track the numbers of rides on each service and work out a revenue sharing deal. However, the passes on SmarTrip took far longer than expected, and now that passes are finally going on SmarTrip a decade later, the regional providers want that revenue agreement.

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.

17 comments

How could Metro share regional bus pass revenue? (Jun 28, 2010)
Bring back bus-rail transfers for pass users (Sep 10, 2010)
SmarTrip passes will start with bus (May 6, 2009)
SmarTrip Web site, passes coming this year (Jun 8, 2010)
Paper bus passes extended through January (Jan 6, 2011)

Even more Arlington

Mon, 14 Jun 2010 12:42:00 EDT

by David Alpert

The Arlington County Board approved a snow ordinance by a 4-1 vote ... If 95/395 HOT lanes go forward, they would require some public money, which Virginia doesn't have in any case (Uriah Kiser/Inside NoVA via ARLnow) ... An ART fare hike will follow WMATA's, but will eliminate the cash-SmarTrip differential. (Gavin)

Comment