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