More on Metrobus stop names

A few weeks ago, at the Mobility Lab Transit Hack Day, I mentioned the small matter of the Metrobus stops at Rosslyn all being named “N MOORE ST + ROSSLYN STATION BUS BA”. Since I have the Metrobus stop database (all 11430 stops) loaded into MongoDB, it’s easy to write a MapReduce query to find all of the stops where a single stop name is associated with more than one stop ID. It’s perfectly normal for a stop name to be associated with two stop IDs, since at most locations you’ll have one stop on each side of the street. However, there are a total of 86 stop names which are associated with three or more stop IDs. Most appear to be cases where there are two stops in one direction in a given block, but some could cause real confusion:

  • COLLEGE PARK UMD STATION + BUS BAY: stop IDs 3003451, 3003913, 3003944
  • N MOORE ST + ROSSLYN STATION BUS BA: stop IDs 6000818, 6000824, 6000827, 6000882
  • TYSONS WESTPARK TRAN STA + BUS BAY: stop IDs 5001919, 5001941, 5001981, 5002109
  • WEST FALLS CHURCH STATION + BUS BAY: stop IDs 5001951, 5001958, 5002067, 5002151

At some of these locations, the bus bays are some distance from each other (and at WFC, there are bays on both sides of the station, although all of the Metrobus bays happen to be on the south side), so not being able to distinguish one bus bay from another poses a real wayfinding problem.

For the most part, this is a symptom of the fact that until the (relatively recent) advent of the open data movement, the development of GTFS, etc., the data contained in a transit agency’s internal databases would never be seen by the general public. Many transit agencies (even large ones) still generate timetables using manual or semi-manual processes, so errors in the data don’t necessarily result in errors in the published timetables. Thus oddities can lurk in the data for years, until someone finally comes along and starts looking at the data more closely. Stop names are a perfect example of that—if anything, only the stop names for major timepoints would have any public visibility. In addition, you’ll notice that all of these names are truncated at 34 or 35 characters. It’s entirely possible that somewhere within WMATA’s enterprise systems, the names are stored in full, and they only get truncated at some later point in the pipeline.

As an aside, there are even more interesting things in the data; all public WMATA stop IDs are seven digits long. But there are 519 stops in the Metrobus data whose IDs are less than seven digits long, including stops like 4229, which has no name, and stop 17014, whose name is “NO”.

4 thoughts on “More on Metrobus stop names”

  1. I remember when I did a query of the bus stops, the full name would come out from the DCGIS database, but I think with the scheduling software Metro uses, the stop names probably get truncated, which can impact the stop name especially for the longer ones. It’s been shown in both NextBus and the GTFS data about the stop names not having the full name. Hopefully, Metro will correct the data in the future to allow for the full stop name. Also, regarding the bus bays at Metro stations, I really do feel that they should implore the parent_station option in the feed to join all of the stop ID’s into a single station than having data for every single stop. It would also help for Nextbus because you’d have a common stop number (similar to Boston) that can pull every route that services that stop.

  2. Well, the only thing that would change for NextBus is if they used the common stop ID for that station. Boston and TTC does it both with their GTFS and NextBus data. If Metro had the same scheduling software that Boston has (HASTUS vs Trapeze), it’d probably be easier to do GTFS exports and data. TTC does use different stop IDs for the same station to represent different routes, but it’s hard having to remember stop ID numbers for different bus bays especially if they aren’t in sequential order. Case in point, Silver Spring Station. I have to plug in at least 5 different stop ID numbers to try to get information for all the routes that service that area. It’s just as bad for the Pentagon. I mean I know which routes operate from there, but there is no way to figure out the exact stop ID number for the bus bay to where you’re bus is leaving from. I say do away with stop IDs per bus bay. Wayfinding and maps at the station should suffice for finding which routes operate from which bus bays.

  3. It looks like Metro somewhat caught their mistake with the stop names. I noticed some of the stops in the Nextbus data have changed to include the full name. I don’t know if the GTFS data reflects this. Also, I did notice there are a few stops that have the stop geo numbers instead of the names and no set stop ID numbers (i.e K St & 6th NW is supposed to be 1003737, but it’s not assigned to it). Another thing to notice is that on the 28A, a couple stops in Falls Church just say STOP 2 and STOP 3. If only they would let me reorganize their data since I am a GIS major.

Comments are closed.