by WAYNE WATANABE and MARK HALLENBECK*
There has been considerable concern expressed about the declining reliability of bus arrival information provided by OneBusAway (OBA) over the past seven months. As the managers on both ends of the data stream, we’d like to provide a little more insight into why those errors are happening and what is being done.
Last summer, OBA and the other tracking applications appeared to be working reasonably well. But, users probably weren’t aware of how much work it took behind the scenes to make that happen. Metro and University of Washington researchers led by Dr. Dan Dailey had 15 years of data debugging invested in the stream going out to developers like Brian Ferris, who created OBA. On the receiving end, Brian was making adjustments to the data and code to make OBA present the most accurate predicted-arrival information possible.
The data and its presentation in the tracking programs has never been 100 percent accurate, but the errors coming from Metro’s legacy system using Automatic Vehicle Location (AVL) were well understood, allowing for better correction and filtering by both Metro and the app developers.
Then, last October several things happened:
- Metro had a huge service change that created large, multiple data updates. After the service change took place, some corrections were needed. It was hard for app developers to keep up with all the updates.
- More Metro buses were converting to the new GPS-based On Board Systems (OBS), which required Metro and OBA to handle data streams from two different vehicle-location systems simultaneously.
- The OBS system was providing more data, but it had to work in tandem with the old systems and that created more places where inconsistencies and data errors could happen.
- The legacy system had been repeatedly fine tuned over the years. The OBS data stream has not yet had that same long-term rigorous analysis.
- Accurate bus tracking depends on both scheduled data that defines where and when the bus should be at a location, and “real-time” data that reports where that bus actually is right now. The only one that Metro controls is the scheduled data. With the new system, Metro had to manipulate the scheduled data to create a format that OBS could accept. That led to more opportunities for data errors, and the need for more corrections and updates. We had to perform some unexpected manipulations to our own data. Now, we’re going back over those manipulations to see if they are contributing to some of the problems we’ve been seeing over the past seven months.
- Over at OBA, there was a transition in support and operations as Brian left the UW, and a partnership between the transit agencies and the university was created to keep OBA running.
The problems are not only showing up on OBA; Metro’s Tracker app is also affected. We believe there are three key places where the errors are popping up: the new bus hardware; the data manipulation in the middle; and how the applications handle the output from the two bus-location data feeds.
Metro and OBA staff have been talking and meeting a lot over the past several months. We have identified and fixed a variety of errors in the process already, but we haven’t finished identifying all of the errors. As a result, we’ve prioritized the creation of an error-trapping process which allows us to trace the errors we (and others) observe. We then trace those errors backwards through all of the current data manipulation steps to find and fix the cause. It’s tedious, painstaking work, but necessary while we sort out the complex data path.
Metro is also starting a data remodeling project. The same data model has been used for 30 years for everything from the creation of paper timetables to the current automated systems. Over the years, new products like Trip Planner, different vendors, and changing systems have been additions to Metro’s “data house.” It’s time to rebuild that house.
Take a step back and look at all the factors. It’s not the same, but think about what happens when you try to digitize your dad’s (or grandpa’s) Led Zeppelin album to play on your iPhone. When you convert a classic vinyl LP into a digital format, it’s no good without noise correction. It can be a tricky balance that you can’t correct until you actually listen to all the songs. Leave in all the clicks and pops, and the static is louder than the music. If you eliminate too much, you weaken the integrity of the analog signal. And, if you are too brutal with the noise reduction, you can lose the signal entirely.
Right now, OBA is catching all the clicks and pops in Metro’s data streams and reporting them as information about buses on the road. With more data streaming in from Metro’s new OBS, there is “noise” we never expected – and now we are trying to track it, filter it, and improve the accuracy of tracking information for public use. We assure you that everyone involved is very serious about finding solutions to fix the problems.
Problems delivering real-time transit info are not just happening here in King County. There’s a lot of research and reporting about how difficult deployment of these new bus systems are, and what havoc they can create with tracking apps. If you want to read old articles about this, a good place to start is Washington, DC’s NextBus implementation. The agencies that seem to have fewer problems are those that spend a lot of money with one vendor on a single system. Metro is integrating as much and as fast as it can, but it’s working with multiple systems and vendors – and dwindling dollars for its entire budget.
While Metro has assigned resources to make fixing the tracker apps a top priority, not everything can be done at once. We have already started the work and are seeing some successes. For example, on April 11 Metro replaced its old General Transit Feed Specification (GTFS) feed and saw some problems resolve that same day. UW staff will be looking at ways that OBA might be modified to prevent the propagation of data errors.
It won’t be an overnight fix. We know there are multiple challenges, and as it always has been, the fixes will be ongoing. Each service change, every reroute, and all the traffic disruptions mean there is no rest for the programmers on either end of the data feed.
*Mr. Watanabe is the IT Service Delivery Manager for the King County Dept. of Transportation. Dr. Hallenbeck is Director of the Washington State Transportation Center.
Pulling back to a broader perspective of the problems was highlighted by trying to figure various travel times between points on the previous post. Both Metro and ST have their own trip planners, which give different results, depending on which one you use. Within each set of planning tools and schedules, you’ll get different times for the same trip??. I finally had to just take an average of what the real answer was!
If the legacy system is relying on schedules, plus updated way marker times, then it seems like the system accuracy is doomed from the beginning. Now start the painfully slow process of upgrading all the buses to GPS (which was available in the early 90’s – [Kitsap was the 1st on the block, thanks to Dick Hayes]), and infuse a brand new ‘state of the art’ light rail system that can’t seem to display where the trains will be in a few minutes.
Rider information should be accurate, consistent across all the modes, and simple to operate.
I fear all we have now is a jumble of different systems, with multiple layers of band aids and software patches to keep the thing from exploding. Throw in a snow event and the whole thing come crashing down, which is when you want it to shine.
Sounds like Windows
I think it’s unreasonable to expect OBA/Tracker/or any system to work well in a snow event when there are reroutes, unexpected traffic jams, accidents etc. Even if you could call the bus driver thats driving the bus you are waiting for and say “hey, when are you getting to my stop here at X” S/He would probably say “no clue, I’m stuck in traffic and have to take a different way up the hill” I think best bet on snow days is to either work from home, call in sick, or wear winter gear for a potential walk home.
I think the big reason people seem to be saying “just fix it” is that systems like NextBus have been working for years. They rely on GPS also AND they give you the position of the bus so you can make your own prediction if you’re familiar with the area.
Good Point. Most bus riders are repeat customers. I threw out the snow card to make the point that the least bit of disruption in the system should not throw things into chaos, as seems to happen all too frequently around here.
At least with NextBus, if your bus is supposed to be here in a couple of minutes on X-street, but you see it coming down ‘off route’, 10 minutes away, you can do something instead of standing there like a droid with a bad battery pack.
Mic said: “I threw out the snow card to make the point that the least bit of disruption in the system should not throw things into chaos”
I would hardly call a major snow “the least bit of disruption”. For our transit system, snow is a major anomaly that doesn’t even happen every year.
Can OBA work on simple prepay, no-contract cell phones that don’t connect to the internet or have data plans? The kinds of cell phones that many poor people use, who are with Boost or Cricket?
Yes, it supports both text messaging and a call option. See OBA’s website.
I read somewhere that 50,000 people a week use OBA. Have they ever done a study to see who uses it, and who doesn’t use it?
Sam: I’ve never used it, but OBA has SMS support, which can be found here: http://onebusaway.org/p/Tools_SMS.action
SMS support for OBA died a few months ago and has never come back.
SMS never died. On the page that explains its usage:
I use the OBA SMS interface exclusively when I’m out – I have no data plan. There’s also a touch-tone service if you don’t have text messages.
However, simple prepay no-contract plans from the providers you listed are now coming with unlimited data and text for $50/mo. Prepaid customers are generally limited by device cost, not network privileges. If they’re on a basic device they’ll be limited to the mobile-optimized web interface or the SMS interface.
Before I had a smart phone I used the touch-tone interface most. You can save present so for commonly used stops it look me less than 10 seconds to make the call and get the info I wanted.
That’s good to know. I use OBA, but sometimes I wonder if people with limited resources can access it, or are even aware of it.
Regarding the Touch Tone interface, the DTMF decoder in my head doesn’t work so well. It would be nice to have a voice response interface. :^)
I use OBA all the time, and I’ve never used it on anything but a cheap, prepay cell phone. It works just fine.
This has been a great post guys, but the one thing I wonder about it, why was this not posted on the OBA site? You have a great service that I use daily, and I’m really interested in seeing “behind the curtain.”
Right now, it seems like every couple of months, there’s a blog post that shows up somewhere to remind us that OBA hasn’t been abandoned. I think this isn’t a good communication strategy. How about more active dialog? You have twitter, you have a blog, why not use them more often? I would rather see small, one paragraph entries on your blog every few days to see that there is activity on OBA. I think more people, specifically the power users, would be much more understanding if there was just more communication with the users on a constant basis.
Also, is there a good and easy way to report bugs?
You can try submitting an issue to their GitHub page:
https://github.com/OneBusAway/onebusaway/wiki
If you are using an iPhone, you can report trip and/or stop problems using the UI. That’s very useful information because it’s structured enough for developers to put it into a context of AVL data.
Email to contact@onebusaway.org is read and, most often, replied to. When we report a problem to an agency, it’s almost always due to email to that address.
The sentiment about more frequent communication is welcome information. We try to be careful about what we say on the blog because it can be quoted elsewhere, so the overhead is a lot higher than for a tweet.
It’s good to hear that the state/region is taking OBA seriously, because in my opinion there are few things that will help to improve long-term ridership than a consistent, accurate bus tracker. I think that’s especially true due to our relatively small size compared to transit systems like those in Boston, DC, NY, and Chicago, where trains/buses can often run with such short headways that tracking arrival time is ultimately unnecessary. That’s not the case for the vast majority of Seattle, and probably never will be, so I hope we can get this system functioning properly as soon as possible.
I hear you about the various reasons for the problems, but at the same time, I feel that OBA has wanted to have it both ways, and is only just now acknowledging that it “stands on the shoulders of giants”.
For the customer, this is a relationship disaster. Putting out an app which actively causes problems with behavior in relation to transit.
Yes, from the inside you can claim all sorts of justification, but as the user interface, what people see is OBA.
I imagine what you have going for you is that probably the type of person who uses 95% around here is probably someone who works at Facebook or other high tech places and will cut you some slack.
Still, detailing what sounds like not a technical problem, but a change control and IS issue in this blog still does not excuse your responsibilities.
Asking for something for nothing? Where’s the big grant of cash to accelerate this work? OBA may have some responsibility for not disclosing more prominently how fragile its predictions are, but it was an academic experiment which is one step away from a volunteer project, so it doesn’t “owe” anything to you. Metro was hesitant to invest in BOA when its academic funding broke down because people would blame Metro for it not being perfect — as you are indirectly doing — but in the end it put OBA on life support anyway because it didn’t want this significant service to die. Meanwhile Metro has suffered loss of tax revenue, fuel costs, and uncertain stopgap funding, which has eliminated the fleet of standby buses that used to step in when a bus was late — no wonder buses are routinely 5-15 minutes late now. Ultimately, the solution is to fully fund Metro so that the buses will be reliable and frequent, and then you won’t need OBA.
I don’t ever want to carry around a whole whack of paper schedules, so a smartphone app is useful even if we ever got to the point where arrivals matched the schedule. Of course, we’d also need a completely accurate schedule feed. I’d also like a pony.
There should be a shoutout to Pierce Transit, who stepped up, along with Sound Transit and KCM, to fund OBA. They kicked in just as much, despite they’ve sustained gigantic service cuts and serve a smaller customer base.
You get what you pay for.
That exact admittance was made 804 days ago:
http://onebusaway.blogspot.com/2010/02/why-real-time-tracking-is-always-broken.html?showComment=1265783211580#c3233598870951130039
Sorry, but “We introduced a shitload of bugs and errors through shoddy updates and sloppy data migration and an insistence on continuing to depend on massively-flawed legacy systems” is among the lamest reponses I’ve ever heard come from a software house.
How hard is it to receive Metro’s schedule data? Did they change format? No? Then data size shouldn’t matter, if your import process is solid. Of course, if your import process is baling wire and 20 guys in India (or whatever) doing piecemeal data correction, then it’s no wonder it fell apart, and doesn’t inspire any confidence.
How hard is it to receive location data from GPS OBS? Bus number, lat, and lon sound pretty straightforward. Either the OBS systems suck at sending consistently formatted data, or OBA sucks at reading it. It sounds like, instead of relying on the GPS whenever available, they decided to combine the accurate OBS GPS *and* the inaccurate, legacy spot-transponder system. Why?
Even if you say that the problems are due to trying to combine accurate GPS data with legacy transponder data… that’s no excuse for saying a bus is and was somewhere it isn’t and wasn’t. Does Metro’s data feed have lag issues? If so, I don’t see why they were any better before the quarterly system change. They certainly don’t have more buses or buslines to track! Do the transponders claim a bus was there when it wasn’t? Then you shouldn’t be reading that data, ever. I mean, if you care about accuracy at all, you don’t pass on data that is inaccurate, at least not without huge “THIS DATA IS HIGHLY LIKELY TO BE INACCURATE” caveats.
“probably the type of person who uses 95% around here is probably someone who works at Facebook or other high tech places and will cut you some slack.” Ha, quite the opposite! Anyone who works in software would recognize that these are lame excuses and would never fly at Facebook or Amazon or even Avdanced Web Design.
Sorry, but after all that avoidance of responsibility, why should we ever trust OBA again? How will they prevent another f***-up after the next big service change? They are in reactive mode, not proactive mode. Heck, they’re not even in reactive mode, they’re in denial mode.
Armchair condemnation.
Facebook and Amazon don’t run a county bus service, and they have much more spare cash to make sure things run smoothly.
You see, that’s not coming from a software house. It’s coming from a college software project that was functionally abandoned when the UW student who was maintaining it for free graduated and moved out of the country.
That it has nevertheless maintained obscene marketshare for being still the best option available is amazing.
To be clear, OBA started as a student project, and Metro is giving them stopgap funding for now. A future super-duper system may or may not be based on OBA. Metro is transitioning to GPS, and it’s a several-month transition time with its thousands of buses. The inconsistencies between the systems is causing internal problems for Metro, which need not concern us here, but the effects are spilling over into OBA. Using only GPS data at this point would remove many (most?) buses from OBA completely, which is arguably worse than the status quo, especially if users assume that buses not in OBA don’t exist.
To reiterate my other point, Facebook or Amazon would approach this problem by spending millions of dollars to hire a dedicated team of programmers to work full-time on accelerating the transition, maintaining workarounds, and adding redundant systems as backups in case something fails. Metro barely has enough money to keep the buses running and make some sort of transition to GPS. If that bothers you, talk to your councilmembers and legislators about giving Metro proper funding. Cutting Metro further would just force it to stretch the band-aids further until things break down.
Sounds like a good countdown to have on the STB site. OBS Coaches: ? vs. Legacy Coaches: ?
From my perspective, the data has become far more accurate – presumably since April 11th. I’ve actually been using OBA again and finding it to be accurate – on the Eastside at least.
I think this is a bit too easy on Metro. If OBA truly were a priority, which I think it should be, they could have cut service, deferred other capital projects, or delayed the rollout of new service. Increasing spending by a factor of 10 — to $1m — would still be a rounding error in the Metro budget. I’d rather have a bus that comes every 20 minutes with OBA than one that came unreliably every 15.
The current situation was entirely forseeable. But instead, they decided to hope that Brian Ferris would never graduate. Rather than be proactive about making OBA robust, they took the bid from UW to keep the thing barely afloat.
If Metro doesn’t want to put all its chips on a “student project,” then by all means develop something better in house. But I’m not holding my breath, so they ought to go with what works.
And let’s not forget ST, which hasn’t managed even Metro’s level of real-time awareness with Link.
Wrong-o, Martin. There’s real time data and predictions. Nobody ever got to see it.
That’s not what ST told me, but sure. The idea that they know and aren’t sharing it with riders is even worse than the alternative.
Look closely at the path. Brian would never say much about it. The only thing I got is that it processed real data.
The big problem here seems to be metro. Trying to mesh and feed two systems together dosent seem to be working very well. Mabye they should have tried the conversion on a line-by-line basis. Of course, for what it is, and what is costs its still a pretty damn good deal. Could it use more funding and a dedicated team to improve it? Probally, but for what we have now it still seems to work really well. Mabye sell some ad’s on the site and mobile app to bring in extra revenue?
Yes, they did. It’s now using GTFS spec for schedule and the GTFS realtime spec for, you guessed it, the real time data.
Yes, all that is pretty easy. But what you’re completely glossing over is the prediction. Sure we might know the exact location of a bus at a given time, but how do we know when it’s going to arrive at ten other locations? How do you calculate this when the bus is off route?
Because OBA isn’t actually collecting the data? They’re just grabbing it from the transit agencies. And may I remind you that Pierce Transit, which has had a 100% GPS equipped fleet for a few years, is working just fine through OBA.
I’ve heard much lamer excuses..
But I’m with ‘K’, how hard would it be to stop trying to predict the next bus, and instead just give us the actual location. Most humans are pretty good at interpreting a bus icon not moving as “my bus is stuck in traffic.” Doing good predictive analysis is difficult, you can’t take just this instant’s bus velocity (it may be stopped to drop someone off, or at a light) to know it’s average velocity over the “next” quarter mile. Then you need the actual trip distance via say google maps, overlayed with the actual planned route. With the known time way points.
But again, a regular rider will know that a bus at location “A” will reach location “B” in about N minutes because that’s how long it took them yesterday. And if at location “A” there are three buses that they are running late.
Oh and as for these excuses flying at software companies… heard them all… “I’ve never seen that before.” “Works on my system.” “Can’t repeat it.” “That’s from the legacy system we have to support.” … followed by “oh!, I see the problem. It’ll be fixed in the next release.”
But what it sounds like more than anything is a lack of unit/whitebox and black box testing.
Thanks for the info. I assume that this means Metro is going to have some gaps in the ability to use tracker data to analyze speed and reliability of routes until these issues is resolved.
Although I not gad about these issues, I am glad that this is affecting Metro’s internal ability to track buses. It gives me more confidence that Metro will sped that resources it needs to fix the issues.
When will all buses have GPS? By that point, pubish schedules, routes, and GPS data in an open, consistant manner, and let the market take over. Given consistant and accurate data, there’s probably a dozen people on this blog that could write an app to interpret it – one of them likely will and charge $1 or pay for it through advertising.
I’ve heard that late August is the expected timeframe for the completion of the GPS conversion process.
Any coach that hasn’t been retrofitted with a new radio by the end of the year will be sidelined until it gets one installed.
Are they going to really put GPS in buses that they’re going to ditch in a year or so?
Joseph Singer … yes they have to … but the equipment can be taken out and reused for new buses later
Metro has already auctioned off some buses that at one time had the GPS equipment installed. It’s possible that some of these developed serious mechanical problems that put them at the top of the disposal list. The GPS and related equipment gets pulled prior to sale. So does the farebox and just about everything else.
But yes, they will continue to install equipment on all coaches. Next year they won’t be able to use their UHF frequencies, and since you can’t send an operator out in a bus without a radio, the coaches will either be sidelined or retrofitted.
like ST 9506…thought that rolling disaster was long gone till it showed up at BTC on 556 a week or two ago
As Tim says, they have and they have to. However, they are doing as little work as possible on those buses. I’ve driven a couple of Gilligs with OBS on board. In those coaches, they didn’t bother hooking up the signs so we still switch those manually. I’m not sure what other corners they are able to cut but at least there is an effort to cut costs on coaches that won’t be around much longer.
“Metro had a huge service change that created large, multiple data updates. After the service change took place, some corrections were needed. It was hard for app developers to keep up with all the updates.”
I shudder to think what will happen this fall.
I don’t blame the engineers at all that are working on this, they are doing the best they can with limited resources. And I certainly appreciate the update on the problem and what the underlying causes are. It’s just amazing to me how difficult this is considering dozens of other transit agencies of similar size and scope have long figured this out.
Agree! The troops working in the trenches on this are to complimented for daily heroics to keep it working well. It’s not their fault the system is so fractured and cumbersome to maintain.
I think part of the problem is that Metro used to be on the cutting edge years ago, but because of that Metro is now stuck with an outdated system that doesn’t conform to modern standards. It’s much easier to start from scratch compared to transitioning from a legacy system to something else.
How much of this angst over OBA having accuracy problems related to technophiles and smart phone addicts having a panic attack at the thought of a having to rely on a paper sign post schedule?
a paper sign post schedule
HAHAHAHAHAHA. As if those are ubiquitous, or Metro could actually reliably maintain their schedules.
Or stick to a schedule. My bus left a major transit center 3 minutes early this morning, leaving behind a bunch of regular riders.
You’ve crossed the line Zed. Nazi-bus-driver says “No more rides for you”
zed … by your clock or Metro’s?
My watch, phone, OBA, and the clocks of about ten other riders.
What is Metro’s clock, the dispatchers gold pocket watch? I’ve seen the 255 leave 3 min ahead of schedule as my son was walking up to the bus at South Kirkland P&R. No need to run when you’ve got three minutes. In the age of cell phones that automatically keep time within a minute of the nuclear clock there’s no excuse for leaving early from a timed checkpoint. Yet it happens.
The DDU is often inaccurate. Operators are told to not use it. Some do.
Having a time point at South Kirkland P&R with schedule padding (excepting the bus to sit there and wait for several minutes) is part of the problem in that that it makes trips unnecessarily slow for people getting on further back. In fact, by detouring into the parking lot and waiting for a specific timepoint before proceeding, we’re actually incentivizing people living further up the route to drive to the P&R, rather than catch the same bus as it goes by their house. This has an impact in the availability of parking there for those that don’t live along the 255 route.
GPS requires very precise and accurate clocks to function. If they can’t even get the correct time on the DDU/OBS, forget about accurate bus predictions, let alone locations.
GPS is a very accurate clock. The satellites all keep time and broadcast it. The receiver computes the location based on the time shift over distance from each satellite. Determining your position with a sextant requires a very accurate clock.
What I said is still true. GPS wouldn’t be possible if they couldn’t put atomic clocks on board satellites. That Metro’s DDU/OBS has incorrect and unreliable time keeping baffles me.
More than half of of all US households have a smartphone, and my guess is that number is significantly higher in Seattle. Smartphones aren’t just for technophiles anymore- they’ve become an ordinary part of daily life for the majority of people. It would be wasteful for Metro and Sound Transit to not make bus and train arrival information easily and reliably available for smartphones.
Sound Transit does make them easily and reliably available for smartphones. Have you seen their mobile website?
Metro is supposed to be working on a new website; they have been for almost 2 years. And they’d better, too, as the schedule pages are completely unviewable on BlackBerry OS 5 or below, which is the OS of smartphones carried by many of Metro’s top management.
It’s not “technofiles” getting in a snit it’s your everyday person who gets a report that your bus will be here in X minutes and when X minutes roll around checking the schedule again it says it left already two minutes ago!
The problems I’m seeing with OBA are all on the 355, which has GPS now. (The talking buses with the signs inside that tell you the next stop are the GPS buses, right? That’s the kind of bus I’m talking about.) On the evening commute, OBA will say the 355 is arriving in a couple minutes, then it’ll change and say a couple minutes more, then a couple minutes more, and before you know it I’ve been waiting 15 or 20 minutes for a bus, when if I’d know I had a 20 minute wait, I would have gone to a different stop and caught the 358 instead. And, that’s at the start of the route (is the 355 through-routed? I didn’t think so but I could be wrong) so it makes no sense that a bus could become 20 minutes late in the time it takes it to get from Belltown to the financial district, especially when the other buses running on 3rd are on time–I mean, what traffic could the 355 be stuck in on 3rd that every other bus on 3rd is magically avoiding? So to me, that means something is wrong, and it’s wrong on a route using GPS buses.
As an end user, I don’t care why it’s wrong or who is responsible for fixing it, I just want it fixed. Or, just set it to display scheduled arrivals instead of estimated arrival times for routes where there is a problem.
Right. But there’s no guarantee that just because the bus is talking the GPS data is actually getting to Metro’s servers.
Depends on the trip. Look at the details for a specific trip. Notice that there’s an incoming route. It means that before that trip, the bus ran another trip. This is meant to help riders decipher the schedule of a through-routed run, but because the same bus operates both schedules, they end up showing up back to back. Because the termini of the routes are so far apart, the driver has to deadhead from one terminus to the other. I know I don’t have to explain how there can be delays getting from an outlying part of Seattle (or outside of Seattle) to Downtown in the afternoon.
In the category of vulture lawyers making an easy living off of suing governments:
A patent troll company is suing transit agencies for stealing their idea of alerting riders when their bus is about to arrive.
I hope whoever invented the idea of patent trolling sues ArrivalStar for all they are worth, for stealing their idea of patenting obvious ideas without making any effort to develop the technology to implement them.
Your complaint is with Congress. Patent troll companies didn’t draft the statute. No one has to develop a single bit of technology to get or enforce a patent.
Can OBA take a voluntary payment for it’s smartphone app? Obviously people could just donate to them directly but they might get more response from users and more ongoing support if it was an option to contribute on the phone, say $1 when you download, or $.25 when there’s an update. Can apps accept voluntary payments like that? I won’t venture to guess how much they could raise, but it wouldn’t be nothing because I would gladly put in my dollar.
In the case of IOS apps, if you charge for it using the iTunes appstore, then Apple requires a 30% cut. If OBA is organized appropriately to accept donations or revenue, then they could set up a web page for that purpose and not “sell” the apps through the appstores.
Being a product of the UW, there are extra legal hurdles in taking money.
I wonder if there’s some kind of foundation already in existence, with 501(c)(3) status and all, that could take donations for OBA and then donate it to the UW, which would circumvent that problem.
I wish we had the system like they have in Portland. At your bus stop, there’s a number to call, you enter the code for your bus stop and you find out when the next bus is coming. It’s a simple system that worked great the few times I used it.
We have that system http://www.onebusaway.org/p/Tools_Phone.action
What percentage of stops have it though? It’s not at my usual stop on Westlake Ave N, near Lake Union.
I love One Bus Away. Together with Google Maps, it’s worth owning a smartphone for on it’s own. I would be happy to pay for it. Make a paid donation version, or some obvious way for us to give you money.
Noise reduction sucks. Leave in the crackles and pops, and you’ll get a better sound. Better yet, invest in a good record cleaner and eliminate those other noises. But by no means should you use noise reduction, a horrible idea when it was first introduced in the 80s, a horrible idea now.
Just listen to the name – noise reduction. I.e. loss of dynamic range.
I rest my case.