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.