Use Scenarios

Traveling Salesperson

The well-known Traveling Salesman Problem is a special case of the Vehicle Routing Problem: It describes a salesperson who wants to visit a specific set of locations at least once and return to the origin. The order of which the salesperson visits the locations does not matter. The goal is to keep the traveling costs and distance as low as possible. This is a famously difficult problem in computer science since exponentially growing computation time is required to find the optimal route. Popular use cases include “maintenance round-trips”, “customer on-site visits”, and “planning city tours”.

Multi Traveling Salesperson

In many practical scenarios it makes sense to split up the work to be serviced by “multiple “resources”” instead of one. Since the “resources” can operate in parallel, all customers can be visited earlier. To find optimal routes, the service has to decide which “resource” visits which locations (and in which order). Popular use cases include “maintenance visits”, “customer on-site visits”, and “planning public transportation routes”.

Multiple “resources” can also be used to split up the work sequentially, e.g. a facility manager is in charge of 20 locations and has to visit them once per week - he can use 5 “resources” instead of one to split his viewings up into 5 tours (one per work day).

Vehicle Routing with Customer Deadlines and Priorities

In many scenarios the route is not only determined by its duration but also by “deadlines” that must be met: Customers that have a deadline coming up soon should be prioritized, despite it not being the quickest path. The fleetplanner service will first try to avoid missing deadlines, and then attempt to improve the routing duration. When trade-offs need to be made (e.g. when not all deadlines can be met), then you could assign a “priority” to each customer to ensure that higher priority deadlines are met rather than low priority deadlines (if this trade-off is necessary at all).

That means for the optimization: meet high priority deadline > meet low priority deadline > total duration of routes

Vehicle Routing with Capacity Management

For Vehicle Routing use-cases where freight is picked-up or delivered it is important to not exceed each vehicle’s capacity. The service interface allows you to specify each “order’s load values” (e.g. its weight) as well as each “vehicle’s load constraints” (e.g. its maximum load weight capacity). Popular use cases include “transport” or “delivery companies”.

Inputs

Input consists of a config object see docs

{
  "optimizationTime": 2,
  "optimizationAlgorithm": "CONSTRAINT_SATISFACTION",
  "stores": [], // stores or depots - where the delivery comes from
  "orders": [], // orders to fulfil
  "transports": [], // vehicles available for deliveries, associated to stores
  "optimizationMetadata": {}  // fine-tune the optimization, and configure outputs 
}

Outputs

Output is an object containing an array of order details see docs

{
  // includes entire input config object, plus:
  "tours": [], // the orders, assigned to transports, arranged by delivery time
  "resultStatus": {} // information about the optimization: processing stats, unfulfilled order details, etc.
}

Operations counting strategy for public use

orders: each order is counted as 1 operation.

example:

• single request for 10 orders = 10 operations.

10,000 orders could be routed with the 300 € monthly use-credit.