Topic: Outline of proposed and work in progress changes to passenger transport

[jamespetts]

This year, I have been working on what I hope are significant improvements to the way in which passenger transport is handled following experience on the Bridgewater-Brunel server showing this to be an area in much need of improvement. Some of these things I have already implemented in various Github branches - others are still at the planning stages. The purpose of this post is to summarise those changes, and invite comment on them, especially the more radical amongst them, to help to refine the systems before they are released.

The first of the changes I have written about elsewhere, and I have now implemented on the walking-passengers Github branch: passengers can walk all the way to their destination provided that it is within their journey time tolerance (assuming a straight line journey from beginning to end and a walking speed set in simuconf.tab - the default is 5km/h); and the time for passengers walking from their origin to the first transport stop and from their last transport stop to their destination is taken into account in time calculations both for routing choice and journey time tolerance. No longer will passengers always walk if the stop closest to their origin and the stop closest to their destination are both within the coverage radii of stops: they will take transport if this is faster than walking. The coverage radius system is unchanged, but it is intended that the coverage radius be very greatly increased to go with this feature.

A related improvement that I have implemented just to-day is the transfer time. This takes into account the walking distance inside larger stops and adds it to the journey time. Because of the way in which routing works, it was not possible to make a bespoke transfer time depending on where in the stop/station that particular convoys stop, but the transfer time is based on the size of the stop and is shown in the stop details window in minutes and seconds. This behaves in the same way as waiting time, and is cumulative with waiting time. Small stops have a zero transfer time.

These two measures together make irrelevant the former practice, which is rather an exploit, of covering entire towns with very large stations made up of diagonally connected road stops.

The next improvement, which I have finished implementing to-day on the private-cars Github branch, is a reworking of the already existing private car routing system to make it work within reasonable limits of performance on larger maps. Currently, this feature has to be disabled on larger maps. Enabling this feature means that private journeys between towns (and to out of town attractions and industries) are based on the actual road network: private car journeys cannot be made where there is no road network, and their journey time will be based on the speed and directness of connecting roads.

Congestion has also been refined on the private-cars Github branch: instead of being a generalised disincentive to travel, congestion is now taken into account when determining journey times (the percentage figure represents the percentage of extra journey time above uncongested conditions), and the choice between walking, private car and public transport is based exclusively on journey times (taking into account congestion and the walk to and from transport stops, as applicable), except for that stubborn proportion of people who will always take their car if they can, the percentage of whom can be set in simuconf.tab.

I plan to refine and recalibrate congestion further so that the level of congestion is based on real life data about the relationship between the number of private car trips and the numbers of kilometres of road (TomTom publish quite extensive data on the subject): currently, the level of congestion is not well calibrated. I also plan to have player vehicles taken into account when calculating congestion, although I have not quite worked out how best to count them yet. Certainly, a city filled with 'buses and lorries should be more congested than one not so filled, all other things being equal.

A somewhat more radical feature that I am planning is to simulate car parking. Because private car usage is now dependant exclusively on journey times, I suspect that too high a proportion of people will use private cars (with the result that player transport will be under-utilised) unless limits on car parking are simulated, which is, in real life, a very significant incentive to use public transport in the largest of cities. Each building will have a setting determining whether it has unlimited, limited (and, if so, how many) or no car parking spaces. Car parking spaces will be defined as vehicle journeys ending in that building per month, multiplied by a factor designed to simulate the fact that average car occupancy is greater than 1. When the car parking spaces in that building have run out, no more private car journeys can terminate in that building that month: passengers must either walk or take public transport unless there is a nearby public car park (more on which below). The idea is for larger buildings to have proportionately fewer car parking spaces than smaller buildings (on average) so that higher density cities are realistically simulated with more restricted car parking. I also wonder whether I might borrow (and adapt) an idea from Sim City 4 and have a per city setting to allow or disallow street parking: when allowed, each building gains extra car parking spaces (even if its base allowance is zero), but congestion in the city is increased.

Aside from car parking in buildings, which is private car parking (in that the spaces will only be usable by passengers whose journeys terminate in those buildings), I plan to add public car parks, which can be built by players. Public car parks (which I think should probably be coded as a derivative of a stop or station extension building) will also have a limited capacity, but will allow any private car journey to terminate there: the passengers can then walk from the car park to the destination building, or a nearby (or even connected) public transport stop to continue their journeys. This will allow for park and ride facilities as well as station car parks allowing stations (and airports, docks, etc.) to have a much expanded range for motorists.

As an aside, I am aware that Kieron has hinted that he is planning to code some system of car ferries for Standard. He has not revealed how he plans to implement this system, but it would be interesting to see whether this can be made to fit in with this model of private car traffic such that passengers could drive to a ferry terminal, take their car on a ferry, and continue to drive to their destinations provided that there are adequate road links.

Much has already been written about the details of calibrating the number of passengers generated, but things need to be considered more expansively than this, as the development and relative density of villages, towns and cities is highly relevant to this, too. On development, the plan is for the pattern of city development to be influenced heavily by transport. Each building will record the proportion of successful journeys made from it (subdivided into types of journey; this part is already implemented in the walking-passengers branch). When a city tries to build a new building, it will strongly favour locations that are next to other buildings with high success rates. Likewise, buildings with high success rates will be the first to be upgraded to higher levels. Higher level buildings will not be able to develop at all unless certain minimum thresholds of success rates are met, which will be higher the greater the level of the building. This system will not replace the cityrules.tab system (as that determines the structure of cities, which is a different thing), but will replace the existing rules causing higher density buildings to be built near the geographical centre of cities, and also the rule that larger cities grow faster. The reason for this is that both of those rules are simply proxies for the fact that larger cities, and areas near the centre of cities, tend to be better connected to other larger buildings (which are already favoured as passenger destinations over smaller buildings, even in Standard), and that this better connectivity is the reason for the greater development. This system will simulate the rapid expanse of towns following the introduction of urban railways, and the sort of suburban sprawl associated with high car usage (as increases in residential population will by preference be handled by new low density buildings over upgrading existing buildings). It will also simulate the fact that there was a very real limit on the size of towns and the placement of residential buildings when people could only get to work by walking.

What I have not yet quite worked out is how best to deal with overall city growth, and in particular, whether to continue with broadly the existing system of having cities grow in proportion to the overall level of transport and electricity provision, or whether to have some system whereby people will move to the better cities in preference to the less well connected cities, overall population growth being pre-determined (but, if that is done, it is hard to see how to avoid having only one city having all the growth).

Better to simulate journey patterns, I plan to categorise passenger destinations into residential, commercial (which will include attractions and consumer industries such as shops) and industrial (which will include all non-consumer industries), and borrowing (and probably adapting) the proportions from the original Sim City, have differing proportions of journeys go from different sorts of building. All outward journeys will go from residential buildings (this will avoid having to step commercial and industrial buildings, which will reduce computational load; this will require recalibration of my passenger generation calculations, however), and all journeys will generate a return journey (currently, only out of town journeys generate a return). Some journeys will also create an onward journey: for example, a residential to commercial journey might generate an onward journey from the destination building to another commercial building (and both parts of the journey will also generate a return journey). This is to compensate for not generating passengers afresh at commercial and industrial buildings. Passengers (always originating at residential buildings) will be far more likely to have destinations that are commercial and industrial buildings than other residential buildings, and onward journeys will likewise be weighted.

Passenger journeys will be of two sorts (to replace the current division of short, medium range, and long distance: this abolition is discussed furhter below): journeys to work and other journeys. Each different sort of journey will have a different journey time tolerance range, specified in simuconf.tab. The plan is for journeys to work to have a narrower range of tolerances (perhaps 20 - 75 minutes), whereas other journeys will have a wider range of tolerances. Onward journeys will always be counted a non-work journey. The success rates of these different sorts of journeys will be measured separately for each building. Building new or upgrading existing residential buildings will depend more heavily on success rates at journeys to work (as, for the most part, people move to find work and access to other amenities is more of a luxury), while commercial buildings will care more about other journeys (as they need customers even more than workers). Industrial buildings will also care about journeys to work more than other journeys, as they need a good workforce, but are less dependant on having customers actually visit them. Industrial city buildings (i.e., not industries that can be supplied by a player) sit in a somewhat odd position: there is much to be said for having the growth of these depend heavily on the success of full industries in the town (so that industrial city buildings are more likely to be built in towns with well connected industries than towns with no or badly connected industries). Indeed, it might be helpful to have a radius of influence around full industries which attract industrial city buildings in proportion to their success. This would have the effect of giving towns a distinctive growth pattern: industries are placed randomly (one day, it would be good to have their placement depend on resources), which attract residents to work there - if they are well connected (the industry boost function will be useful here). The residents provide customers for commerce, which also provides more jobs for residents, and, if everything is well connected, a positive feedback cycle will emerge. It will be sensible in the light of this to have all but primary industries (farms, fisheries, mines, quarries, etc.) located in towns.

The measure of a town's population also needs to adapt to take into account the above: instead of a single population figure, we need to adopt the practice of Sim City 4 and have a separate figure for population (based on the residential buildings) and jobs (based on the commercial and industrial buildings). This, too, will require some recalibration of my passenger generation figures. With this system, it will not much matter that the jobs and population in a single city do not match, as, if they are well connected enough, people can commute to a neighbouring city for work.

As mentioned above, I plan to abolish the system of classing journeys as long-distance, mid-range and local. The idea of having this system was to simulate the fact that most passengers travel to local destinations. This is true enough, but this is only because journeys to local destinations take less time than journeys to far away destinations, and we already simulate journey time: there is little point in adopting an heuristic to represent something that is already simulated in detail. All that needs to be done is to have a weighted system for the journey time tolerances (as discussed elsewhere to ensure that the greater proportion by far of tolerances are at the lower end of the range) so that it is no longer necessary to break them down into three linear ranges, and to allow a much larger number of alternative destinations so that passengers are permitted to have many retries to select a viable destination within range, where that range is based on journey time. There is much to be said for having the number of alternative destinations partly set by a formula based on the size of the map (x destinations per 1,000 sq. km, for example). Some careful work will need to be done to ensure that these settings produce realistic proportions of passengers desiring to reach particular locations and that broadly match real life figures as to the distances of their journeys.

This set of changes will hopefully allow for a far more realistic simulation of passenger transport (and urban development, for that matter), and will hopefully alleviate some of the difficulties in passenger transport currently encountered in present versions of Simutrans-Experimental (and a side effect of more accurate tolerances will be far fewer passengers travelling, which should both directly and indirectly improve in-game performance).

I should be very interested in and grateful for people's thoughts on these features so that they can be refined and polished before being included.

[Carl]

James, thank you for this detailed post. These feature changes sound like a very impressive advance on what we already have. Several of these features (transfer time, changes to walking) are things I had assumed were pipe dreams, so I'm excited to hear that they will be implemented.

These two measures together make irrelevant the former practice, which is rather an exploit, of covering entire towns with very large stations made up of diagonally connected road stops.

I have to admit that I was initially ambivalent about this consequence -- but now I've thought it through, I am in support. I've used this practice a lot, for (what I think are) fairly good reasons -- I usually build maps which have very computationally intensive rail networks, and which could not accommodate the addition of bus networks too without grinding to a halt. So I've used this 'exploit' as a kind of shortcut to simulate the fact that passengers from the town will get to the station some way or other. But the more I think about it, I can see that increased station coverage along with the changes to how walking works will completely offset the need to do this. The key feature here, I think, is that passengers which are within coverage but ten squares away will have to account for their walking distance to the station in their journey time. So, in fact, I am now looking forward to not having to blanket my cities with bus stops!


A couple of small questions: how will transfer time interact with waiting time? Will waiting time still measure the total time from arriving at a station to leaving it, or will it offset this against transfer time? Also, will transfer time come into play for passengers whose journey originates at the station in question?

[asaphxiix]

Well, this is one of the most exciting posts ever. It's great to see my fantasies from the days of Transport Tycoon in the 1990's not only coming true, but by far exceeded in realism and detail.

On paper, these mastermind ideas sound just right, I hardly have anything to add or comment, but let's try:

The first of the changes I have written about elsewhere, and I have now implemented on the walking-passengers Github branch: passengers can walk all the way to their destination provided that it is within their journey time tolerance (assuming a straight line journey from beginning to end and a walking speed set in simuconf.tab - the default is 5km/h); and the time for passengers walking from their origin to the first transport stop and from their last transport stop to their destination is taken into account in time calculations both for routing choice and journey time tolerance. No longer will passengers always walk if the stop closest to their origin and the stop closest to their destination are both within the coverage radii of stops: they will take transport if this is faster than walking. The coverage radius system is unchanged, but it is intended that the coverage radius be very greatly increased to go with this feature.

I wonder, if pax will at any case calculate the walking distance as part of the journey, why is the station coverage still needed? Also, I'm thinking walking will need to be limited in some way, to avoid pax from walking unrealistically large distances.

There's also the problem discussed before, that pax shouldn't wait very long for a scheduled departure from their first stop - since IRL they should know when the bus is supposed to depart. Only if the schedule is not met - then they will wait.

The idea is for larger buildings to have proportionately fewer car parking spaces than smaller buildings (on average) so that higher density cities are realistically simulated with more restricted car parking. I also wonder whether I might borrow (and adapt) an idea from Sim City 4 and have a per city setting to allow or disallow street parking: when allowed, each building gains extra car parking spaces (even if its base allowance is zero), but congestion in the city is increased.

Are there actually cities that completely disallow street parking, other than futuristic "green" new suburbs? I would think this should be part of a needed reform in roads and streets in general - a matter for a separate discussion, but in short I think we need more diversity in roads and streets, in cities for instance it would be cool to have narrow streets, broad streets, alleyways, pedestrian only streets, etc, each with different way type parameters, one of those is street parking.

Better to simulate journey patterns, I plan to categorise passenger destinations into residential, commercial (which will include attractions and consumer industries such as shops) and industrial (which will include all non-consumer industries), and borrowing (and probably adapting) the proportions from the original Sim City, have differing proportions of journeys go from different sorts of building. All outward journeys will go from residential buildings (this will avoid having to step commercial and industrial buildings, which will reduce computational load; this will require recalibration of my passenger generation calculations, however), and all journeys will generate a return journey (currently, only out of town journeys generate a return). Some journeys will also create an onward journey: for example, a residential to commercial journey might generate an onward journey from the destination building to another commercial building (and both parts of the journey will also generate a return journey). This is to compensate for not generating passengers afresh at commercial and industrial buildings. Passengers (always originating at residential buildings) will be far more likely to have destinations that are commercial and industrial buildings than other residential buildings, and onward journeys will likewise be weighted.

Perhaps it makes sense for onward journeys to have short time tolerances, for instance when shopping for stuff and comparing prices, you're likely to wander a bit between places, but not likely to go very far between each place.

As mentioned above, I plan to abolish the system of classing journeys as long-distance, mid-range and local. The idea of having this system was to simulate the fact that most passengers travel to local destinations. This is true enough, but this is only because journeys to local destinations take less time than journeys to far away destinations, and we already simulate journey time: there is little point in adopting an heuristic to represent something that is already simulated in detail. All that needs to be done is to have a weighted system for the journey time tolerances (as discussed elsewhere to ensure that the greater proportion by far of tolerances are at the lower end of the range) so that it is no longer necessary to break them down into three linear ranges, and to allow a much larger number of alternative destinations so that passengers are permitted to have many retries to select a viable destination within range, where that range is based on journey time. There is much to be said for having the number of alternative destinations partly set by a formula based on the size of the map (x destinations per 1,000 sq. km, for example). Some careful work will need to be done to ensure that these settings produce realistic proportions of passengers desiring to reach particular locations and that broadly match real life figures as to the distances of their journeys.

So you're saying, the destination will be determined according to time tolerance, and not vice versa as it is now. It's kind of a chicken and egg thing, I guess, but there should be an option for very long journeys to happen because someone really want to go to a specific far away place, and hence they are willing to travel for a very long time to do so. Also, I think tourism should also receive a small, but important portion, with high tolerance of course. Business trips should also be considered.

Also, I must say I never really understood the alternate destination system. If I'm in London want to go to a friend in Liverpool, but I can't get there, I guess I might go visit another friend in Manchester instead, although, it's not great. But if I need to get to work and I can't get there, I'd probably go home and wait for the call from the boss, firing me for the absence. I don't know, I can't really see the sense in alt. destinations.

[Carl]

A small aside on the alternate destination system. I always understood this as a mechanism to make starting out on maps viable. If passengers never had alternative destinations, it would be very difficult to turn a profit until a large amount of cities were connected to a network. With this system, though, it's realistic to make a profit by connecting only a few cities. Is this along the right lines?

[jamespetts]

Thank you for your responses - I am glad that these features are having a positive reception. Let me deal with some of the questions:

A couple of small questions: how will transfer time interact with waiting time? Will waiting time still measure the total time from arriving at a station to leaving it, or will it offset this against transfer time? Also, will transfer time come into play for passengers whose journey originates at the station in question?

Transfer time is added to the waiting time of the departing stop. Transfer time is intended to represent the time that passengers take to get from the entrance of the station to the platforms (gate, jetty, etc.) where they can actually do the waiting. The computation of waiting time is unaffected.

I wonder, if pax will at any case calculate the walking distance as part of the journey, why is the station coverage still needed? Also, I'm thinking walking will need to be limited in some way, to avoid pax from walking unrealistically large distances.

The station coverage is needed for technical reasons - if it were not for station coverage, every stop would have to check every building at every game step, and that would take too much in the way of resources. The station coverage model is fairly fundamental to the way in which Simutrans works, so it would be a very large amount of work to do away with it. The idea of this feature was to find a way of working effectively within existing systems.

As to the limits on passengers walking, I think that I omitted to mention in my original post that, for journeys made up entirely of walking, passengers are limited to journeys of no more than half their normal journey time tolerance. This should make canal passenger journeys viable, since early canal passenger boats travelled at no more than walking speed.

Are there actually cities that completely disallow street parking, other than futuristic "green" new suburbs? I would think this should be part of a needed reform in roads and streets in general - a matter for a separate discussion, but in short I think we need more diversity in roads and streets, in cities for instance it would be cool to have narrow streets, broad streets, alleyways, pedestrian only streets, etc, each with different way type parameters, one of those is street parking.

I rather suspect that this would be a bridge too far, if you will excuse the transport related pun. Having different sorts of streets in a city would be very complicated (the means for determining where each type of street would be built would be very difficult). Smaller buildings will have a number of built in parking spaces in any event. If we want to simulate the fact that street parking restrictions apply only to higher density areas, we might, I suppose, impose minimum thresholds on the levels of the buildings that are affected by allowing or prohibiting street parking.

Perhaps it makes sense for onward journeys to have short time tolerances, for instance when shopping for stuff and comparing prices, you're likely to wander a bit between places, but not likely to go very far between each place.

Not necessarily: think of the long business trip made after a short commute to the office.

So you're saying, the destination will be determined according to time tolerance, and not vice versa as it is now. It's kind of a chicken and egg thing, I guess, but there should be an option for very long journeys to happen because someone really want to go to a specific far away place, and hence they are willing to travel for a very long time to do so. Also, I think tourism should also receive a small, but important portion, with high tolerance of course. Business trips should also be considered.

The system of weighted journey time tolerances should take care of this: a packet of passengers generated with a high tolerance and which hits upon a random destination at some distance away will indeed travel a considerable distance. I do not think that it is necessary to differentiate between tourism and business trips, as the characteristics of each trip are not sufficiently different for the parameters that we simulate.

Also, I must say I never really understood the alternate destination system. If I'm in London want to go to a friend in Liverpool, but I can't get there, I guess I might go visit another friend in Manchester instead, although, it's not great. But if I need to get to work and I can't get there, I'd probably go home and wait for the call from the boss, firing me for the absence. I don't know, I can't really see the sense in alt. destinations.

One should think of the alternative destinations system in somewhat more abstract terms than this: people choose where to work in part based on where they can travel (and where to live on the basis of whether they can get to work in a reasonable time). Alternative destinations represent (in an abstract sort of way) long term choices about where to work, as well as shorter term choices about which shops to visit this afternoon: the overall effect in the game should be the same.

A small aside on the alternate destination system. I always understood this as a mechanism to make starting out on maps viable. If passengers never had alternative destinations, it would be very difficult to turn a profit until a large amount of cities were connected to a network. With this system, though, it's realistic to make a profit by connecting only a few cities. Is this along the right lines?

This is indeed part of the purpose of the system - this offsets the exponential growth in passenger traffic that is seen in Standard where passenger destinations are chosen at random from anywhere on the map and there are no alternatives, which is not economically realistic.

[jayem]

The first of the changes I have written about elsewhere, and I have now implemented on the walking-passengers Github branch: passengers can walk all the way to their destination provided that it is within their journey time tolerance (assuming a straight line journey from beginning to end and a walking speed set in simuconf.tab - the default is 5km/h); and the time for passengers walking from their origin to the first transport stop and from their last transport stop to their destination is taken into account in time calculations both for routing choice and journey time tolerance. No longer will passengers always walk if the stop closest to their origin and the stop closest to their destination are both within the coverage radii of stops: they will take transport if this is faster than walking. The coverage radius system is unchanged, but it is intended that the coverage radius be very greatly increased to go with this feature.

A related improvement that I have implemented just to-day is the transfer time. This takes into account the walking distance inside larger stops and adds it to the journey time. Because of the way in which routing works, it was not possible to make a bespoke transfer time depending on where in the stop/station that particular convoys stop, but the transfer time is based on the size of the stop and is shown in the stop details window in minutes and seconds. This behaves in the same way as waiting time, and is cumulative with waiting time. Small stops have a zero transfer time.

These two measures together make irrelevant the former practice, which is rather an exploit, of covering entire towns with very large stations made up of diagonally connected road stops.

Sounds good, some thoughts to throw in the mix.

I'm not sure about how the transfer time should react, there's a bit of me that thinks it should be the max of the two values.  On the basis that if you were catching a train an hour apart the transfer time (and coffee time) overlaps with the waiting time. 
However then there's the possibility of missing a train, (whether due to real-life bad timetabling or the time it takes) which isn't accounted for and would affect infrequent stations worse, which is probably as well compensated by the adding as anything else.

Will some station buildings reduce the effective station size?  I'm thinking that would give a purpose to escalators and perhaps airport buildings.  If travel time is also standing in for 'time cost' then perhaps restaurants could bring it down, or alternatively up the comfort of the next trip somehow.  The obvious flaw is you'd either need to have lots of code to make them fit in, or accept people gaming the system and hope it's not worth it to them.

On a similar theme walking time (speed), does there need to be any variance to reflect the rich being unwilling to walk.  Or does it all come out pretty much naturally anyway (particularly from the 1/2 journey length).

[jamespetts]

On transfer times, we have to be careful not to let complexity spiral out of control: if we start distinguishing between restaurants and cafes and the like, it could take months just to implement this element of the code (as indicated previously, this feature is already written, albeit without restaurants, cafes, escalators, etc.).

The idea of using a maximum of waiting and transfer time is an interesting one, however, and one on which I should be interested in further comments, as this would be easy to code if it were desirable. I am interested in people's thoughts on whether this or the present implementation of summing the two fits in better with real world transport dynamics.

As to rich people being reluctant to walk - this is simulated with the proportion of people (by default 5%) who will use their private car wherever they can.

[Carl]

I am in two minds about this.

If it takes ten minutes to interchange at a station, and the wait between services is 15 minutes, I only need to budget 15 minutes for transferring there -- not 25. In this respect, Jayem's suggestion seems realistic.

However, I am tempted to think that this is not the case when transfer time > waiting time. If it takes twenty minutes to transfer at a station where the expected waiting time is 10 minutes, it seems that I should budget for more than a twenty minute transfer time. Indeed, I should budget for 30.

[jamespetts]

Hmm - in the former instance, if it takes 10 minutes to walk to the platforms from the street (or from the 'bus stop, or other platforms, etc.), surely one can only begin waiting once one has reached the platforms? It might happen that a train leaves during the transfer time.

[wlindley]

I have been playing the 'git' version where the station radius is 12.  This much improves the game, particularly in the 1830s, as city streets can now sensibly handle passenger loads, and even the somewhat overeager demand for post to boot.

However, industry service is confounded because the early industries tend to be so close together that any reasonably placed station probably overlaps both the supplier and the consumer.  Is there any way to give freight stations a smaller radius?  Or perhaps require that industries will only be served by stations adjacent to that industry or one of its fields?

[jamespetts]

Freight stations are given a smaller radius in the walking-passengers branch: freight will not transfer unless the station is actually touching the industry (i.e., a radius of 1). Passengers bound for or coming from the industry will use the full passenger/mail radius.

[jayem]

Hmm - in the former instance, if it takes 10 minutes to walk to the platforms from the street (or from the 'bus stop, or other platforms, etc.), surely one can only begin waiting once one has reached the platforms? It might happen that a train leaves during the transfer time.

Thanks for the nice response, I think I'm coming in favour of the sum.
I'm utterly persuaded where transfer>=waiting.

I think my model makes more sense [accurate] where I live where transfer<<waiting.  Where two trains crossing over is unlikely because of timetabling*, and in any case you see it and run.
But by definition it's not an interchange (well there is a bus, but...) so wouldn't affect nearly as many passengers as the other.
And likewise it's small so the difference is negligible and even less as a percentage.
[so basically sum is more accurate where it counts, and where not the difference is too small to bother with]

*and in any case you look at the timetable in advance, and plan your day around it (which would make things complex)

[edited [ ] in response to next post up post- and the better symmetry of summing with actual disjoint stations I think seals the deal]

[jamespetts]

Hmm, I think really that summing is better in all cases. The transfer time inside a station is in principle the same as walking time to a station, which was the original intention: this is what makes irrelevant the practice of having large stations to obviate transfers. It makes no odds to passengers whether they arrive at station A then have to walk to station B or if they arrive at station X, which is as big an area as stations A and B combined, and have to walk just as far inside it. Only summing, I think, can give the necessary degree of neutrality between split and joint stations.

[isidoro]

I think the ideas I read on the thread go in the right direction.  Some comments:

• I specially like the walking distance penalty.  But I would also apply it to goods, since the same exploit (artificially huge stations) can be used.
• I will also consider a special penalty when the station covers different heights.  Moving up or down should cost more in time.
• Regarding parking spaces, I would include its penalty inside the general system:  when a (private) car tries to find a destination in a place with few parking spaces, a time penalty is added corresponding to the time the driver is looking for a free space.  This can be done instead of other ad-hoc rules and will contribute to a bias for public transportation in places with a lack of parking space.
• Talking about city growth, a very important factor to be considered is how well end industries (shops, in some paks, most notably in Pak128.Britain) are served.  This should be a two-way rule: if all end industries within the city are well served, the city grows and some more end industries are created.

I hope these ideas are useful.

[o_O]

Sounds good.  All this will be complicated to balance but worth it. 

Certain mass transit stops should have limited car parking built in.  An actual train stop is just a platform, track and ticket booth, but most of them also have their own small parking lot.  Given the tile size they have plenty of extra room for one anyway.

Also, each building only generates a few passengers per month right?  Upgrading them based on successful journeys could lead to very spotty growth due to low sample sizes.  Maybe each building should also take into account the success rate of adjacent buildings to average out the low sample size? 

Also, will pedestrians be able to path through buildings on the assumption there are little alleys and side streets between them? 

[ӔO]

I am definitely looking forward to the changes.

[jamespetts]

I specially like the walking distance penalty.  But I would also apply it to goods, since the same exploit (artificially huge stations) can be used.

I don't think that it makes sense for goods. Goods don't walk - they are loaded onto and unloaded from vehicles. The radius for goods has been reduced to 1 tile, so that goods stations must be touching an industry to collect goods from them. Unlike with passengers, there would be no incentive to create larger concatenated stations, as, given that goods origins are single sources rather than multiple points over a city, there is no advantage of doing so.

I will also consider a special penalty when the station covers different heights.  Moving up or down should cost more in time.

I had considered this, but this is programatically complicated, and may well not be realistic, as many stations on multiple heights have escalators, lifts, etc.

Regarding parking spaces, I would include its penalty inside the general system:  when a (private) car tries to find a destination in a place with few parking spaces, a time penalty is added corresponding to the time the driver is looking for a free space.  This can be done instead of other ad-hoc rules and will contribute to a bias for public transportation in places with a lack of parking space.

To what other ad hoc rules are you referring here? The trouble with this system is that it introduces arbitrariness: the time penalty for going to a building with "limited" car parking is not based on any real life value and cannot be. Also, it does not take account of the fact that the important thing as far as parking capacity is concerned is not the total number of spaces, but the relationship between the number of spaces and the number of users. We can have a fair idea of (1) how many parking spaces that real life buildings have available to them; and (2) the time for which any given user of that building is likely to park there, so we can have a fairly precise idea of what numbers to use for car parking capacity in the game according to the system that I have envisaged.

Talking about city growth, a very important factor to be considered is how well end industries (shops, in some paks, most notably in Pak128.Britain) are served.  This should be a two-way rule: if all end industries within the city are well served, the city grows and some more end industries are created.

The extent to which consumer industries are well served is already, even in Standard, taken into account in city growth by mapping the proportion of goods supplied against goods needed, but this has the problem that, in a city with no consumer industries, this is deemed to be 100%. This might need looking into.

Certain mass transit stops should have limited car parking built in.  An actual train stop is just a platform, track and ticket booth, but most of them also have their own small parking lot.  Given the tile size they have plenty of extra room for one anyway.

The plan was to have various sizes of car parks as something similar to station extension buildings, which could be added to stations and stops as desired. This is more flexible than having car parking built in, and is realistic in that it causes car parking to require land space.

Also, each building only generates a few passengers per month right?  Upgrading them based on successful journeys could lead to very spotty growth due to low sample sizes.  Maybe each building should also take into account the success rate of adjacent buildings to average out the low sample size?

This is not a bad idea, although note that the success rate is averaged over a year.

Also, will pedestrians be able to path through buildings on the assumption there are little alleys and side streets between them? 

Walking journeys are not based on any sort of pathfinding algorithm: it is simply assumed that people can walk anywhere in a straight line. It would be too programatically complicated to be practical in the short or medium term to have pathfinding for pedestrians.

[isidoro]

I don't think that it makes sense for goods. Goods don't walk - they are loaded onto and unloaded from vehicles.
[...]

Precisely.  They don't walk, but they magically and instantly appear on the other end of an artificially 100-tile long station, and are just immediately loaded to the next convoy in the chain...

They don't walk, but they have to be walked...

Regarding a penalty for traveling up and down some levels:

I had considered this, but this is programatically complicated, and may well not be realistic, as many stations on multiple heights have escalators, lifts, etc.

It may be not desirable/realistic, but it is not programatically complicated: just apply a correction factor to the z component of the distance function you use...

Regarding time penalty for parking:

To what other ad hoc rules are you referring here? The trouble with this system is that it introduces arbitrariness: the time penalty for going to a building with "limited" car parking is not based on any real life value and cannot be.

The idea was in connection with your comments about the problem that basing on time travel (and congestion only), few people would choose public transportation.  You said you have to put ad-hoc penalties based on parking space availability.  Mine is to integrate that in the general time travel picture.  When I have to go the city center, I can get there in 30 minutes walking, 30 minutes by bus (considering waiting times) and 15 minutes by private car.  These are real numbers for my case.  But, since in the city center there is nearly no free (no cost) parking space, I have to circle and circle around until I can find one and that may add more than 20 minutes extra.  So, it is that time (apart from costs) that make me not driving to the city center.

How to incorporate that into simulation?  There may or may not be real direct figures, but you can estimate them.  Just record the free parking space in each tile and build a function considering that number in the place you want to go and some tiles around.

Alternatively, include that in the simulation:  when a private car reaches destination, it has to park.  It will roam around looking for a free space in the neighboring tiles until found.  Record the time spent in the destination tile to serve for future calculations.  This has the advantage that cars looking for parking space will add to congestion.  Just like in RL.

The extent to which consumer industries are well served is already, even in Standard, taken into account in city growth by mapping the proportion of goods supplied against goods needed, but this has the problem that, in a city with no consumer industries, this is deemed to be 100%. This might need looking into.

Just force an end industry for each town, which is not very unrealistic after all...

[Bear789]

I'm not a great player of Experimental, but I eagerly follow everything that happens here.
I have a doubt about the industries: if the stop/station must touch the industry, how can you serve farms, since they are spawned sorrounded by fields? If the number of fields is too low (in my experience with Pak Britain, that means every newly spawned farm), the game won't let you bulldoze them to reach the farm.

[jamespetts]

Precisely.  They don't walk, but they magically and instantly appear on the other end of an artificially 100-tile long station, and are just immediately loaded to the next convoy in the chain...

They don't walk, but they have to be walked...

The problem is that we know nothing about the rate: they might be pushed in hand-carts, pulled by horses, lumped in a sack on somebody's back, dumped onto a conveyor belt, put in a little trolley and pulled by a small battery powered road locomotive: there is no constant rate in the way that there is for passengers' walking. This is why we have to build transhipment time for goods into the load/unload times instead of having a separate transfer time. The load/unload times for goods are in any case much, much higher than for passengers.

Regarding a penalty for traveling up and down some levels:
It may be not desirable/realistic, but it is not programatically complicated: just apply a correction factor to the z component of the distance function you use...

It gets complicated if one wants to do it accurately: imagine a vast airport with a small underground railway station: is the transfer time for the whole airport to be trebled just because a few tiles in the corner are two tiles underground?

Regarding time penalty for parking:
The idea was in connection with your comments about the problem that basing on time travel (and congestion only), few people would choose public transportation.  You said you have to put ad-hoc penalties based on parking space availability.  Mine is to integrate that in the general time travel picture.  When I have to go the city center, I can get there in 30 minutes walking, 30 minutes by bus (considering waiting times) and 15 minutes by private car.  These are real numbers for my case.  But, since in the city center there is nearly no free (no cost) parking space, I have to circle and circle around until I can find one and that may add more than 20 minutes extra.  So, it is that time (apart from costs) that make me not driving to the city center.

How to incorporate that into simulation?  There may or may not be real direct figures, but you can estimate them.  Just record the free parking space in each tile and build a function considering that number in the place you want to go and some tiles around.

The trouble is, there is no way of making even reasonably close estimates of this, whereas we can make educated guesses based on real statistics about the number of car parking spaces per building available for parking for any given time. There is nothing particularly ad hoc about the system that I outlined.

Alternatively, include that in the simulation:  when a private car reaches destination, it has to park.  It will roam around looking for a free space in the neighboring tiles until found.  Record the time spent in the destination tile to serve for future calculations.  This has the advantage that cars looking for parking space will add to congestion.  Just like in RL.

This is not really feasible, as route searches for private cars are not carried out per journey (as this would overload the CPU), but abstracted from city to city pathfinding calculations carried out monthly.

Just force an end industry for each town, which is not very unrealistic after all...

This is an interesting idea, but I wonder how this would actually integrate with the current city generation code; and what happens if a consumer industry in a town closes down and the industry density as it now stands does not call for any more industries?

I have a doubt about the industries: if the stop/station must touch the industry, how can you serve farms, since they are spawned sorrounded by fields? If the number of fields is too low (in my experience with Pak Britain, that means every newly spawned farm), the game won't let you bulldoze them to reach the farm.

I have taken account of this, and allowed bulldozing up to half the "minimum" number of fields to allow direct road access to farm houses.

[greenling]

Hello Jamespetts

The radius for goods has been reduced to 1 tile, so that goods stations must be touching an industry to collect goods from them.

I think that's better not to make a radius from 1 for Frieght stations, i have sometime problems to find a flat place to build
a station.

[jamespetts]

Hello Jamespetts I think that's better not to make a radius from 1 for Frieght stations, i have sometime problems to find a flat place to build
a station.

All part of the challenge of the game! Real life transport planners have to face this challenge - freight sidings or loading bays are generally not placed many hundreds of meters from a factory.

[wlindley]

On-street parking, taking a cue from Pak128...

[jamespetts]

That is interesting (although the signs are a bit too big), but this would have to be encoded as a very small public car park, and would not affect congestion. These appear to be designated parking spaces on the side of the road, rather than people just parking in the main carriageway, which is what I had in mind when considering street parking.

[isidoro]

Thanks, James, for your answers.  I can know see problems that I overlooked at first sight.

[jamespetts]

Thanks, James, for your answers.  I can know see problems that I overlooked at first sight.

Thank you for your inputs - they were most useful. I am still interested in the idea of forcing a consumer industry in each town, as this would be very helpful with the growth model. If you had any thoughts about how in principle this might be made to fit in with the existing game architecture, I should be most interested.

[MCollett]

This year, I have been working on what I hope are significant improvements to the way in which passenger transport is handled

Lots of good ideas - I look forward to seeing them in action.

A related improvement that I have implemented just to-day is the transfer time.

A couple of observations on the question of adding this to waiting times:

• There do exist specifically scheduled connecting services.  For example, two trains that are intended to have a substantial number of passengers transferring between them may deliberately stop at adjacent platforms to minimise the time required for the transfer.  But such things are only a small fraction of all the transfers that actually occur.
• If there is a transfer time of 10 minutes, and the train being transferred to has (ignoring the transfers) an average waiting time of 15 minutes, then the sum of 25 minutes is the generically correct estimate.   If the second train is scheduled to leave 15 minutes after the first one arrives, then the actual waiting time of the connecting passengers will only be 5 minutes.  If this is a connection used by many passengers, then in the long run the calculated average waiting time will reduce accordingly.

(In other words: short of introducing impracticably fine-grained analysis of both transfer and weighting times, yes, adding them is the right thing to do.)

Best wishes,
Matthew

[sdog]

Quite interesting and very sensible choices. When it is doable, it could increase the depth of simulation for pax transport quite a bit. While going quite far away from the initial concepts of simutrans.

As mentioned above, I plan to abolish the system of classing journeys as long-distance, mid-range and local. The idea of having this system was to simulate the fact that most passengers travel to local destinations. This is true enough, but this is only because journeys to local destinations take less time than journeys to far away destinations, and we already simulate journey time: there is little point in adopting an heuristic to represent something that is already simulated in detail. All that needs to be done is to have a weighted system for the journey time tolerances (as discussed elsewhere to ensure that the greater proportion by far of tolerances are at the lower end of the range) so that it is no longer necessary to break them down into three linear ranges, and to allow a much larger number of alternative destinations so that passengers are permitted to have many retries to select a viable destination within range, where that range is based on journey time. There is much to be said for having the number of alternative destinations partly set by a formula based on the size of the map (x destinations per 1,000 sq. km, for example). Some careful work will need to be done to ensure that these settings produce realistic proportions of passengers desiring to reach particular locations and that broadly match real life figures as to the distances of their journeys.

I'm rather sceptical about this change, as it would require an increase of alternative destinations. If re-trying very often, the result will be that a passenger finds a reachable destination most of the time. This would cancel the network effect. The massive gain in passenger numbers when you increase your network, or speed up conexions to distant nodes of a network. Since the passengers with destinations there would not have started the journey otherwise.

[jamespetts]

I'm rather sceptical about this change, as it would require an increase of alternative destinations. If re-trying very often, the result will be that a passenger finds a reachable destination most of the time. This would cancel the network effect. The massive gain in passenger numbers when you increase your network, or speed up conexions to distant nodes of a network. Since the passengers with destinations there would not have started the journey otherwise.

This requires some careful thought generally. At present, what happens is that passengers first pick weighted random destination in the same way as they do in Standard (that is, weighted to favour buildings with a higher level over a lower level from a list of all the possible passenger destinations on the map). Then, the straight line distance is checked between the origin and destination, and, if it is outside the assigned distance range, a new destination is chosen at random. This process continues until either a destination within range is picked, or a fixed number of retries has expired, whichever is first. The passengers then attempt to find a route to that destination. If they cannot find a route to that destination that is within their journey time tolerance, the process is repeated until the number of alternative destinations assigned to that passenger expire.

What I had planned to do is, in effect, combine those first and second steps, and journey time tolerances stand instead of straight line distances (which straight line distances are in any event merely proxies of journey times). Not all passengers have the same number of alternative destinations. The number is assigned at random between zero and the specified maximum. The same would hold once the maximum is increased to allow for this feature. If we know approximately and on average how many retries are required under the existing system to get a destination within the current geographical limits, we can use that number in calibrating the number of alternative destinations for passengers to have. It should be noted that passengers picking alternative destinations from anywhere on the map, rather than just within a certain geographical radius, will reduce the chance of any given alternative destination being a reachable one (all other things being equal), which concomitantly reduces the effect of having any given number of alternative destinations compared with the present system, where most passengers are local, and therefore most alternative destinations will be within a short geographical range. It is also worthy of note that some parts of the map will be denser than others (having more higher level buildings), so a higher proportion of destinations will be in those areas. This will create a (realistic) differential in the number of successful journeys from dense and from sparse areas, as people already in dense areas are more likely to pick nearby destinations.

Properly calibrated, I think, this feature can have the same effects as are intended by the present system, but be more efficient and accurate. To take account of the fact that geography is relevant, having the number of alternative destinations being adjusted to take into account the size of the map is of some importance: there is a much greater likelihood of any given randomly picked destination being within a short distance (and therefore probably having a lower journey time) on a small map than on a large map, and that likelihood is proportional to the number of square kilometres in the map, which is why I plan to have a system of specifying the number of alternative destinations per square kilometre.

[waerth]

I love what you are proposing to do.

There is one thing that has me slightly worried though. The thing about industries needing to be supplied for towns to grow. I usually only play passenger networks myself which I consider enough of a challenge. So will you really go this way that the player needs to transport goods as well? Or am I misreading it?

Sometimes; like in my current 1835 game, I will transport mail as well. But that has currently greatly overtaxed my network (the amounts of mail are plain insane :( ) and I am finding myself building intricate railway lines similar to metro lines (with 1830's trains) with high frequencies just to get the mail transported!

Which brings me to a question: Will you also do some recoding for mail levels?

[jamespetts]

There is one thing that has me slightly worried though. The thing about industries needing to be supplied for towns to grow. I usually only play passenger networks myself which I consider enough of a challenge. So will you really go this way that the player needs to transport goods as well? Or am I misreading it?

I have not fully formed my view on this point yet: it arose out of a suggestion by Isidoro that the supply of goods to consumer industries should be important in the growth of towns, which suggestion I have been considering. Even at present(and in Standard), the supply of goods to consumer industries in towns affects their growth rate, but a problem arises in that some towns do not have any consumer industries, so they are deemed to be 100% supplied, leading to arbitrary differences in growth rates between towns that do and do not have consumer industries. Isidoro suggested that every town should be forced to have a consumer industry, but this presented possible problems the solutions to which are not apparent at present. One possible simple solution would be to have towns with no consumer industries deemed to be 0% supplied, giving a growth advantage to towns with consumer industries, but still allowing towns without to grow to some extent.

Sometimes; like in my current 1835 game, I will transport mail as well. But that has currently greatly overtaxed my network (the amounts of mail are plain insane :( ) and I am finding myself building intricate railway lines similar to metro lines (with 1830's trains) with high frequencies just to get the mail transported!

Which brings me to a question: Will you also do some recoding for mail levels?

Mail does need reconsidering, too: it might well be that the stepping of buildings for mail generation needs to be separated from the stepping of buildings for passenger generation, such that we step all buildings (not just residential buildings) for mail, but do so far less frequently than for passenger buildings. The issue of calibrating mail volumes is discussed more fully here.

[o_O]

Each town could have a "market square" which consumes smallish amounts of a variety of goods with larger outlet stores tending to appear in cities.  This would also provide a niche for companies that start small, relying on public roads to service a network of rural villages. 

[kierongreen]

Regarding car ferries, the plan is for a generic vehicle transporter type, capacity will be indicated by length of vehicles transported and, if implemented private cars will load if they enter a terminus stop and there is a waiting vehicle transporter. The intention is not just to simulate car ferries but train ferries, Eurotunnel, motorail and more.

[jamespetts]

Interesting - how would you have private cars being generated? How would you handle the relationship between private cars and passengers (1) at the generation stage; and (2) in the vehicles?

[kierongreen]

I would just use the standard code for private car generation it doesn't really affect that. Passengers would be assumed to stay in the vehicles being transported.