Improving the simulation of passenger walking - the simple way

[jamespetts]

I have in the past considered rather theoretically a number of quite complicated ways of simulating the fact that people are sometimes prepared to walk far further than the current stop catchment area and generally improving the simulation of people walking from place to place. These complicated ideas would have involved a re-working of the station catchment area idea, which would require major surgery to the code and be a very large project.

However, it strikes me that there is a much simpler way of achieving as much as sensibly needs to be achieved for our purposes by using the existing journey time tolerance feature. If we ascribe to passengers a walking speed, we can work out how long that it would take them to walk to their destination (on the assumption that they are able to walk in a straight line - we might need to knock 1km/h off the walking speed to compensate for the fact that people often can't) and use the journey time tolerance to see whether they can get where they are going by foot within a reasonable time. (Currently, passengers will only consider walking within the stop coverage radius). To compensate for the fact that people get tired while walking, we can reduce the effective journey time tolerance for a walking journey compared to being a passenger by a simple expedient such as halving it (or a more complicated expedient of halving any margin over some figure, such as 15 or 30 minutes). By this simple method, we can simulate the fact that, in days of old, people would sometimes walk a very long way to get to their destinations, but, because of having to walk, would travel overall far less than now - the number of people generated with the journey time tolerance to walk such a long distance will be suitably low once the journey time tolerance system is recalibrated as I propose.

As to the interaction between this and a player's stops, it can be made quite simple by just adding the calculated time for the walking journey from the origin building to the first stop to the overall journey time for all possible journeys from all reachable stops from the building generating the passengers. This would then make the proximity of a stop to a passenger's origin building a relevant factor in deciding which transport to use from a given point: at present, all stops whose coverage radius includes any given building are treated equally, the passengers choosing the route based on the journey time from one of the origin stops. One of the effects of this would be to increase the diversity of passenger routing, especially on local journeys. This will also make the walk to the origin stop consistent in its treatment with the existing method of considering the walk between a pair of intermediate stops when the setting allowing walking connexions is enabled. The same could be done for the distance between the destination stop and the building that is the passenger's ultimate destination.

However, another consequence of this springs to mind. If the coverage areas on stops are made considerably larger, then we can properly simulate the reality of transport in areas not covered by a dense grid of local connecting routes: some people, but not all people, will make a long journey on foot to their local station/'bus station/airport/etc. Some passengers will have a very low journey time tolerance, and if the walking time to the origin stop plus the intermediate journey plus the walking time from the destination stop to the ultimate destination building will exceed their tolerance levels even if the intermediate journey - the only thing taken into account now - does not.

If the coverage areas are expanded, players will be able to serve towns by placing a railway station on their borders without having to build a large 'bus network. This will remove one of the unrealistic aspects of the game at present (and that which can introduce distortions into the game play and confuse new players), where players have to infuse a town with a dense local transport network in order to run a profitable long-distance service from that town. A town would still be better served if it had such a dense network, but it would be optional rather than necessary, at least for smaller towns. 'Bus networks could grow organically on a commercial basis, possibly by a different operator than a railway company building into the town, rather than being an essential component of any long-distance transport network serving the town.

One issue is how to make clear to the player what is happening. Perhaps the best way of doing that is to give players a list of the stops with passenger facilities within a building's coverage area when a player clicks on a building, together with the walking time from that building to each stop, for example:

"Stops potentially within walking distance:
- Charlford West Station - 12 minutes' walk;
- Charlford High Street Stop - 5 minutes' walk;
- Charlford Meadow Street Stop - 2 minutes' walk;
- Charlford Cross Stop - 25 minutes' walk"

and so forth. This would be relatively easy to code, since there already exists code for determining which stops are within a building's coverage radius, used by the passenger generation code.

I also wonder whether this refinement would enable a means of checking whether any given prospective site for a city building is well connected enough by transport to a potential workplace (in the case of a residential building) or to a a source of workers (for a commercial or industrial building) to be worth developing, and, if so to what level, although I have not yet fully thought through a system of doing so.

[wlindley]

Excellent!  A village or even a small town could logically then have a single bus stop or railway station to serve the whole town, as would be realistic.  Beyond five minutes walk, adding a bus or tram station or two would decrease total travel time and increase use of the main-line services... all of which are perfectly prototypical.

Presumably there would be a commensurate increase in the cost of stations to match -- but the net cost would be similar, and the effect far more realistic.

No longer would we need absurd stations with a dozen bus-stop tiles to expand the catchment area!

[asaphxiix]

Sounds great! Excellent simulation

Some passengers will have a very low journey time tolerance, and if the walking time to the origin stop plus the intermediate journey plus the walking time from the destination stop to the ultimate destination building will exceed their tolerance levels even if the intermediate journey - the only thing taken into account now - does not.

I think this needs rephrasing

[ӔO]

I think it's a good solution.

I can't help, but wonder, if it is possible to add a small chance, around 10% to 20% the person will walk at 3x the walking speed, by riding a bike.

Assuming an average person can walk at 5km/h, a bike would do 15km/h

but if that's too complicated, then the walking only is perfectly suitable.

[Carl]

Just to add to the chorus of support for this proposal.

[jamespetts]

I think it's a good solution.

I can't help, but wonder, if it is possible to add a small chance, around 10% to 20% the person will walk at 3x the walking speed, by riding a bike.

Assuming an average person can walk at 5km/h, a bike would do 15km/h

but if that's too complicated, then the walking only is perfectly suitable.

I was wondering about this - what we'd have to do is something similar to what is currently done for private car traffic, and have a .tab file with the proportion of people with access to a bicycle at any given time and then generate a weighted boolean value at the time that the passengers are generated as to whether these particular passengers have access to a bicycle.

However, we have to consider: how do we simulate the question of whether bicycles can be conveyed on transport or whether there are bicycle parking facilities at the destination? Remember, the routing system (which is highly optimised and with which I do not wish to interfere) only returns a journey time to the destination station and the next transfer - no other details.



One thing on which I am really quite keen is the simulation of transport influenced urban development, which I foreshadowed a little above. I am still thinking of a workable way of doing this, but one method would be to check any tile on which a city proposes a building and see how many possible destination buildings are within x minutes' journey; or, perhaps more accurately, calculate what proportion of passengers would be able to get to how many buildings of what level at the current journey time tolerance settings. In other words, we might say that, for each building (or each of a subset of buildings: see below) that is a possible destination building (i.e., if this is a residential building, the building is a commercial or industrial building or an attraction; if this is an industrial building, the building is a residential or commercial building; if this is a commercial building, the building is a residential or another commercial building, etc.), the tile gets a rating of the level of the possible destination building, multiplied by the proportion of passengers who can reach it within their journey time tolerance by whatever is the fastest means of transport available (including walking, cycling (if this is implemented) or, for that proportion of passengers who have access to one, using a private car. The journey time both with and without a private car (and bicycle, if implemented) would have to be calculated to the destination building and a calculation made from that of the proportion of passengers for whom those journey times are within their tolerance.

However, this searching is not simple, as there is no easy way in the game to tell how far away that a building is without first finding the building in the city's weighted vector then checking its location, then running a shortest distance algorithm. This is a potentially costly process if done for every building in the game when there may be 300,000 or so of them in a well developed game. One possible means of limiting this search would be to look only for buildings in the current town plus towns within a set radius of the present tile (perhaps the maximum distance for mid-range journeys, which will be 80km in the next release of Pak128.Britain-Ex). This would simulate the fact that people do not usually consider convenience for long-distance journeys when deciding where to live or do business. We could continue to simulate the effect of long-distance journeys on development in the current way, by having the town's growth demand based on the total proportion of successfully transported passengers, mail and goods, which would therefore include long distance journeys. This would involve a de-coupling of the current growth demand mechanism from actual development, as, with this system, a building of any given level would only be built if the destination tile was sufficiently well-connected to transport. It would then be necessary to alter the way in which population is counted, so as to include only population arising from buildings, although that is under consideration as part of the calibration of the passenger generation mechanism in any event.

Private car use will need further consideration. This thread's discussions have shown that attempting to model building to building private car trips (as is done in Sim City 4) does not look as though it will be possible for a large Simutrans sized map within the confines of what is possible with current hardware, but some consideration will need to be given to this topic to see whether at least a rough idea of the journey time between different towns or within a town can be generated based on actual road connexions and conditions. Assuming that everywhere is connected by road is unfortunately crude for our purposes.

The calculation of congestion will need to be refined, too. Presently, it has no effect on private car journey times, but is a somewhat arbitrary number which dissuades people from making private car trips when it is too high. This needs to change, I think, since we need to simulate the effect on journey times of congestion in order for the development model to work. If we are simulating the impact on journey times, we can also begin to calibrate congestion in a realistic sort of way, even if it will be somewhat approximate and based on statistical assumptions, rather than the tile by tile congestion model that would be ideal (but which seems for the moment too costly in terms of computing resources for anything other than an infeasibly small map). We can use statistics of the real life average car speed in certain towns and cities to get an idea of how congestion affects private car journey times. Using this for intra-city travel is easy enough - one can simply substitute the congestion adjusted average speed for the raw average speed actually attainable on town roads when calculating the time from the distance. On journeys between cities, it is trickier, since some of that journey will be done (1) in another town; and (2) on roads outside any town, on each of which the congestion may be different (and on the second of which we presently do not simulate congestion at all, and does not seem as if it will be possible to do so within the confines of present hardware for anything other than small maps). Some sort of formula is needed for determining what proportion of a journey is affected by the town's congestion levels and therefore the congestion adjusted average speed (and one might make an assumption that congested towns tend to have the roads leading into them congested, too, and adjust accordingly; indeed, perhaps the answer to the above conundrum is simply to average the congestion of the origin and destination towns when making assumptions about the journey speed, although some accommodation must be made for the fact that a long distance journey road between two heavily congested towns will be made at considerably greater speed than the town road speed. Perhaps the better thing to do is take the radius of each town as the journey distance completed within that town, and the remaining distance (if any) as the journey time on country roads).

Some consideration is also needed as to how to represent this to a player. Do we replace the current congestion rating with a graph showing the average private car speed in a town? We might want to remove the current effect of congestion on growth (with the congestion rating being a percentage figure of the proportion to which growth is impaired, 0 being no impairment from the basic model, and 100 and above entailing no growth at all), and replace it with the more organic effect that buildings simply will not be built if the journey time to nearby useful locations is too high. We can then also replace the current and rather approximate system for determining whether people use private car or public transport based on the congestion rating itself, and use instead a comparison of the respective journey times between the modes, the private car journey time now taking into account congestion more precisely.

If all this is done, however, we can have a wonderfully realistic set of transport driven development, and simulate the delights of suburban sprawl and "Metroland" of the early 20th century, as well as the vast increase in town size in the 19th with the coming of the railways.

[inkelyad]

This would simulate the fact that people do not usually consider convenience for long-distance journeys when deciding where to live or do business.

I believe it is not true for Japan, for example.

[jamespetts]

I believe it is not true for Japan, for example.

Hmm - I do not know the details of this, but people's primary consideration tends to be their journey to work and the shops and so forth. Certainly, it would not be possible within the confines of the computationally viable to search for journey times to all reachable buildings for every possible development tile.

[inkelyad]

Look at  Japanese simutrans maps. They love fast semi-local train transport.

[jamespetts]

How far is "semi-local" here?

[inkelyad]

For example: http://janneinosaka.blogspot.ru/2008/01/commuting-time.html

[jamespetts]

Ahh, those are times. We can deal with these using journey time tolerances, as described. The actual distances are not given here. In order to make this computationally serviceable, it would be necessary to limit the search to buildings in a town within a certain distance.

[ӔO]

probably best to just look at average speeds and work out the distances from there.

Keikyuu does something like 70km/h to 80km/h average with their express service. Top speed 120km/h
JR West does something like 92km/h average with their new express. Top speed 130km/h

local service may only hit something around 40km/h to 60km/h average speed, even if their top speed is 80km/h to 110km/h. This is due to local services waiting at stations to let express services pass through. Typically, you will see two express services passing before a local train will depart. Some places, like Meitetsu have up to 3 express trains passing, at the cost of the local line being extremely slow, with an average of less than 40km/h.

You also might only have 1 or 2 local service per hour, where as express can have around 8 per hour.
Station spacing is around 800m to 1200m and express services, obviously, skip most of them.

Or, actually, to give an idea of how slow some services are, take a look at Yamanote Line. That's 29 stations, 34.5km loop with top speed of 90km/h, yet it takes just over one hour to do a full loop.

[jamespetts]

Could this not be dealt with simply by having a higher radius for medium distance passengers in a Japanese pakset? In the UK, very few people live more than 80km from work.

[ӔO]

I think 80km would be the high side. Most people would be in the 40km to 60km bracket.

[jamespetts]

Well, indeed - 80km would be the upper limit.

[greenling]

That it a heavy idea.

[asaphxiix]

one major issue to consider about this great feature to be introduced is that it will no longer be possible to separate different operators within the same city or even in proximity out of the city.

With the new pax generation system and further fixes and enhancements, perhaps such separation won't be necessary, if no refund effects will occur from connecting two large networks, for instance, but until then, introducing this feature may be problematic.

[jamespetts]

It ought not be possible to separate networks in this way, as that is not realistic. Indeed, this absence of separation might well make passenger routing more stable.

[asaphxiix]

It ought not be possible to separate networks in this way, as that is not realistic. Indeed, this absence of separation might well make passenger routing more stable.

indeed, far more realistic this way. It's game-play that I'm worried about, but I do hope that this problem will be mitigated as said above.

regardless, I'm all for it.