The routing based method is the standard use case using the PTV xDima Server. All start and destination locations have to be included in the distance matrix. In case there is no distance matrix, a new one has to be created.
For a new distance matrix, a unique ID has to be assigned. All other methods refer to this ID. For creating a new distance matrix, the following parameters are available:
Vehicle type (CAR or TRUCK and therefore the corresponding ini-files dimaCar.ini and dimaTruck.ini)
Coordinate format (Mercator, WGS84, …)
Speed profile (16 values describe the minimum and maximum speed of 8 road classes)
Weight between the fastest and the shortest route
Preference and avoidance of map attributes (e.g. highways, toll roads or ferries)
Exclusive or banned country selection
For technical reasons, the maximum number of distance matrices is limited to 1000. They are stored in the <PTV xDima folder>/data/dima. Please note that the distance table itself is not calculated in this but rather in the next step. So only an empty wrapper is created.
For calculating the distance table, all relevant locations have to be transferred. The list consists of pairs with x and y coordinates referring to the defined coordinate format. If there is already a distance table available, only the locations not included so far are added (see chapter 2.6). Please note that the PTV xDima Server expects coordinates and does not geocode addresses. For this task, you have to use the PTV xLocate Server.
Now there are routing calculations between all locations considering the chosen parameters in the creating step (see chapter 2.1.1). As a result, there is a distance matrix stored on the hard disk containing for each location pair the distance in meters and the driving period in seconds.
During the calculation, this distance matrix is locked for all other requests. Please note that it is possible to calculate more than one distance matrix at the same time (of course with other IDs).
| Location 1 (X,Y) | Location 2 (X,Y) | Location 3 (X,Y) | ... | |
| Location 1 (X,Y) | 0/0 | [m]/[sec] | [m]/[sec] | [m]/[sec] |
| Location 2 (X,Y) | [m]/[sec] | 0/0 | [m]/[sec] | [m]/[sec] |
| Location 3 (X,Y) | [m]/[sec] | [m]/[sec] | 0/0 | [m]/[sec] |
| ... | [m]/[sec] | [m]/[sec] | [m]/[sec] | 0/0 |
Structure of a distance table
Currently the distance table is limited to 18918 different locations. One entry consists of six bytes (four bytes for the distance and two bytes for the driving period). For this reason, the maximum size of a distance table amounts to two gigabytes (= six bytes * 18918 * 18918).
As you can see, the distance matrix contains no route description and so the PTV xDima Server does not deliver this information as a result.
As the calculation of the routings, particularly between many locations, could be time-consuming, controlling the calculation progress is recommended. The range of the progress value is between 0 and 1000 and could be used e.g. to display a progress bar on the client side. Moreover, the calculation could be aborted by the client.
There are two ways to request the calculation progress:
You can use the service method getCalculationProgress(). In this case, there is at least one free backend instance necessary.
You can request a web page with all progress data displayed in the status monitor. To do this, you have to use the TransactionId of the caller context. This is the recommended option.
In order to get the single distances and driving periods from the distance matrix, you have to transfer the corresponding location pairs. For the routing based method, the mode ROAD has to be selected. If the locations are part of the already calculated distance matrix, you get the distances in meters and the driving period in seconds for each location pair. Now no routing calculations are necessary and so the response time is very short.
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint
