Check these terms to ensure you understand the whole use case.
Addresses of which the position cannot be altered (e.g. customers) or reference points of administrative territorial units (e.g. postcode areas)
Assignment of a location to a territory; multiple assignments are not possible
Planning result; allocation of the locations to a common unit (e.g. operational area); territories without a fixed territory center can also be called 'clusters'.
Fixed territory center which services the other locations in a territory
The PTV xTerritory server does not include geographical functions, meaning that the geometry of territories cannot, for example, be merged or processed in WKB form. When planning areas using postcodes it is necessary to work with territories' reference points (the central or focal points).
Simple territory planning with PTV xTerritory server offers a range of possibilities
Planning balanced territories e.g. according to revenue potential, number of households.
Creating territories which are geographically compact, based on actual kilometres of road and travel times, to reduce travel time and maximise time with the customer.
Quick simulation of various planning scenarios ("What would happen if" cases).
Check if the following prerequisites are fulfilled before you start with the use case.
PTV xTerritory server is installed
High-performance routing network for calculating routes, if applicable.
During territory planning, a number (to be specified by you) of territories are planned from scratch. This use case describes planning on greenfield land, i.e. there are no existing territory centres to take into account. For planning with existing territory centres, please use information given in the use case location assignment.
An important consideration when territory planning is the distribution of levels of activity at locations (e.g. revenue, size of firm, number of occupants or number of households). Changing location assignments and their activity can therefore have a directly proportionate impact on the amount of activity in the affected territories. Any numerical field of your choice can be used as an activity.
Example: If a customer with a revenue of X is assigned to another territory, the revenue total for the old (- revenue X) and newly (+ revenue X) assigned territories will change.
The target criteria of territory planning with the PTV xTerritory server are:
Balance (total activity per territory): as far as possible, every territory should have the same size and/or workload in relation to the total of the activity in its locations.
Example: Every territory belonging to a sales representative has the same revenue volume. This means that it is possible to regulate the maximum capacity of each territory. This is based not on any absolute, but rather on percentage equality. In the response, all locations are always assigned which can lead to overloading.
Contiguity and compactness (consideration of the distances): a planned territory should have a geometric shape that is as compact as possible. In an ideal world this would thus be a circle (as long as the road network is not taken into consideration) such that the travel time is minimised to the greatest extent possible. The ideal area boundaries are those which are as clear and smooth as possible. You can find a precise description of the terms contiguity and compactness in the use case "How to visualise planned territories and KPIs".
Planning issues can arise, depending on the data layer, because of the target criteria. Even without taking any special restrictions into account, the planning criteria distance and activity can find themselves in competition with one another: The optimum solution in terms of compactness simply assigns locations to the nearest territories. Only if locations and activities are distributed very evenly the competing aims start to come together; in a hypothetical ideal world, assignment to the closest territory is also the optimum solution in terms of activity level. The value distribution of the activity level, e.g. the spread of revenue, can have a strong impact on the evenness of territories in terms of their revenue total or even prevent a solution from being found, if there is a serious lack of homogeneity.
The PTV xTerritory server tries to plan territories so that they are as compact as possible, allowing for a tolerance threshold (which must be specified) of the deviation of activity from absolute balance (0%).
"Difficult data layer": the less homogeneous the data layer (geographical spread of locations, activity distribution, multiple restrictions), the greater the tolerance needs to be in order to create territories which are as compact as possible without overlaps.
It is with low tolerance (<5%) and a difficult data layer that it may become impossible to find a solution.
As soon as a solution (planning response) is found within the specified tolerance threshold, no further attempts at improvement are made.
The choice of distance criteria is another important aspect of the planning. You can select distance 'as the crow flies' (ApproximateByDirectDistance) or by travel times (NewDistanceMatrixByRoad or ExistingDistanceMatrixByRoad). Planning on an 'as the crow flies' basis creates the most "attractive", compact and circular territories and is thus well suited to uses with a visual element. However, the results in areas with road networks that are not passable (e.g. due to rivers or mountains) can create territories that are inaccessible to drivers. Planning on the basis of travel times requires a distance matrix for a predefined vehicle type and somehow tailors territories to the basic road network on the map. This also may result in territories that are long and narrow e.g. along motorways.
Aside from the digital map of the area in which the locations are found, a license is needed for the planTerritories method and for the desired number of territories and locations.
If high-performance routing networks are to be used, a license must also be obtained for these. Furthermore, the path to the Routing Network folder must be placed accordingly in conf/xterritory.properties.
To carry out territory planning on greenfield land, the following are necessary:
Locations
parametrisation for the calculation of stretches of route
Number of territories to be planned
Each location to be planned will be represented by an id and a coordinate.
Furthermore, an activity must be assigned for each location, since the aim of territory planning is to calculate territories which are as evenly balanced as possible. For simple activity measures the class AbsoluteActivity is used, of which the value contains a double value which is simply totalled for each territory during territory planning.
"locations": [
{
"id": "location1",
"coordinate": {
"point": {
"x": 6.166279,
"y": 49.629301
}
},
"activity": {
"$type": "AbsoluteActivity",
"value": 3.0
}
}
]
Since the location coordinates are in geodecimal format here, the coordinate format must also be specified in the request, in the CallerContext.
PTV xTerritory server offers several ways to calculate stretches of route:
ApproximateByDirectDistance)NewDistanceMatrixByRoad)ExistingDistanceMatrixByRoad and ApproximateByReferenceMatrix)The respective option will be chosen according to the DistanceCalculationOptions subclass that is instantiated.
Example for NewDistanceMatrixByRoad:
"distanceCalculationOptions": {
"$type": "NewDistanceMatrixByRoad"
}
The precise number of territories to be planned must be set in the PlanningOptions.
"planningOptions": {
"exactNumberOfTerritories": 2
}
complete JSON request
{
"locations": [
{
"id": "location1",
"coordinate": {
"point": {
"x": 6.166279,
"y": 49.629301
}
},
"activity": {
"$type": "AbsoluteActivity",
"value": 2.0
}
},
{
"id": "location2",
"coordinate": {
"point": {
"x": 6.105082,
"y": 49.640585
}
},
"activity": {
"$type": "AbsoluteActivity",
"value": 1.0
}
},
{
"id": "location3",
"coordinate": {
"point": {
"x": 6.059420,
"y": 49.585083
}
},
"activity": {
"$type": "AbsoluteActivity",
"value": 1.0
}
}
],
"distanceCalculationOptions": {
"$type": "NewDistanceMatrixByRoad"
},
"planningOptions": {
"exactNumberOfTerritories": 2
},
"callerContext": {
"properties": [
{
"key": "CoordFormat",
"value": "OG_GEODECIMAL"
}
]
}
}
The planned territories are listed under territories in the PTV xTerritory server's response and contain, among other things, an id and a referencePoint (territory center), along with the ids of locations which are assigned to them.
"territories": [
{
"id": "1",
"referencePoint": {
"$type": "Point",
"point": {
"$type": "PlainPoint",
"x": 6.1050618437,
"y": 49.64057301
}
},
"summary": {
"totalActivity": 2,
"numberOfLocations": 2
},
"locationIds": [
"location2",
"location3"
]
}
]
If a distance matrix has been calculated or expanded in the request (NewDistanceMatrixByRoad or ExistingDistanceMatrixByRoad) a DistanceMatrixSummary element is included in the response. Among other things, it provides the id for the distance matrix, which can be entered in the ExistingDistanceMatrixByRoad element in any further requests, in order to reuse the distance matrix which had just been calculated.
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint
