Planning a Tour using Freight Forwarding

In this use case several transport orders are planned by a freight forwarding agent without any own fleet and the resulting schedule is executed by a subcontracting carrier. No goods have to be delivered from or to any depots, just transport orders between pairs of customer sites have to be executed.

Example | The following picture shows an example of the order structure

Geographical overview of single orders planned by a freight forwarding agent.

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 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. as the plan should contain

Concepts

The next sections explain the resulting tour structures depending on how the locations are modeled. Due to the definition of tours and trips, the structure changes if locations are modeled as depot sites instead of customer sites.

Modeling every site as customer

Depot sites are currently the only available trip delimiters. Therefore the resulting xTour schedule (no matter, which algorithm settings were applied) consists of a single trip, since no depot sites are involved. However, this trip contains a lot of empty drives on route legs A route leg is a part of a route between two consecutive waypoints., since there is no central location where the most of the goods are picked up or have to be delivered to.

Geographical tour structure and stop sequence of pickup-delivery orders with all sites modelled as customers.

The execution of the schedule is outsourced to subcontracting carriers and, depending on a payment tariff structure, several short trips might be in favor compared to one long trip with a lot of empty legs.

Modeling every site as depot

There is a workaround to achieve several short trips instead of a large one: call the planning function with customer sites modeled as depot sites and do not restrict the tour structure to single trips or single depots. This would allow the resulting tour to be split into several trips. However, the downside of this workaround is, that there are more restrictions with regard to tasks, which can be carried out at a depot site. As soon as a vehicle carries out a single delivery task at a depot site, it is not allowed to pick up anything or approach customer sites until the vehicle is empty. This limitation results in trip structures where at first all pick-up tasks are carried out, followed by all delivery tasks.

Geographical tour structure and stop sequence for pickup-delivery orders with all sites modelled as depots.

So there is the choice between

an unordered pick-up and delivery sequence contained in one big trip or
an ordered pick-up and delivery sequence with several short trips.

Programming Guide

This example explains how the request should 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 locations 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.. Depending on the choice of desired tour structure, as explained in the concept section, locations are either modeled as depot or as customer sites.

The fleet in this example consists of one type of vehicle, with a single available instance (defined by the number of vehicle ids). This vehicle has undefined start or end locations because it does not matter to the planning use case. To simplify the example code, we assume that the vehicle uses direct distance (can be set in the distance mode of the request).

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.

In order to achieve the first example of tour structure, one long trip, all locations are modeled as customer sites. Change the type of all the locations to depot sites if you want to achieve the second example of tour structure, several short trips.

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 tour of the result is displayed in gray.