Thoughts on calibration of passenger generation and city size

[jamespetts]

I have come to think recently on the question of a realistic calibration of passenger generation in cities to the population size to the land are that cities occupy. Currently, there does not appear to be any attempt to make the relation between those three variables realistic, and this could do with work if realistic service frequencies on passenger routes  are  to be obtained.

The firststep, I think would be the calibration of the size and relative density of towns and cities with their actual reported population size. Currently, the reported population szes seem far too low for the actual size of the cities, and do not appear ot be an attempt to get a realistic level of population. This should be easy in principle, as all that it involves is modifying the way that cities' reported poulation is calculated. The tricky part will be doing the actual calibration. I should be very interested in any figures that anyone is able to come up with for this.

The next step, the harder of the two, would be to calibrate levels of population withthe number of passenger journies. This is made more complicated by the facts that:
(1) real figures tend to be based on journies by particular modes, not passenger journies overall;
(2) those figures do not tend to distinguish between journies starting in a town (i.e., the truly generated amount) and those merely ending in the town (and simply dividing by 2 will not do, since many journeys both start and end in the town); and
(3) the real figures will report the number of journeys that passengers actually make,  not the number that they might potentially make if the transport infrastructure was better or if they had cars, which is the number that Simutrans needs.

With all that in mind, this calibration can only be appropximate, but it is worthwhile to try to get it approximately right , at least. A further and more difficult complicating factor, however, is peak flow. The number of passengers can vary by ordres of magnitude between peak and off peak periods. If we do not siimulate the peaks (currently, my preferred option due to the excessive complexities of trying to do so),  we have to work out whether we take peak traffic, off-peak trafffic, or some medium of the two as the basis for our calibration. This is a difficult questiion, as much reallife infrastructure is designed with peak capacity in mind, but does not earn  the level of revenue that it would be able to earn if peak traffic was constant. Some adjustment, possibly, might be made by having near peak volumes, but with lower rates, but this might adversely affect rural areas with lower traffic overall.

Alternatively, if one were to try to simulate the peaks, there would be great additional complexity introduced in scheduling (which is why I  have provisionally ruled this out, subject to any ingenious suggestions as to how to circumvent these problems). If we take the simplest possible approach to simulating peak time and have a peak and off peak traffic level (just the two discrete levels with no smooth transition) alternating during a game month,  players would, it seems to me, have to have the option of having a peak and off peak schedule for every line. That would have to allow some vehicles to be stabled during off-peak periods. The really difficult part is transitioning between the two schedules - what would happen if peak time begins or ends in the middle of a convoy traversing its schedule - at what point would it switch to its peak schedule, and at what point in that schedule would it start? There would then have to be separate peak and off peak journey times, waiting times, etc., and goodness knows how the transitions between those might be effected. One possible alternative might be to allow players to have somesort of demand management built into a single schedule, but I am not really sure how that might be accomplished, especially without skewing waiting times etc. (for example, by making all the waiting times come out as an implausible avreage between an intense peak time service and a virtually non-existent off-peak service). All of this mess makes it easy to see why I favour retaining flat demand, unrealistic though it is, for the foreseeable future, unless there are any truly ingenious ideas as to how to circumvent it.

Comments on all of the above will be most welcome!

[Carl]

Hi James,


I'll have a chance to read through and think about this properly tomorrow, but two quick comments initially:


1. If reported city populations are to be changed, then the meters per tile setting will have to be taken into account in working out what population each building level should represent.


2. If there is to be a peak/off-peak mode -- which sounds interesting if complex -- it should be optional and possible to disable.

[ӔO]

The normal way of dealing with peaks, is to increase the frequency or increase capacity along the congested areas. This is already easily achievable with with trains and the scheduling implemented. The hard part is figuring out which stations would benefit from these somewhat express trains.

If you take real world examples, for instance japan's bullet train. On average, there is a local service every hour, but the rest are entirely express service. Some of the private companies also run something like a 4-car local train every hour, but the express will get 8~12 cars and tend to be more frequent.


I'll go make an extension request for this, but a usage history log in the station info dialog for direct connections would be quite helpful in this regard. Currently, you have to sort of sabotage your lines, so that the pax pile up, in order to see where most people want to go.

-edit: seems to be already implemented in standard as of r5723... whatever those "<##>" means.

[Carl]

I think the calibration of reported populations might take some trial and error. One can look at a host of examples and try to come up with an equation that best respects them all. The equation should presumably just be of the following type:

Current population x (Magic number) x (Value that varies with meters per tile value) = new population

Where "current population" is 6 for a level 1 building, etc, and "magic number" is the number we're searching for.

The meters per tile value in this equation would not be linear. At mpt=250, buildings take up four times as much space as at mpt=125, so this value should be quadrupled as the mpt value is just doubled.


So here are some examples which one can use to search for the magic number:

The city in which I live, Aberdeen, is approx 6.5km x 6km. At your new desired mpt of 125, this amounts to a city size of 52 x 48. The population of Aberdeen is 217,000.

Macclesfield (at mpt=125) is 28 tiles x 32. Its population is 50,688.

You get the point. One can do this for other cities too.


--

The difficulty with calibrating the number of passenger journeys is that there is no one definitive relationship between population and public transport use across the board. It can vary with all kinds of social, economic and geographical factors. Some of these are to do with the quality of the system -- if you build it, they will come -- but others are completely unrelated. This kind of variety is difficult to reproduce within Simutrans. As such I am not sure that one needs to fret too much about hitting on the accurate calibration here -- so long as the passenger levels don't seem wildly off -- and lead to fun and challenging gameplay -- the brief has been met.

[jamespetts]

AEO - the real problem with the peaks is not the adjustment of frequency (which can to some extent be done with the wait until x% load feature, albeit only if service frequency and speed is not a priority), but the impact on having two different levels of frequency (etc.) at different times of day on passenger routing. Using journey times and waiting times that are an average of the two (which is what would happen if no specific changes were made to accomodate this) would result in timings that would be accurate neither for the peaks nor the off-peaks. Having separate timings would require two entirely separate sets of routing information to be stored, and would create great complexity at the points of transition (of any kind) between them.

Carl - I agree that it cannot be exact, but some approximate calibration is needed such that the optimum service intensity on any given route in the game approximately matches the optimum service frequency in reality for the same route.

the

[ӔO]

@james
ah, I see. If such a peak system were to be implemented, I would suggest an automatic method.
The player should simply setup a line as usual and release all convoys for that line. The game should then automatically take out, around 10~25% of the convoys in that line during regular time and add them back during peak.

[jamespetts]

Hmm - I'm not sure that a non-controllable variation in service frequency would either be desirable or workable. If passenger numbers decline in an off-peak time, the most efficient system might be to discontinue some services entirely, which then means that some other services require more capacity. Service patterns would need to be able to change as well as service frequencies. Also, what would happen to convoys part way through their schedule when off peak time comes? Which ones would be removed, at what point in their schedule would they be removed, where would they go, and where would they come from at peak time again? What of lines with one or two convoys where a figure of 33% makes no sense? What of lineless convoys? What about route finding - do passengers take the route that would be fastest in the peak even if the peak has nearly finished? What happens to passengers waiting during peak time when the off peak time commences and a different route becomes the optimum route - do they continue their planned route, or deviate based on the optimum off-peak route? The more that the concept of peak time is considered, the more that the difficulties with it seem insurmountable.

[el_slapper]

problem with peak is that people usually want to arrive à a given time. So, they think backwards. For example, me : I must be in Riquet at 8h40, so if I'm at Stalingrad at 8h35 it's OK, so I must be before 8h30 in Gare du Nord. 7h49 train from Taverny arrives at 8h23 at Gare du Nord, I'll take that one.

try to modelize that in Simutrans..... For example, let's imagine a coal mine, with a bus bringing workers in the morning & bringing them back to, let's say Blackbath. Without peak, the bus simply takes 40 people from BlackBath, puts them at the mine, takes 40 people at the mine, & brings them back to Blackbath. Day or night, no matter. But, at least, it is manageable. Now let's imagine people work from 5 am to 2 pm. You'll have 3 buses going full at 69 people at 4 am from Blackbath(assuming the travel time is 1 hour), arriving at 5 am at the mine, and coming back empty, then waiting empty at the depot, then coming back to the mine, & be full for the afternoon comeback to Blackbath.

Hum. Seems like a whole new game to me. A whole new game to develop. As probably many workers do not live in Blackbath main bus station, but must already rely on another lie to reach the main station, before taking that bus bringing them to their workplace. So you have to develop a complete set of schedules, just for 1 single lone service.

IMHO, that's another scale of game. Instead of planning 3 minutes for 3 bus lines(2 feeding the main bus station & 1 feeding the coal mine), you'll be planning for hours just for one single line. That's another game. I want to plan 100's of lines & link every town of the map. Without peak management, I can. If I have to take care of every working schedule, my life will not be enough. That's a full-time job for plenty of people.

(and I do not even speak about the nightmare it would be to balance the game with such peaks; it's already very tough).

[jayem]

I think you're right on not trying to do peaks directly.  It would be a different game (an interesting one, none the less, but definitely different).


Some numbers from wikipedia (+ a bit of google mapping impressions)
London 5000/km2
Most central districts seems to be 12000/km2,
the outer around 4000/km2 <This would mean each tile represents 250 people, probably each house represents 1000>

Bedfordshire 500/km2      (around 10% of the population in each of 4 big 4 towns, coming to around 1/2 the population)
(It's probably similar to what is now Greater London 100 years ago?)
There's a kind of fractal pattern where (now) roughly the distances between settlements is roughly twice the size of the settlement.  So the big towns contain around 10% of the land.

Bedford itself seems to be around 1000/km2 as a whole and 2500/km2 where built up.

Aberdeenshire 40/km2     Aberdeen 1000/km2  (again the urban population more or less matches the rural population)*

All in all I'd guess 250 people per 'entry grade/1 passenger level' house (at 250m scale) ought to give the right order of magnitude for a first approx in terms of nominal area.  You'd need to see how the cities build the houses but it seems you get a mix between 2&6 passenger levels in 1995, which would work out about right.  But it would look 50* too high in terms of houses (perhaps there would be a case for a compromise).
Once you've got the right number.  You'd then want to tune the city building probabilities to match and give any variation for multiple cities.  Although I suspect it's good enough for several years.

Anyhow that's my entry for the guess the population factor (at 125 m scale this would go to ~60, and be only 12* high in terms of visual effects).
*I thought I picked Aberdeen at random, but I had read Carlbakers post...

With the traffic I concur you want something that "feel's" right, and has the right effects rather than a realistic model.  You want 'London' to be worth an underground system, something 'Bedford' sized to be worth a station and bus route, etc...  Getting trains behaviour sufficiently to scale to use real numbers throughout would be a nightmare, especially as 1 day=1 month.
(just seen this page, might be interesting for numbers)
NB an station to underground hub (Waterloo) sees 60,000 people in rush 3 hours (18 minutes game time), and one line has 76 trains in operation (over 60kM/240 tiles).
http://www.tfl.gov.uk/corporate/modesoftransport/londonunderground/1608.aspx

[jamespetts]

Thank you for that analysis - most interesting! Am I right in deducing that your formula would entail one person per square metre...?! (250 people per tile at 250m/tile would be 250 people per 250 sq. meters, or 1 person per square meter, would it not, or am I terribly confused)?

As to the timings, one oughtn't convert 3 hours into 18 game minutes - the idea is that 3 hours' worth of passengers in real life should convert to 3 hours' worth of passengers in game time (at least, if game time is set to display the measure of time used for trip calculations, which it does in recent versions of Pak128.Britain-Ex by default).

[jayem]

Not quite, I badly formatted it (and will have to check I've been consistent)

As written it would be about 1 person per 250m*1m strip (or everyone could stand in a grid 15 metres apart from each other). 
That's what I was estimating a semi-low density (e.g. a constant field of bungalow icons) represent.  Town houses would be a couple/family in that space.

[late modification to try and reclarify]
Basically the feature is due to population/area being related to the square of the tile length.
If each tile is 250m long and 250 m wide then there are actually 250*250 m square tiles.

The feature is actually very interesting and it may be worth reading up on the square/cube law at some time.
If we take an ant which can carry 10 times it's body weight and make it 100 times bigger.  Now it can only carry 1/10th of it's body weight (although 10000 times as much).  It's strength is proportional to the square, it's weight to the cube. 
But it's strategy would have to change completely.  Relating to simutrans, favouring different strategies is what we want.

[jamespetts]

I'm slightly confused (and also bad at mathematics, so bear with me): where do 1m strips come into all of this...?

[kierongreen]

1km2=1000000m2

Therefore:
5000 people/km2 = 0.005 people/m2 (200m2 per person - roughly 13m by 13m)
12000/km2 = 0.012/m2 (80m2 each - 9m by 9m)
500/km2 = 0.0005/m2 (2000m2 each, 45m by 45m)
40/km2 = 0.00004/m2 (25000m2 each, 160m by 160m)

[MCollett]

As to the timings, one oughtn't convert 3 hours into 18 game minutes - the idea is that 3 hours' worth of passengers in real life should convert to 3 hours' worth of passengers in game time

Which is, if it were needed, another argument against any idea of including rush hours in the game at present.  When a day is only about 3 hours long, there is simply no time for peak and off-peak periods within that.  If you really want rush hours, you first need to get the day length up to something of the order of 24 simulation time hours.  Similarly, if you were to want weekends and public holidays, you would first need more than one day a month.   

(Actually, slightly less than 24 hours would do: by omitting or compressing the 'wee small hours' you could have say an 18-hour day with 1 hour morning rush, 8 hours of working day, 1 of evening rush and 8 of evening/night.  Overnight sleepers anyone?  But now I'm rambling ... )

Best wishes,
Matthew

[Carl]

I share the opinion expressed above (by e.g. el slapper) that to implement a peak/off-peak distinction properly would be a gigantic change and would potentially turn this into a different game altogether. It also seems to me that it would require one to remove many avenues of customization: month length (should be 18/24 hours), passenger factor (should correspond to real numbers), etc.

The passenger factor aspect of this discussion is particularly interesting, since if "3 hours' worth of passengers in real life should convert to 3 hours' worth of passengers in game time", then many people's play styles will have to change dramatically. I doubt anyone would be able to build a network without convoy spacing. On one of the network games, most routes were running five or six times an hour -- a frequency which only the busiest urban routes reach in real life. Now there is much to be said for realistic frequencies -- but I'm not sure they should be forced upon players. Someone who likes Standard-style gameplay in an Experimental-style framework should have the option of turning up passenger-factor.

[jamespetts]

I share the opinion expressed above (by e.g. el slapper) that to implement a peak/off-peak distinction properly would be a gigantic change and would potentially turn this into a different game altogether. It also seems to me that it would require one to remove many avenues of customization: month length (should be 18/24 hours), passenger factor (should correspond to real numbers), etc.

Yes, it is increasingly appearing as though an attempt at simulating the peaks is thoroughly impractical in the framework of this game.

The passenger factor aspect of this discussion is particularly interesting, since if "3 hours' worth of passengers in real life should convert to 3 hours' worth of passengers in game time", then many people's play styles will have to change dramatically. I doubt anyone would be able to build a network without convoy spacing. On one of the network games, most routes were running five or six times an hour -- a frequency which only the busiest urban routes reach in real life. Now there is much to be said for realistic frequencies -- but I'm not sure they should be forced upon players. Someone who likes Standard-style gameplay in an Experimental-style framework should have the option of turning up passenger-factor.

It wouldn't be too hard to have a realistic base, but retain customisation potential. If a passenger factor of 16 (the default) were calibrated to be as close to a realistic level as possible, players in single player games, hosts of server games and pakset designers could then use the existing passenger factor setting to customise from the realistic base.