Some thoughts about "alternative routes"

[Bernd Welter]

These days a partner asked me for the meaning of alternative routes. I just want to share some thoughts with you - feel free to think yourself through the topic and get back to me if you have questions.

Built in alternative routes

So basically "alternatives" are required for different purposes:

• A user wants to compare different approaches based on different input settings
• illusion of choice you want to enable a user to pick something by himself based on whatever criteria applies

For the first approach you could e.g. compute three "alternatives" based on three times different setttings for

• 3 vehicle profiles
  • small / medium / large truck
  • truck uses ferries without special handling / truck avoids ferries / truck does not use ferries at all
• 3 times of departure
• 3 tarrifs for "price per kilometer"
• or any other variability

Each one of these triplets produces KPIs that the user would use for a decision. This is an easy way to get the alternatives and the meaning of the alternatives is given by the user. It requires three individual routing calls and it works both with ABSTRACT and MONETARY cost optimized routing.

Besides these approaches the ABSTRACT approach also offers a built-in mechanism for "alternative routing". As you may know the abstract approach computes the "price" of a segment based on a virtual tarrif scheme which is influenced by many (often quite confusing) malus values and the "optimal route" is the route that minimizes the abstract costs.
Now computing alternatives based on ABSTRACT simply means to proceed as follows:

• Compute the base route aka zero alternative
• then increase the price for all segments of the zero route and calculate the first alternative
• then increase the price for the 1st alternatives segments, too - and so on.

We support this approach with a built-in calculation triggered by ResultFields.AlternativeRoutes and instead of several individual routing transactions a single call is sufficient. The route response will then return the zero route with all it's KPIs and toll and segment lists (both if needed).
And for all the AlternativeRoute computed under the roof we simply return the driving time, distance, polygon and the binary path which can be used to quickly recalculate the complete route object for an alternative if needed. Check the PathWaypoint! This approach works only with pure A:B routing with 2 stops. As it is based on "abstract" costs (which are no longer returned in the xRoute2) it is often difficult for the user to understand the meaning of such alternatives.

If you want more info - get back to me.

Best regards,
Bernd

[Guillaume Vallin]

Hi Bernd,

A custoomer asked us to calculate "alternative" routes with more than 2 waypoints.

It is a common situation for hauliers if we integrate driver's current location or driver's home in the route.

From my understanding we would have to calculate let's say 3 routes with 3 different calls, changing options within every call.

What I am wondering concerns the correct options to change. I see the MONETARY vs ABSTRACT method, I would imagine a second one with "no toll" and also a last one with SHORT / FAST. But i'd like to stick to our internal logic of "alternative" so that we generate different routes dued to these options (e.g : not always the case with SHORT/FAST, it can provide the same route in many cases).

Any idea ?

Thanks

[Bernd Welter]

Well, in fact my proposed approach with three different settings has a weakness: it does not guarantee that the alternative geometries differ from the 0-alternative at all as it is based on independent routings where the succeeding call is not based on the previous one at all.

I forwarded the topic to some colleagues of the routing engine. Maybe they can propose some workaround for xServer2. But the first response was "completely different approach in xServer2"...