Poznan is timeout city?

[d.zamysloff]

We have a problem calculating routes to Poznan (Poland). Our use case is as follows. In our software it is possible to select only cities without exact addresses for route calculation. The coordinates of the cities (city centres) we get from the public service. So we experience that route calculation from e.g. Hamburg to Poznan takes about one minute, which causes our services to timeout and break their SLAs. But the route calculation in the opposite direction takes only a few seconds. The same happens with any other city instead of Hamburg. Berlin-Poznan, Paris-Poznan - all route requests to Poznan take a long time. The response time for calculating the return journey is satisfactory. I have already created a ticket, but just want to share this experience. It might help if someone has the same problems.

We using REST client 2.30.
I have attached two json files with requests from Hamburg to Poznan and return journey.

[Bernd Welter]

Hello Dmitri,

my colleague Max performed some analysis and here's what he identified as the cause:

We can confirm the high runtime of the request in the direction from Hamburg to Poznan. The coordinate in Poznan is at a road with two closures:

• The first is a truck restriction for vehicles above 3.5 tonnes of weight which is always valid.
• The second is a traffic incident which says that there is a road closure until March 1st, 2024.

the inner city of Poznan in tewrms of "PTV_TruckAttributes"

Why does this relate to the runtime?
The route is violated because of these two restrictions because actually the destination cannot be reached. When routing from Poznan to Hamburg, then the algorithm already knows that it departs from a violated start and the violations do not lead to a longer runtime. It is already violated, so there is no need to try to find a way without violations.
However, in the other direction, that means routing from Hamburg to Poznan, the route start in Hamburg is not violated and hence when reaching Poznan the algorithm tries to find a way with the least amount of violations possible. This is the reason for the long runtime. Actually, there is some special handling in place to avoid such a big search space, because regardless of this location being start or destination, the algorithm knows which coordinates are violated and can therefore adapts its behaviour.
So this is a really unfortunate combination of data and algorithm. There is a threshold on the remaining duration of the road closures in PTV_TrafficIncidents for when it is either treated as a violation or the remaining duration is added to the traveltime. I suspect in this case the latter to be the case. This increases the search space a lot because with a driving time of almost 2 weeks you can drive very far.
Furthermore, the request makes use of PTV_TruckSpeedPatterns in combination with time consideration mode ExactTimeConsiderationAtStart. This means, that the speed information on a street is evaluated exactly for that moment when the vehicle would be there. This of course is the most precise but also the most expensive way. And unfortunately with increasing search space, this becomes even more expensive.
What can the customer do?
Try the parameter simplifiedRouteCalculation as part of ExactTimeConsiderationAtStart. This reduces the runtime in this case by about 50 % on the machine I tested the request with.
Try the parameter restrictionMode AUTOMATIC as part of searchSpaceBounds as part of geographicRestrictions on the routeOptions. This reduces the runtime by about 80 % on the machine I tested the request with.

[d.zamysloff]

Hi Bernd,

Thank you for your reply. I wonder how the parameters you mentioned affect the quality of the answer. If some would calculate the route, let us say without Poznan. You have seen our typical request. We want to get back route, country events, sometimes combined transport events, route report and toll report. How mentioned parameters will influence the answer. What would be the difference between a query without these parameters and one with them? Is there a loss of accuracy and precision? What can we expect? You have your specific tools and I hope this answer can be given by you more quickly than if we would do the research ourselves. Thanks in advance!

[Bernd Welter]

Here's some more feedback from Max:

Using the option 'simplifiedRouteCalculation' will simply not use the speed information from PTV_TruckSpeedPatterns during route calculation, so the static speed of the map data will be used. The speed information from PTV_TruckSpeedPatterns will then be applied after route calculation on the calculated route itinerary to get the most precise travel time for the given reference time and route.

Time-dependent truck attributes and traffic incidents are not at all impacted by this parameter.

You can also use the showcase "Calculate and Visualize Time Dependent Route Metrics" to see the impact of using speed patterns during route calculation. Although the optimistic route uses the best speeds of PTV_TruckSpeedPatterns which is not the same as static speeds of the map data.

The parameter restrictionMode=AUTOMATIC restricts geographically in which area the route calculation may take place. Basically as soon as the route calculation reached a certain proximity to the destination, it may only look for a route within a certain radius around the destination. This could lead to non-optimal routes especially in sparse areas.
Non-optimal in this case means a violated route even though a non-violated route with a big detour might exist. Or in a similar way a route that is shorter in distance but higher in traveltime than the optimal.
In both cases the optimal route would have been cutoff by the geographic restriction. Both cases shouldn't appear very often as the radius is adaptive to the input coordinates.