RouteCalculationCriteria: difference between ABSTRACT_COSTS and MONETARY COSTS

[Bernd Welter]

Hi there,

many customers are comparing the well known MAP&GUIDE Internet routes (based on HERE and xServer1) with their results gathered trough PTV xServer2 and PTV Developer (check this concept, too):

Hi, whats or why the difference between Map&Guide and monetary settings? What it offeres different route in our planner? Can you pls. check it a/o explain?

Let me collect some info about this MONETARY approach we invented in PTV xServer2 in 2020...

• Routing in general:
  • In the context of a routing each road segment has a price which is usually determined based on a combination of segment and vehicle properties. That's why we offer more than 100 parameters to control the routing calculation.
  • The "best route from A to B" is a connected set (path) of segments that links the two waypoints and that minimizes the "aggregated costs" of the involved segments.
  So far - so good. Now let's get closer to the APIs:
• ABSTRACT : In PTV Map&Guide Internet and PTV xServer1 the only routing mode was the abstract one. All segment prices are based on a virtual cost metric that applies several percentage bonus/malus values to add/reduce the virtual costs of segments as some kind of weak or strong preferences / avoidances. This approach has several disadvantages:
  • It is complicated. We often had discussions with users about the proper malus values. Or they told us "the result was fine with a malus of xx% - but can you explain why?" - and we couldn't.
  • It does not consider the segment's real toll prices at calculation time. With this abstract approach the toll is determined in a post processing step.
• MONETARY : Now with the new monetary approach the segment's price is now derived from real fiscal values and these costs are used during the calculation of the optimal (cheapest) path:
  • Price per working hour
  • Price per distance
  • Toll price
  • Price per "fuel/energy" consumption
• Also relevant to consider
  • As we do not know the prices of ferries you would have to add ferries manually into the waypoints list
  • MONETARY does not support ALTERNATIVE ROUTES. You may send different tarrif settings instead.
  • It might be necessary to combine the monetary approach with geographic restrictions, e.g. if you want to avoid a delay at the Swiss customs which sometimes causes detours around Switzerland (but within the EU) to be cheaper.

    

    BLUE and GREEN are driving through Switzerland but they do not consider waiting times at customs. The purple (Abstract) and cyan (Monetary) routes are applying the geographic restriction ForbiddenCountries=["CH"] to enforce the detours which are cheaper from a dispatchers experience.

[danper]

Hi Bernd,

Just one note from my side about monetary cost optimization.

To calculate a route with minimal total monetary cost, it is used a tradeoff between the toll costs on the one hand and the distance, time, and fuel/energy costs on the other hand.

I had experience with customer that would optimize just by toll costs: be aware that at least one of the factors cost per kilometer or cost per hour must be set otherwise you obtain exception; using fake costs bring the algorithm to run not in a proper manner, or better to say, it give back to you not expected result.
In general, the more real are the inserted costs, the better will be the answer;
see different concept of routing algorithm MONETARY, as you already posted.
Even if you want to optimize just by toll costs, because of the different criteria used (see concept), you need to add also cost for hours, to reduce the time duration in the routing selection by algorithm, and also cost per Km and per fuel to reduce the length.
An example Lyon (FR) to Erfurt (DE):

Case 1:
Price per working hour................. = 20,5 €
Price per distance...................... = 1,2 €
Price per "fuel/energy" consumption = 1,9 €

In this case the result is a tradeoff and the returned route is more feasible by the driver saving around 100 € of toll costs and 30 Km of route but using around 1h 35m more than the standard.


Case 2: remove all the cost you mentioned and maintain just one between cost per kilometer and cost per hour, to avoid exception

Price per working hour = 0 €
Price per distance = 1,2 €
Price per "fuel/energy" consumption= 0 €

in this case the differences are much more marked: the route duration in time is too high, using 8h more than the standard and use minor Network class. Sure, the toll cost is drammatically decrease but the routing is not a real case.