Delays are one of the main disadvantages when using public transport. However, where applications (like Google Traffic) are available to keep track of delays for motorists, relatively little help is available for public transport users, especially for predicting the likelihood of any major delays.

To illustrate why the problem matters, suppose one is taking a local bus service to connect to another mode of transport (say, to the railway station, coach station or airport). If the bus is late, one might miss the connection, which is especially a problem if the ticket for this connection is non-refundable. In the absence of any information on the punctuality of the local bus service, the best one can do is to prepare for the worse and leave home way in advance. This of course is very inefficient and leaves public transport at a disadvantage compared to other forms of transport (e.g. car or taxi).

One possible way of dealing with this is to implement a smartphone app that records the actual departure times of public transport users and stores these in a database. This database (with historic delays) can then serve as a basis for prediction of any future delays, to the same smartphone users.

The overall architecture of such a system would consist of three parts: (1) an iPhone app that registers the time and location (bus stop) when the user gets on the bus, the time and location (bus stop) when the user gets off the bus, as well as the bus line (2) a back-end server that receives this information, stores and processes it (3) the same iPhone app, which also allows users to query (based on previous data stored on the server) the most likely bus delay for a particular time, location and bus line

One of the main challenges is obtaining the data of (1). The aim is to automatically detecting this using the GPS of the phone, which is used to determine the proximity at a bus stop (as indicated on Google Maps). Once the speed in which the phone is travelling is greater than walking speed, the user is most likely inside of the bus. As for (3), the user should get options of what to query, depending on how much data is available on the server. Ideally, the user should be able to get timetables (using existing APIs) plus expected delays. The user should be able to also query nearest bus stations to a given location/current location.