Using Resources of Neighboring Depots to Avoid Order Overflow

This use case describes how to use vehiclesClosed The term vehicle describes what is being routed or planned for. Vehicles are used in route calculation, distance matrix calculation and effectively also in tour planning. In route calculation, vehicle properties like overall size, weight and speed are in focus. In tour planning, it is vehicle properties like capacity and availability. Commonly a vehicle is motorized, like a truck - including its trailer or a car. However also a bike or even a pedestrian are included in this definition. to execute orders of depots other than their home depot in case of limited vehicle resources (number- and/or capacity-wise).

In this use case the capacity of vehicles located at a certain depot is not sufficient to execute all orders from this depot. Vehicles from neighboring depots should be used to execute the remaining orders.

Example | The following picture shows an example of the desired tour structure

Geographical structure and stop sequence of tours that use vehicles from neighboring depots to execute remaining orders.

In this example the available fleet capacity of Depot B is too small to execute the current amount of orders. Therefore, vehicles of a neighboring Depot A shall help to master the situation. Vehicle A2 approaches Depot B running empty. After that it performs delivery and pick-up orders of Depot B before heading back to the vehicle location at Depot A. Vehicle A3 is supposed to perform some of the deliveries of Depot B as well as deliveries and pick-ups of Depot A. In order to avoid empty route legsClosed A route leg is a part of a route between two consecutive waypoints., the vehicle is loaded at Depot A with some delivery orders before approaching Depot B for further loading. Since there are no delivery orders to Depot B involved, there is no need to return back there, in contrast to vehicle A2, and the vehicle A3 heads directly to its final location at Depot A at the end of the journey.

Benefits

  • Users learn how to parametrize the current use case.
  • Basic insight into how to influence the course of a tour.

Prerequisites

Please ensure following prerequisites are fulfilled before you start with the use case:

  • Installed and licensed PTV xTour service
  • License for as many vehicles as the plan should contain

Concepts

Programming Guide

This example explains how the request has to look like in order to influence the tour structure as mentioned in the use-case description above.

First we define our locations as OffRoadRouteLocations in the default EPSG:4326 format (see RequestBase.coordinateFormat). You could also use OnRoadRouteLocations, see the technical concept on waypoints and route legs for more information on the different types of route locationsClosed A route location is the position of an object to be routed to or from, which contains additional information on how to link this position to the road network and whether or or not this position is actually reached. Route locations are used as the input for route calculation and optimization throughout PTV xServer.. Since the use case describes deliveries from and to several depots, we define some locations as depot and some as customer sites, see Orders, Locations, and Stops for more details. The orders need to have specific quantities set, which may lead to multiple tours if a vehicles maximumQuantityScenario is not high enough to load the combined quantities of all orders.

The fleet in this example consists of two types of vehicle, one containing three available instances and the other one containing only one available instance (defined by the number of vehicle ids). The two types of vehicle only differ in their start and end locations which are located at the different depots. To simplify the example code, we assume that the vehicles use direct distance (can be set in the distance mode of the request).

In this example we do not want to return to the depot(s) in between stops at customers, so we need to activate the tour restriction singleTripPerTour. This restriction could also be omitted if other tour structures should be allowed.

The last part of the example request are the orders, in this case only consisting of pickup and delivery orders.

We pass the request on to planTours. Once xTour has processed the request a callback is invoked which gives us access to the result of the calculation in form of a ToursResponse object.

The customer sites of the request are displayed in gray, the depot sites in orange. Since the ToursResponse only contains references to the given locations, the corresponding coordinates are taken from the request. The first tour of the result is displayed in gray, the second one in blue, the third one in red and the fourth one in cyan.

Each vehicle starts from its start depot. The maximum quantities of the vehicles of DepotB is not enough to execute all orders of DepotB. Therefore the vehicles vehicleA2 and vehicleA3 have to execute orders of DepotB although their start depot is DepotA.