by BRIAN FERRIS and CAITLIN BONNAR
When I have friends visiting for the holidays, I like to take them on a “Best of Seattle” transit tour. We could ride the route 98 to Lake Union Park or maybe catch Link to “St Light Rail & S Edmunds St” station for lunch. Even though it’s the holidays, I’m sure I can trust all these scheduled arrivals I see in my favorite transit app.
What’s that? You’ve never heard of the 98? Did Sound Transit secretly add a new in-fill station when you weren’t paying attention? Or maybe you spent the holidays like me, waiting for buses that were actually running late or not at all.
If you are using any one of the apps most Seattle riders use to navigate our transit system on a daily basis, I’ll forgive your confusion. Apps like OneBusAway, Transit App, Google Maps, and others are all powered by transit data from local agencies and increasingly, that data is just plain wrong.
Route 98? Better known as the SLU Streetcar. “St Light Rail & S Edmunds St” Station? Try Columbia City Station instead. Yet these are the names King County Metro publishes in the official schedule data they release to developers. Issues with holiday schedules and real-time data have been a problem for years and this season was no exception [Ed. note; Sound Transit says it has now resolved the holiday schedule issue.]. Even worse, there have been persistent issues with Metro real-time data, especially near the start of routes, since the upgrade to GPS years ago.
A transit agency might be tempted to dismiss these issues as minor, especially compared to the challenges of keeping buses running under perennial budget pressures. However, at a time when service is in flux and traffic snarls even the most frequent routes, timely and accurate rider information is critical. Given a choice between accurate real-time info and a slight reduction in headway on their favorite routes, I think many riders would actually pick real-time.
Does Metro lack the resources to fix these issues? They did find the time to put out a new trip planning app last week… which has the all same data problems (try taking the 599 to the airport). Why is Metro investing in its own app when there are plenty of existing transit apps already used by riders, apps that would work even better if Metro cleaned up their data?
Or perhaps Metro could just share more data in the first place. Ever notice that TriMet’s app page has 10x the number of entries as Metro’s equivalent? Unlike Metro, our neighbors to the south in Portland have opened up their real-time transit data to developers and a diverse app ecosystem has blossomed as result. Metro has a GTFS-realtime feed that they could open tomorrow (Brian should know, he wrote it). What’s holding them back?
At a fundraiser last year, Dow Constantine issued a challenge. “To all you hackers toiling away in your dorm room writing the next version of OneBusAway: we’re coming for you.” To Dow, I challenge back: open your data and make its quality a priority. Your own app will benefit, new and better apps will come right back at you, and the real winners will be Seattle-area riders.
Action Items for Transit Agencies
All Agencies:
- Communicate honestly and regularly with riders and developers about the state of your transit data, both schedule and real-time.
King County Metro:
- Make your GTFS-realtime feed available to developers.
- Fix issues with Link and Seattle Streetcar in your GTFS feed.
- Fix issues with real-time, especially at route endpoints, in your AVL system.
- Publish your service alerts in an open format like GTFS-realtime.
Sound Transit:
- If Metro won’t publish quality schedule data with correct station names for Link, take ownership and publish it yourself.
City of Seattle:
- If Metro won’t publish quality schedule data for Seattle Streetcar, take ownership and publish it yourself.
Community Transit
- Publicly publish your GTFS feed for developers.
Brian Ferris is the original creator of OneBusAway and currently employed at Google working on Maps. Caitlin Bonnar is the current maintainer of the OneBusAway iPhone app.
The names of things is critically important. I wrote (just for myself, at the moment) a “dashboard” app, similar to the kiosk mode in OneBusAway that Metro uses along 3rd. I have to do a lot of back-end work to get the names to match with what is on the front of the bus. A comment pointed this out in the other OBA thread: the 3 will almost always say “Downtown Seattle East Jefferson” even when it’s headed north to Queen Anne. Even worse, there is no way to know, from the OneBusAway API, which 3 or 4 continue to Queen Anne, which 3s turn into 4s (and vice versa), and, perversely, the API feed has now even eliminated the “,” that used to signify “Via.” At least the API is now consistently returning version 2 results, which is handy for the “show me where the bus is currently located” feature I wrote.
I like the Metro trip planner app, really. But I really, really wish that the resources spent on it could have been given to the OBA team to make the API data source better.
Oh, and Community Transit, why on Earth did you roll your own solution???? I have half a mind to start scraping the CT mobile web site and feed the results into a half-baked, standalone OBA install just so an enterprising soul can get to the data in the same way that we currently read Metro, Sound, and Pierce Transits.
OK, that’s kinda incorrect about knowing which route goes where on linked routes. The OBA API does expose a trip ID and you can make a separate query to the trip ID to know which trip comes next but you have to sometimes (apparently, to me) guess which trip is which in the results of the trip data.
Inserting “via” in trip headsigns is also on my gripe list, but I left it out for the sake of brevity.
This is a usability issue that my dad has complained about as well.
Don’t forget the 2, which has two directions — Downtown Seattle – 0 and Downtown Seattle – 1!
Is it technically immature of me to suggest that these corrections and alternate names could be crowdsourced by adding a feedback mechanism? (Maybe this was a deliberate non-feature, for a good reason) Opt-in for the transit agency, of course, but of little cost to them and of large benefit to the riders.
Name suggestions are accepted, normalized, and tallied; highly popular suggestions (overall) are shown to a judge / metro employee as proposals for changes to the primary name of a route or stop; secondary popular suggestions (per route / stop) are added as alternate names and are available when searching for stops but not displayed.
Just piling on to add a reminder of the “padding problem”, which remains acute on any routes birthed in the 2012 restructure (40, D) as well as on other busy routes padded under pressure in subsequent schedule revisions.
When Metro pads a schedule, what it essentially does is to point at the differential between a handful of major time points and the stops immediately prior, and then declare that it takes 5 minutes to travel those two blocks. Any unfamiliar user on their way to a major stop — Market & Ballard, 3rd & Pine — will see the bus listed as 4+ minutes away, and will saunter over without the slightest inkling that it is barely a block away, and likely to be gone by the rider gets there.
The problem occurs whether the bus is late, early, or precisely on-time: the app is reporting essentially accurate data, but the predictions are corrupted based on Metro’s ridiculous padding. Most drivers are equally unaware: a northbound 40 that crosses downtown at anything resembling a reasonable speed is likely to depart 3 minutes (or more) ahead of schedule. But since the OBA feed doesn’t correct until the moment it reaches Pine, its data is functionally incorrect for the enduser every time.
Metro needs to smacked upside the head about its “slowest common denominator”, for many reasons. Its effect on app data is yet another one.
I wonder if there is any kind of feedback loop to drivers showing them whether they’re running ahead or behind the predicted arrivals, like some kind of app that knows their location and route and updates at each stop if they’re early/on-time/late. This could be used by the driver to maintain schedule but also to update an arrival prediction database.
I think as long as we have drivers timing their trips by run cards we’re never going to improve our real time arrival feeds (padding, bad schedule data, etc).
I’ve seen a phenomenon with Onebus, I’m curious if this is caused by padding or something else. If I track when the northbound 372 will arrive at the UW Hub in the evening, OBA often tells me it’s going to be 25 minutes late. But if I click on the route, OBA shows me the bus is sitting on Campus Parkway, presumably just having finished the southbound 372 trip. At some point about ~5 minutes before the scheduled departure, the 372 switches from “25 minutes late” to “on time” (maybe when the bus makes the U turn starts its northbound route) and sure enough it’s on time. Why would OBA consistently get the ETA so wrong on a bus that’s running on time?
But certainly frustrating for the ETA to jump forward by 20 minutes, especially at night when the 372 runs hourly.
Larry,
What you describe is not the padding problem, but the layover/”pole” problem, which remains the most pervasively destructive bad-data result that Brian and Caitlin describe in the main article. (The route 8 graphic up top shows this problem as well.)
At least your 372 sends updated data while u-turning, thus allowing OBA to correct with any warning at all. Some major pole-problem routes, such as the 44, won’t self-correct until they reach their second time-points, half a mile into the route, and way too late for many riders.
In my experience, OBA has attempted to program perpetual pole-problem routes to revert to scheduled data rather than to (inaccurately) show extreme lateness. Sometimes the fix works, other times it doesn’t. But the real solution would be for Metro to provide a reliable data feed in the first place, which the agency has clearly failed to prioritize in a way that reflects a pervasive and ongoing disrespect to its passengers.
Brett,
I thoroughly agree with your last sentence. The problem with trying to correct via a digital feedback loop, as you suggest, is that drivers would be routinely given the same terrible information that we are, thanks to the same stupid padding. At 3rd and Union, the driver will be told she’s perfectly on time. At 3rd and Pine, mere seconds later, she’ll be told she’s massively early. So unless she’s constantly checking the display, she’s going to be leaving passengers behind on a regular basis.
And it’s not like buses can just squat for five minutes in the 3rd or Ballard Ave bus zones, as the padders seem not to have realized. It’s almost as if the padding points were custom-chosen to screw over the most possible people, by giving the worst information to riders at the busiest of stops!
p.s. I’ve noticed that some drivers on hyper-padded routes, especially at off-hours, will simply correct for the padding by starting the run really late. For obvious reasons, on dark/wet/windy/sketchy nights, this approach carries its own downsides for customers.
I suspect a lot of the problem is that public bureaucracies tend to move at a snail’s pace. The agencies probably decided to develop their own planner apps years ago, and even though it now looks like a silly waste of resources, they’ve already decided they were going to do it, so they do it.
The decision to fix the holiday schedule data (which just happened a couple weeks ago) was probably “decided” years ago.
If only Metro’s planning could be a little more …agile.
It isn’t a minor issue at all when snow storms happen, and riders may be stuck waiting for hours in 19 degree weather for a bus that might arrive who knows when, or may have been cancelled. Having an accurate idea of when / if the bus is coming when the system is way off schedule is a huge help on these types of days.
Sadly, that is also typically the type of day when the information systems are least likely to be accurate.
Much as Metro wants to get rid of printed schedules, I don’t see that as realistic anytime soon.
I am one of the many riders who don’t invest in a pricey phone. The vast majority of stops don’t have OBA signage. Indeed, most of the major stops (e.g. next to train stations) don’t have them. Nor do I think it makes sense for Metro to deploy 10,000 OBA signs.
The deployment of such signage along 3rd Ave was one of the most underappreciated accomplishments for Transit in 2014. That in itself made waiting downtown to catch a bus a lot more tolerable. Thanks Metro and SDOT for making it happen!
I look forward very much to seeing it happen at other major stops, such as ones next to train stations, or even putting the signs in the train stations. Many times I have been heading home, and the presence or absence of OBA signs (or to be specific, my memory of where they are), has altered my path. If it is late at night, I may spend an extra 10 minutes headed away from my final destination, just to reach an OBA sign, and know for sure whether I’ll be waiting an hour for my half-hourly bus, at which point I’ll catch whichever bus gets me within walking distance of my final destination.
Here in Portland someone (annoyed TriMet employee?) has gotten in the habit of writing the stop number on the pole in permanent marker. Or, stops with less ambitious vandals have them scratched into the paint with what looks like might be produced by a thumb tack.
Not that I condone vandalism mind you. With TriMet severely limiting the availability of printed timetables now, I have found such vandalism, where provided, useful.
There in Portland, you can get a plain old sms with the arrival times for the next transit at any station, using that stop number. Works with any cellphone.
Here we insist that people have a smartphone that can run an app.
Doesn’t the OneBusAway SMS system still work? I haven’t used it for a little over a year, but it worked fine (after some initial clunkiness with setup) when I did.
Keep in mind the system here is pretty old. The same basic concept was in use in the late 1980s for those getting information via touch-tone phone (“Sorry this information is not available when using a rotary dial phone.”). I believe this option is still available, using the same phone number that was in use then. They went with stop numbers after a failed experiment with early voice recognition technology.
I’ve been told before that it works here, but it’s never worked for me. There’s no information about it at the stations, and the information I got here on STB indicated a number to use that has never worked correctly.
The portland system just works. You text a stop number and in a few seconds you get full information back about what’s coming next and when.
and, you also get a 30 character advertisement at the end of the arrival information – which helps fund the sms system and keep it going.
SMS still works for Metro. I use it every day, though I have to memorize some of the numbers, and use a 10 key pad to type “ONEBUS” every time. http://199.191.49.179/p/Tools_SMS.action
Humph. What’s the onebus modifier do? It seems like the phone number you are texting to should be enough to tell it what you want.
Seems like it would be nice to replace that with something that would identify the location so you don’t get multiple stop results.
SMS OneBusAway works fine for me.
For SMS, you text the stop number to 41411. That number is shared by many different transit regions (there’s a table at http://www.nextbus.com/wirelessConfig/sms.jsp), so you have to type “onebus” to specify Seattle.
If onebus is used to specify Seattle, then what is the purpose of the region selection response that asks for a zip code?
I’ve always wondered why KCM doesn’t fix glaringly obvious issues like this. I know nothing about the backend systems, but it seems to me like it is a simple fix of renaming the stops in Hastus. Then it’ll never happen again.
As a software engineer with over thirty years in the industry, and no vested interest in any transit software, I completely agree with the authors of this post. It is absolutely ridiculous for Metro to produce its own app, when there are perfectly good apps out there and Metro has data production problems. In the software world, this is known as “reinventing the wheel” and is considered a stupid thing to do. To make this even more ridiculous, the apps (or at least the main one) is open source. If there is something that Metro feels is lacking from OneBusAway, then work with them to improve it. Volunteer to add some functionality — even functionality that serves only Metro. If the OneBusAway organization refuses to allow those changes, then (and only then) consider building a new app.
But at this point, based on the information in this post (and previous examples) this should not be the focus of Metro IT efforts. The biggest problem is bad data coming from Metro. Once they fix that they can work on improving the apps that exist.
Exactly. Decisions coming from Metro have suggested incompetence for years. I mean levels above any other agency in the region. Yet people decided we need to give them more money. Thankfully prop 1 allows the city of Seattle to tell Metro what they get so it’s better than if Metro had received funding directly from the county.
“Software Engineer”
Well that answers your question right there!!
I’m pretty sure it has a lot to do with the hills, water and unique streetgrids, not to mention were just now coming out from under a huge ass glacier.
Thank you two for writing this piece. As two of the key developers of OneBusAway you’ve made a hugely positive impact on the Puget Sound transit community. That being said you and other developers can only do so much before the regional transit agencies must step up to the plate – you can only do so much for them while they are wasting money on things like duplicate apps (according to the KCM website the iPhone and Android apps cost a total of $80,379 so far).
I’ve been reminding KCM & ST for awhile now about these things and I’m sure they are sick of seeing my name. I’m glad to see other people bringing the same issues to attention. KCMs response has typically been that ST is working on a regional transit data project and that they are working with them. I’m glad they supposedly have the holiday schedules loaded now but that feels like a small accomplishment in the overall scheme of data issues.
In addition to your todo list I’d like to see the following addressed:
* All agencies: release alert data (reroutes, stop closures, etc) in an open format like GTFS-realtime. Reroutes should include machine readable shape data for maps.
* All agencies: stop independent development and invest in producing quality data. Google, other companies, and the open source community will make better usage of your data. By encouraging users to use not regional specific apps transit when on travel will be easier for everyone.
* Everett Transit: release GTFS & GTFS-realtime data (data exists in ST schedule tool and ET has a new text message to get bus arrival time service)
* Community Transit: stop rumored app development and invest in open data and OBA. Release GTFS and GTFS-realtime data. In particular Swift for sure already has realtime data easily available as it is shown on digital displays.
* King County Metro: make sure beginning of routes show correct arrival data
* King County Metro: make sure RapidRide digital displays never show “see schedule”
* Sound Transit: add realtime data to Link
* Stabilize downtown transit arrival displays (they are constantly having browser crashes, rendering issues, and/or just appearing blank)
Top priority for all agencies should be to release *good data* in GTFS format.
Then volunteers will, *at no cost to the agency*, figure out how to produce all possible apps, schedules, and so on. Surely this should be worth something to the agency?
Thank you Nathanael, I was going to ask if there was an industry wide transit data sharing standard.
Since you pointed out that there is the Google Transit Feed Specification, …
It all makes perfect sense now!
Completely agree GTFS data is the highest priority. Worth noting GTFS now stands for General Transit Feed Specification.
Resistance is futile.
A problem with king county metro particularly on the a line but also other lines is vandalism. This unfortunately wrecks the data streams and adds to expenses. If people would only respect their equipment.
The Transit App cared enough to hardcode an override, so they that the E-Line from day 1 while Metro had “675” for weeks in OBA. And Metro’s new app still lists all RapidRides as 67x, in addition to the 98/SLUT and 599/Link problems Brian and Caitlin mentioned. When your three ‘premium’ services (lrt, brt, and streetcar) all lack even basics such as a correct name, agencies are basically saying they don’t care.
This. Not only does the new KCM app add nothing of value to the pool of apps already out there, it’s actually a lot worse than all of them.
Getting the Transit App working took weeks – OBA has a unique API, and it took the developer time to write a model to speak it. Even then, he had issues with the app bumping up against the API key’s request limit in OBA.
The SLU streetcar has always been rt 98. Just like the former waterfront streetcar was RT 99
Who besides anyone who works for KCM or reads STB calls the SLUT route 98? Absolutely no one.
I encounter the issue with incorrect data at the beginning of routes all the time. The schedule is right much more often than OBA on my inbound trips on the 28.
On the way home, the situation is reversed. The bus is much more likely to be off schedule due to unpredictable downtown traffic, but OBA is usually pretty good about predicting arrival times after the bus has been going for a while.
There’s one question underneath all this: why, in a city and county this wealthy and well-educated, does every element of passenger information and communication stink to High Heaven?
My own theory is that none of the “high tech” industries that make up our economy communicate very much in plain English, either within their own industries or to anyone else.
I certainly don’t mean the many employees from overseas. I really think that correct business English is presently confined to Pakistan and former British possessions in Africa and the West Indies.
I mean that I think a very large percentage of spoken and written communication consists of abbreviation and jargon. And worse, in whatever the term is for the weird language of e-mail and texting.
In the old business and industrial world, people had to talk with and write to each other in very plain English. Some say the reason English enjoys such world-wide popularity is that it is the world’s best language for getting work done.
I also suspect that the middle management of Seattle has an ingrained habit of seeing closely-held information as personal power. Reason why after five years of LINK operation, there is not a single sign visible from the foot of the escalator at the Nordstrom’s end of the southbound platform? “That’s just to remind you that we don’t have to tell you!”
What does everybody think? Am I close?
Mark Dublin
I work for a company that builds electrical equipment for railroad passenger cars. Somehow, this has put me on the junk email lists for a bunch of electronics suppliers. The amount of obscure abbreviations used in each message subject line is astounding. Most of them have at least three abbreviations I have never seen before.
However, by far the biggest problem is that there is a certain set of people making decisions about this type of thing that have never used transit before, yet work in transit agencies, their consultants, or other vital positions. Therefore, they don’t know how the information is actually used or what pieces of it are actually vital.
Oh how I wish I could tell some of the stories of my own experiences at this company with some of our customers that have employees that have no idea what is involved with railroad equipment and thus make really poor decisions about what passengers need and what is actually important, and what is physically impossible. (I’m sure I can get away with telling you that one project I was involved with came to an abrupt end when someone attempted to put bedside hot tubs in some sleeper compartments – imagine what happens to all the water during a more than friendly coupling and you get the picture.)
In this case, the problem may be exactly the opposite. Metro probably knows buses, but they have no idea how software works. They have an IT department, and based on this, they are dysfunctional. The first priority of the IT department (in this instance) should be to clean up the data, so that OneBusAway works properly. This may be as simple as changing a few entries. It may be something messier. Maybe they aren’t returning back the proper format. Maybe they misunderstood the OneBusAway specifications. Either way, that should be the first thing that is fixed.
Then, if they see something with OneBusAway that they don’t like, they should volunteer to fix it (or add to it). That is how software typically works (and it typically works really well that way). If, for some reason, OneBusAway simply can’t do what they want it to do, then, and only then should they consider building a new app. But they didn’t even fix their data problems. Nor have they opened up the data, so that others can fix it. That is crazy.
Maybe it’s obsession with the oil tank cars which are the answer to my question: “What kind of train could I hate worse than a coal one?”
But first thought that comes to my mind about the bedside sleeper hot tubs is to equip every passenger consist with a tank car divided into compartments that would make use of the car’s liquid-carrying capacity.
One idea would be to divide the tank into horizontal compartments using baffles. Put the bed and bathroom part of each compartment on a horizontal platform maybe mid-level of the car. Give each compartment a dramatic curved window from platform to near top of the car.
But leave an aperture between the living space and the side of the car so passengers can soak dreamily in the hot water constantly pumped through the rest of the tank car. Sloshing suggestively with the motion of the train- especially on rails trashed by fossil fuel trains.
But might be good idea to buy these cars new off the line. In my school days, Alberta mineral beds were known as “tar sands”. As befits something that has to be refined to be oil. So most fragrant bath salts (the lavender kind, not the ones that cause psychosis) still wouldn’t bring many repeat passengers.
Also wonder if original problem doesn’t result from a language problem. Maybe spec was supposed to be a hot water radiator- from a country where home heating is exactly 70 years behind the US. Ever see “The Christmas Story?”
And incidentally, you’d know: is it true that Talgo trains in Spain have real barista-operated espresso machines in the Bistro cars? Sorry, but coin-operated 7-11 models don’t count. Neither do Starbucks’ automatic ones, or their coffee either- see above note on Alberta.
Mark
Leave space between the
It was definitely a hot tub they tried to put in there, and everyone involved was definitely from the USA.
Was that the Marlboro Train, Glenn?
I doubt it, Mark. Generally speaking, the older the organization, the tougher it is to work with their data. Banks and insurance companies were the first private organizations to invest a lot of money in software and hardware, and it is really hard to work with that information. The code is typically written in software languages that are older than the typical developer, and aren’t taught in many schools. Remember the Y2K crisis? Do you think all that software was replaced? No. It was patched up,and the companies muddled along. I have no idea what things are like at Metro, but my guess is that a lot of their software is old and hard to work with. Or their IT organization is, well, dysfunctional (this is probably all too common with public IT departments). So even though the folks there might know their domain quite well (and be able to communicate about it clearly) it doesn’t make the task of producing the data easy.
But they produced most of the data. Again, the big problem here is not their lack of skill, or the fact that they made mistakes, the big problem here is lack of priority. Why did they create a new app (that wasn’t cheap to produce) without fixing their data problems? That suggest a problem higher up. Someone thought it would be cool to produce an app, rather than fix the bug. That is nuts.
They also have a lack of transparency. This hurts everyone. I think Metro really needs to address the issues raised in the post.
Even though the ancient trip planner needed updating why not just punt the problem to Google? Plenty of companies and individuals have shown a willingness to work on the user interface portions of transit data.
Get the data feeds right first then focus on things like displays at stops and stations. Leave the web and app view to someone else.
I’ve learned to use both the local Trip Planner and Google to plan trips. Sometimes Google produces better results, and sometimes the local trip planner finds a route that Google didn’t.
I find it difficult to believe that an actual app is that necessary though. I’ve used KCM’s trip planner (or maybe it was SoundTransit’s?) on my phone. It seems like all you would need to do is detect that it is a mobile device and produce a mobile friendly web interface.
PDXBus (one of the popular Portland apps) just provides a mobile friendly interface to TriMet’s trip planner for that type of thing. Unless you plan to have an app that has every single bus stop and route in the Puget Sound region, and run updates of the app regularly every time some agency changes something, you are better off just having a mobile interface to some web based trip planner or other.
Thanks, Ross. Though could lose tonight’s sleep finding out that the computer elements that kept me from ever touching one of the damned things until I was fifty and SolidWorks was invented still leads an undead existence.
Maybe this is what the zombie preoccupation is based on. Thought the Bredas were the only thing in the transit world that smelled so much like zombies. Do they still have those huge reels of tape?
But I really think that with trip information at least, main problem is use of an information tool as a garbage disposal- from intake to drain-pipe. As amply and accurately noted above- no software in the world can turn ininformed input into useful output.
Though number of people who think otherwise can only be explained by a desperate widespread wish for it to be true.
One thing IT can do swiftly and effectively: transmit a mistake at nanosecond speed to every nook and cranny of an organization before anybody with a brain-cell can call it back.
Reason I don’t worry about computers taking over the world- bad as millions of users really wish they would: artificial intelligence will never defeat the natural organic stupidity originating millions of years ago from a monkey who got kicked in the head by a mammoth.
Mark
You get what you pay for.
I think that’s exactly the problem, Jim. Rather than pay a decent living wage to the working human beings who used to (and used to be able to) handle the world’s communication, we’re paying a huge amount of money to people who take pride in how little they know about the real world.
The thought about the benefits of English for work is important. In the days when ordinary people were a major part of our functioning economy, even an illiterate worker knew the difference between what and who worked- or didn’t.
Now, from drain-cleaner to CEO, nobody can really tell. The people who do well are personified by Dilbert’s colleague Wally. They know how to use this indecipherable situation to avoid doing anything. Ever notice how few people like this ever get fired?
My own favorite- and most destructive- example is from elementary education. Children learning to read and write are not “working.” They’re “on task!” Even the Nazis had the decency to have the sign above the Auschwitz front gate read “Arbeit Macht Frei!” Not “Having Children Be On Task is a Measurable Guarantee of Charter School Profits!”
Also: If being “On Task” is the goal, their task can perfectly well be sitting hunched over a desk trying to solve an indecipherable story problem and getting ever more frightened of mathematics. And mos of all, the system is freed from any responsibility to either teach or perform work.
Mark Dublin
What is your point? Really, I don’t understand your argument. The article is interesting (as far as it goes) but hardly a surprise. Companies know about bugs and release the product anyway. Shocking! Next thing you know, they will say they haven’t tested the product thoroughly. Incredible! (snark).
Seriously though, software companies have done this for years. For as long as I remember, really. Microsoft was notorious for buggy software, but that didn’t stop them from making billions. Unless you make software that really can’t fail (like medical device software) you are going to accept some level of failure in your code. To do otherwise is extremely expensive, and means hiring a lot more testers and developers. The most important thing is stay reasonably consistent, or improve. If your software is solid for many years and then suddenly becomes buggy, you piss off a lot of your customers. But if you can at least achieve a quality level about the same as you always have (even if it isn’t up to NASA levels) than you will probably be fine.
Besides, what does that have to do with anything. The bugs in the data are well known. My guess is that these are data entry mistakes, not coding mistakes (but I have no way of knowing for sure). It should be very cheap to fix them. A lot cheaper than developing a brand new app. That is the point of this post. To quote just one sentence:
Why is Metro investing in its own app when there are plenty of existing transit apps already used by riders, apps that would work even better if Metro cleaned up their data?
Your comment does nothing to answer that question, nor suggest why it isn’t important.
Are the busses actually using GPS for location data? I had heard that they were instead using mileage information that was periodically uploaded. When I heard this, I was pretty shocked given how widespread GPS is at this point … so I hope that I’m mistaken.
Historically that was the case, but KCM started an upgrade to a GPS-based system about four or five years ago? It’s been complete for a while now, so all real-time you see is GPS-based at this point.
The systems I am familiar with, even when using GPS, still require some lookup to the timetable information to display the minutes distant. TriMet’s has been that way for a long time. Last year’s snow storm was the first time I remember seeing the default display change from minutes distant to miles distant, so that might be the solution they wind up going with here when they have trouble calculating the minutes.
I believe the major avl systems require routes to be numbers. I know where I work that is the case. It shouldn’t be hard at the app stage to convert “98” to “slut”, etc. end of line data has historically been poor because drivers tend to layover wherever they feel like rather than at the correct location.
If so, that’s unfortunate, given how not all bus routes are numbers. Back where I grew up, in Chapel Hill, NC, all bus routes are given letters. And while most of the regional all-day routes are numbered, a lot of the regional peak expresses are lettered.
Portland Streetcar shows both NS and CL line, but they do a behind the scenes name swap. Notice that the route = in the URL below shows as 193.
http://trimet.org/arrivals/tracker?d=0&route=193&locids=13604&showAll=True
“City of Seattle:
1. If Metro won’t publish quality schedule data for Seattle Streetcar, take ownership and publish it yourself.”
2. Transfer the real-time data for the Streetcar from the Nextbus system into the One Bus Away system, so riders can get all the real-time info in one place.
7 years after startup, OBA shows “scheduled arrival” for the streetcar despite real-time data being available.
I’d put a little bit of the blame on NextBus for having an API that makes getting bulk access to real-time data really difficult.
My conversations with many staff of several transit agencies is that user experience technology issues are not a priority with the management or board. There needs to be more attention to technology issues in general, and usability/user experience issues in specific. Usually, there may be one or two staff that have a personal interest in the issue, but the rest of the staff doesn’t care much or they don’t want to look at issues even though staff members raise them. At the end of the day, there is not attention given to these issues (which is strikingly different to most private firms that daily provide transportation services like airlines).
I think there are some management solutions that can be proposed:
1. Having board members and upper management force the issue. This is an area where board members and upper management could have impact if they wanted to.
2. Use existing citizen’s committees to force the issue. Most transit citizen’s committees aren’t really tasked with resolving these things, but if a committee chair wants to make user experience an priority, he/she have some discretion to do so. The committee would have to not only take up these issues, but would have to make a valiant effort to let the public know where to send their user experience concerns! I’ve also seen many agencies not use citizen’s committees very strategically, as they are viewed as a “necessary obstruction” to what some staff members want to do.
3. Require and highlight a “technology program” as a major part of the Transportation Improvements Program process. Many agencies don’t have a coordinated program of linking all the different data systems on their buses into a cogent, integrated system. Most agencies buy technology on an “as needed” or “grant award” basis without much attention to life cycle costs, technology trends, integration or user experience. Most agencies think technology is all about hardware too, when many issues are more related to software.
If Metro is going to continue to publish bad data, and not prioritize fix it, it’s worth asking whether OBA should blindly publish whatever data Metro gives it, or whether OBA should hack around known cases where the schedule feed has incorrect arrival times or stop names.
One the one hand, working around Metro’s buggy data may further reduce the priority on Metro’s side to fix it. On the other hand, the public needs accurate information now, not 10 years from now, when Metro finally decides to get its act together. While not ideal, I have seen firsthand that it is quite common in the software industry to be forced to work around other people’s bugs, even at the cost of making one’s own code less maintainable.
I agree with you to a point. When it was just me running OBA back in the day, I certainly applied all sorts of hacks to clean up the data I received from KCM, ST, and other local agencies. That said, these days OneBusAway is a generic application suite used in a handful of cities and any data cleanup needs to be done by the people actually running the data server. Today, that’s Sound Transit.
But more generally, most of the transit apps that are both (a) good and (b) sustainable have grown to cover multiple cities because there is value in scale. App developers can choose to apply local hacks in every city they support, but the amount of work quickly piles up. What’s more, we’re not talking about just one app anymore. OneBusAway is just one of many: Transit App, Moovit, Google Maps, Bing Maps, Nokia Here, whatever Apple is about to drop… asking them all to apply the same hacks when the agency can just FIX THEIR DATA seems unreasonable.
And of course, not everything can be fixed with a quick hack. At some point, only KCM has the data to produce a valid holiday schedule that also works with real-time. Only KCM (and their AVL vendor) can fix systemic issues with real-time vehicle tracking.
Can’t there just be a process hook built into the page layout process that goes to a cross-reference lookup table for line numbers and stop/station names? If no matching key for a particular type, direction and route is found just display what the feed provides. If found display the lookup value. These sorts of identification things seem pretty static and therefore amenable to efficient fixes with cross-references to me.
If Metro shows the north and west bound #3 as destined for “Downtown Seattle East Jefferson” and you really want it to say “Seattle Center North Queen Anne” put a cross-key of type “destination”, route “3”, direction “N” or “NW” or “”, and a lookup value of “Seattle Center North Queen Anne”.
In fact, this is a way to fix a lot of the niggling things that irritate the local ridership and maintenance staff when the local agency goes off the rails. (Yes, a bad pun.) Lots of people bemoan the lack of a “Via” in OBA displays. Well, put in a destination record for every route in both directions that has a near and a far destination and stick a “Via ” between the existing destinations ones that you otherwise like. So the previous example would have “North Queen Anne via Seattle Center East”. Or whatever; I know that’s a lot of text for a handheld device.
Data fixes in code are “regrettable” to say the very tiny least.
Oops. Used less than and greater than signs. Sorry; that’s why you see “”. It should have said “or however one says northbound in GTFS”.
I’m waiting for a transit app that simultaneously tells you 2 arrival times to use for transferring at a location… one for the arrival of the bus you are riding to see when you arrive at the transfer point stop near the line you want to transfer and the other for the arrival of the connecting bus you want to take at its nearby stop. For example, if I’m on the 8 bus, I can see when I’d arrive at Westlake for the #40 and also when the #40 would arrive at Denny Way. Oh, my 8 arrives at Denny Way at Westlake in 3 minutes and the 40 arrives at Westlake at Denny Way in 5 minutes, perfect! It would help a lot deciding where to transfer especially when there are options for other lines to take (and transfer points), perhaps if the 40 is awhile I could stay on the bus and transfer at the 26/28 transfer point.
Do you mean an app that determines this dynamically (I’m going to Fremont from Madison Valley –> 8 to {40, 26, 28, E, 5, 16}), or just an app where you can put in multiple stops?
In either case, it could be called Multiple Buses Away, and I would totally use this, since I already do — one hack is to use the webapp and just chain together a bunch of stop id and routes, e.g. http://pugetsound.onebusaway.org/where/iphone/stop.action?id=1_71350&route=40_100241&id=1_25243&route=1_100162&id=1_25243&route=1_100228 (h/t Tim)
A nicer front-end (tap some stops, save as a cluster) would be nice. These clusters would be useful for the planners to show popular connections, if this data weren’t already available by analyzing ORCA taps.
At the TRB annual conference and attended a session about this subject. KC metro was there and promised all these problems would be fixed between 2015-2017. Woo hoo
The benefit of the doubt you give to metro is downright sad. Metro created an app, sure to be supported by full time employees and budget, because it can and it only cares to survive by adding employees. Why? When they overspend (aka budget gap) they can come back to the low information masses and claim “well….if you don’t add more taxes…we will throw away a perfectly good app used by millions of wheelchair bound children!”.
Yeah…you have been had. METRO could have just provided the data for free. But instead….It took the money you gave it and made itself bigger.
With all the extremely talented and knowledgeable posters here, I’m sure Metro can hire some of them to straighten everything out.
Google Maps/Transit app comes pre-installed on nearly every Android phones and their website is used by very many people, some of whom are potential riders know very little (if any) about transit services in the region. Google’s trip planning works pretty well unless you need to find a Community Transit bus route or stop or plan a trip using the Swift BRT route for example.
The lack of Community Transit (and Everett Transit) data means Google Transit’s trip planner function is essentially broken for any regional transit trip with at least one leg on Community Transit (i.e., unlinked trip on a linked trip involving two or more service providers).
Why is the lack of open, public schedule data from Community Transit not a bigger issue for the regional transit community as a whole?
If you try to search for “Community Transit Swift” service, you get nothing useful in terms of routes and schedules::
https://www.google.com/maps/place/Community+Transit+Bus+Stop+%231176/@48.0074695,-122.1927834,10z/data=!4m5!1m2!2m1!1scommunity+transit+swift!3m1!1s0x5485518339763873:0x6b5ea4b9c74f06a9
For some odd reason only one Community Transit stop is on the map and has its own page but with no meaningful bus route or schedule information:
https://plus.google.com/105544063026023027659/about?hl=en&gl=us
Searching for “Community Transit” doesn’t help either:
https://www.google.com/maps/search/community+transit/@48.0074695,-122.1927834,10z/data=!3m1!4b1
Wake up, elected officials of the Community Transit Board! Direct your staff to stop treating publically-funded and owned schedule data (and in the future, real-time data) as proprietary and making it difficult for citizens to obtain their data.
Please allow legitimate developers to produce a much better solution than the crappy app promised by your staff to the public nearly a year ago:
http://communitytransit.blogspot.com/2014/01/whats-going-on-with-busfinder.html
At least schedule data could have been made public instead of forcing the OBA developers (and others) to jump through the hoops and make a Freedom of Information Act request to obtain it. The public has every right to expect your $14M investment of public funds in the APTS project to be worth the cost.
My simple wish: that when I log into the KC Metro web site on a Saturday or Sunday in search of a schedule — when is the next bus downtown? — the Saturday or Sunday schedule (whichever is in effect) is the default. ARGH. I have no use for the weekday schedule when it is not a weekday!
Great article! Yes, details matter! Unfortunately, because these agencies don’t have much accountability to the voters and riders, they operate somewhat like fiefdoms, their primary aim to protect that and isolated from the real world that the rest of us operate in. I give them credit for what they provide, but it’s hit-and-miss, as some don’t provide “real time” data; instead of staving off service hour cuts, one has sunk millions into their own rider app – that has still to be released and would be the only place to get real-time info for them (more inconvenience for the riders); and another app has “stops” that don’t exist anymore, suggesting that there’s no coordination between their bus stop manager and the app developers. And, unfortunately, this is just scratching the surface.
What we need are some minimum level of transparency and accountability standards for all agencies, as well as some level of oversight from somewhere that’s independent of all of them. I’m not holding my breath for any of this, though, as I continue to see pleas for giving them more money, no strings ever attached. Until some are attached, we’ll continue to see them falling short, as this article points out well.