City extension and building renovation around stations

[Phystam]

Hello, James and everyone!
I have considered the city extension in simutrans-extended which become extremely square.
In the real world, the city grows together with the transportation network, so the more citizens will live around stations.
However in simutrans-extended, the method to renovate city building is:

1. get the center coordinate of the city
2. select a building randomly
3. calculate renovation probability from the distance between the building and the city center
4. if okay, then renovate the building.

And also, the method to build new building is:

1. get the empty tiles within city border
2. build road or building
3. if there's no empty tile, enlarge the city border.

These method is not real because they don't consider station existence.
So I tried to include "station effect" using a model which depends on station capacity and the distance between building and the station.

1. select a building (or empty tile)
2. get some nearby stations and distance of the building
3. calculate the renovation (or build) probability using "Woods-Saxon distribution" (<- usually used on nuclear physics)
p(distance)=log(station_capacity)*10 / (1+exp( (distance-(2/3)station_coverage)/(station_coverage/12) ) )
4. if okay, then renovate (or build) the building

This method will make new city area around large station and old city area with less transportation, and avoid that square city shape.
In fact, the probability don't depends only the station capacity but also the number of passengers, so it is necessary to include this factor.

How do you feel this idea?




This is my github repository:
https://github.com/Phystam/simutrans-extended/tree/city_renovation

Mod note: please avoid making unnecessary double-posts. Edit your last comment instead.
~IgorEliezer



The attached screenshot shows the feature when I used the "+100 people" tool.
They act like they are attracted around station

[THLeaderH]

The idea that places near a big station is more developed is good.

3. calculate the renovation (or build) probability using "Woods-Saxon distribution" (<- usually used on nuclear physics)
p(distance)=log(station_capacity)*10 / (1+exp( (distance-(2/3)station_coverage)/(station_coverage/12) ) )

I doubt station capacity itself is a factor of development. A place flourishes because it is "convenient" to go to other places. The number of stops that can be directly reached from the halt has a meaning, IMO.

Moreover, it is not always the fact that a place that has a convenient public transportation flourishes. For example, in rural area of Japan, there are many big stores along a major road and the surrounding areas of a railway station is desolate. Needless to say, people gather around the big stores that can be reached by private cars, not a shopping street near the railway station.

Current renovation rule of simutrans extended that buildings near the "center" of the city area is more likely renovated is odd, I think. At least, buildings near the city hall should have a priority, or the rule of simutrans standard is actually preferable.

[Phystam]

As you say, there are many factors on the city growth, for instance, shops, city halls, coal mines and other factories etc...
In my current modification, I focused on the "station capacity" which is only one feature of city growth listed above.
I don't think this version is the best, so we should consider other factors...

[jamespetts]

This is very interesting - thank you for working on this. I have long planned to implement a local town growth system based on actual transport metrics (somewhat along the lines suggested by ThLeaderH): see here for the list of current development projects, which includes town growth. For reference, the relevant parts of that post I reproduce below:

Town growth based on local transport

Currently, towns grow based, in part, on the overall number of goods, mail and passengers transported in that town in proportion to that town's demand, as well as the proportion of electricity supplied to that demanded. The actual pattern of growth within a town is based on fixed rules.

What needs to happen in order to have realistic growth and to simulate the historically and economically significant phenomenon of commuter housing being built specifically along transport routes (Metro-Land being the most well known example) is for the places where cities build new buildings and the level to which buildings are built depending on the quality of transport in that specific immediate vicinity, rather than the town as a whole.

To do this, it be necessary to use the success percentages of passengers/mail/goods transported from and to city buildings and factories (this information was always present for factories, and is recorded for city buildings from 11.0 onwards) in two ways: for existing buildings, how far and fast that they upgrade to larger buildings should depend on these percentages, and for new buildings, the higher the percentages of neighbouring buildings, the greater the chance that a new building will be built on the location.

Different sorts of buildings should care about different statistics: residential buildings should principally respond to commuting success rates, as people tend to follow jobs, but also to a lesser extent to non-commuting success rates, as how easy that it is to access leisure (etc.) facilities is of importance to people. Industrial city buildings should respond mainly to the extent to which local industries (that is, actual industries that accept goods other than those which consume but do not produce, which should be deemed commercial, not industrial city buildings) are well supplied, and should prefer to grow near actual industries, but should also respond to a lesser extent to commuting success rates, as it is important that there are enough people to fill the jobs (this should be secondary, as people come to the jobs rather than industry to the people). Commercial city buildings should respond principally to the success rates of non-commuting trips ending in commercial buildings, as commerce needs customers, but should also respond, to a lesser extent, to commuting success rates and the success rates of local end-consumer industries (presumed to be shops) in receiving goods, to ensure that they are well supplied.

Conurbations and districts

At present, towns can grow to overlap each other as in reality, but the two towns retain their equal status as towns, which can cause anomalies in determining which town any given building is in.

What ought to happen is that smaller towns that are encroached upon by larger towns become absorbed into the larger towns, and cease to be full towns in their own rights, but become instead districts of the larger town.

Whenever one town hall falls within the boundary of another town, whichever of the two towns is the larger should be converted into a conurbation, and the smaller town into a district of that conurbation. Any other towns or villages absorbed by the conurbation would also become districts.

This should affect the town statistics, such that the statistics for the conurbation are the statistics for both the original town and all the districts in the conurbation, whereas the districts retain separate local statistics. Likewise electrical supply to any part of the conurbation should give power to all districts of the conurbation, and private car routing should treat the conurbation as a single town and journeys between districts of that conurbation as journeys within a single town, rather than journeys between towns. The existence of conurbations ought also to affect how stops are named, with docks, airports and first stops taking the conurbation rather than the district name.

This may not directly affect town growth if implemented after the local town growth feature described above.

Neroden had proposed something similar a few years ago involving the larger town completely subsuming the smaller town and removing the town hall, but that would be difficult to achieve technically, since pointers to the original town which would, on deletion, become invalid, would be strewn around the code and hard to unpick. In any event, I believe that the idea of having conurbations with separate districts is more realistic (and will also give more variety to local stop names).

and

Towns generated to serve industries [*B]

Currently, industries require passengers to work in them, or else they will cease to function, but there is no way of making sure that, in early eras when transporting lower class workers to farms from their homes by horse would have been uneconomic, industries are in walking distance of a town. It is not practical to secure this result by using the industry's maximum distance to its consumers, as this would result in that distance being too short in many cases.

A solution to this is to spawn a new town whenever an industry is built too far from an existing town. Whether an industry is too far from an existing town should be determined by a maximum distance to town parameter in the industry's .dat file. The town that spawns will need to be a small town, just enough to supply the industry with employees.

Careful thought will need to be given to how this interacts with the planned improved town growth mechanic (on which see below) and additionally how this works when maps are generated: if a player has specified a certain number of towns, this has the potential to interfere with that setting if it applies on map generation by creating more towns than the player requested; yet, if it is not used on map generation, many industries generated on map generation may be too far from the nearest town to attract enough workers on foot to operate.

Consideration will have to be given to how town naming should work when automatically generating towns in online games. Currently, town names are generated using the asynchronous random number generator, as using the synchronous random number generator causes loss of synchronisation between server and client when the server and client have different language files. Ideally, the name should be set by the server and propagated to clients, but I am currently unsure how well that this will work with existing code structures.

You will notice that all of the buildings in the game have some values for passenger success (residential buildings), or jobs/visitors (other buildings). The idea is to use these data (probably plus extra data about mail not yet collected) to calculate town growth so that buildings are constructed and upgraded based on desirability, and desirability is heavily (but not exclusively) influenced by the quality of transport in the vicinity of that individual tile. I also should like to use this to simulate land value (the simulation of which is currently very approximate indeed), such that, the more desirable the land, the higher the land value, and the greater the cost to the player of building on the land; but I should also like to use land value to simulate something else more interesting, which is the "Metroland" phenomenon, in which transport companies built local settlements next to their own (often newly opened) transport links; the idea would be that players would be able to build, buy, sell and rent out city buildings, and the purchase cost of the land, the rental income and sale value would all be related to the desirability, which in turn would be strongly influenced by the functional quality of transport in the immediate vicinity of each tile. I believe that it is an important aspect of Japanese railways even in modern times that the companies that run them have a strong incentive to do so efficiently because they often own and/or develop land near their stations, and it would be good to be able to simulate this.

There has been some detailed techincal discussion of these features a few years ago in this thread, and there would be much to be said for reading that discussion if you are interested in working on town growth mechanics. This is now a little out of date, and some further things (such as the need for towns to serve industries and also the need to use mail as well as passenger statistics to affect desirability) will need to be considered.

The reason that this has not yet been progressed is that my time is limited and I have had other priorities: in 2014/2015, I had a break from Simutrans development when I moved house, and, after returning, I concentrated first on railway signalling, then on performance improvements/multi-threading, then on logistics passenger and mail classes and, now that the latter is now (mostly) complete (save for some rail vehicles in the pakset), the next major task is a set of features relating to vehicle maintenance and inflation so that I can finally make an attempt at cost balancing.

After cost balancing (and the features necessary to achieve it), however, town growth is currently my next priority. One reason for that is that the recently implemented logistics feature makes it especially important that towns grow and, when the map is generated, spawn in ways that complement the industries, as mentioned above.

However, the work on cost balancing will take me a considerable period of time. If either or both of you (or either or both of you in combination with others; I know that Ves has been very helpful at adding the UI for features that I have implemented recently, saving me a great deal of time) are interested in working on the town growth mechanics, this could achieve a major improvement in the depth, realism and balance of the game possibly years sooner than would have been possible if it were left for me to do it on my own, which would be very beneficial for Simutrans-Extended generally.

If either or both of you (or others) are interested in working on new town growth features, I suggest that we start by reviving the old technical discussion thread (as linked above) and finalise the design before starting coding. As this would be a large project, it would be helpful if it could be split into multiple sections each of which would be worthwhile on its own and could be implemented without the others, but would all fit together into a coherent whole when complete (for example, the mechanic for the the player constructing or receiving rental income from city buildings need not be implemented initially, but the whole design of the things that are implemented initially will have to take into account the plan to implement this later). The more people who work on it, the less work that there will be for any one person to do, but the more detailed discussion about design and organisation of work will be necessary.

Thank you again for your interest in working on this topic, and do let me know whether you would be interested in working towards the planned features on town growth.

[Phystam]

Thank you for your reply.
I think it is necessary for us to discuss the city growth well on the old thread.
What I want to discuss are city merging, grouping, growth improvements and decaying.
Merging and grouping are not so related to this discussion, so I have to separate them to discuss.

City growth should be based on not macroscopic but microscopic phenomenon.
This is like a relation between statistical dynamics and thermodynamics.
Each building has interactions with others, through players' transportation or private car.
If the interaction is strong, the building will be upgraded. And if not so, the building will be abandoned.
The land value related with the interaction, so it is effective to building renovation.

In order to simulate the city decay, I think it is necessary to introduce a .dat parameter like "average_available_years".
The building life is determined from this parameter, and when the time comes, the owner determines whether upgrading, keeping, abandoning or removing the building from the convenience including the land value.

Is it good idea?

[THLeaderH]

I have to work on other various projects, so this time, I just leave an idea to this topic.

Basically, I agree with the concept that places near a station should flourish. However, in more generally, it is a place where transportation is convenient that flourishes. "Transportation" is not be limited to public transportations. It can contain private cars. For example, in rural area of Japan, there are many big stores along a major road. This is because the stores along major roads are convenient to go with private cars.

However, it is not always case that convenience for private cars brings more development. For private car users, the cost of a parking lot must be cheap, usually free. This cannot be realized in area where there are many skyscrapers. Public transportation is essential for highly developed cities.

Moreover, population of areas where main transportation is private cars does not seem to grow. You can often see sprawl phenomenon, but in that, people just moves from an old area of the city to a new area of it. It is not so odd to think that the key element of city growth is improvement and maintenance of public transportation.

From these, I propose the following.

• Passenger demand from a place that is not covered by public transportation is treated as the demand of private car transportation.
• City growth depends on the amount of public transportation.
• Renovation percentage declines when the share of private car transportation is large. Renovation percentage should be high in places where public transportation is convenient, that means the nearest halt has many stops that can be directly reachable.
• Apart from city growth, passenger demand level of each city building moves from old one to new one. If the share of public transportation is small, passenger demand level should be moved to a newly constructed building. This encourages construction of new buildings and reproduce sprawl phenomenon in the cities where public transportation is poorly served.

If this post confused the discussion, please just ignore it

[jamespetts]

Phystam - thank you indeed for your interest in working on this. I agree that it is sensible to discuss the city growth algorithm on the old thread; there are more things that need to be considered that have not fully been discussed. Perhaps it might be useful for me to start with a discussion of the features necessary to deal mail and industry.

I definitely agree that city growth should be microscopic rather than macroscopic, and should be responsive to actual transport quality/mobility in a specific location, rather than overall in a city.

As to decay, we need to be careful to separate two things: (1) the renewal of older buildings (which very often never happens such that the better older buildings stay around for hundreds of years; my house is nearly 110 years old, and my workplace over 200 years old); and (2) the abandonment of buildings due to reduced desirability or economic decline.

As for (1), we need a way of simulating the fact that some buildings are replaced when they get old, whereas others do not, and also that replacing old buildings with new buildings happens more in places that are desirable than places that are not. As to (2), we need, as discussed on the old (2014) thread a system of separating the theoretical capacity of the building from its actual occupancy, as well as a way of simulating when abandonment occurs (as well, perhaps, as overcrowding). There are already memory structures in place in Simutrans-Extended to allow for this, but the code for processing and making use of these structures has yet to be added.

THLeaderH - thank you for your thoughts. In fact, much of what you suggest is already planned (albeit ins some cases with a different implementation). For residential density, what I had alighted upon was that, all other things being equal, low density buildings would be considered more desirable (this is generally the case in the UK at least, where people tend to prefer to live in houses rather than flats; this might differ in other countries, so should be a pakset setting), but this desirability for low density can be offset by other factors, such as better mobility and/or general amenity in certain higher density areas.

I had also planned (and designed in some detail) a specific feature relating to car parking, which I have not yet had time to implement; the idea is to simulate car parking directly, and allow players to build car parks. See this excerpt from the outstanding coding projects thread:

Park and ride and car parking

Currently, passengers can use private cars to make complete, but not partial journeys, and, whilst private cars are affected by congestion, there is no attempt to simulate another important economic limitation on private car use, scarcity of parking spaces.

In order to improve the realism of private car transport, it needs to be possible for passengers to make private car journeys from their origin to a station equipped with car parking facilities, and then continue their journey by player transport (aircraft, train, bus etc.). There also needs to be some simulation of car parking scarcity.

A way of implementing this is to start with the car parking scarcity feature: a destination building (i.e., an industry or a commercial or industrial city building) should have a limited number of car parking spaces available per month. When more cars have reached that building as a destination in that month than the building has internal car parking capacity, no more private cars should be able to make a direct route to that building until the next month. This simulates buildings' in-built car parks. This number should be set in the pakset for each building: larger or older buildings might well have no car parking space, whereas smaller or medium sized newer buildings (or buildings such as large factories) might have generous provision. Care will need to be taken to design a system to prevent private car journeys all being made at the beginning of the month when parking spaces are available - consideration will have to be given to some sort of offset allowing rolling resetting of car parking data rather than doing it at the beginning of each month. Consideration should also be given to a town-wide setting to allow street parking: this would give all buildings X number of extra parking spaces (where X is a figure that can be set in simuconf.tab) even when they have none built in, but would increase congestion in the town by a set factor, also set in simuconf.tab. This setting should be changeable in the same way as "allow city growth" (i.e., only by the public player in online multi-player games).

A new stop type, a car park (US English: "parking lot") would need to be defined. This would be a sub-class of the current "haltestelle_t" class (which deals with stations and stops). It would be able to be built on its own or as an extension to an existing stop/station. It would have a defined capacity, which would work in the same way as the capacity of individual buildings. Different car parks could be defined with different graphics and different capacities (from small areas of gravel to large multi-storey car parks). A car journey could then be made to the car park and passengers could continue the rest of their journey by foot or by connecting to another form of transport (such as 'bus, train or aircraft).

To the game's internal routing system, road connexions to car parks would be calculated from towns in the same way as they are from towns to other towns. This would give whether any given car park is reachable from any given town, and the journey time per straight line tile from origin to destination. When passengers search for a route, those with access to a private car would search not just local stops, but stops attached to or reachable from any car park connected to the town in which the passengers' journey starts.

It should be possible to have short-stay or long-stay car parks; short stay car parks would be available only to visiting passengers, whereas long-stay car parks would be available to visiting or commuting passengers, or those transferring to another form of transport. It should be possible for players to choose to have a car park connected to a stop reserved for the exclusive use of passengers using that stop.

This system could also interact with the passenger and mail classes system by allowing players to set different levels of price for car parking corresponding to the different classes of passenger: a low priced car park could be afforded by passengers of all levels of wealth, whereas a higher priced car park could be afforded by only those passengers of the corresponding level of wealth or higher, and would be unavailable to passengers of a lower level of wealth in the same way as it would be if the car park were full.

I should note that, since writing the above description, I have realised that a very simple but effective way of simulating car parking scarcity is to use the exact same algorithm as is used for jobs, which is very efficient.

Car parking, of course, is only indirectly related to town growth, and is one of those things that can be added later, rather than being part of the core town growth algorithm. It will nonetheless add considerable realism to town growth.

Incidentally, having re-read the original text of the feature design and THLeaderH's comments, I note that what I propose does not account for lack of car parking for residents - only visitors and commuters to buildings. It may well be that a separate system is needed for dealing with residents' parking; perhaps all residential buildings might have a (separate) parameter for residents' parking (up to a certain number of residents per building being able to use street parking if permitted in that town), and buildings with no residents' parking might be less desirable than those with residents' parking, but the difference in desirability would be much less in a place with good local mobility than without. Residents in buildings with no residents' parking would not be able to use private cars, and residents in buildings with limited parking would only be able to use private cars on a random basis (e.g., every resident who has already been assigned access to a car by the general random function is only able to use a car if that resident passes a further weighed random function). However, there is currently no system designed for measuring the quality of public transport specifically (as opposed to transport generally), so the desirability effect might be challenging to simulate accurately.

I do not think it sensible to limit the impact of town growth generally to public transport, since (1) there is no sensible way of telling the two apart with current data; (2) it is planned to allow hybrid journeys featuring both cars and public transport; and (3) (most importantly) this does not model reality accurately, where the popularity of private cars in the mid 20th century fundamentally altered the shape of town growth. The plan is to use the existing statistics passenger success rate, which were specifically inserted for this purpose, and which include successful journeys from walking as well as private cars and public transport, to determine residential desirability metrics.

In any event, thank you all for your interest in this project. I suggest continuing the discussion on the other thread.