Earliness and break periods in xTour 1.22.0.2

This forum deals with any kind of trip optimization whether it is automatic planning or manual dispatching, refering to transport orders or service planning.

Earliness and break periods in xTour 1.22.0.2

Postby Lauterfeld » Tue Oct 11, 2016 12:36 pm

Hi Bernd,

we changed Touropt.Ini like that:
MaxTourEarlinessPeriod=1800
MaxStopEarlinessPeriod=900

That's because we want to avoid tours with long waiting periods between the transport points. With the defaults of 31536000 (=365 days) we had tours starting in the morning delivering one order and wating until the evening delivering another order. We wanted xTour to come back to the depot between the 2 orders.
With the entries 1800/900 we hit another problem: if xTour plans a break period of 2700 seconds at arrival time at a transport point the 2700 seconds are marked as 'earliness'. In my opnion break period is not earliness (earliness for me is lost wating time :-)) but a normal (and important) part of the tour period. The 2700 seconds of "break time earliness" strike against the touropt.ini parameters. If we had more than one order / transport point to the same location they were not planned but marked as feasible. When we set up the touropt.ini to 5400/2700 all orders to that x,y were planned.
Is there a chance in xTour to separate break (and probably rest) periods from earliness periods?

Regards,
Volker.
Volker Lauterfeld
Software-Entwicklung und Projekte
COS GmbH
Gesellschaft für Computersysteme,
Organisation und Softwareentwicklung mbH
Raiffeisenstraße 21
D-77704 Oberkirch
http://www.cosonline.de/
Lauterfeld
 
Posts: 22
Joined: Tue Apr 14, 2015 1:19 pm

Re: Earliness and break periods in xTour 1.22.0.2

Postby Bernd Welter » Wed Oct 12, 2016 2:44 pm

Hello Volker,

(XSERS-436)

the discussion not only deals with "waiting" period and but more in general with "arriving to early".
So arriving to early could be handeled as "waiting" but also as "break".
This is what "too early" means in terms of the touropt.ini. Whether you can use it as a break or not.

Even if we can report a break it is difficult to prove that it is a necessary break that has to be applied.
To recognize this we would require many complex analysis within each check of the restriction settings - which would lead to a significant loss of performance.

Therefore the answer ist: sorry, our implementation is not able to treat the conditions in the way you want them to be handeled.

Best regards Bernd
Bernd Welter
Senior Technical Consultant Developer Components
PTV GROUP - Germany

Bernd at Youtube
User avatar
Bernd Welter
Site Admin
 
Posts: 1412
Joined: Mon Apr 14, 2014 10:28 am


Return to PTV xTourServer