I think you may be presuming that every UI that consumes this data is able to display a map showing the bus’s location. We do make real-time bus lat/lng available through our API and lots of clients use that data. But there are other applications where a time prediction is still helpful. For example in many of our stations that serve bus routes, we don’t have the infrastructure (yet) to display a live map but we do have digital signs that tell when the next bus is expected to arrive.

A map isn't necessary to show a location. The digital sign could just display the name of the last intersection the bus was at. (I'm not convinced that's any better than a reasonably good prediction though.)

Each approach has its own tradeoffs.

- Time. Time has the advantage of brevity ("15 min" takes up a grand total of five characters) and indisputable meaning. It's also the hardest to predict, and people get pretty upset about incorrect predictions.

- Intersection. On a signboard, intersection names can get quite long. You would also need familiarity with where exactly the intersection is located, how the bus gets from there to your stop, etc. Boston is famously non-gridded, and has no real consistent rhyme or reason to its street layout, so that would be very confusing.

- Miles/stops away. New York's BusTime uses this. This is a pretty indisputable metric, and if you have GPS or a working odometer is trivial to confirm. But this runs into the same problem as intersections; you need context. The bus is two stops away, but how long does it take to make those two stops? A mile passing through Times Square is very different from a mile through the leafy, quiet suburbs of Queens.

You can pick between meaning and certainty, but it's very hard to have both.

King County Metro (Seattle) had a system like this back around 2003. Interestingly enough they did not have GPS on the buses, they'd simply instrumented the trip meter which was plenty good enough since buses were (usually) running along fixed routes. The real time location of the bus was displayed in a fairly crummy Java applet, but at least for the route I live on it worked great. I just waited for a bus to show up on the map about a mile from my apartment and that gave me plenty of time to walk to the nearest the bus stop.

I have found One Bus Away to be completely inferior, to the point that I usually don't bother to check it.

You can see bus locations on the individual bus route pages, for example: https://www.mbta.com/schedules/741/line

They commented that they just started rolling it out this week.

The problem is that they should have spent 0% of their time on prediction and 100% of their time on actual tracking.

Once you have tracking, prediction pretty much comes along for the ride.

Not really. Just tracking the location in an app isn't going to tell you anything about traffic conditions. Seeing that the bus is only a mile from your house might not be that useful if one day it's in gridlocked traffic and the next it's nothing but open road and green lights.

I use the MBTA buses sometimes to get from my house to the nearest train stop after which I make a transfer to another bus. A real time map of the bus locations would be 100x more valuable than just a prediction.

Same with the train - I use a website that shows the exact locations of all the MBTA trains, and I am able to accurately predict how long the train will sit outside of the Alewife station (which is infuriating BTW) based on the number of trains currently at the platform. A prediction would not be able to take into account this domain knowledge and would be completely worthless.

> A prediction would not be able to take into account this domain knowledge and would be completely worthless.

This x100.

I do this all the time with Lyft drivers. "No, please don't listen to Google Maps for this. The route it is trying to take you on goes from totally open to totally clogged over the span of 6:45AM to 7:00AM. Trust me, the route I am having you take me on will be faster by the time we get there."

People are way more clever than you think.

TFE (Transport For Edinburgh) uses vehicle on-board Wifi to update buses position instead of GPS and it works pretty well. They do offer a global map (https://tfeapp.com/live/) of all their vehicle as well as a mobile app (https://tfeapp.com/) and dynamic timetable at stop (but not all of them). [The API serving the data seems to have an issue today though]

I have worked in support for a well known GPS navigation software and the GPS accuracy is terrible for most consumer devices. You have to spend a lot of money in a GPS receiver to get past this accuracy issue. What Lothian buses (the company I have mentioned above) have done is using something lower tech to replace the need for such an expansive device. And overall it does work surprisingly well even in heavy traffic occurrence (road work, rush hours, etc ...).

This is more a business issue than a tech issue. There are two dominant RTI systems providers in England (where my bus knowledge comes from), and only a few more in the world. If they start providing an open data feed of real time locations, then they are giving a leg up to competitors who would potentially be able to leapfrog their predictions, as well as undercut them on price. This would threaten their ticket machine business (the ticket machines incorporate the GPS tracker - something like 98% of buses in England have GPS). Having spoken to all of the RTI suppliers during my work for DfT in the UK government, I am convinced that they will not release these data unless legislation forces them to.

And that is basically what is happening early next year.