Then they opened their APIs, and now I have a half dozen apps to choose from that will show the approximate time until the next bus from a particular line will reach any given stop.
(Not always 100% accurate, but useful enough to know when to wait indoors for 5 min if it's raining, or pick another line/choose to walk because of delays.)
That's all speculation though.
It's a tricky one, because they have big concerns about over-promising (e.g. the bus could be stuck behind an accident instead, in which case guessing that it's 5 minutes away because of past behaviour will really annoy people) so in some situations they err on the side of caution.
But they are unable to get rid of all of the corner cases. E.g. a bus that moves rapidly for a short stretch, then gets "stuck", will often appear, disappear, appear, disappear, with much less progress in time estimates than elapsed time should indicate.
The thing is, the team working on it has a huge amount of gathered info on how to give these predictions in a way that tries to minimise surprise and avoid making promises that cause problems for people. E.g. often it's better to take a bus off the list so people who are in a hurry will grab a taxi, rather than "promise" the bus will be there in just another few minutes. They still get it wrong too often, but I really don't envy them trying to get the right balance between promising too much and too little.
I don't know about London, I've seen some systems where the stops had "live-updating signs" but only provided the time of the next official passage. And while I wasn't clear, my bug is not just stop signage but phone access as well (that's most useful when e.g. it's raining cats and dogs and you want to avoid waiting in the rain at uncovered bus stops)
Apps like 'Transit' also (accurately) show the current GPS location of the bus as it approaches, and it updated every minute (I believe)
http://reisapi.ruter.no/Help/Api/GET-StopVisit-GetDepartures...
>Returns a List of StopVisits (departures) from a Stop. If no time parameter is supplied, departures in realtime will be returned.
Consider that e.g. in London the old route indicators on the buses used odometers. Which worked for telling you were along the route a bus was. Most of the time. But didn't tell you how long it takes until the bus reaches the next stop other than on average, as it would tell you nothing about traffic etc.
Today London buses don't use just GPS to replace it either, because that's nowhere near good enough. See the "Tracking" section here [1].
Even with all the extra data, and a lot number crunching, in London it's a challenge to get it to withing a few minutes during rush hour.
So, sure, if you're dealing with simple, small systems with little congestion, you can simplify.
We had that, through GPS + GPRS (or SMS?), back in 2001-2 in a small city I was living in Europe. Complete with full (flash based) website map of where each bus is.
I used it to get out of the tech park/institute I worked at and into the bus stop outside at the very last minute (since bus timetables where completely unreliable).
Displaying the actual bus status, though, is huge progress.
On some bus routes (and/or outside of peek times) you can pay a cash fare on the buss, but even that is still a single-use paper RFID card that should be tapped on and off. These sales are in the extreme minority though - the elderly require an electronic card to get their discount IIRC.
it is scalable because the bus-stop transmitters are added , moved, removed as needed.
updating the data can also be done remotely
These connections are in both the busses and the stops. The reason is so the stops can provide real time updates to people at the stops too. If a bus breaks down its no longer tracked on the real time updates so you are not effing and blinding because a the stop said there is a bus due in 5 mins and no bus comes. And if a bus is removed from service unexpected then the information on why can be feed to people waiting for the bus. People are less likely to be pissed that a bus didn't come when expected if they are given a valid reason.
Personally I was hoping they used some form of radio link I could of sniffed with a SDR so I could put a live updating sign in my house. I just scrape the data from their live feed they use to update the tracker on their mobile app/website instead.
Broadcasting out a signal from the stops could need a transmitter that may need to be licensed as the signal would be to be picked up quite a distance from the stop. Also not all the stops in my area are these "real time updating" stops as they are normally put into covered stops (EDIT: Bus Shelters... The correct term wouldn't come to mind while I was typing this.) and some of our stops are just poles in the ground with a sign on them. The busses tracking their own position wouldn't need these stops upgrading to give this information to people on board the bus as the covered stops can be quite a distance between each other and removes any issues if a stop get damaged and stops broadcasting data (say a car crashes into it).
The busses tracking themselves also have benefits that don't visibly benefit passengers. The services back office can monitor busses and spot problems on the network as they happen. Unexpected heavy traffic on a route may trigger the company to skip or stagger a bus (one of my local routes in advertised as being "every 5-10 mins". The real time traffic condition information could also be sold on to other companies (not sure on the value of this data esp for busses that run once an hour or even longer).
http://www.windytan.com/2013/11/decoding-radio-controlled-bu...
I would love to be able to talk to a tech at the travel network about this. My own research came to the suspicion that because where I am in the country they would of had to strike up deals with multiple transmission sites to get the coverage needed.
Also, there are things you want to do that this doesn't cover. For example, announcing the next stop when you pull away from the last stop.
(Lets ignore the security issues that have been shown with amplifying the low powered radio in cars for a second) It's a method used in keyless entry in cars. A higher powered radio is used for button press on the cars key so you can unlock the car/open the boot/sound the horn to locate the car at a distance but keyless unlock should only work at a much closer distance.
Not saying its the correct way to do it (my local bus network doesn't do this) but stop proximity can be worked into their idea.
I guess it is easier in the long run to have all routes mapped and instead of GPS you use something like doors open / doors close as a trigger to jump to the next entry.
For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.
And the entire data set for the route should be able to live offline onboard the bus. Changing bus/numbers routes should include the step for updating route data.
Notice how we're now adding more complexity now anyway though...
This feels like a dangerous hack that will come back to bite you in any number of unexpected scenarios that probably occur frequently during an average bus driver's day.
> For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.
That's not remotely accurate for the reason above.
> And the entire data set for the route should be able to live offline onboard the bus. Changing bus/numbers routes should include the step for updating route data.
It can. E.g. the old London system used odometers. But that was sufficient only for showing "next stop ..." and for reporting very rough estimates. Today it uses odometers, gps, rate gyros and turn rate sensors to be able to more accurately position the buses along a route, and they still regularly "give up" and take a bus off the schedule when traffic conditions means the uncertainty is too high.
3G is necessary for live ETA, if you want to get fancy. All these complications, in my view, are worth it if you want a system that works 24/7 and serves thousands of people daily. The HW and SW dev costs are acceptable, but it does need a decent team, depending on what the starting point is and the ability of the team members.
Yeah, and now we need to install and manage thousands of beacons in bus stops in pretty hospitable conditions.
Of course, GPS isnt perfect either. It tends to fail in CBD areas.
I can't imagine many reasons a route would have to change on short notice (accident blocking a road?), and in those situations the announcements not quite being right would not be the end of the world.
I've never had this problem.
That's a non-issue.
>- 3G/4G connectivity, need a mobile data contract with local ISP
This is a duh!
>- The announcement should be bi-lingual for Airport busses
It can always not be. How would that be worse than NOT having the announcement at all? Besides what would the other language be? French, German? That would still be useless to 90% of foreign visitors...
I guess the names of the stops are untranslatable anyway :)
I think it just counts the number of stops and has some input from the driver
Sometimes, a doorbell just needs to be a doorbell.
Sure you can do the simple announce but the even easier one is to just have the driver talk over a mic, he needs one anyway. There I one upp'd you on KISS. But there is a reason not to KISS.
Why? You can announce the next stop a few seconds after departing from the current stop, and then again at the opening of the doors.
Is it more economical to pay for constant cellular connectivity across 1,000 buses, support IT staff for when the system fails or needs upgrades, etc. or to have the guy you're already paying $15/hr press a button after each stop?
The on-board display can overlay a map and call the next stop based on proximity. Not a weekend project, I'll admit, but many existing moving parts available off the shelf.
Hams play with this stuff... a lot.
[0] https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_Sys...
Half of your points assume that current transportation companies don't have any digital data about bus stops and reroutes.
Anyway I haven't been in a bus that doesn't have such a system for at least for a few years (in western Europe and China).
The question is what is more work: Using the existing data that is stored in some obscure format for which you first have to write an importer/converter or just recreating the data. Add the fact that the existing data might need some cleanup/additions (e.g. times on timetable are only stored with minute precision and you want second precision for more accuracy).
You can do quite a lot with a small local company. It's global reach that's expensive, as soon as you start needing any kind of high-touch sales.
GPS and 3G/4G are trivial add-ons. There are stacks for mobile data.
RFID doesn't have the reliable range, so that won't work as a solution.
It's not really a hard problem for a competent small engineering team with a mix of embedded hardware and software skills. It's not quite a trivial problem, because there are some interesting edge cases, mostly when a bus is diverted. But there is absolutely zero rocket science required.
You could hack something unreliable together in a weekend, but it would take up to six months to get all the bugs out, do the production engineering for a bullet-proof solution, standardise the installation process (if retrofitted), and so on.
Double that if management is poor. :)
Those last parts often get forgotten in software. Hacking something together that kind of works if you don't look at it with a visible frown is hobby coding, not engineering. Engineering is the boring work that happens after that, to build something with a quantifiable many-9s uptime that meets or exceeds a standard spec with comprehensive test cases.
Source: I don't drive,and ride the bus a lot.
Some sort of near-field beacon on the stops might be more durable than relying on GPS, but it won't help with missed stops.
Breaks down quickly if you need bi- or tri-lingual announcements, which is the norm in many popular tourist destinations.
Aside: I'm impressed with the amount of bike-shedding for this one. Though I'm part of the problem, too :-)
More like 2 guys working for a month.
(I calculated the geometric mean of the numbers both of you have given, in case you're wondering ;) )
I'd say something like 3 people for 6 months to 1 year (not all 3 being needed 100% of the time).
That's just faster horses though.
Conductors aren't a solution to a problem in themselves, they're a means to solve a problem. So what's the actual problem? WHY do they want conductors back?
Think a bit further:
- Hardware needs to be resistant to harsh diesel engine vibrations
- 3G/4G connectivity
- Need a mobile data contract with local ISP
- Software needs to be able to handle network disconnections
- GPS needs to be able to pin-point at which stop the bus is currently stopped, even with bad GPS coverage in larger cities
- If the bus skips a stop because of a detour, the software should be able to detect it and announce the next stop
- The announcement should be bi-lingual for Airport busses
- The announcement should work for people with hearing aids
- Server needs to know all bus-stops
- Server needs to know different stop types, such as bus terminals, intersection stops, regular stops, hand-over stops, virtual stops
- Server needs to be able both work of a yearly bus schedule and real-time update
- Server needs to output in an understandable JSON/XML because the government subsidies demand an open-data format
- Server needs to publish data to an open-data server because of the subsidies
- Because the bus-company is sponsored by European Union money the control interface should be translated to German/French/English/Spanish
And now this weekend project takes a team of 10 engineers working for a year.