Greater Greater Washington

Posts about Ride On

Transit


Montgomery County added 100,000 residents since 2002, but driving didn't increase

Montgomery County has 100,000 more residents than 10 years ago, but the amount of driving in the county has actually stayed the same, says a new study on how people get around. Meanwhile, more people are walking and biking inside the Beltway, and bus ridership is growing well outside it.


Montgomery County's population has grown, but the amount of driving miles hasn't.
Graph from the Planning Department.

Drivers traveled about 7.3 million miles on state roads in the county in 2012. It's a slight decrease from 2011, but about the same as in 2002, when the county had just over 900,000 residents, compared to 1.005 million residents today. It's in line with both regional and national trends, and suggests that people didn't stop driving simply because of the Great Recession.

The results come from the Mobility Assessment Report, which the Planning Department conducts every few years to identify Montgomery County's biggest transportation needs. County planners measured pedestrian, bicycle, and car traffic throughout the area, in addition to looking at transit ridership.

Silver Spring has more foot traffic, Bethesda has more cyclists

Planners counted the number of pedestrians at 171 locations and the number of cyclists at 25 locations across the county, and plan to do more detailed studies in the future. Not surprisingly, the most walkers and bikers can be found in the county's urban centers, including Silver Spring, Bethesda, and Wheaton, as well as White Flint.


9,500 people use the intersection of Georgia and Colesville each day. All photos by the author unless noted.

The county's busiest pedestrian intersection is Georgia Avenue and Colesville Road in downtown Silver Spring, with 9,500 pedestrians each day. (By comparison, the intersection of 7th and H streets NW in the District sees 29,764 pedestrians daily.) All of the county's busiest intersections for cyclists were in Bethesda; number 1 is Woodmont Avenue and Montgomery Lane, with 163 bikes during the morning and evening rush hours.

More bus riders in the Upcounty

Montgomery's busiest Metro stations are inside the Beltway, including Silver Spring, Bethesda, and Friendship Heights, as well as Shady Grove, a major park-and-ride station. The most-used Metrobus routes are also closer in, like the C2/C4, which serves Langley Park, Wheaton, and Twinbrook and serves over 11,000 people each day, and the J line, which serves Bethesda and Silver Spring.

Surprisingly, the county's busiest Ride On routes are now in the Upcounty: the 55, which runs along Route 355 between Rockville and Germantown, and the 59, which serves Rockville, Gaithersburg, and Montgomery Village. These routes all carry between 3,000 and 4,000 riders each day; the 55 is one of the county's most frequent bus routes, running every 10 minutes during most of the day.


A Ride On bus in Germantown.

That said, transit use in the county has fluctuated in recent years. After decreasing during the recession, daily Metrorail ridership has remained stable since 2009 and fell slightly from 28,504 riders between July 2012 and July 2013 to 27,360 during the following year. About 57,000 people rode Metrobus each day over the past year, a decrease of 6,000 from the previous year.

Most transit riders in the county take Ride On, which carried 88,370 people between July 2012 and July 2013. While it's a slight increase from the year before, it's still 7,000 fewer riders than in 2008, when the county made significant service cuts that were never restored.

More people are using the ICC, but fewer than expected

Meanwhile, more people are using the Intercounty Connector, the highway between Gaithersburg and Laurel north of the Beltway that opened in 2012 and will finish construction this year. An average of 30,000 vehicles used the toll road each weekday in 2012, while traffic rates have increased about 3% each month.

But traffic on the ICC is still much lower than state officials' estimates, raising the question if it was worth the $2.4 billion cost. It does appear to have taken cars off of parallel roads, like Route 108, Route 198, and Norbeck Road, where traffic has fallen by up to 16.9% since the highway opened.

Some roads are always busy

Planners noted several roads that have consistently high congestion, like Rockville Pike, Georgia Avenue, Veirs Mill Road, and Colesville Road. It's no coincidence that these are four of the corridors where both the county and the State of Maryland are studying the potential for Bus Rapid Transit.

There isn't a lot of room to widen these roads or build more interchanges, meaning we have to find new ways to add capacity. Trends suggest that Montgomery County residents are driving less and using transit more, at least when it's frequent and reliable. And as the county continues to grow, we'll have to provide more alternatives to driving if we want to offer a way out of traffic.

Budget


Montgomery's proposed budget takes transit funding and gives it to wealthy homeowners

Yesterday, Montgomery County Executive Ike Leggett unveiled his proposed budget, and it has no good news for transit riders. Ride On will get more state aid and hike fares, but it will not run any more buses. Instead, transit revenue will be used to cut real estate taxes.


Photo by Adam Fagen on Flickr.

The cost of running Ride On, as shown in the budget will go up $3.5 million, from $98 million to $101.6 million. Meanwhile, the county will receive $7 million in new revenues, double the cost increase. $5 million in new state aid will come from the gas tax increase passed last year. And fares will rise $2 million, likely a result of matching Metro's fare increase.

Where will this money go? The county's "mass transit tax," a component of the real estate tax, will drop by $5 million. Bus riders, many of whom have low incomes or are renters, will pay more while a tax cut disproportionately benefits the county's wealthiest homeowners.

When Maryland discussed a gas tax increase last year, many groups complained about "raids" on the state's transportation trust fund, including county governments, legislators, conservatives, and the highway lobby. It will be interesting to see how these groups react to this diversion of trust fund money to non-transportation purposes.

Ride On could put the new money it is getting from the state and its riders to good use. The system lacks relief buses, or vehicles on standby, stationed around the county to fill in when other buses break down.

The county counts all late buses equally when it tracks Ride On's performance, but for a rider, there's a vast difference between a replacement bus that comes late and a bus that doesn't come at all. If there's no replacement, the next bus half an hour later might be so full that you can't get on.

Other needed upgrades include restoring the connection to Frederick County buses in Urbana, straightening out the tangle of bus routes around downtown Bethesda, and better weekend service. Funding is also needed for Metrobus's Priority Corridor Initiative, which would improve service on several of the county's highest-ridership routes.

The budget now goes to the County Council for approval. Hopefully, bus riders will find friends there.

Transit


What's up with NextBus, part 3: Where Ride On is the leader

Which Washington-area bus system was the first to offer its bus position data in an open standard? Would you believe it's Ride On?

In part 2, we talked about how there are many different APIsapplication programming interfaces, the way one computer system, like an app, gets data from to another, like bus positions from a transit agency. The fact that there are so many APIs means many apps don't include all of the types of buses in the region that have real-time positions and predictions.

Prince George's The Bus, Fairfax City CUE and the DC Circulator are available using NextBus, Inc.'s API, which is one of the most common because many agencies contract with NextBus, Inc. WMATA also contracts with NextBus, Inc. but doesn't use its API; WMATA built its own. ART has a different one entirely.

Since NextBus is most common, some residents asked Montgomery County officials why RideOn is not part of NextBus, too. One was Evan Glass, who tweeted last May:

Why is MoCo's Ride On bus system not accessible on the #NextBus app when all other jurisdiction are? #14bus cc @hansriemer (@EvanMGlass)

Note that Glass was talking about the "NextBus DC" app, the one that died this past December and, people discovered, actually wasn't from the same company as the one that provides bus prediction services to many transit agencies.

Councilmember Hans Riemer passed the question on to Ride On officials. Carolyn Biggins replied:

Recently, our staff met with a representative of NextBus to discuss products and costs. Although NextBus has not yet given Montgomery County a firm price quote, they offered a ballpark figure of approximately $55,000 per year for operating costs. This would cover a barebones system which would only have their mobile and desktop web site along with a suite of management tools. There are also undetermined setup fees, probably starting around $15,000 but possibly much higher. ...

At this point the inclusion of NextBus into the Ride On Real Time customer information product line is actively open for discussion. Feedback from our customers and industry critics point us in various directions and toward various apps; and, interestingly, NextBus is not at the top of our customer's request list.

Besides our Eastbanc/Nerds Ride On Real Time App (available for iPhone and android) which, by the way, includes integrated real time data from Metrobus, Metrorail and several Northern Virginia jurisdictions, our customers have asked us to integrate into the "DC Metro Transit App" and "OneBusAway."

We have been working with developers for DC Metro Transit App who recently responded to us with a very encouraging post about our open data: "This seems well thought out and documented. It is also nice that you can get the data in both JSON or XML [the 2 most popular formats for getting data from APIs] in a restful service [basically, a way of making APIs easier for the app developer to use]. I'll give it a try in the app and let you know if I have any questions. You guys are ahead of the curve compared to other agencies."

As you mentioned in your recent e-letter, Open Data and public/private initiatives, such as 3rd party app development, is the wave of the futureto "disrupt and create." 3rd party app development not only unleashes the initiative of the private sector but also provides varied choices for our citizens: the delivery of information in many different formats to suit different consumers with varied needs and tastes.

In developing our Ride On Real Time system, Transit Services has taken this approach, both through internal product development but also by providing its data in as many different formats as possible while trying to maintain fiscal responsibility. We will continue to work with NextBus and other vendors to try and provide Montgomery County citizens the very best in transit information and customer service.

(Notes in brackets added.)

Biggins is right. The solution to the problem of Ride On not being part of many existing apps is not to work with any particular vendor, but to provide open data in more formats.

It's particularly good to hear this from Ride On, because at first they did it wrong, and contracted with a software developer just to build them a website where people can track buses, but with no way for 3rd party app developers (in other words, people who aren't the agency or one of its contractors) to access the data.

Following prodding from Kurt Raschke, us, and others, Ride On started offering an API, and even fairly quickly improved it based on feedback from Raschke and other developers.

Why doesn't everyone just use GTFS?

In the area of transit schedules, one standard has largely emerged as the most common, and one all transit agencies ought to offer: the General Transit Feed Specification, or GTFS. GTFS is basically a set of big files that contain every single stop location and all of the schedules for the transit system. You can download it, write code to analyze it, and then do whatever you want.

There's an analogue of GTFS for real-time buses, called GTFS-realtime. However, real-time is not the same as schedules. With schedules, you can download the whole thing once and it basically won't change except every few months. With real-time bus tracking, the positions change every minute.

GTFS-realtime lets you download the entire set of bus positions as they constantly change. It's a huge amount of data. For some applications, like if you're making a live map showing buses, that's what you want. For the typical smartphone app, where you just want one bus position at a time, it's too much. That much data would overtax the user's data plan and burden the phone trying to deal with it all.

Other APIs, like the NextBus and WMATA APIs, work differently. For those, an app sends it only the very specific question it wants answered, like asking for next arrivals at a particular bus stop.

Twitter, as an analogy, has both types of APIs. For most uses, you use a more transactional API. You ask Twitter for a list of recent tweets matching a hashtag, or ask it to post a specific tweet. But Twitter also offers a "firehose" API where certain users, who have to be approved ahead of time, can get the entire stream of all tweets, everywhere.

We need GTFS-realtime AND a transactional API

Ultimately, for transit, there needs to be both. If you're building a smartphone app, it's too hard to get the firehose of all bus positions, and easier to ask one simple question. But if you're designing a real-time screen, it's a burden to ask for each possible bus and bus stop every minute; you'd rather just get all the data at once.

WMATA's API also goes through another service, called Mashery, which limits how many of these API questions you can ask in a set period of time. The intent is to keep someone from overwhelming WMATA's systems and crashing them. But when Eric Fidler was building the real-time screen demos, he found that just asking for a few bus lines at nearby bus stops every minute, his system quickly hit the limit.

Plus, since one server was running many screens at once, the more screens, the quicker you hit the limit. We kept asking WMATA to increase the limit, and they did, but for many applications these limits will quickly become untenable.

Every transit agency ought to provide GTFS-realtime feeds for those that need them. ART's vendor, Connexionz, now also offers it, making 2 area agencies that do. Others should join Ride On and ART and offer this feed as well. Often it will be the agency's API contractor that offers it; agencies that pay NextBus for bus tracking services should require NextBus to offer a GTFS-realtime feed.

What's the common transactional API?

At the same time, we need a transactional API, ideally a common one. If everyone used the same API, it would be really easy for app developers to support all of the region's (or the nation's or world's) bus systems.

Unfortunately, there is no consensus here, unlike with GTFS. Most APIs are nonstandard ones an agency's IT staff or its contractor devised. New York uses the European standard SIRI, but had to make some changes of its own, and few US agencies use that. NextBus's is pretty widespread since that company serves a lot of agencies.

What to do? There are a few solutions.

First of all, everyone could get together and try to coalesce around an existing standard. It doesn't really matter which. It doesn't have to be the best one. Most standards are pretty imperfect; we type on QWERTY keyboards, which are one of the least efficient keyboard layouts you could devise, but any effort to come up with something else has failed. There's a strong lock-in, but to some extent, it doesn't really matter; we manage to type fine.

We could use SIRI; Europe does. Or NextBus could make their API a standard. Google did this with GTFS. Google initially created GTFS, but then they stopped controlling it and let the community of developers and agencies take control. They changed the "G" to stand for "General" instead of "Google." Many standards in computing started out as some company's property, but they transferred it to some national or international committee to shepherd.

If NextBus wanted to do this, they would probably want to give it a different trademark, so an agency offering the API wouldn't be saying they offer "NextBus" (we've had enough problems with NextBus trademark confusion already). And they would need to let other agencies and developers make changes, through some process, without the company having control.

Another approach would be to not worry about this at all. It's not all that hard to write some code to interact with multiple APIs, as long as they have a few features that you need to make them interoperable, like common identifiers. In the next part, we'll talk about this.

Some other company or entity could also set up an intermediary computer system that takes in all of the data on one end, and lets app developers connect to it. It would have to get the "firehose" style data from the agencies, and can then even offer 5, 10, or 50 different styles of APIs on the other.

What has to happen for that to be possible? For one, someone has to maintain it and pay for the bandwidth. An organization like COG, or a partnership of the DC, Maryland, and Virginia state DOTs, could do it. Or, to go national, a group like APTA or a federal agency could provide it. Or, perhaps some private entity would find it worthwhile, though the amount of revenue they could make is probably limited.

But for that to happen, the agencies have to offer the "firehose" of GTFS-realtime. For that reason, while there isn't consensus around all of the APIs, our region's transit agencies can and should take one step now, to offer GTFS-realtime, as Ride On and ART now do.

Transit


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

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 APIsapplication programming interfacesand 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.

Transit


"Transit-oriented" development plans are meaningless without transit

In Clarksburg's Master Plan, the Montgomery County town is a transit-oriented community. But in reality, Clarksburg is a transit-lacking community, because the county government has not supported transit.


Photo of Clarksburg by Dan Reed! on Flickr.

Construction has begun in Cabin Branch, Clarksburg's first development west of I-270. Cabin Branch is 535 acres approved for 1,886 houses, 500 senior units, and 2.4 million square feet of commercial space. And Cabin Branch is transit-oriented development.

Or, rather, "transit-oriented" development.

The transit that Cabin Branch is oriented around is the terminal station of the Corridor Cities Transitway at Comsat in Clarksburg, a planning consultant told the Boyds Civic Association last week. The station is located a mile or two east of Cabin Branch, on the other side of I-270. Residents will travel to this station via Newcut Road Extended, a 4-lane divided arterial highway with a separate bike path and an interchange with I-270.

However, the new residents of Cabin Branch may find it hard to actually use this transit, because there is no Corridor Cities Transitway station at Comsat. In fact, there is no Corridor Cities Transitway at all. And the Newcut Road crossing of I-270 does not exist either.

Nonetheless, despite the absence of transit, it is legitimate to refer to Cabin Branch as transit-oriented development. Why? Because the Clarksburg Master Plan says so.

Some background on Clarksburg: Clarksburg is the last corridor city along I-270 in Montgomery County's 1964 land use plan, called On Wedges and Corridors. Roughly 6 miles north of Germantown and 12 miles northwest of the Shady Grove Metro station, Clarksburg is both a historic small town and, since 2000, a neo-traditional new suburb. The 1994 Clarksburg Master Plan governs the town's development.

This Master Plan refers to the transit-orientedness of Clarksburg development at least 24 times. For example, "...the most critical function of this Plan is to establish a strong public commitment to the vision of Clarksburg as a transit- and pedestrian-oriented community...," the plan says on page 1. "Transit is an essential feature of this plan; without it, the Plan's vision cannot be realized," the plan says on page 22.

The plan envisions a transit system consisting of 3 parts:

  1. A "regional transitway," extending from Shady Grove to the City of Frederick, with a stop in Clarksburg Town Center;
  2. An additional "through-transit" system in the form of the existing MARC station at Boyds, 2 miles south of Cabin Branch; and
  3. A "comprehensive" network of local buses linking neighborhoods with the regional transitway and the Boyds MARC station.
For Cabin Branch specifically, the Plan says that "the opportunity to provide a transit-oriented residential neighborhood" is one of the "most important public policy objectives" (p. 64). Also, it says that the "Plan endorses a transit-oriented development pattern…which will place all residents within convenient walking distance (one-quarter mile) of a bus stop," with the "neighborhood core to be located so that bus service will link the area to the transitway to the east, and the MARC station to the southwest" (p. 68).

Fine words.

But the Master Plan does not link these words to deeds. There is nothing in the Master Plan's staging requirements about the transit that, according to the plan, is "essential" for turning the vision of Clarksburg into reality. The staging requirements relate only to water quality reviews; provision of water and sewer service; amount of retail development; number of building permits; and the financing of public facilities. Note that, according to the county's Adequate Public Facilities Ordinance, public facilities include roads, but they do not include transit.

As a result, the transit-oriented development in Clarksburg has proceeded without transit.

In 1994, the Master Plan stated that "[a]t present, transit service consists of a limited number of buses on existing roadways and the commuter rail station in Boyds."

18 years and more than 12,000 new Clarksburg residents later, transit service still consists only of a limited number of buses (2) on roadways and the commuter rail station at Boyds.

Of the 2 buses, 1 runs every half hour on weekdays between the county jail in Clarksburg and the Germantown Transit Center. The other runs every half hour during weekday peak hours between Clarksburg and the Shady Grove Metro station, a 45-minute trip by the schedule.

Meanwhile, the Boyds MARC station has limited service, an 18-space parking lot that is already often full, and no bus connections. In fact, there is not even a bike rack.

So when people start moving next year into the "transit-oriented" Cabin Branch development in "transit-oriented" Clarksburg, they will have little choice but to drive. Montgomery County says all the right things about transit. But what Montgomery County actually acts on is cars.

Transit


Which DC-area transit agencies offer open data?

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

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

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

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

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

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

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

Transit


Ride On piloting real-time bus tracking

Bus riders in Montgomery County can start trying to track their Ride On buses with a new real-time system the county is piloting. However, the system still lacks a public API that would allow developers to use the data in other applications.

A map application lets you enter a stop, pick a stop from a list of routes and their stops, or enter an address. The map then shows the entire route, a green circle at the stop's location, and the position of buses along with an estimate about when they will arrive.

One potentially tricky element for those picking routes is that you have to choose routes just by number; there's no explanatory name for each route, as there is with Metrobus, to help riders know if they have the right route.

According to Carolyn Biggins, chief of the Division of Transit Services for Montgomery County DOT, Montgomery County will also be placing some digital signs showing real-time arrival information. When the new "Paul S. Sarbanes Multimodal Center" opens in Silver Spring in the spring, it will have signs, and Montgomery hopes to add more "in the next few years."

One of the most valuable aspects of real-time data is the way most systems provide an API, a computer interface that lets other applications like smartphone apps or Web tools from outside the agency access the real-time bus predictions.

People have already developed many useful tools, and the Mobility Lab in Arlington is working now on some more, including more low-cost digital screens which can combine data from multiple bus providers. Doing this requires having APIs for each bus system.

Metrobus, Circulator, Arlington's ART, and Fairfax CUE buses already offer real-time arrival data, accessible to developers through APIs. This allows Web and mobile apps to aggregate data from all the systems and display it all in one place.

Biggins says, "Ride On also plans to offer the data in an open format for people to use in other applications as well." However, Kurt Raschke explains that the system Montgomery County chose, AVL SmartTraveller Plus, does not support an API for accessing the data at this time.

Raschke writes,

It seems that Montgomery County judged the options mainly on their ability to provide a Web frontend and an SMS interface to real-time passenger information. Regrettably, that's a somewhat backwards way of looking at things.

As far as I am aware, unlike NextBus, SmartTraveller Plus has no API for developers. From what I can tell, if Montgomery County wants an API for real-time data, they're going to have to build directly on top of the OrbCAD database, because it's not going to come from SmartTraveller Plus.

Instead of picking a vendor for their frontend, Raschke says Montgomery should have focused on setting up technology to expose the bus location data, then used a freely available Web and mobile interface like One Bus Away or hired one of the consulting companies that can customize it.

Meanwhile, Ride On riders can start getting their bus predictions, but will have to use separate webpages and apps to transfer between RideOn, Metrobus, and other systems.

The wait for real-time arrival predictions in Montgomery County is finally over. But those hoping to integrate Ride On into multimodal online tools and help more people use Ride On still have to wait for future phases of this long-awaited project.

Support Us

How can our region be greater?

DC Maryland Virginia Arlington Alexandria Montgomery Prince George's Fairfax Charles Prince William Loudoun Howard Anne Arundel Frederick Tysons Corner Baltimore Falls Church Fairfax City
CC BY-NC