Times are changing and everybody is in a hurry. The system of calling a taxi and waiting for it to pick up the customer is now redundant. Taxis face active competition from each other and from other services like ride-sharing. Since practically everyone has a smartphone, a taxi app would do the trick. But how much time and effort will such an app require?
Occasionally, we read news of a taxi union planning its own app service to compete with Ola or Uber. Even though a taxi service is a local operation, can a local service hope to compete with a national or even an international service?
In this article, we study the software to enable such a service. It is easy to underestimate the effort involved when looking at the mobile app. However, it is not hopeless if the taxi unions use the open source model. In that way, each taxi union or taxi aggregator can use and expand the same set of software.
It is important not to think that a new taxi service is a ‘freeloader’. Rather, let’s hope that the new taxi service succeeds, because any service that does is bound to contribute to the application as it improves and expands its services.
The maps
A core critical component is the street map. Fortunately, OpenStreetMap already exists and each taxi union is well equipped to collect data for its metropolitan area.
Before the service is launched, the drivers can start collecting the data and improving the OpenStreetMap for their region.
The backend for routing taxis
The server application will need to use the OpenStreetMap and location information from each taxi to make informed decisions in real-time. For that, there may well be a need to enhance the OpenSreetMap API as well, in order to meet the needs of the taxi service provider. Open source ensures that there is no need to take anyone’s permission before working on enhancing the OpenStreetMap services.
The app needs to have the location of each active taxi. It needs to know the direction the taxi is facing. There are instances on main roads where the taxi may be just across the road. However, the U-turn needed could take up to a quarter of an hour.
The app also needs to use the street map data and the location of the customer to find the nearest taxis and provide a reasonable waiting-time estimate to the customer. It may need to keep track of any constraints a taxi may have. For example, if a particular taxi driver is going home, he will only accept a customer going in the same direction as his home-bound journey. There is no point in assigning a taxi to a customer and then finding that the customer is left waiting.
The app needs to keep track of the destination of a taxi in use, in case there’s a request for a taxi, which can be honoured after the current ride is completed. It needs to keep track of current traffic conditions and historical data to ensure the least expensive or the fastest trip for the customer.
Each of the tasks has to be handled in parallel as there may be multiple requests for taxis at any one time.
Programming each of these tasks is not easy, especially considering that the response time to the app has to be fast, the server should not go down, and there should not be erroneous matching of taxis to customers.
App for the drivers
Ideally, each taxi would have to be equipped with a navigation and communication device to minimise the driving risk. However, given the cost of a smartphone, it is more likely that at present, most drivers will use an app on a phone.
The app must be simple to use. It must smoothly manage erroneous inputs and unexpected conditions. Getting the usage right and making sure that the driver is not distracted by the app can take substantial effort.
The app must communicate with the maps for navigation purposes, and to the backend servers of the aggregator in order to share information.
It must give the location and status of the taxi and receive the pick-up location and destination of a rider. It must provide a way for the driver to communicate directly with the customer. However, it would probably be desirable from a security/ privacy perspective that neither is aware of the phone number of the other.
The driver must be able to communicate any change in the route or in the client’s destination. The payment system must be convenient and should offer cashless options.
At the end of the day, a driver will expect to know what his earnings are—the cash collected by him and the earnings credited by the cashless transactions.
The driver should be able to provide feedback about the customer as well, although one expects all customers to behave in a civil manner with the driver.
App for the customers
A client application would obviously be similar to the ones that many of us have used. The functionality has to be similar, though the user interfaces could be better. A local taxi aggregator may not be as interested in pushing other products and services on the main page.
The app will need to provide information about the availability of taxis, as well as the approximate time and cost for a ride. Clients should be able to request for a taxi to pick them up at the current or another location. There should be an option to schedule a ride.
A client should be able to contact the driver if need be, especially if the driver appears to be headed towards an incorrect location for the pick-up.
At the end of the trip, the client should be able to pay by his or her preferred method and provide feedback in case needed. A desirable capability would be that a client should have control over the amount of customer history that the taxi aggregator can keep.
Optimisation goals
The goals for a local taxi union will be very different from the current model. The taxi union will obviously want to maximise the earnings of its members. However, that does not necessarily conflict with the customers’ needs. Both would want to wait for as little time as possible. A taxi driver will not like his return journey to be in an empty vehicle.
A local taxi union will also need to use Big Data and statistical modelling to optimise the movement of taxis. The best way to do this would be by finding ways to optimise the fare a client pays.
There may still be time-and traffic-dependent discounts in fares for travelling in certain directions. In case of a shortage of taxis, the shared taxi options may be made more attractive.
Each taxi aggregator may add the functionality and models appropriate for its area, which may then be adapted and extended by other communities.
Each of these could be interesting and useful projects for computer engineering students. So, if some students start on it, who knows, some taxi union somewhere in the world may take it up from there.
