As a programmer who develops software for public transit, there is a lot of opportunity for technology to make a difference. But, it's not the kind of market that VCs and entrepreneurs prefer.
Public transit agencies vary dramatically from city to city, but they are the ones who provide Google with data on their transit system's timetables. In fact, Google is the last in a chain of software and manual labor that creates and manages transit schedules. It's very hard to create software that captures all the nuances and variations in transit to create a one-size-fits-all solution.
The other tough part is funding - public transit improvements are often driven by grant money because the operating budget all goes to day-to-day expenses. And oftentimes the wealthier people who could make a difference in transit (e.g. SV techies) own cars or otherwise avoid public transit because it's so inconvenient, so they often don't notice the problems.
Yeah. To give an example of these agencies being stuck in the stone age, in Melbourne, the transport timetables still haven't been offered to Google. You can't choose the public transportation option on Google Maps at all. It's an absolute embarrassment for a city just 800km from where Google Maps was created.
If you're a visitor accustomed to using Google Maps to navigate transit systems in a new city, the extensive tram and train network of Melbourne will be useless to you.
Hi, I'd like to hear more why data couldn't bridge that gap and why Google maps would work accross the world for cars but not for public transits.
- The game would be probably to provide some kind of standard or API that would make all those independant providers rally accross a common model. Would save communities cost & improve the service. Probably a big market.
- If you look outside of the US, public transit (in some form or the other) is for wealthy people as well. Think Japan & Europe.
> The game would be probably to provide some kind of standard or API that would make all those independant providers rally accross a common model.
This common specification already exists. It is called GTFS [1] (General Transit Feed Specification) and can be used to exchange static transit data. There is also GTFS-realtime [2], an extension to GTFS, to be used to exchange realtime transit data.
The specification was designed through a partnership of the initial Live Transit Updates partner agencies, a number of transit developers and Google. The specification was introduced and released under the Creative Commons Attribution 3.0 license in August 2011.
In addition to GTFS, in Europe we have Transmodle [0], with the UK implementation being TransXChange [1], for scheduled public transit timetables and SIRI for real-time [2].
The TransXChange schema guide is a 300+ page PDF [3], so there is a big barrier to entry.
I'd like to add as an example the city in Europe I live in. The reason my city doesn't have public transit coverage in Google Maps is that they seem to have an exclusive deal with a local public-transit-route-finding company. I get it that business is business, free markets, etc. but this is clearly a suboptimal solution for an end-user. The website they give their data to is not bad, but Google Maps are clearly, objectively, better for both locals and tourists.
As the author of a public transit iOS/Android app, these kinds of improvements to Google Maps both excite me (from a "that's cool" perspective) and worry me (from a business perspective) at the same time.
Real-time data is an area Google haven't pushed too hard into at this time (despite developing the GTFS-RealTime standard), so that has been an easy way for me to differentiate from Google Maps.
If anybody's interested in the kinds of real-time and static data Google (and other developers) use, I collect and archive many of the feeds here:
Due to how rapidly things change, the system also needs to display when multiple options are equivalent. For example, it might say, “Go to the train platform and take the B train northbound.” Then due to how things have change, you see a C train show up — do you get on it? Instead, it should say, “Take a B, C or E train going north towards X, Y or Z, but B should come first.”
Google Maps already does this to some extent. In the query for "Zurich Hbf to Zurich Airport" below, the first option is given as "IC/IR/S/S2/S16", and only when you click on "Next trip" are you given a specific train name, platform, departure time etc.
If anyone wants to point to a place where the latest tech boom has benefited the environment, the best place to look in my opinion is public transit. Catching a bus or train, which once held a significant learning curve is now a couple taps on a smartphone or a text message away.
I remember going back to San Francisco with a couple friends and they were just as able to navigate muni as I was, even though they had never lived there.
Been living in San Francisco for a few weeks now and it still takes me a minute to figure out which direction I need to take in the Metro. Why they chose such unintuitive names such as Inbound and Outbound baffles me.
The Metro system outgrew what it was circa 1980 and hasn't really caught up with itself. Everything used to end at Embarcadero and there were no loops or crossovers, so station platforms were simply labelled "Downtown" or "Outbound." Then the lines started going beyond Embarcadero starting in 1998 with the extension to Caltrain. Then we got the T Third Street extension in 2007. At that point the old convention stopped making sense, and I completely agree with the confusion.
I've recently started using Citymapper for iOS and have found it to be quite simply the most useful app on my phone. 'Next level' usefulness, stemming from great UI that shows you the time and cost (in money or calories!) of making the journey by foot, bus, underground/train or taxi. It turns out in London 'by foot' is a much more viable option than you think once the overheads of other methods are taken into account.
Weird thing is - it doesn't seem to use real time data, just uses average wait times, based on timetables. Turns out in London and Berlin where I use it, there are so many transport options that average wait times, (when known) never seem problematic.
That said, combine in real time data then clearly choosing routes becomes easier.
After that combining in data on how loaded each vehicle is makes things a whole lot more efficient. Ie 'walk 2 mins extra to this other stop as this next bus is rammed'.
>Weird thing is - it doesn't seem to use real time data, just uses average wait times, based on timetables. Turns out in London and Berlin where I use it, there are so many transport options that average wait times, (when known) never seem problematic.
I am quite sure Citymapper uses live data for buses (not sure about tubes as some lines, such as the Circle/District, don't always have correct data).
So it will often recommend you to take the bus if there happens to be one shortly arriving at a stop nearby as opposed to walking to the tube that might be 5-10min walk away.
Sadly some cities are loath to release their data. I more or less begged Santa Monica's Big Blue Bus to let me make an app showing nothing more than the real-time arrival data they already had on signs (but only in the very busiest and most touristed areas) and they blew me off repeatedly. They have been claiming they will add this for 6 years. Meanwhile this data is available for every other bus operator (LA Metro, Culver City bus, etc.) in the area.
The Google Maps public transport routing in London is often sub-optimal. It seems very hesitant to recommend taking the tube - an example recently involved it recommending that I took a 45 minute bus rather than a 10 minute tube journey.
I imagine that the problem is hard - in London you can easily have 10 different bus routes available. Start combining multiple buses in complicated routes and the number of possible routes grows exponentially. It may also be that the system places different value on the variables than me - journey cost, number of changes, the journey time, the likelihood of delay (buses in rush hour can be slow!) and acceptable walking distance all play a part in my selection of routes, but if the algorithm is set up differently then it might produce a different result. I think Google are trying to address this by gathering data about your habits and informing choices based on that (certainly Google Now makes route recommendations based on my location history, and tweaks that based on historical route preference). It will be interesting to see how this progresses.
There's sort of an opposite weirdness in San Francisco which is a bit ironic given where Google is located. Namely, based on various visits, Google seems very big on one taking the streetcar. Now SF streetcars are all very scenic and fun and all that but--with the possible exception of a few routes at non-crowded times of day (if there is such a thing)--useful public transportation they really aren't. (For one thing, there's often a block long line of tourists waiting to get on.)
But, yeah, it's hard. Not sure how you handle it other than just excluding streetcars from the list. (Which might not be a terrible heuristic in SF; locals feel free to disagree.)
I moved to Oslo (the city mentioned in the article) last week. I have to say Google Maps hasn't always played nicely, if it were not for me having been here before I would have wasted a lot of time.
I have a much better experience using HERE Maps (by "old" Nokia). The great part about them is that you can download a region (not just buffer map data as you do on Google) so searching in the map, public transport, directions etc. all work when in unknown cities abroad without mobile data.
Google Maps actually already does some of the things listed in the article (such as indicating multiple alternatives between two particular stops) but its ability to do so depends on the quality of the data provided by the local transit agencies.
Yes, sometimes I feel sad I have to read about all this cool stuff that is just "not available in your country" usually because it's a too small market or whatever. In particular transport data (and maps and even streetview) for Dublin, Ireland is very bad, which is weird given that it hosts Google's EU HQ.
Transport data for Google Maps is something you have to (and can) lobby your municipal government for. (I'm assuming your transit authorities are under municipal jurisdiction, like the ones in Canada and the US.)
It took us the better part of the last decade, but virtually every transit operator in the Toronto, Ontario, Canada area is now on Google Maps. Not necessarily with real-time GPS, although the transit authorities in more well-to-do municipalities tend to have it.
But you have to work with your neighbours to make it a priority. Whenever they ask for comments (hopefully your municipality is modern enough to ask for this through online forms) then fill it out and ask for them to provide Google Maps data.
(On the other hand, local lawsuits also had a part in it -- a disabled (blind or deaf, I forget which) person sued a local transit authority saying that not having the stops announced was preventing him from using public transit and won. So every transit authority had to have drivers read out every stop until they could install computers with GPS and LCD displays and text-to-speech to read out all the stops. Once the buses and trains all had GPS and computers on-board, adding real-time tracking was just a matter of installing a GSM modem on each vehicle.)
Back in 2008 I submitted a similar idea to Google for their 10^100 idea fest. It goes a step farther in that not only do you get directions from your phone, but the buses are re-routed dynamically, in real time, to optimize travel times. Think of your phone as a fancy elevator call button—you use it to summon a bus but furthermore the central routing computer knows where you are and where you want to go. The buses (er, bus drivers—for now) also get directions from the routing computer.
The 10^100 deal seemed to just quietly fizzle. I never heard back anything, and I'm not sure they ever picked any projects to run with. FWIW, here's the submission.
10. What one sentence best describes your idea? (maximum 150 characters)
Bring the bus system into the new millennium.
11. Describe your idea in more depth. (maximum 300 words)
The goal is to revamp the municipal bus system by using a little technology. The key ideas are:
a. Riders use their cell phones as a kind of "elevator call button." Using an Android app, they tell a central computer where they are (possibly automatic with GPS) and where they want to go.
b. There are no fixed routes. A central computer is continuously processing requests and sending routing information to the bus fleet in real time.
c. Riders are given instructions, via their phone, as to where to go to catch which bus, and where to get off.
d. Integration with Google Maps is an obvious win!
12. What problem or issue does your idea address? (maximum 150 words)
Current bus systems are underutilized because of long wait times and because most riders don't know the routes well enough to feel comfortable.
13. If your idea were to become a reality, who would benefit the most and how? (maximum 150 words)
The biggest beneficiary would be those who want to ride the but but don't now because of route unfamiliarity and long wait times. All commuters would benefit from the decrease in traffic and pollution.
14. What are the initial steps required to get this idea off the ground? (maximum 150 words)
At first, a simulation to demonstrate the effectiveness of the new model. Then, a pilot city to give it a real spin.
15. Describe the optimal outcome should your idea be selected and successfully implemented. How would you measure it? (maximum 150 words)
The desired outcome is an increase in ridership and fewer cars on the road. A straightforward metric is a simple rider count.
18. If you'd like to recommend a specific organization, or the ideal type of organization, to execute your plan, please do so here. (maximum 50 words)
I think you'll be happy to hear that not only has this idea been worked on starting much earlier than 2008, but I was part of a group to implement this for a city in the US. Service is scheduled to start later this year.
As it turns out - many of the hurdles are non-technical, especially without many examples of pre-existing systems to base it off of.
In smaller cities, buses are frequently on demand service, rather than planned routes (In Michigan, there are many county transit authorities, _ATAs, that do this). It's because they don't have the ridership to support planned routes.
There must be some tension between point to point service and having each passenger walk a few minutes, where the walking ends up saving time, even if it doesn't seem like it.
As a Seattle resident I've found the OneBusAway app extremely useful, it's never been off by more than a couple minutes. Getting widespread realtime transit info into a mainstream app like gmaps could be a complete game-changer for public transit.
I'm not sure that's the case, but if it were, perhaps more people would start using Waze again after Google Transit became worse. (Repeat process forever.)
Public transit agencies vary dramatically from city to city, but they are the ones who provide Google with data on their transit system's timetables. In fact, Google is the last in a chain of software and manual labor that creates and manages transit schedules. It's very hard to create software that captures all the nuances and variations in transit to create a one-size-fits-all solution.
The other tough part is funding - public transit improvements are often driven by grant money because the operating budget all goes to day-to-day expenses. And oftentimes the wealthier people who could make a difference in transit (e.g. SV techies) own cars or otherwise avoid public transit because it's so inconvenient, so they often don't notice the problems.