OneBusAway is an integrated, open-source suite of software components that provides real-time and schedule information for public transit, supported by a nonprofit organization that is responsive to the needs of transit agencies and the riders. It is also an important alternative to the surveillance capitalism business model for providing such information. In this post, I will argue that King County Metro, Sound Transit, and other regional agencies should embrace it more fully, in particular by giving an official status to the OneBusAway apps rather than regarding them as just one of many “third-party” apps.
Regarding surveillance capitalism: a large portion of the software side of the global information technology infrastructure, including web search, email, social media, and much more, is often provided free to the end users, although the corporations that provide this, for example Google and Facebook, are often enormously profitable. The business model for this involves customized advertising and sometimes behavior manipulation, powered by intensive gathering and cross-correlation of detailed personal information. These companies provide some great products and services that are free to the end users. But surveillance capitalism has a dark side as well, with negative impacts for privacy, autonomy, human dignity, and democracy. The term comes from Shoshana Zuboff – please see her recent book The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power, or a recent interview.
Accurate and convenient schedule and real-time transit information, particularly when available to riders on apps on mobile devices, is an important part of making transit satisfying and easy to use. Much of this information is provided via a surveillance capitalism business model, for example via Google maps. Another source of information is via apps provided by venture-capital funded startups, for example Transit App or Moovit – it seems safe to assume that these, too, have an eventual goal of participating in the surveillance capitalism business model. (Venture capitalists seem unlikely to invest tens of millions of dollars in for-profit corporations just because they want the world to have better transit information.) OneBusAway provides an important nonprofit alternative.
Taking on surveillance capitalism in its full, global reach is a daunting, although important, undertaking (see for example this paper). However, the situation is simpler for transit information: agencies can provide a “public option” for accessing their information. Riders who want to use information provided via surveillance capitalism remain free to do so; but there is an alternative for those who don’t. And unlike health care, this public option can be provided at a relatively low cost and with minimal political drama. There are also strong benefits to the transit agencies, by giving them control over at least one end-to-end way for making their schedule and real-time information available that can be responsive to local needs, including issues of equity and social justice.
OneBusAway originated at the University of Washington – itself a public agency – as the PhD dissertation projects of Brian Ferris and Kari Watkins in Computer Science & Engineering and Civil & Environmental Engineering. It continues to be widely used in Puget Sound, and has also expanded to serve Rogue Valley, Oregon; San Diego, California; Spokane, Washington; and Tampa Bay, Florida, with branded versions available in Buenos Aires, Argentina; New York City; Poznań, Środa Wielkopolska and Kórnik, Poland; Washington DC; and York, Canada. This year, the project took the major step of forming a 501(c)(3) nonprofit organization, the Open Transit Software Foundation, as a long-term home for OneBusAway as well as potentially other open source transit systems.
Within this region, Sound Transit administers the OneBusAway server that aggregates schedule and real-time information from King County Metro and 10 other regional agencies, and provides the data used by the OneBusAway apps, website, and many of the other apps as well. There is much more that should be done to improve real-time accuracy, to support carefully targeted alerts (including cancellations, stop closures, etc.), and other things – but administratively, the server side of the transit information ecosystem is being handled appropriately. It’s a different story on the app side. Sound Transit has no officially supported apps, and King County Metro has its own proprietary apps, which receive relatively little use despite their official status. Meanwhile, the OneBusAway iPhone and Android apps are basically supported by one volunteer each, despite being widely used. I suggest that Sound Transit, Metro, and other agencies adopt the OneBusAway apps as their official ones, and that Metro drop its current ones. A recent report from the King County Auditor’s Office in fact recommended that Metro drop its current apps – but then fell short by simply lumping OneBusAway with for-profit third-party apps. (I was interviewed by the auditors while they were preparing their report, and after it was released did have a cordial exchange of emails with them on this point.)
With official support and funding for app maintenance and development, there is much more that could be done, for example: develop tutorial and outreach materials; re-enable trip planning on Android using open source geocoding and add trip planning support on the iPhone; add app support for targeted alerts, including trip cancellation information; have an accessibility consultant on retainer to help ensure good accessibility for blind and low vision riders, with strong outreach to those communities; and much more. And because OneBusAway is open source, these benefits would flow to other agencies using the software, and those agencies in turn could help support the applications as well.
About the author: Alan Borning is Professor Emeritus in the Paul G. Allen School of Computer Science & Engineering at the University of Washington. I was the co-advisor for Brian Ferris and worked closely with Kari Watkins as well as they wrote their dissertations. I am currently a member of the Board of Directors of the Open Transit Software Foundation. However, all opinions in this op-ed are my own, and are not endorsed by OTSF or any other organization, and I am responsible for any errors or omissions.
24 Replies to “Surveillance Capitalism, Transit Information, and OneBusAway”
Thank you for your work. OneBusAway is excellent — not only for what it does, but as an example for other organizations.
I think the future of government related software is in open source. Too often I see government projects being built on a contract basis, with very high expenses, and poor results. The HealthCare.gov (ObamaCare) rollout was a great example. A handful of companies bid on the work, and they did a poor job. Those companies got paid a huge amount of money, and they didn’t cooperate well with each other. It is clear to me that a relatively small team, working with open source code, would have been able to build a better site. It would have cost the government a lot less money, and flaws with the software would have been easier to detect. Improvements would have been much easier to make — individuals states could have customized their websites a lot easier. What is true of HealthCare.gov is true of most federal, state and local software. You still need a team to manage the software, and in many cases, do the bulk of the coding and testing. But open source software — just as open source information like Wikipedia — has an excellent reputation for quality and cost effectiveness because of the contributions of people outside the organization.
I agree, open source is the way to go. And IIRC, the lead company on the health care debacle was a Canadian firm. They couldn’t find a “Buy American” option?
Many thanks for your kind words and support!
Open Source does not equal nonprofit, although I will admit in One Bus Away’s case it certainly seems to. My biggest issue with making OBA an official app is its alarming inaccuracy. Their aggregate methodology overvalues the arrival times of the past when compared to real time information. This leads to frequently late busses being given a later posted time than the schedule, stranding passengers that then arrive late on the days when the bus is on time. Making these inaccuracies official is just a bad idea in my book.
OBA needs to vastly improve the quality of its service before I can get behind it as a replacement for an official app.
I don’t think that is a feature of the app, at least on iPhone. It either shows me the current status of a bus or the scheduled time of arrival, you can even click through to see where the late bus is when it’s late.
OneBusAway is only as accurate as the data feeding into it. Other clients (e.g. Google Maps) use the same data feed and, consequently, have the same inaccuracies. From what I’ve been able to infer, the prediction algorithm for King County Metro-operated buses is very naive and basically works like this:
– Each bus transmits to a server the stop id that the bus most recently passed approximately every 1-2 minutes.
– The server has no way to know where the bus is between the stops and assumes that a bus whose most recent stop is “foo” is actually at stop foo. For local routes that stop every other block, this ends up not mattering much. But, for freeway-running expresses, it matters a great deal. For example, the eastbound 255 is believed by the server to be sitting at Olive/Boren for the entire period that the bus is actually on I-5 and the 520 bridge, with the location only updating once the bus actually reaches Evergreen Point.
– To predict the travel time between what the server thinks is the bus’s current location and the user’s location, the algorithm naively uses the published schedule, irrespective of traffic or how long other buses took to traverse the same stretch of road a few minutes ago. Again, using the eastbound 255 as an example. When the bus leaves Olive/8th, OneBusAway predicts some 20 minutes to Evergreen Point, even when the freeway is wide open, and the bus should actually arrive in no more than about 10 minutes.
– Because the official PDF schedule only officially provides times at a few “time points”, the software uses distance-based linear interpolation to provide “scheduled times” at other stops. The software is unaware of road characteristics such as speed limits and traffic lights, causing it to consistently over-estimate travel times in some places and under-estimate them in others. Again, using eastbound 255 as an example, the last time point downtown is 6th/Union, so the prediction software assumes a uniform speed from 6th/Union to Evergreen Point, which we humans know is an impossibilty. The result is a bus that always appears late leaving downtown and early leaving Evergreen Point.
– If the bus has any kind of reroute, the stop-based software becomes confused and has no idea what’s going on until the bus finishes the detour and resumes regular route.
– When a bus is in layover, it doesn’t transmit its location when the bus is “off”. When the app doesn’t get any data, it shows a “scheduled arrival”. When OneBusAway shows a scheduled arrival in 2 minutes, this does not mean a bus is coming in anywhere near 2 minutes. Instead, it usually means that the bus driver hasn’t turned on the bus yet, and that the bus is actually all the way at the start of the route (which might be miles back of where the schedule says the bus is supposed to be). If your stop isn’t very close to the route start, this means a long delay.
Bottom line, even though a sophisticated user can get a reasonable prediction by mentally compensating for the system’s inaccuracies, it’s still a mess. And, it doesn’t have to be this way. For example, the 512, which is operated by Community Transit, doesn’t have any of the above problems. The software simply knows where the bus is.
This is also not a OneBusAway problem per-say. Google Maps, as do the real-time arrival signs at some of the transit stops, all use the same data feed, and all have the same inaccuracy problems.
Google Maps times do not match up with One Bus Away times. They may use the same data, but if they do that data is treated very differently.
Right, OneBusAway itself does not generate the real-time arrival predictions. In this region, Sound Transit is responsible for the OneBusAway server, which in turn aggregates data from multiple agencies (King County Metro, Community Transit, Pierce Transit, etc). There is an open source system for generating arrival/departure predictions given raw vehicle data (TransitClock), but as far as I know, all of the agencies in this region are using proprietary systems for this. Indeed, KCM’s system ought to do a better job at generating predictions; the one at Community Transit does better. Sorry, I don’t know why the predictions shown on Google Maps are sometimes different.
Would appreciate translation of this entire piece into English. Starting with definition of “Surveillance Capitalism”. Which sounds unconstitutional, and if it isn’t also illegal, should be.
Could we have a posting that details exactly how fast location of the political event I just attended via transit can right now be in the hands of my worst enemies in whose-ever uniform and payroll?
Definitely one of those pesky longevity things, because I personally carry memories of times when transit carried a massively greater percentage of the population than is now the case, with the phone system and dispatch equipment of the late 1940’s. Details hazy, but had a lot to do with experience and competence in transit operations.
Including ability to create a simple paper or plastic transit pass that is plainly and simply a receipt for a month’s worth of system-wide transportation, and no more or less information than the Fourth Amendment permits anyone but me to have. For “Surveillance”, word “No” says it all with two letters.
The Constitution has nothing to do with the way private corporations act. It solely concerns itself with the structure of the Federal Government and with the relationships between that Federal Government and the various States and with The People.
Congress could forbid private corporations from collecting data on their users or allow it but constrain its use in various ways, but surveillance which breached such legislation the would then be “illegal” but not “unconstitutional”. The Constitution is mute on the activities of “persons” except insofar as it protects citizens from tyranny from the Federal and several State governments.
Thanks, Tom. Whatever the Fourth Amendment implications of ORCA, they’re off my main point of the real world getting kicked to the curb by requirements of the virtual one. Would like assist of my travel planning to be the work of drivers and supervisors with actual transit vehicles in their sight and thoughts, rather than programmers. If One Bus Away – or anything else- works, use it.
Or, just maybe, we can follow the world’s best practices and just put arrival information on every stop.
Also, those seem ridiculously expensive to install (I remember reading something when they were putting those at Phinney & 46 — something on the order of more than a mil for 4 signs — which just smells of corruption)
Real time information signs are not wholly expensive to install where there is existing infrastructure. If the infrastructure isn’t there then it requires the installation of new utility boxes and hardware to run the signs. A good analogy is that the RTIS signs themselves are sort of like a computer monitor and the underlying utility boxes are the computer itself. If you already have the computer, the monitor is not very expensive; however, it gets really expensive if you need to buy the computer as well. I suspect in the case of the example you listed, they needed to install all of the relevant hardware to make the signs operational.
Couldn’t we just buy some waterproof tablets and mount them with batteries and a solar panel instead? Assuming that a waterproof tablet is $1,000 with a cellular modem, a battery with a 100 watt solar panel is $1,000, and installation costs are $1,000 each, that’s $3,000 per stop. KCM had 8,521 stops in 2012, so we’ll round that up to 10,000 stops. That would be a cost of $30 million. Consumer tablets appear to have a lifespan of about six years. Dividing the cost of the tablets by six years comes out to a cost of about $5 million per year. Add a cost of $120 per year per tablet for cellular Internet service and that comes out to about $6.2 million per year.
Do you seriously think it’s feasible to put real-time info signs at every stop Metro and ST serve? There’s easily several thousand, not all in areas where electrical or battery infrastructure are likely to happen. Versus supporting an app that the majority of riders can put on their phones?
We can’t even get them to put benches or shelters at every stop, let alone this.
I’m constantly conflicted about OneBusAway. I love it for the reasons described in this post, I recognize how much they’ve singlehandedly moved transit data accessibility forward in the years since they launched, and I am proud that it’s something that came out of my school. At the same time, as a user and a software guy I’m constantly frustrated by the choices they make on the UX side, and the way they don’t support the things they’ve built.
For example, they built a OneBusAway Alexa skill fairly early in the Alexa platform, and the concept was a perfect fit for the platform. But their implementation was far from optimal, in that it makes you sit and listen to a bunch of stuff you absolutely don’t care about before getting to the one piece of data you need. Still, I used it every day while packing up my things for work, until about a month ago when they decided they were going to turn on the Alexa personalization feature, which completely breaks the skill – it won’t even launch anymore.
Another example – they recently updated their web UX (which is what I started using – or rather, reverted back to using – after they broke their Alexa skill). Now it shows a fancy real-time map with all the buses flying around on it, and a ton of extra information. Which I recognize is super cool! And which I also recognize as being a total UX trap, in that they did not maintain feature parity with the way things used to exist. Because while the map is cool, what I actually needed was just a page I could bookmark for my stop with big, easy to read at a glance cards that tell me which buses are coming to my stop at what time. You know, the type of data that lets me know whether I need to walk or sprint to my bus stop. Unfortunately, they were unconcerned with backwards compatibility, and so they broke any past direct-linking without so much as a grace period with a deprecation notice. This is a cardinal sin of software design.
And the thing that really kills me is that they are just so absolutely unresponsive about any of this. I’ve tried repeatedly, across multiple channels, to reach out to them to offer to help make their Alexa skill better, for free, on my own time (I’m one of ~30 Alexa Champions worldwide). I’ve reported various issues with their different implementations. And at no point have they ever even acknowledged receipt of my offers or bug reports.
This seems like something professor Borning should address, since he is on the board. For open source projects to work well, there has to be a solid organization behind it, willing to accept input from various sources (otherwise, there is no point).
I agree. Last week my PC web bookmarks for OBA stops died. The new map showing where the buses is at is cool, but the small popup window showing arrival times at a stop gives less info than the old system (and my Android app). The new one says when the bus is predicted to arrive, but doesn’t say how many minutes early or late it is, which is info I have relied on to gauge the accuracy/reliability of the prediction.
We do welcome contributions to the open source systems, and try to take account of recommendations and pull requests. (I am one of the people who answers the email to our general info address, and to the iPhone-app address — I try to make sure they are all answered, except for a couple of rude profanity-laden messages that I just didn’t want to deal with.) @Eric, I apologize that we fell short in your case. If you want to send me an email personally I will route it to the Alexa developer (my last name at uw.edu).
For software developers, please see our GitHub page (https://github.com/onebusaway), in particular the issues pages for the different modules. Regarding the recent update to the web interface, apologies also for the lack of notice about the change. Indeed, you will need to update bookmarks – if there is some other functionality that is missing, we welcome actionable feedback on this. The onebusaway-developers list on googlegroups is the place for that discussion. For comments about the apps, send those to firstname.lastname@example.org or email@example.com
PSRC has a Transit Operators Committee. It unfortunately has little charge. This would seem to be the place to provide direction and oversight for multi-agency software coordination about transit real-time arrivals — if the operators and PSRC would take on the agencies’ culture to do it. That’s a tall order considering that the committee meets six times a year and mainly hears presentations without giving substantive feedback.
One Bus Away works ok, but I vastly prefer PDXbus. Among many other things, it allows me to have a single bookmark for multiple stops so that I can tell which of the 5 or so routes within walking distance of where I live, none of which share any stops, is the best option. The data feed tells me how long ago it has been since the bus was detected by the system, and sometimes how crowded it is. The numbers change to grey if the bus can’t be detected by the system so that I know when it has reverted to timetable times rather than real time estimates. There is a system in place that allows system alerts, such as reroutes or other issues to show up as well so that I know if a stop is being skipped or other issues are going on.
PDXbus, however, is a labor of love. It was created by a software engineer at Intel that got pissed off about how bad all the other products on the market are at doing what they do.
The idea of putting this into the hands of a 501c3 is an excellent idea and will probably assure that OneBusAway is around far longer than PDXbus.
Very timely article given the NYT series on surveillance capitalism that Prompted me to shut off location services on my phone yesterday.
This series makes the point that the problem of phone surveillance is larger than individuals can address without government intervention. However, in the meantime I am second guessing my use of Transit app and going back to OBA.
As someone who has worked closely with a number of projects associated with a similar framework, I would caution against it. If you want the cautionary tale of what could happen, look up the Kuali foundation, which is now effectively the property of the for-profit businesses it billed as implementation consultants.
Please get some engineering talent and build your own systems that meet your needs, and start your own open source initiative with it. Public Works and business software originating in universities are generally poorly equipped for use in actual business. Don’t pour taxpayer money into an academic exercise.
KC Metro tried that, and what it produced is horrible compared to OneBusAway.
You’re telling us to reinvent the wheel when there’s already a working cart and horse standing right in front of us.
Comments are closed.