xRoute distanceTimeWeighting Problem

[mobi]

Hi,
we've got following problem:
We would like to calculate the fastest and the shortest route between two coordinates. To do that we are using the parameter "distanceTimeWeighting" (100 = fastest; 0 = shortest).
We are using following penalties:

Code: Select all

"penalties": [0, 20, 30, 35, 40, 90, 100, 100]

which is the default for the "truck11_99t" profile.

Our example waypoints are:

Code: Select all

"waypoints": [
    {
      "$type": "OffRoadWaypoint",
      "location": {
        "offRoadCoordinate": {
          "x": 9.94179,
          "y": 50.93384
        }
      }
    },
    {
      "$type": "OffRoadWaypoint",
      "location": {
        "offRoadCoordinate": {
          "x": 9.9040498475,
          "y": 51.530239138
        }
      }
    }
  ],

For this route we are getting following result:
shortest route: 85750 m in 5858.583 s fastest route: 132450 m in 6446.185 s

The duration of the fastest route is bigger then the duration of the shortest route.

If we set all the penalties to 0, then we get a result where the duration of fastest route is smaller than the shortest.
But we are trying to get a route information for trucks, so I think the penalties are important.

Is that a bug?

[Joost]

EDIT: i initially read your question wrong. The post I made was not applicable to your issue.

[Bernd Welter]

Hello Michael,

this is not a bug but requires some more background info.
I can understand that the expectation of a value of "100" is the absolute fastest route.

But: the "distanceTimeWeight" (formerly known as "the OPTIMIZATION") is just one out of a set of parameters that influence the metric on segments.

You already mentioned some other relevant values : the penalties on the network classes.

And let me add a third group of params: the speed values. Usually you'd expect that a detour at a higher speed at least has some potential to find a global minimum of traveltime.

So imagine to apply a metric based on these three (and more) dimensions on the "100%" route below producing a total "metric cost" of XXX. The route we returned in thsi case is the one which minimizes this metric.
In other words: If you apply the same metric on any other possible geometry this alternative metric would not be better than XXX.

If you want to get rid of this behaviour you have to remove the "penalties" from the NCs as I did below.

I recommend to return to your assigned technical consultant to discuss this in detail - probably better than trying to fix this via texting.

Best regards,
Bernd

[mobi]

Thx Joost and Bernd for your quick answers.
Yes, I understand that the speed values have a lot of influences. It makes sense that if the route is calculated for a car that the quicker route is via A7.
For the speed values I take the default values in 'truck11_99t'. I also use 'PTV_TruckAttributes' as theme.

I dont not understand why the penalties (default ones of truck11_99t: [0, 20, 30, 35, 40, 90, 100, 100]) do influence the route for distanceTimeWeighting = 100 and not for values below ~80.
I thought the route is punished the same way (not depending on distanceTimeWeighting).
So for example if the direct route in my example is bad because of the penalties -> for both values of distanceTimeWeighting the result route should be via a7.

@Joost: I tried distanceTimeWeighting = 65. I got kind of the same route as for distanceTimeWeighting = 0. It is also quicker then the distanceTimeWeighting = 100 route (via A7). I dont get any violations of the route. I could not find any details in the API for "aStarAggressiveness". (We are using PTV2).

Do you have a recommendation how we can get the shortest and the fastes route. It doesnt have to be the global minumum, but the fastest route should be not slower than the shortest.

My full request including the json which I used for this example in Integration Samples/Calculating the Shortest or the Fastest Route is:

Code: Select all

var A = {
    "$type": "OffRoadWaypoint",
    "location": {
        "offRoadCoordinate": {
            "x": 9.94179,
            "y": 50.93384
        }
    }
};

var B = {
    "$type": "OffRoadWaypoint",
    "location": {
        "offRoadCoordinate": {
            "x": 9.9040498475,
            "y": 51.530239138
        }
    }
};

var map = new L.Map('map', {
    center: [49.61, 6.125],
    zoom: 13
});

// Add tile layer to map
var tileUrl = xServerUrl + '/services/rest/XMap/tile/{z}/{x}/{y}';
var tileLayer = new L.TileLayer(tileUrl, {
    minZoom: 3,
    maxZoom: 18,
    noWrap: true
}).addTo(map);

var outputString = '';

function calculateSpecificRoute(dtw) {
    xroute.calculateRoute({
        "waypoints": [A, B],
        "resultFields": {
            "polyline": true
        },
        "requestProfile": {
          "featureLayerProfile": {
              "themes": [{
                  "enabled": true,
                  "id": "PTV_TruckAttributes"
              }]
          },
            "routingProfile": {
                "searchSpace": {
                    "heuristicAggressiveness": 0,
                },
                "course": {
                    "distanceTimeWeighting": dtw,
                "violations": {
                    "enabled": false
               	 },
                    "network": {
                        "rampPenalty": 0,
                      	//taken from the default
                        //"penaltiesByNetworkClass": {
                        //    "penalties": [0, 0, 0, 0, 40, 90, 100, 100]
                        //}
                    },
                    "maneuver": {
                        "uTurnCost": 0
                    }
                }
            }
        },
        "geometryOptions": {
            "responseGeometryTypes": ["GEOJSON"]
        },
      "storedProfile": 'truck11_99t'
    }, function(route, exception) {
        var geoJson = route.polyline.geoJSON;
        if (dtw < 70) {
            displayGeoJson(geoJson, '#ffa225');
            outputString += 'shortest route: ' + route.distance + ' m  in ' + route.travelTime + ' s   violated:' + route.violated + ' ';
        } else {
            displayGeoJson(geoJson, '#2882C8');
            outputString += '|fastest route: ' + route.distance + ' m  in ' + route.travelTime + ' s   violated:' + route.violated + ' ';
        }
        print(outputString);
    });
}

function displayGeoJson(geoJson, color) {
    var jsonObject = JSON.parse(geoJson);
    var geoJsonLayer = new L.GeoJSON(jsonObject, {
        style: {
            color: color,
            weight: 8
        }
    }).addTo(map);
    map.fitBounds(geoJsonLayer.getBounds());
};

calculateSpecificRoute(65);
calculateSpecificRoute(100);

[Joost]

@Joost: I tried distanceTimeWeighting = 65. I got kind of the same route as for distanceTimeWeighting = 0. It is also quicker then the distanceTimeWeighting = 100 route (via A7). I dont get any violations of the route. I could not find any details in the API for "aStarAggressiveness". (We are using PTV2).

I read your message wrong so the information i gave was incorrect, hence i removed it. I was under the impression that you where using xServer 1 , but you are using xServer 2. Things are a little bit differently structured in xServer 2.

[Bernd Welter]

Hi Mobi, Joost,

I am already in touch with the tech team in the headquarter. We will check who will return to you 1:1.
From my perspective it is just the superpositioning of many, many factors at the same time which makes it hard to understand that there's no bug.

And by the way:
the attached screenshot displays the two routes with
- TruckAttributes being considered (violations disabled)
- Stored Profile = 11.99t truck
- penalties disabled through the request

shortest track is shortest, fastest ist fastest,
no conflict
Just two local detours (red lines)

Looks good, doesn't it? I saw the strange conflict while the penalties have been enabled.
But if I remove their effect by setting them all to 0 the result is as you'd expect it.

Best regards,
Bernd

[Joost]

Looking properly at it I can explain the effect.

So we have the route that take the highway around which is 132450 m in 6446.185 s driving time. Let's call this one the outer route. And we have the direct route on trunk roads which is 85750 m in 5858.583 s. Let's call this one the inner route. The inner route is not strictly on trunk roads only (for example take a bit of highway at the end) but for simplicity let's pretend that it is only taking trunk roads. Also let's pretend the outer route only takes highway. The avoidance on trunk roads is 30 with the default values. So let's do the math on how our engine will evaluate both options under different value of distanceTimeWeigthing.

• So for 0 (pure distance) our engine will compare 132450 again 85750 * 1.3 = 111475. 111475 is the lowest so the inner route wins and is being returned.
• For 100 (pure time) our engine will compare 6446.185 s against 5858.583 * 1.3 = 7616.1579. 6446.185 is lower so the outer router wins and is being returned.

So i would explain your problem as:
The distanceTimeWeigthing is a weighting in the algorithm, it is not the goal of the algorithm. It is not there to force the shortest or fastest route, it is there to tell the engine when looking for the best route how much value it should actually attach to both the properties when evaluating route. Most of the time change in the distanceTimeWeigthing will line up if it was threated as the "distanceTimeGoal", but not always.

As for the avoidance:
We put avoidance on certain road types for our profile since we know that driving a route isn't always accelerate at the start, activate cruise control , and break at the end of the route. If there are for example traffic lights it means an extra stop and start witch costs fuel and wear and tear on the engine in compared to driving on cruis control. Als smaller roads are more likely to have inclines and sharp turns which again cost more energy and engine wear and tear to take.

So when comparing the outer route to the inner route it is not as simple as saying 132450 m in 6446.185 s vs 85750 m in 5858.583 s. In reality it is comparing 132450 m in 6446.185 s vs 85750 m in 5858.583 s with (for example) 5 traffic lights, 12 sharp turns and 7 steep inclines. To prevent the algorithm from being to overly complicated with simplify this to 132450 m in 6446.185 s vs 85750 m in 5858.583 s with "30% extra penalty to take into account all the situation that cause extra energy use and extra wear and tear"

I hope this clarifies it a bit for you.

[mobi]

Yes thanks, that makes sense.

Are the set of penalties in the profiles trustworthy or just an idea what could happen in the worst case? It makes sense to use them and leave them like in the profile?

There is no possiblity to get a final distance + duration with the punishment of each route segment? That would be clearify my result a lot.

In your experience what parameters could be a good choice to get two possible routes depending on distance and duration without getting to unrealistic (they dont have to differ, but maybe they do).
distanceTimeWeigthing = 60 for the distance one and distanceTimeWeigthing = 90 for the duration one?
Surely it doesnt fit all routes, but thats ok.

[Joost]

Are the set of penalties in the profiles trustworthy or just an idea what could happen in the worst case?

Our penalties as calibrated for our default profiles. Because time scale differently on roads then distance (you are no allowed to drive as hard on a highway then on a trunk road for example) you could argue that with different distanceTimeWeighting you should be using different penalties. In my experience if you do not go to extreme values of distanceTimeWeighting the standard hold up. With extreme values i mean close to 0 or close to 100.

distanceTimeWeigthing = 60 for the distance one and distanceTimeWeigthing = 90 for the duration one

These seem ok. Most of the time for fastest I stick to our default profile which have a weighting of 80 to get the best calibrated result. For shortest I drop down to 65. 60 overall gives still nice routes, but there a some cases where IMO the routes goes a little bit to much on roads that truck should stay avoid.

[mobi]

Perfect.

One last question: Is there a way to get also the duration/distance after the penalty?

So in your example:
111475m and 6446s for the inner route.

Ideal would be the "real" distance/duration and the one after the penalty.