Despite open data, has the travel app ecosystem become closed off?
In a world where urban travel information is becoming ubiquitous, are third-party developers being marginalised, leading to fewer choices for end users? Paul Harrington, Owner of YourStop, explains why open data might not be as open as it seems.
In the last decade, there has been a strong push towards open data in the transit sector. In the UK for example, the 2017 Bus Services Act includes a requirement for bus companies to publish information on their operations. This includes making data on services and fares publicly available with the intention to promote open data, putting information in the public domain, so others will be able to make it accessible in user-friendly formats. This data should include real-time information on running services as well as timetables.
In the West Midlands region of the UK, Transport for West Midlands (TfWM) was set up as an executive body of the West Midlands Combined Authority (WMCA) and is the public body responsible for coordinating transport services in the West Midlands metropolitan county in England. Under their remit, schedules and real-time data (when available) have been combined for over 80 bus operators and made accessible using General Transit Feed Specification (GTFS). The associated data feeds have been made publicly available and can be presented to end users by GTFS consuming applications such as YourStop.
YourStop allows users to find next arrivals at bus stops and is a compact, easy-to-use service which can be displayed on all types of devices. Live predictions are given when available, allowing users to track buses in real time. It is a generic, advert free and socially-oriented project built around the widely-used GTFS. The app can be used in multiple regions, and it can be easily extended to other locations.
The quality of data
TfWM’s policies and strategy are set by the Transport Delivery Committee of the WMCA, which generally meets every two months. With regard to passenger information, they had clear objectives as stated in one of their regular reports: “TfWM continues to make data open to third parties who may wish to use it, as part of our strategy to get good passenger information into the hands of as many existing and potential customers as possible. These third parties can be mobile applications, developers’ universities and even the general public.”
These objectives have been met with regards to making quality data openly available. In fact, an impressive amount of work has gone into integrating so many diverse data sources, but it’s at this point that the doors close.
When YourStop first went live with the West Midlands feeds, emails were sent to most of the Transport Delivery Committee members asking for help in promoting it and getting the word out. Efforts were also made to get a link from the Network West Midlands website as this would be a first port of call for many looking for bus timetables or real-time data. All requests met blanket silence.
Rather than being an isolated case, this would appear to be the norm. Almost all transit providers provisioned in YourStop have been asked to link to it from their main website without success. A particular page would be proposed and as most already have their own offerings, a new section suggested to cater for third party applications such as YourStop. Other providers were approached to see if they would be interested in being incorporated with their only obligation being a link to it. Requests were met with either a polite refusal or no response.
It was not always the case that operators locked their sites down to a small set of apps. In the past, some operators at least were more open to supporting third-party applications. A few years ago, York Region Transport in Ontario had an ‘app centre’ page but moved towards a single official offering based around OneBusAway. MBTA in Boston used to have a page listing a large number of independent apps. In 2016, they held a competition to find those which were best suited to their network and soon after chose to officially endorse TransitApp. In both these cases, the operators removed their old third-party listings page.
While these events are understandable and arguments can be made for better customer experience with a single offering, one does wonder why they could not at least maintain a page for unofficial alternatives. It could be made obvious to users that these are not official and most users these days are well aware of the risks involved. While not ‘supported’, the offerings could still be validated by transit staff to ensure they are current and work within reasonable bounds. Many operators have employees to do this type of work anyway and are not shy when it comes to checking out the functionality of other systems using their data. They may validly argue that this is the purpose of mobile stores, but with the convergence of native and web app technologies, there is less need for completely separate development on native platforms.
The GTFS world
In the GTFS world, it is often found that when new real-time feeds are published, there is a link on the operator’s website to the Trip Updates and Service Alerts feed but not the Vehicle Positions feed. The first two are used to show predicted times at stops and operator notices, while the latter gives the GPS coordinates of buses and trains en route along with an associated time stamp. More often than not, the predictions feed is based on a self-learning algorithm which takes the positions feed as input. The open source TransitClock project is an example of this and it is reasonably safe to assume that vehicle positions feeds exist even if they are not being published. In many cases, they can actually be accessed by simply guessing the URL.
To see a working example of these reservations, one can look at the National Transport Authority in Ireland. They have had transport APIs for years but have only recently commissioned real-time data to be made available in GTFS formats. The release date has been continually pushed out and the natural assumption is that feeds are not yet available. However, a new version of their own app shows live bus positions. While there are still plans to make bus predictions and alerts publicly available in GTFS format, it looks like a decision has already been made to not make actual bus locations available. The delay in making feeds available means their own offerings will be well established by the time alternatives using these feeds are available; the inability of other applications to show bus locations means commuters are unlikely to try anything else.
Given the cost of investment in app development, this is understandable and fairly common practice. More often than not, the organisation that produces the actual feeds is either the same as or closely linked to the body that creates the end user offerings. In spite of stated aims and open data principles, this effectively creates a culture where there is an implicit push to get the commissioned app as widely used as possible and discourage alternatives. Ideally, the entity that is contracted to produce the data feeds would have no relation whatsoever with that contracted to produce end user systems. In fact, an argument can be made for operators opening data from the start and giving independent apps a chance to feature, before considering investment in their own offerings.
By going down the path of favouring a single app, smaller players are squeezed out of the market and there will be less diversity in how information is presented. An example of this is a fairly unique feature in YourStop where an All Destinations drop down box appears when viewing departures for a stop. This lists all stops in alphabetical order that can be reached from this stop without changing bus. When a destination is selected, departures which do not stop at this destination are filtered out. All remaining departures will stop at the destination and the time at the destination shown.
While features such as this may not be of interest to most, you will always find some riders who would use them. Many are quite happy to work their way through available implementations looking for features that suit their particular needs. Removing choice ultimately deprives the end user. It also begs the question: why make data open when there is little to show for it?