Possible refinement of waiting time and journey time tolerance

[jamespetts]

There was a time in Simutrans-Experimental when all waiting times were halved to take account of the fact that services would in reality run to a timetable and people would be able to plan their trips so as not to be waiting for as long as the actual service interval. This was removed in 10.12 with Carl Baker's overhaul of a number of aspects of waiting times.

However, investigations into the calibration of passenger generation, including research into real life frequency of services, gives me to think that this mechanism needs to be replaced with something. The reason for this is that, once the passenger generation is properly calibrated, there will be places where the passengers generated for any given run are so few that only a very infrequent service - one every dozens of game hours - will be justified; yet if the actual wait time recorded for a journey ended up being, say, 12 hours (for a 24 hour service frequency), for a journey of perhaps 9 hours, this would require a 21 hour tolerance for a 9 hour journey. In reality, people would just go to the stage coach inn, or the airport as the case may be at the appointed time, not turn up at any old time and hope for the best, then wait half a day before the next service leaves.

One possible solution would be to adjust the journey time tolerance to take out of account part of the waiting time for the passengers' origin stop, to take into account that the passengers can control their departure time from home, but not from connecting stops. For example, if the wait at the passengers' local stop is over 30 minutes, half the wait time over 30 minutes can be added to the journey time tolerance, and if the wait time is over 2 hours, a further three quarters of the wait time over 2 hours can be added to the tolerance.

However, this will not entirely deal with it, as often the journey starts with a local frequent 'bus ride to, say, an airport terminal or a dock from which a long-distance journey will start. In reality, passengers would not embark on the local 'bus journey except shortly before the time that the long distance service was due to depart.

It is not immediately clear to me how to deal with this common situation without substantially upsetting the routing code, which is not something that I am prepared (or able) to do. Any suggestions on this topic would be welcome.

[asaphxiix]

the only way i can think of is for waiting time to be very very dynamic, accurate and foreseeing - say, an hour before the next scheduled bi-monthly (12:48h) flight, waiting time decreases to an hour, which opens a "window" in which the journey time allows for the journey to be made.

However this would mean that journeys of pax generated e.g. 6h before the flight will be lost, rather than postponed, they would not wait at home.

[Carl]

Your suggestion seems sound, and while I agree it would not totally solve the problem, it would at least mitigate it to a certain extent.

This may be a situation where we have to apply a merely good solution in the absence of a perfect solution.

[jamespetts]

the only way i can think of is for waiting time to be very very dynamic, accurate and foreseeing - say, an hour before the next scheduled bi-monthly (12:48h) flight, waiting time decreases to an hour, which opens a "window" in which the journey time allows for the journey to be made.

However this would mean that journeys of pax generated e.g. 6h before the flight will be lost, rather than postponed, they would not wait at home.

Hmm - I can't think of a way of doing this, especially since this "timetabling" is far from universal.

Your suggestion seems sound, and while I agree it would not totally solve the problem, it would at least mitigate it to a certain extent.

This may be a situation where we have to apply a merely good solution in the absence of a perfect solution.

The main difficulty is that it would have only a very small effect indeed, although the effect might be greater once the refinement of walking is implemented.

Actually, it might cause anomalies if we allow further walking, and might be best left alone until we can solve this fully. If it is faster by far to catch the 'bus to the airport, which is a hour's walk away, but there is only one plane a day to one's destination, then, if we can't discount the airport waiting time if we travel by 'bus, but we can if we walk, then passengers would walk rather than take the 'bus even though the latter is faster, as walking would appear faster when waiting times are taken into account.

[Carl]

I wonder if we are jumping the gun a bit here. Even with passenger_factor set as low as 1, it is still very difficult to set up a route whose passenger numbers only warrant a convoy e.g only every 12 hours. (In my experience, anyway: it may be that some of my settings are not optimized.) So it is not clear that this becomes a serious issue until the passenger levels allow for such sparse service.


It is ultimately hard to see how this can be entirely solved unless passengers know exactly when they should turn up in order to catch the very infrequent services - and I take it this counts as the "substantially upsetting the routing code" you referred to above.

[jamespetts]

Hmm, perhaps. We can leave this for the time being and return to it if it is an issue after the passenger generation has been optimised.

[greenling]

That idea must we test with the new Calibrating the passenger factor.
http://forum.simutrans.com/index.php?topic=10953.msg109818#msg109818