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_EVENT is 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 as CFL_Hauteur can 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: Large distance differences between GPS mileage and xRoute route reconstruction for toll calculation 

PTV xServer 2: RouteNotFoundFault when using truck profiles with PTV_TruckAttributes enabled