xTour and SpeedPatterns

[Acteos_1]

Hello,

We now know that it’s not possible to use SpeedPatterns for tour optimization on multiple points with xTour.

However, we understood that it’s possible to use xTour with SpeedPatterns only between 2 points.

1. We tried to test but it seems it doesn’t work as expected because we had the same time with xTour regardless of the departure times.

Here are the results of our tests :
We took 2 points from A to B.
A --> (258137.0, 4860375.0)
B --> (220537.0, 4898950.0)

xTour :
• without SpeedPatterns : 7933 seconds
• with SpeedPatterns, starting at 8am : 8016 seconds
• with SpeedPatterns, starting at 11pm : 8016 seconds

2. Moreover, the times compared to those we got using xRoute are differents

For the same two points, here’s the results we got with xRoute :
• with SpeedPatterns, starting at 8am : 4263 seconds
• with SpeedPatterns, starting at 11pm : 3439 seconds

Maybe the difference between xTour and xRoute is due to the used profiles but the main problem for us is the first point.
• The times we’ve got with or without SpeedPatterns are too close (1%)
• The times are the same regardless of the departure time

Could you please tell us if our request to xTour is fine, if not what it has to be?

Request.zip

xTour Request

(2.36 KiB) Downloaded 349 times

And if it is really not at all possible to use SpeedPatterns with xTour, could you please update the technical support material?

Thanks in advance

Yann LEFORT

[Bernd Welter]

Hello Yann,

from my understanding the tour response deals with a double directions:

• Depot
• A (which is equal to depot)
• B
• Depot

Furthermore you apply a driving period factor = 0.8.
Sounds like we have to corret the 8000 seconds to 8000 / 2 / 0.8 = about 5000 seconds.

Furthermore I used the snippet to play with xRoute: I get amlost equal seconds for 8am / 11mp with a carfast but the tour request deals with the default profile which is using dimaTruck as a base (explains why we face something around 5000 seconds).

I assum that both tour requests with speed patterns refer to the same base time. How did you try to specify departure time that should be used in the dustance matrix computation?

More generically spoken:
Applying time dependency in a distance matrix doesn't make that sense as a dima is some kind of a SNAPSHOT in time but xTour would require lot of various distance matrices to reflect all the possible permutations (or at least to approximate them).

But: you are right: in a context of a 1:1 routing as it is processed with xroute it makes sense to apply time dependency. And there it seems to work fine.

Best regards Bernd

[Acteos_1]

Hello,

Thanks for your detailed answer.

Actually it's not the starting date we specified but the arrival times at the transport point B.
Here's what we did.

We made the first request with no limiting contraints (opening intevals of transport point A, opening intervals of vehicule...).
We just specified the opening intervals of the transport point B to :
17/10/2016 08:00:00 to 17/10/2016 10:00:00 (Monday)
This way, the trip started at 17/10/2016 06:53:06 (from point A) and arrived to the transport point B at 08:00:00.

And then, we made the second request with also not limiting contraints except for the opening intervals of transport B to :
Sunday : 16/10/2016 23:00:00 to Monday : 17/10/2016 00:00:00
This way, the trip started at 16/10/2016 21:53:06 (from point A) and arrived to the transport point B at 23:00:00.

We can see that the trips took the same time in both cases.

Here are the resquests we used :

Requests.zip

(4.7 KiB) Downloaded 321 times

So, are we missing something in our requests?

Also we noticed a parameter named enableTimeDependency in the generated file RoutingProfile.xml (in the folder corresponding to the DIMA) and it was set to false. May this parameter be preventing xTour from applying traffic patterns? If yes what should we change in our resquest to let xTour set this parameter to "true" when generating the file?

Thanks for your time,

Yann LEFORT.

[Bernd Welter]

Hello Yann,

I downloaded and compared your requests and I can confirm that the only difference between the requests are some time intervals. In both requests the distance matrices are deleted before the planning.

This also means that in both cases the distance matrices content is equal because the "reference time" of the dima isn't set.

From my point of view both plannings have to return with equal structures (incl. distances and periods) as there is only one "end" of the trip attached to an interval.

Now pleased check the following statements:

• I recommend that you check the validity of the routing profile by using a single AB-routing with xRoute
• Once you ensured a proper XML profile you can set the reference time of a dima by using the
  referenceTime = Calendar : Reference time for time-dependent feature layers. Each route in the distance matrix contains this time as start time.
• Anyhow: I'm doubting in the expected quality: using a daytime dependent routing is not meaningful for long distances. It might work in urban logistics on short tracks.

Best regards Bernd

PS: I asked Francois to have a look at this thread, too.