Symptom

When calling planTours with a tunnelRestrictionCode (e.g. "B") set in the vehicleProfile, the resulting tour plan includes route segments that violate ADR tunnel restrictions. The response contains:
"routeViolated": true

This confirms that ADR violations are detected, but the route is not recalculated to avoid the restricted tunnels.

Cause

The planTours request is configured with:
"distanceMode": {
 "$type": "ExistingDistanceMatrix",
 "id": "<matrix-id>"
}

When using ExistingDistanceMatrix mode, planTours reuses pre-computed distances and travel costs from the matrix. It does NOT call the routing engine dynamically. As a result:
•    The tunnelRestrictionCode passed in the planTours vehicleProfile has no effect on the pre-computed routes.
•    ADR violations can only be detected a posteriori (flagged as routeViolated: true), but no alternative route is computed.
•    Even with PTV_TruckAttributes feature layer enabled in planTours, the matrix data is already fixed and cannot be changed at request time.

This is expected behavior by design in xServer 2. The ExistingDistanceMatrix mode is optimized for performance and does not support dynamic routing constraints

Resolution

Option 1 – Embed ADR constraints in the HPR and regenerate the matrix (recommended for fixed vehicle configurations)

Include both the PTV_TruckAttributes feature layer and the tunnelRestrictionCode in the HPR creation request:
"requestProfile": {
 "featureLayerProfile": {
   "themes": [
     {
       "id": "PTV_TruckAttributes",
       "enabled": true
     }
   ]
 },
 "vehicleProfile": {
   "load": {
     "tunnelRestrictionCode": "B"
   }
 }
}

Then regenerate the Distance Matrix from this HPR. When planTours is called with ExistingDistanceMatrix, the vehicle profile is inherited entirely from the HPR – no profile needs to be declared in planTours.

Important limitation: this approach bakes the ADR restriction statically into all routes using this matrix. If the vehicle delivers its hazardous goods mid-tour and is no longer restricted, the matrix will still apply the restriction for all subsequent legs. See KB-002 for handling dynamic vehicle state changes.
 

Option 2 – Use xRoute with VehicleParametersAtWaypoint for post-optimization recalculation

After a planTours optimization, individual trips can be recalculated using xRoute with the VehicleParametersAtWaypoint parameter. This allows modifying vehicle properties (including load/ADR restrictions) at each waypoint, reflecting the actual vehicle state at each stop.

Recommended workflow:

1. Run planTours with a conservative (most restrictive) vehicle configuration to generate a feasible tour plan.
2. For legs where the vehicle state changes (e.g. hazardous goods delivered), recalculate using xRoute.
3. In the xRoute call, apply VehicleParametersAtWaypoint to modify tunnelRestrictionCode at the relevant 

Option 3 – Use the conservative (most restrictive) profile as a safe default

If dynamic recalculation is not required, build the HPR and Distance Matrix using the most restrictive vehicle configuration (i.e. with all ADR constraints active). This ensures all generated tours are feasible regardless of actual load state. Some legs may be sub-optimal when the vehicle is not actually carrying hazardous goods, but all tours will be executable.

Related articles

PTV xServer : Route divergence after changing vehicle parameters (height, weight) 

PTV xServer: HPR created successfully via API but does not appear in the HPR list