Ola started there business in December 2010 formerly known as

OlaCabs, It was founded by the two graduates of IIT Bombay. The

Ola service bridges the gap between cab owners and commuters.
Rather than buy and rent its own cars, Ola partners with drivers and
owners of taxis and adds a modern touch to the whole process.

Ola provides mobility solutions that match riders with drivers

automatically. It also includes Ola ride share, which connects riders
with overlapping itineraries, resulting in a cheaper ride for all
customers. The greater the overlap between two routes, the greater
the discount they can offer.

Idea and Motivation behind the rideshare

Before launching the there product in the market they studied the
situation and maintained constant eye on the industry for several
years. They wanted to wait until there was enough data for the
ridesharing service. They ran a simulation on existing Ola Classic
journeys (non-shared) in May and discovered that over 80% of rides
in Mumbai shared a major chunk of their route with another ride.
only a small percentage of the city’s automobiles were Ola rides, yet
the bulk of those could potentially be connected with other
passengers. This was a great potential to transform transportation
and provide its passengers with more cheap services.
Design Decisions

The main design decision was made for the passengers in which they
would enter their origin and destination, receive a fare for the ride.
And then be placed in a matched pool for 1 minute before being
allocated a driver.

Finding drivers for all of their passengers at the same time would
cause a supply shock, as we’d need to have a pool of drivers ready at
the ten-minute mark. A ten-minute gap meant passengers had to
wait longer before being shown their itinerary. Given that the initial
implementation was likely to have some flaws, a ten-minute delay
might be excessive if they were then matched incorrectly. Finally,
they determined that the one-minute matching pool would provide
the best experience for their passengers and was what Ola’s on-
demand users had grown to anticipate.

Geo-hashing

Geo-hashing is a method of grouping coordinates based on their

latitude and longitude. They might record the average speed of rides
from one geohash to the next using historical data from previous Ola
rides and save it in a simple hash-table query using historical data
from previous Ola rides. They’d then multiply the haversine distance
between the two places by this speed to get a time estimate. This
method proved to be far more precise, allowing them to avoid
matching via mountains and distinguishing between highway and
street driving. It was also incredibly efficient, but it didn’t do a great
job of resolving one-way streets or rush-hour traffic because their
predictions were consistent throughout the day. They devised a
geohash-based model for estimates instead because it was too early
in the product’s development to invest in that level of labor.

Improvements

They had only considered pairing two passengers in a route so far.

They had spent a lot of time focused on passenger experience at this
point, but not nearly as much effort improving product efficiency,
which would allow them to provide higher discounts. This
squandered a lot of efficiency: more people in the car at the same
time meant more cost savings they could pass on to their customers.
The next logical step for them was to implement Triple Matching,
which allows them to add a third and fourth passenger to the
vehicle. Also, on basis of gender they Provide a security safety in the
app. Such that the female candidate feel safe during there long
journey.

Rerouting

They were then able to tackle another milestone in Ola Line

efficiency gains: rerouting, thanks to advancements in system
performance, such as the longitudinal sort. They had only agreed to
add a passenger to a route provided it did not change the driver’s
next stop up to this moment. That meant they couldn’t alter a |AA
route (where the vertical bar represents the driver) into a |BABA
route because the driver’s first pick up would have to be changed
from passenger A to passenger B. Similarly, they couldn’t add
passenger C to make it AB|CABC on an AB|AB route if both
passengers had already been picked up, however they could do AB|
ACBC.

Rerouting was not allowed for a variety of reasons, both technical

and user-experience-related. Imagine being one block from your
drop-off point and being told to turn right to pick up another
passenger. Worse, the driver may have picked up the first passenger
and merged onto a highway onramp only to be instructed to exit the
freeway, reverse direction, and pick up a second passenger. It was a
dangerous move, but the benefits were too appealing to pass up for
efficiency enthusiasts like us. They used some ingenious tactics to
recognize when a car was about to pull onto an onramp, so routes
wouldn’t be redirected if the driver was due to drop off a passenger.
Overall, rerouting increased efficiency significantly, and they were
able to transport it with minimal disruption to the passenger
experience.
They were winning big with Triple Matching and Rerouting, but they
weren’t able to take full advantage of the increasing amount of rides.

The Road to Becoming Less Greedy

Many efficiency gains were made along the road, but the algorithm’s
next big step was to adapt to a well-established product with
considerable demand. Their greedy algorithm was designed to locate
a match, and they went with the first one that presented itself. As
Line evolved to become the majority of Ola trips in Mumbai, they
couldn’t just pick the first match they came across because that
would waste a lot of time. They had to discover the finest potential
match instead. This entailed taking into account all system riders as
well as forecasting future demand.
This became something of a maximum matching problem for a
weighted graph mixed with components of a Secretary Problem for
those interested in Algorithms. The ideal approach would combine
an accurate forecast of future demand with an algorithm that
searched for all possible matches before selecting one. It was an
ambitious adjustment to overhaul the architecture to handle the
problem in this way, and given the agile mindset, they realized there
was an interim step they could take — Route Swapping.

Algorithm

At the starting of ola rides its only depends on the binary

classification because the passenger is either going to accept the
rides or cancel the ride. Hence, the simple logistic regression of
binary classification is used. But, as the customers requirements and
choices are taken into consideration the machine learning algorithm
is started to becomes an complicated and continuously the new
feature are being added like geo location, rerouting, increase in the
safety etc. Hence they move to the decision tree and random forest.
After considering the normal middle class group of people who are
ready to share the cab in that situation this algorithm are not giving
good accuracy and then the clustering comes into a picture as the
clusters are being form according to the area and started using the
K-means clustering algorithm.

Thank you… Any suggestions are welcomed…