Ex­plor­ing Soft­ware: What it Takes to Cre­ate a Taxi-hail­ing App

OpenSource For You - - Contents -

Times are chang­ing and ev­ery­body is in a hurry. The sys­tem of call­ing a taxi and wait­ing for it to pick up the cus­tomer is now re­dun­dant. Taxis face ac­tive com­pe­ti­tion from each other and from other ser­vices like ride-shar­ing. Since prac­ti­cally ev­ery­one has a smart­phone, a taxi app would do the trick. But how much time and ef­fort will such an app re­quire?

Oc­ca­sion­ally, we read news of a taxi union plan­ning its own app ser­vice to com­pete with Ola or Uber. Even though a taxi ser­vice is a lo­cal op­er­a­tion, can a lo­cal ser­vice hope to com­pete with a na­tional or even an in­ter­na­tional ser­vice?

In this ar­ti­cle, we study the soft­ware to en­able such a ser­vice. It is easy to un­der­es­ti­mate the ef­fort in­volved when look­ing at the mo­bile app. How­ever, it is not hope­less if the taxi unions use the open source model. In that way, each taxi union or taxi ag­gre­ga­tor can use and ex­pand the same set of soft­ware.

It is im­por­tant not to think that a new taxi ser­vice is a ‘free­loader’. Rather, let’s hope that the new taxi ser­vice suc­ceeds, be­cause any ser­vice that does is bound to con­trib­ute to the ap­pli­ca­tion as it im­proves and ex­pands its ser­vices.

The maps

A core crit­i­cal com­po­nent is the street map. For­tu­nately, OpenStreetMap al­ready ex­ists and each taxi union is well equipped to col­lect data for its met­ro­pol­i­tan area.

Be­fore the ser­vice is launched, the driv­ers can start col­lect­ing the data and im­prov­ing the OpenStreetMap for their re­gion.

The back­end for rout­ing taxis

The server ap­pli­ca­tion will need to use the OpenStreetMap and lo­ca­tion in­for­ma­tion from each taxi to make in­formed de­ci­sions in real-time. For that, there may well be a need to en­hance the OpenSreetMap API as well, in or­der to meet the needs of the taxi ser­vice provider. Open source en­sures that there is no need to take any­one’s per­mis­sion be­fore work­ing on en­hanc­ing the OpenStreetMap ser­vices.

The app needs to have the lo­ca­tion of each ac­tive taxi. It needs to know the direc­tion the taxi is fac­ing. There are in­stances on main roads where the taxi may be just across the road. How­ever, the U-turn needed could take up to a quar­ter of an hour.

The app also needs to use the street map data and the lo­ca­tion of the cus­tomer to find the near­est taxis and pro­vide a rea­son­able wait­ing-time es­ti­mate to the cus­tomer. It may need to keep track of any con­straints a taxi may have. For ex­am­ple, if a par­tic­u­lar taxi driver is go­ing home, he will only ac­cept a cus­tomer go­ing in the same direc­tion as his home-bound jour­ney. There is no point in as­sign­ing a taxi to a cus­tomer and then find­ing that the cus­tomer is left wait­ing.

The app needs to keep track of the des­ti­na­tion of a taxi in use, in case there’s a re­quest for a taxi, which can be hon­oured af­ter the cur­rent ride is com­pleted. It needs to keep track of cur­rent traf­fic con­di­tions and his­tor­i­cal data to en­sure the least ex­pen­sive or the fastest trip for the cus­tomer.

Each of the tasks has to be han­dled in par­al­lel as there may be mul­ti­ple re­quests for taxis at any one time.

Pro­gram­ming each of these tasks is not easy, es­pe­cially con­sid­er­ing that the re­sponse time to the app has to be fast, the server should not go down, and there should not be er­ro­neous match­ing of taxis to cus­tomers.

App for the driv­ers

Ide­ally, each taxi would have to be equipped with a nav­i­ga­tion and com­mu­ni­ca­tion de­vice to min­imise the driv­ing risk. How­ever, given the cost of a smart­phone, it is more likely that at present, most driv­ers will use an app on a phone.

The app must be sim­ple to use. It must smoothly man­age er­ro­neous in­puts and un­ex­pected con­di­tions. Get­ting the us­age right and mak­ing sure that the driver is not dis­tracted by the app can take sub­stan­tial ef­fort.

The app must com­mu­ni­cate with the maps for nav­i­ga­tion pur­poses, and to the back­end servers of the ag­gre­ga­tor in or­der to share in­for­ma­tion.

It must give the lo­ca­tion and sta­tus of the taxi and re­ceive the pick-up lo­ca­tion and des­ti­na­tion of a rider. It must pro­vide a way for the driver to com­mu­ni­cate di­rectly with the cus­tomer. How­ever, it would prob­a­bly be de­sir­able from a se­cu­rity/ pri­vacy per­spec­tive that nei­ther is aware of the phone num­ber of the other.

The driver must be able to com­mu­ni­cate any change in the route or in the client’s des­ti­na­tion. The pay­ment sys­tem must be con­ve­nient and should of­fer cash­less op­tions.

At the end of the day, a driver will ex­pect to know what his earn­ings are—the cash col­lected by him and the earn­ings cred­ited by the cash­less trans­ac­tions.

The driver should be able to pro­vide feed­back about the cus­tomer as well, al­though one ex­pects all cus­tomers to be­have in a civil man­ner with the driver.

App for the cus­tomers

A client ap­pli­ca­tion would ob­vi­ously be sim­i­lar to the ones that many of us have used. The func­tion­al­ity has to be sim­i­lar, though the user in­ter­faces could be bet­ter. A lo­cal taxi ag­gre­ga­tor may not be as in­ter­ested in push­ing other prod­ucts and ser­vices on the main page.

The app will need to pro­vide in­for­ma­tion about the avail­abil­ity of taxis, as well as the ap­prox­i­mate time and cost for a ride. Clients should be able to re­quest for a taxi to pick them up at the cur­rent or an­other lo­ca­tion. There should be an op­tion to sched­ule a ride.

A client should be able to con­tact the driver if need be, es­pe­cially if the driver ap­pears to be headed to­wards an in­cor­rect lo­ca­tion for the pick-up.

At the end of the trip, the client should be able to pay by his or her pre­ferred method and pro­vide feed­back in case needed. A de­sir­able ca­pa­bil­ity would be that a client should have con­trol over the amount of cus­tomer his­tory that the taxi ag­gre­ga­tor can keep.

Op­ti­mi­sa­tion goals

The goals for a lo­cal taxi union will be very dif­fer­ent from the cur­rent model. The taxi union will ob­vi­ously want to max­imise the earn­ings of its mem­bers. How­ever, that does not nec­es­sar­ily con­flict with the cus­tomers’ needs. Both would want to wait for as lit­tle time as pos­si­ble. A taxi driver will not like his re­turn jour­ney to be in an empty ve­hi­cle.

A lo­cal taxi union will also need to use Big Data and sta­tis­ti­cal mod­el­ling to op­ti­mise the move­ment of taxis. The best way to do this would be by find­ing ways to op­ti­mise the fare a client pays.

There may still be time-and traf­fic-de­pen­dent dis­counts in fares for trav­el­ling in cer­tain direc­tions. In case of a short­age of taxis, the shared taxi op­tions may be made more at­trac­tive.

Each taxi ag­gre­ga­tor may add the func­tion­al­ity and mod­els ap­pro­pri­ate for its area, which may then be adapted and ex­tended by other com­mu­ni­ties.

Each of these could be in­ter­est­ing and use­ful projects for com­puter en­gi­neer­ing stu­dents. So, if some stu­dents start on it, who knows, some taxi union some­where in the world may take it up from there.

By: Dr Anil Seth

The au­thor has earned the right to do what in­ter­ests him. You can find him on­line at http://sethanil.com and http://sethanil.blogspot. com, or you can reach him via email at [email protected]

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.