My previous experience with GTFS made me look for something better. Yes, GTFS is used by many transit agencies and there are numerous open data sets, yet, there is a question: why the vast majority of public transport agencies have little or no interest in GTFS?
First, like any new technology, GTFS comes at a cost: time, money. The data format looks deceptively simple, yet the calendar part is a blackhole. Some agencies create hundreds of calendars, just for sake of making it work. The 25th hour as an indicator of service past midnight is missing most of the time. As for the bus line identifiers, I have seen long sentences with blanks. Make no mistake, I don’t say GTFS is bad, just that it is improvable.
Second, most transit agencies keep their data closed, as in non public. There are different reasons, from safety to just competitive advantage, if any. Today, many companies make money from selling mobile apps for public transportation with adds. By keeping the data private, the likes of Waze are making fun of them, especially when the bus arrives either 10 minutes before, or 20 minutes after the estimated arrival hour. Transit agencies know where the vehicle is and when it is at specific locations.
Third, and this is very sad, the data from the transit agencies is neither GTFS-ready, nor GTFS-friendly. I know this from my own experience. There are historical reasons to that. public transport companies have used their own databases long before GTFS existed. AS the systems keep working, there is no reason to change for a technology that is still too fresh to be considered mature. So, no conversion to GTFS.
The XSTS articles
Enough said. I have started to work on something called XSTS. It is inspired by GTFS, but it takes into account the needs of transit agencies. The transition from proprietary databases to XSTS should be by design much easier than a transition to GTFS.
This page is a table of contents grouping together all my articles related to XSTS. It is recommended to read them in the order.