I recently faced several players who wanted to compute distance matrices / routings in xServer Internet 2 (test / prod) as quick as possible and who therefore parametrized their calls with the routing mode with an insufficient request like this one:
Code: Select all
{
"startLocations": [
....
],
"destinationLocations": [],
"storedProfile": "car",
"distanceMatrixOptions": {
"routingType": "HIGH_PERFORMANCE_ROUTING_WITH_FALLBACK_CONVENTIONAL"
}
}
Please take some time to understand the following mechanism:
- Using that routing type tells the engine to look for a matching search graph: If the search is successful, the routing applies the HPR. If the search fails, the engine performs a fallback to CONVENTIONAL routing which is compareably slow.
- Now many users are aware that we have standard graphs, e.g. for a car profile.
- But what you need to understand is that ALL routing options have to match the graph and when we offer a "ZZ-EUR car with truck attributes" graph this means that the request above would need two inserts:
- The feature layer theme PTV_TruckAttributes has to be added and enabled.
- The geographic restriction to ZZ-EUR needs to be added.
Code: Select all
{
"startLocations": [
....
],
"destinationLocations": [],
"storedProfile": "car",
"requestProfile":{
"featureLayerProfile":
{
"themes":[
{
"id":"PTV_TruckAttributes",
"enabled": true
}
]
}
},
"distanceMatrixOptions": {
"routingType": "HIGH_PERFORMANCE_ROUTING_WITH_FALLBACK_CONVENTIONAL",
"geographicRestrictions":{
"allowedCountries": ["ZZ-EUR"]
}
}
}
Bernd