planBasicTours - double Transport points

[sgebhardt]

Hello PTV team,
after some time I got a question from my customer concerning a planing.
We used startPlanBasicTours to get the sequence between different transport points.
I have the same coordinate twice in different transport points. xTour desides to drive from A to B and back to A. There are no other restrictions.

The request and the response is in the attachement of the post.
This transport point is existing twice:

Code: Select all

<ns10:transportPoint id="100930249" coDriverRequired="false" openingIntervalConstraint="START_OF_SERVICE" servicePeriod="300" useServicePeriodForRecreation="false">
<ns10:location><common:point x="15.07637" y="47.06511"/></ns10:location>
<ns10:transportPoint id="100930302" coDriverRequired="false" openingIntervalConstraint="START_OF_SERVICE" servicePeriod="300" useServicePeriodForRecreation="false">
<ns10:location><common:point x="15.07637" y="47.06511"/>
</ns10:location>

The response id 100931411 is between 100930249 and 100930302.
The transport point is on the same road.. Any chance that I can avoid that feature and plan A, A, B?

[Bernd Welter]

wow, sounds like a very academic condition. Maybe the following effect is responsible for the strange behaviour:

Usually one would expect that a route like A:C is shorter than a route A:B:C.
But: if B is located somewhere along the direct track the additional stop creates a change in the data structure and the definition of the cost function. Look at the following sample:

Left route: simple routing from Karlsruhe to Heilbronn. Track length about 90km. Optimisation set to 90% (shortest time).
Right track: same optimization but additional waypoint somewhere in the countryside which enforces directions. Track length is only 76km.

I know this sounds confusing
In your example the virtual loss of quality is just about 500m.
Let's have a look at a potential distance matrix:

distance matrix simulating the case from above

Academic.DIMA.PNG (6.39 KiB) Viewed 9204 times

The sequence KA-Country-HN-Country-KA is in fact shorter but might require more time!) than the sequence KA-Country-Country-HN-KA because the leg HN-KA performs a large detour.

Happy with that?

Best regards Bernd

[sgebhardt]

Thanks for the response. Not realy what I hoped to hear.
Didn't thought that there can be higher costs between the same stop (geocoordinate) and another.

So the solution is to put the stop just one time in my list. The other parameters are atm not relevant for us.

[Joost]

I ran into this issue recently and found a different explanation, I checked this against your problem and can say this is probably the cause:

One would assume that a route A -> B -> B -> C- > D (what you want) is always shorter then A -> B -> C -> B-> D (what you are getting). But that is not always the case. Bernd gave you an example on how the route can be shorter, however there is another case to consider: the result are exactly the same. And this is happening in your issue. This happens if point B is on route from A to C as well as on route from C to D. No matter where you insert B in the A -> C -> D route the result will not change in distance or driving time.

So from a mathematical standpoint both plan options are the same and there is no incentive for xTour to prefer one solution above the other.

Screenshot of your result zoomend in on the issue. Red flag is point B, purple pinpoint is point C.

What you can do to keep these order together is to use the siteId attribute on the TransportPoint to group these locations by giving then the same siteId. If you then set the extraSitePeriod you give the the xTour an mathematical reason to keep the other together. Xtour will count extraSitePeriod only once if 2 stops after each other belong to the same site. 10 sec extra sitePeriod did the trick for me.

Keep in mind though: This is not an insurance that they will stay together no matter what. The only way to do that is to gorup the order into a single order like you wrote about in your last post.

[Bernd Welter]

Thanks, one more brilliant hint