On the other hand, the overthinking in question (which is probably true for bare-bones next stop indication) provides the base for my personal bus bug: know if/when a bus is reaching a stop from outside the bus in question, especially with geofencing, in order to know whether the bus I want to take is running early/late/not.

This is available for public buses in NYC. The city added GPS to their buses and then the ability to query distance from current stop via SMS.

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.)

They actually do this as well (and many have live updating signs), so the buses do have GPS linked to a server of some kind. It's normally absolutely fine, but on the couple of occasions for me where it broke it seems that the server doesn't conduct the bus in any way and kind of hopes the bus is on the right route.

That's all speculation though.

The TFL system will remove a bus if it doesn't get an update often enough that includes actual progress on the route. This is in fact the opposite problem of what you mention, in that they don't do a very good job of predicting based on past performance. E.g. I used to take a specific bus to pick my son up from nursery that always would "disappear" for a certain number of minutes at a certain part of the journey because a very short stretch of the route was always extremely congested at that time of day.

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.

> They actually do this as well (and many have live updating signs)

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)

There's a standard by Google for transit timings, and Translink, the public transport authority in my state, outputs these times. They're live.

Apps like 'Transit' also (accurately) show the current GPS location of the bus as it approaches, and it updated every minute (I believe)

In London you can go to the TFL website and see live updating times for when the bus will get to your stop: https://tfl.gov.uk/travel-information/stations-stops-and-pie...

Oslo, Norway has realtime data available for all stops as well :)

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.

OK, that's really cool. Definitely means they have "a server, 3G/4G connectivity [and] GPS" though.

Not necessarily. I think some of the systems use radio links to a central location and transponders at fixed points on the route to track the buses.

There is an API for London: https://api.tfl.gov.uk/

Halifax, NS, was doing that in the mid-'80s without the benefit of GPS or handy mobile apps. (Every bus stop/route had a phone extension, and major stops/terminals had talk boxes.) Granted, it wasn't a huge system, but it was hitting rocks with sticks and hollering over tin cans and string compared to what's available as a starting point today, and it worked. The idea that it should be a hard problem today, given GPS, vastly improved wireless communications and eleventy-seven different ways of figuring out where a user is (if entering a stop code seems like it might be too much work) is just plain silly. Or we've significantly redefined what "hard" means.

Or expectations have increased, both in terms of accuracy and in keeping costs low.

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].

https://en.wikipedia.org/wiki/IBus_(London)

When I said "worked", I meant worked, not approximated working or came lose enough not to have caused too many upsets. If expectations have grown to be higher than plus-ten-second accuracy (early wasn't tolerated), then we collectively need some sort of counselling/therapy.

You don't get that kind of accuracy in any system that has to deal with congested roads, or any dense major city. E.g. there's plenty of bus-stops near me where stops on the same route involves going around corners and traffic machines and stopping close enough that GPS would be insufficient to be guaranteed to tell the stops apart if you don't get a good enough fix on additional satellites quickly enough.

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.

>know if/when a bus is reaching a stop from outside the bus in question, especially with geofencing, in order to know whether the bus I want to take is running early/late/not.

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).

GPS is insufficient to give accurate enough estimates these days. It may or may not work depend on your local routes and stops, but it's too imprecise for a lot of locations and traffic conditions to give decent precision. It's good as a "first approximation" and if you don't have anything better. Most systems today end up integrating data from multiple different sensors to improve on gps.

This is the only thing I want. Displaying a bus timetable can be done just fine with laminated paper, and I'm not convinced that the ability to update (with cancellations, route changes, etc) justifies a tech solution.

Displaying the actual bus status, though, is huge progress.

Many providers have an API for this. I used one in my city to build a very simple display that shows you bus times (and I put it in a toy bus):

https://i.imgur.com/LjV7MtB.jpg

Sydney even uses the electronic ticketing system to provide an estimate on the capacity of the bus.

Thats clever. Most public bus systems I know in the US still see frequent cash payments onboard (the elderly, mostly). Is this not the case in Sydney, or is the system cashless?

Over the past few years they've rolled out a new electronic ticketing system which is used exclusively.

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.

Really?! Where can I see this? On an app? I admittedly only use Google Maps when I'm in Sydney.

TripView has it.

I work part time at the company that manages the new style signs for bus stations (EDIT: in London, to be clear), so we've gotten to see a bit of the size of the operation TFL has to deal with gathering and processing the bus information. He might have some details wrong, but he's certainly not gotten the complexity level wrong.

what about the bus stop broadcasting a signal with the id, name etc? the system is activated by the proximity..so you can have smthing like approaching station A, leaving station A.

it is scalable because the bus-stop transmitters are added , moved, removed as needed.

updating the data can also be done remotely

My local bus network use M2M Sim's running on the Vodafone network but its basically a virtual private mobile network running on top of Vodafone's network with no connection to the internet.

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).

There are systems that solve Bus shelter problem by piggybacking on FM station RDS

http://www.windytan.com/2013/11/decoding-radio-controlled-bu...

I was surprised my local network didn't do something similar as it seemed like a logical choice. But after some research I found nothing about them using RDS to do this.

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.

That's more expensive because the cost (installation and servicing) scales with the number of bus stops.

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.

The announcing the next stop could be achieved with a dual radio setup, one high powered and low powered. The high powered could be used to detect an upcoming stop and the low powered could be used to detect proximity to the 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.

German bus drivers have it as well. The routes are lists of stop names and their change is triggered by opening the doors. Can be adjusted by the driver if stops are passed, etc.

Many cities also have an app that displays how many minutes the bus is expected to run late, based on when it passed the previous stop.

Runs on some windows if I remember correctly and routes are probably hardcoded along with the data for the segment display outside above the windscreen.

They use GPS receivers on the bus, which calculates the position then transmits back using GPRS for central reporting https://en.wikipedia.org/wiki/IBus_(London)

Same in Munich. I think those work offline, also the driver can pick the next stop.

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.

you need it. what if you want to connect to something and make some special announces.

What special announces? Either the bus driver does it or it's one that's used frequently (like 'Please move down inside the bus'), in which case there is a button for it.