Symptom
xRoute returns two significantly different routes when only a single vehicle parameter (height or weight) is modified, even though no constraint violation is reported in either calculation.
Examples observed at Capelle Transports:
- Height 4.61 m → long route (1,274 km, 20h21) via western France
- Height 4.70 m → direct route (739 km, 12h43) via the central corridor
- Weight 3 t → different route than 4 t for the same short trip (6–7 km)
In both cases:
- No
ROUTE_VIOLATION_EVENTis returned. - The routing engine does not report any errors or anomalies.
Typical customer reaction:
"If a vehicle can travel at 4.70 m, it should also be able to travel at 4.61 m. Why does the route change?"
Cause
Primary cause – Search space restrictions exclude preferred network segments
The request contains an excludeByNetworkClass configuration that defines minimum distances (in meters) below which specific network classes are excluded from routing calculations:
"minimumDistancesFromWaypoint": [
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
50,
20,
10,
10
]
When segments belonging to CUSTOM_ROAD_CLASS_5 (used through preferredRouteTypes) are physically stored as networkClass 4 in the PTV routing graph, the value 50 may silently exclude those preferred segments from the search space.
The routing engine does not return an error. It simply performs the optimization on a reduced routing graph.
Depending on the declared vehicle height or weight, the set of available alternatives may change, which can shift the global optimum toward a completely different routing strategy.
Secondary cause – Routing optimization is not monotonic
The routing engine does not search for any feasible route. It searches for the globally optimal route according to all configured costs, penalties, restrictions, and preferences.
This optimization process is not monotonic:
- Fewer restrictions do not necessarily produce the same route with additional options.
- A change in vehicle height or weight may enable or disable strategically important segments.
- Network penalties,
PTV_TruckAttributes, and custom feature layers such asCFL_Hauteurcan strongly influence the optimization. - When a key segment disappears from the routable graph, the engine recalculates the entire route. The resulting optimum may be substantially different from the previous one.
Resolution
Step 1 – Analyze the routing request
Verify the consistency between:
- preferredRouteTypes
- searchSpace
If the customer uses: "preferredRouteTypes": ["CUSTOM_ROAD_CLASS_X"]
identify the network class in which those segments are physically stored and compare it with the configured minimumDistancesFromWaypoint values.
A restrictive value may silently exclude preferred segments.
Step 2 – Request detailed segment information
Enable segment output in the route result:
"segments": {
"enabled": true
}
Compare the returned segments before and after the parameter change.
This helps identify:
- where the routes diverge,
- which network classes are involved,
- and which segment attributes influence the optimization.
Step 3 – Adjust the search space configuration
If CUSTOM_ROAD_CLASS_5 segments belong to networkClass 4, consider changing the corresponding search space value to UNBOUNDED.
Before:
"minimumDistancesFromWaypoint": [
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
50,
20,
10,
10
]
After:
"minimumDistancesFromWaypoint": [
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
UNBOUNDED,
20,
10,
10
]
Note: Expanding the search space may increase calculation times and affect routing performance.
In the Capelle Transports case, this adjustment was applied only to the categorized routing mode, while the conventional mode retained the more restrictive search space settings.
Step 4 – Explain routing non-monotonicity to the customer
Recommended customer explanation:
The routing engine does not search for any possible route. It searches for the globally optimal route according to all configured restrictions, penalties, and preferences. A change in vehicle height or weight may remove a strategically important segment from the routable network, forcing a complete recalculation. As a result, the new optimal route can be significantly different from the previous one, even though no routing error or violation is reported.
Related articles
PTV xServer: HPR created successfully via API but does not appear in the HPR list
PTV xServer: ADR tunnel restrictions not applied in planTours when using ExistingDistanceMatrix
PTV xServer 2: Height Violations Disappear or Route Changes When Adding a Waypoint
PTV xServer 2: RouteNotFoundFault when using truck profiles with PTV_TruckAttributes enabled