Introduction

The routing plan generated by the service adapts to drivers' usage pattern with time, and therefore provides better experience to drivers. This adaptation can save drivers' time because the generated routing plan would be more likely to be usable as is without drivers' intervention, as opposed to requiring drivers to manually reorder the routing plan to suit their preference.

A little bit more detail

The feature is implemented by examining drivers route logs, where a route log is essentially an order of the tasks performed by all drivers. When enough route logs are gathered through the service use, we can gain general insight from drivers' routing patterns, along with the metrics for their accuracy. For example, task processing sequence data in a certain region, gathered within a long period of time, might reveal that all drivers performing tasks in the region visits location A before visiting any other location, if they have to perform task at location A at some point.

How, then, are the rules utilized in the service so that they are reflected in future routing plan? Fundamentally, these rules are modeled as penalty functions, grouping them into various constraints with respect to the pattern they represent. Just like all other constraints that ensure certain criteria of routing solution are met, the newly created constraints can be added to the list of constraints in the routing request, effectively penalizing and eliminating the solutions that do not satisfy these rules.

Points to consider

In order to employ the experience mining functionality, relevant route logs have to be added through the API, which will be explained further in the later sections. Note that even though it is possible to exploit this feature to create solutions that would satisfy "custom rules" (for example, you can send fabricated route logs to the server so that the solution generated by the service would reflect YOUR preference and not those of drivers), please be aware that the feature is designed to save drivers' time and cost.

Also to be considered is that not every route logs are relevant to the patterns to be extracted. In other words, it will most likely be the case that the "global" rules do not exist. For example, some route logs might have been introduced to the system from trucks' routing plan, while others might have been generated from the delivery plan for motorcycles. Since the characteristics of these two different modes of delivery are probably incompatible with each other, patterns extracted from heterogeneous route logs are very likely to be incoherent and impractical. If the logs are not categorized with respect to their characteristics, the patterns generated from those logs would cause more harm than benefiting the drivers.

To accommodate grouping of route logs, the concept of expCode is adopted in the mining API. Simply put, expCode is a user-defined label for each of the (also user-defined) categories that all route logs should fall into, and all endpoints of the mining API expect some value of expCode. The full knowledge of the rule mining API is not necessary to understand how expCode is used within the API. It suffices to know that adding a route log and extracting patterns from the logs are the API's main function. With these in mind, when a new route log is added through the API, the value of the expCode attribute must be set appropriately so that the logs can be correctly grouped. For example, "truck" or "4-wheeled vehicle" can be some of the valid values. Also, when requesting patterns to be derived from the route logs accumulated in the server, the value of the expCode attribute should be properly assigned to one of the existing expCode values. For example, if all route logs added to the system have "truck" as their expCode values, the request should also be for finding patterns in "truck" data (i.e the value of expCode must be "truck"), because otherwise it is unreasonable to search for patterns in something non-existent.

Moving forward

The resource URIs and the available HTTP actions are documented in the Experience Mining API section. Also, the examples in the section define the structures of the request and response object.