result difference between xRoute and xTour

[i.kobeissy]

Hello,

we noticed a difference between the time/distance between xRoute and xTour, both are 1.28 version and using the same profile (attached), and attached both request and response, is it possible please to guide me what we are doing and what would cause this difference

thanks in advance

[Bernd Welter]

Hello Ibrahim,

this is a very good question and the answer is not really obvious but requires some insights into the core algorithmic. Let me try to explain this effect on a more generic level:
"I use two different environments to calculate KPI's based on routing and the results differ in driving distances or periods. Why?" So typically the next question that arises from this complex topic is "How can we ensure that the routing results are equal on both environments?". That's tricky. Well, if one or more of the following settings of the to environments differ this could cause the gaps described above:

• Core map data provider(e.g. HERE or TOMTOM)
• Map version (e.g. 2020.1 vs 2020.2)
• Effective routing profile
• Routing engine (e.g. xRoute 1.20 vs xRoute 1.28)
• Routing algorithm (e.g. 1:1 routing vs 1:N routing)
• High Performance Routing status (enabled vs disabled)

While the first bullets in the list are more or less ovious I'd like to go a bit more in details about the algorithm and HPR status: In both terms the temporary data structures that are generated may differ due to the way the routing problem is "seen" by the algorithm itself. Please check the term LEVELING, too.

• 1:1 vs 1:N (aka "one to one routing vs one to many"): if leveling is enabled both approaches reduce the street network to segments that have a.) "a high priority (highways, major roads)" or b.) that have a "low priority and are within a certain range around a waypoint". Especially tour optimization is based on distance matrix routing (which is a n times 1:N routing) and produces a detailed network around all the N involved stations. Some of those local networks could interfere while computing the route for a decent cell.
• HPR: if HPR is activated the process of routing is split in the pre-processing of the search graph and the succeeding routing based on the graph. One implicit characteristics of a search graph based routing is "leveling is disabled". Which means: comparing a CONVENTIONAL routing (by default leveling is activated) with a HPR routing (leveling disabled) once more produces different data structures.

While the upper bullets rely on an administrator task ("keep the environment up2date" both in terms of engines and data - strictly recommended) the later ones have to be handeled (or understood) by the programmer and user: YOU.
The following advice may help:
If possible use HIGH PERFORMANCE ROUTING on both environments and in both modules/algorithms (1:1 vs 1:N). This will have the following effects:

• Leveling is disabled and the routing itself can be treated as exact (remember: leveling is a heuristic and therefore not exact)
• Results of 1:1 and 1:N will be equal
• The sequence of 1:N calls that create and extend a DIMA is no longer relevant (probably a questions you didn't recognize so far)
• For larger "N" values the performance of a DIMA with HPR is much better
• For simple 1:1 routings the perfomance could decrease (due to the efforts of search graph handling

Well, this article is probably much longer than you expected and I still see potential of being incomplete. If more details and guidance are needed get in touch with your technical counterpart to discuss the solution that fits your requirements.

Best regards from Germany,
Bernd

[Joost]

Actually in your xRoute request you are setting multiple routing options that affect the Effective routing. The effective profile is the "de facto"" profile that is applied. It is created using settings from all applicable profiles in the following order, where each step overwrites values of the previous one:

1 default value specified in the profile XML schema
2 server profile referred to as parent of a server profile
3 server profile referred to in the request callerContext
4 profile snippet in the request callerContext
5 API parameters in the request

Documentation link: https://xserver.ptvgroup.com/fileadmin/ ... ofiles.htm

So have a look at the settings:

<ns7:RoutingOption parameter="OPTIMIZATION" value="90"/>
This maps to Routing / Course / @distanceTimeWeighting. You do not set this in the dimatruck so it defaults to 80.

<ns7:RoutingOption parameter="LOW_EMISSION_ZONE_TYPE" value="1"/>
This maps to Routing / Vehicle / Physical / Drive / Emissions / @lowEmissionZoneType . You do not set this in the dimatruck so it defaults to GREEN which is the same as using 1 in your routing option.

<ns7:RoutingOption parameter="AVOID_TOLLROADS" value="2501"/>
Routing / Course / BasicDataRules / Toll / @tollMalus . You have this set to 2501 in the dimatruck profile.

<ns7:RoutingOption parameter="AVOID_VIGNETTEROADS" value="2501"/>
Routing / Course / BasicDataRules / Toll / @vignetteMalus. You have this set to 0 in the dimatruck profile.

<ns7:RoutingOption parameter="AVOID_FERRIES" value="2500"/>
Routing / Course / BasicDataRules / CombinedTransport / @ferryMalus. You have this set to 100 in the dimatruck profile.

<ns7:RoutingOption parameter="AVOID_RESIDENTS_ONLY" value="2500"/>
Routing / Course / BasicDataRules / SpecialAreas / @residentialMalus . You have set this to 2500 in the dimatruck profile

<ns7:RoutingOption parameter="AVOID_RAMPS" value="10"/>
Routing / Course / BasicDataRules / Network / @rampMalus. You have this set to 10 in the dimatruck profile.

Other options are set to false and thus have no effect or do not effect the routing at all (ROUTE_LANGUAGE).

[i.kobeissy]

Great thanks a lot guys, great explanation from both of you,
i'll look into each point and try to unify my profiles and my requests and get back to you. in all cases this is enough for me to start with