Outline of proposed and work in progress changes to passenger transport

[jamespetts]

You are referring to the code for the generation of citycars in Standard?

[kierongreen]

Yes.

[jamespetts]

Wouldn't this be problematic in that the patronage of actual services would depend on the "citycar_level" setting?

[kierongreen]

I don't see that as a problem. It means that on the one hand traffic clogs up roads, on the other it gives you income from ferry fares.

[Michael Hauber]

Hi, I hope you don't mind my late contribution to this topic....

I'd certainly love to see improvements to the passenger generation, and how this interacts with city growth.  One aspect that I really notice is that a hub station within a city is currently a drag on growth, whereas in reality I would expect it to be an important contributor to growth.  Currently hub stations are very difficult to keep from overcrowding, which reduces passenger generation locally and reduces city growth.  All the extra passengers that arrive at the station have no impact on growth at all.  A quick and dirty change would be to give city growth a boost based on the number of passengers arriving at stations within that city.  A problem then would be that a passenger network with many transfers would generate more arrivals at a station and more growth region wide than a network with more direct connections to destination.

I have mixed feelings about the proposal for a simcity 4 style travel to work algorithm.  I love the idea in theory as it would seem much more realistic - commuting to work is a critical factor in real world transport planning (although I have seen it stated that in Brisbane the second biggest trip generator after the central office district is the University of Qld).  However the result in simcity 4 seemed to be rather bland in my experience, and I suspect much of this was caused by residents having  an unrealistically strong tendency to commute to the nearest available job generating zone.  Very few journeys seemed to go to more distant zones.

A possible approach would be to give each job and each commuter a skill number and a level number.  The skill number would be random over quite a large range - something like 1 to a million - and would reflect the wide variety of jobs, eg receptionist to gardener to electrician etc.  The level number would be a fairly small range - maybe between 1 and 5 with 1 being common and low level simple jobs that can be found in any small business, and 5 being rare and specialist high level jobs that can only be found in large corporations or other organisations that will tend to cluster around large city centers.  Each job seeker would attempt to find a job preferring a closer match for skill number (but no need to be exact), preferring a shorter commute, and requiring the same level. 

A similar approach could be used for shopping trips, reflecting the wide variety of different types of products that can be purchased, and the fact that low level products can be found at the local corner store and high level products may need a specialist in the city center that has to have a large customer catchment to have enough customers to be viable.

I'm not sure if this is computationally viable.  But perhaps if instead of selecting a destination and then performing a route search, it might be possible to perform a route search to no specific destination, but instead return whatever destination is found with the best match to the skill/product number with the correct level number and within the journey time tolerance.

Growth for commercial buildings would then depend on whether enough customers find a route to that building, and if the number of customers is too low the business will close down.  Clustering for higher level services might be achievable by allowing longer journey time tolerances, and requiring a high number of residents in the catchment area for a business to be viable (this may not mean high number of customers, just that residents only rarely require services at a higher level).  In contrast a lower level service can set up in a more isolated suburban location and have enough of a travel time advantage over a central location for a small number of local customers to be viable.

Regarding the issues around using a journey time tolerance and repeated attempts to find a destination, an alternative algorithm would be to replace the journey time tolerance with a distance bias.  A destination is selected, and if the destination is close by more passengers are generated, and if its far away less are generated.  A function such as 1/distance could then be used to more precisely control how many passengers attempt to travel to destinations at a certain distance.  Although it will still depend on how many destinations are actually available at that distance.  An issue with this approach is that an origin with many close destinations will tend to generate more passengers on average.  The number of passengers generated would have to be compared to a target number and if it is consistently high or low over time the passenger flow would then need to be adjusted up or down to compensate.

[jamespetts]

Michael,

welcome to the forum! Thank you for sharing your interesting thoughts. I am not far from a release at present, so significant changes will have to wait until the next release now, although I should add that the changes from the last release should reduce the tendency to overcrowding that you notice, which might well at least partly solve the issue with hub stations in any event.

The assignment of workers to jobs is a difficult area: I am not sure whether or not having different types of workers and jobs will be a viable solution (I shall have to consider that along with other things in greater detail), but what we probably do need if possible (and I am still not sure whether this is possible) is a lasting affinity between a particular household and a particular workplace so as to give rise to established patterns of commuting, which in reality have a substantial effect on transport planning: the Thameslink project in London, for example, which aims to increase capacity on the North-South link through central London initially planned to change services from Wimbledon from going through the centre to all terminating at Blackfriars in the Southern part of central London, albeit with more trains from a greater variety of destinations still going through the central section. This plan had to be revised after strong opposition from people who had bought houses along the route specifically because it gave them a direct commute to places North of Blackfriars. How best to establish and change patterns of commuting of this sort, however, I have yet to consider, although I note the relevant point about the importance of realistic distribution of assignments of origins and destinations (but that includes the preference of people to live closer to work if they can).

Commercial buildings should indeed have their growth at least partly based on the number of non-commuters that travel to them: that is already planned. Quite how to handle "closing down", however, is another matter, since Simutrans currently does not have a concept of building abandonment or closure, except for industries in Experimental. One possibility might be to downgrade buildings rather than close them down. As to different types of products being bought at shops, I am not sure how well this could be made to work, and I suspect that it would be particularly difficult and time-consuming to balance at the pakset level.

As to journey time tolerance and distance: the current system uses a mixture of both, with trips generated within certain bands of distance and journey time tolerances set for each trip based on which of the three distance bands (local, medium or long-distance) that people fall into. This is not ideal, because the middle distance band in particular ends up with large numbers of people travelling from large towns to neighbouring small towns even though there is very little of interest there, just because it happens to be within the middle distance band. How far that people travel is actually based on (1) how interesting that the things in near or far places are to people; and (2) how long that it takes to get to those places. Distance per se is not part of the calculation (although people can use it as a means of estimating journey time). We thus need to replace distance based distribution with a system that combines how interesting that the destination is (for which "level" is a proxy) and the journey time (for which multiple destinations combined with the journey time tolerance is the method of simulation).

[HarrierST]

Sorry for the bump.

Has this feature on car parking now been included in Experimental? It is a very realistic idea.

If it has, have you also added out of centre 'car park/bus' links?

Example:

Where I live, you can drive into the town/city centre during the day, but only park in private areas, or short term parking areas (medium cost, but only for  1 or 2 hours) /or long term car parks (all day but expensive) or very few side streets. (expensive but only up to 1 hour) .

So if you live locally - catch the bus, etc. As proposed in this thread.

For people living elsewhere, we have  out of town Car Park/Bus Ride locations (6+ at the moment).  Very cheap, as you park the car,  pay one fixed fee for the day - but up to 4 people can board the bus into the centre and back - on showing the carpark ticket. Only drawback is - the bus back  finishes to early in the evening. So going to the theatre or for an evening meal means you have to pay for a taxi to get back to the out of centre car park.


If not implemented - what would be needed is a combined car park/bus stop graphic feature.  Program wise the number of cars arriving generating the number of bus passengers ( 1/1 to 4). Same with  passengers on bus's arriving, determining how many cars leave (1 to 4/1) plus possibly an additional random number. (to smooth out the odds for departing cars).

[jamespetts]

Car parking has not yet been added, but is still planned. The trouble is that it takes a long time to implement each new feature, and car parking is of lower priority than things not yet complete. I am glad that you like the idea, however.