up

Build Your Own Ridesharing Application Using Ritc and Google

You too can build an UberPool.

Ridesharing has been in the news lately. So to show off the power of Ritc, this ridesharing demo will show you how you can build a real-world cloud-based ridesharing application.

There are actually two demos, one where passengers are picked up by drivers not carrying passengers, and the other by drivers already carrying passengers – something like UberPool. In January 2015, an Uber VC, Bill Gurley, blogged about how this was a ‘BHAG’ (Big Hairy Audacious Goal) – something to be solved by the Uber ‘math department’. Well, Uber has clearly solved this challenge, but these demos will show how it is quite do-able in Ritc with just a few rules.

The demos are based on actual taxi rides that took place in January 2015 in New York City. The data, which you can access too, is available from Socrata (see City of New York 2015 Taxi Rides).

Ridesharing Demo #1

This demo shows passengers picked up by drivers who were nearby (within 1000 meters) and were not already carrying passengers.

After retrieving the historical rides from Socrata, the simulation sends each “passenger request”, with the appropriate delay (slowed down slightly for the demo) to the Ritc rule engine. Ritc tries to match the request with a nearby driver. Passenger requests are shown as green passenger icons on the map. Ritc returns the result back to the “caller” – in this case this simulation page, and when there is a match the passenger icon is removed and replaced with a blue car, which starts moving along its trip route.

In the video, the Passenger Request entries and Pickup entries show on the right. At the end of each trip, indicated by the Dropoff entry, the blue car is removed from the map.

In this “Demo #1”, there are two rules. The rules below are as they appear in the Ritc Visual Rule Editor.

  • Rule 1: Receive the “Driver Available Notification” and store it in the database.
  • Rule 2: Ritc is using just one rule to attempt the match. The rule has four triggers, one of which uses the Google Distance Matrix API (thank you, Google!), and two actions

    and does the following:

    • Trigger 1: Receive the passenger pickup request.
    • Trigger 2: Using the passenger coordinates sent in the passenger pickup request, it looks for nearby drivers in a Drivers database, who are available but not already carrying passengers.
    • Trigger 3: It uses the Google Distance Matrix API to get the actual current distances of each driver, and chooses the nearest one.
    • Trigger 4: At this point, this simulation assumes there is a match, and sends the “start your trip” instructions to the driver. As an alternative, it could send a request to “accept this ride” to the driver, in which case another rule would be needed to process the acceptance. (This would probably be required in real life).
    • The total time taken to process the rule is shown in the entries on the right in the video.

In this demo you will find some passenger requests that are not fulfilled – see the green passenger icon still showing near the end. This is because there were no entries in the Drivers database that were available as candidates. In the next demo Ritc will show that it can handle situations where it matches passenger requests with drivers who are already carrying passengers, and where the new passenger is on the driver’s route.

The “passenger requests” in this simulation are using real NYC 2015 taxi data, but it could just as easily be sent from a mobile phone, containing actual latitude and longitude coordinates.

Ridesharing Demo #2 – Carpooling

This demo shows passengers picked up by drivers who were already carrying passengers, and where the new passenger was on the driver’s route, heading in the same direction.

Actual rides from Socrata were used as a basis for this demo, but additional data was used to simulate the initial coordinates of the new passenger, as this data was not available from the historical record.

The simulation sends each “passenger request” to the Ritc rule engine (see the entries on the right in the video).

The simulation works the same way as in Demo #1.

In this demo, there are two rules:

  • Rule 1: Receive the “Driver Status Update” and store it in the database. This rule is similar to the one used in Demo 1
  • Rule 2: Ritc is using just one rule to attempt the match. The rule also has four triggers, which include calls to Google Directions Service, Distance Matrix API, as well as the Google Geometry Library

    and does the following:

    • Trigger 1: Receive the passenger pickup request.
    • Trigger 2: Using the passenger coordinates sent in the passenger pickup request, it looks for nearby drivers in a Drivers database, who are already carrying passengers and who are heading to the same destination.
    • Trigger 3: It uses the Google Directions Service, Distance Matrix API, and Geometry Library to check that the new passenger is on the driver’s route, is heading in the same direction, and is ahead of the driver.
    • Trigger 4: It chooses the nearest driver out of all it has found.

This demo exemplifies the types of applications that could be built and run in Ritc – where you have a defined population of participants – in this case driver and passenger apps – that communicate with a service that determines what to do next. The Ritc rules can be considered as “use cases”, or “executable requirements” that can be created and managed by non-technical people.

Are you ready to build your application?

Please contact us if you have any questions or comments.

Leave a Reply

Your email address will not be published. Required fields are marked *