Implementing and Testing City Planning Theories
Michael Wood
Abstract
This research presents a software implementation of Mathieu Helie's proposal for managing city growth. This implementation is presented within a general class structure. It is argued that this class structure is flexible enough to incorporate all current branches of urban modeling techniques. Three techniques are selected as representative of their respective branches. Finally future research integrating these techniques with the implementation presented here is discussed.
Introduction
Theories abound on how cities should be managed as they grow. Many people look to improve, or recapture dynamics of social space thought to be lost. By encapsulating and implementing these theories in software we offer visualization, uncover inconsistencies, and examine the consequences. But perhaps best of all, software implementation allows integration with evolving state of the art modeling techniques, allowing our theories to be tested.
In Mathew Heuile's article (Heuile, 2009), he proposes a theory on growing cities centering around some rules for road planning and plot development. The goal of these rules is to create a system of which allows the pattern of development to be driven by demand, while ensuring that the overall road structure is useful. In other words his challenge is to allow bottom up patterns to emerge organically, while creating useful top-down structures. This is quite an interesting theory and deserves the testing and visualization that software implementation can offer.
Mathieu Heile's Rules for Infrastructure Growth
In his essay "The Complex Grid", Helie described the advantages and disadvantages of the ad-hoc method of city expansion popular in medieval times. He then sought to ballance this system with more rigid planning methods. The result would have these characteristics (Helie 2009):
* Any size of urban growth is allowed as long as the new growth extends the boundary of the network. This ensures that the city has the economic flexibility of the medieval city and allows anyone, no matter their economic importance, to contribute to the city's growth.
* The network must not become so complicated that it becomes impossible to move around in order to participate in large-scale activities and a culture of congestion.
* Streets must not grow too long without interruption in such a way that speeding and traffic accidents are encouraged.
To achieve such a system he proposed two rules:
1) For private development: you may build on any available part of the network so long as you replace the part you used up by extending the network around your new block.
2) For community development: any time a part of the network becomes too complicated (for example it takes more than 4 steps to get out of a sector), extend the boundary of that part with a higher capacity road (a boulevard).
In essence what Helie proposed was a behavior model for city planners. Under his rules, planners would let developers place a plot anywhere they like, with the condition that they would also be charged with expanding the road structure to surround the plot. An assumption is that this financial incentive would encourage dense structure. I.e. there would be financial incentive to fill in the gaps in a neighborhood rather than developing the perhiphery.
To maintain the top-down structure, Heuile proposes that planners examine the road structure and monitor its complexity. If the new plot makes it too hard to get across town, the planners are to create a ring road around the development, simplifying the journey.
Heile demonstrates that as this algorithm is applied at different scales, it can create a road structure that is interesting, organic, and functional. Examples shown below are taken from his article.
Figure: Example progression from village to city under Helie's rule-set.
This theory is simplistic. However this simplicity is deliberate, as it demonstrates that random behavior can be molded into useful form with a minimum of rules. Simplicity lends itself to implementation in the real world, and one immediately wonders how well such a strategy would fare in an actual city.
In order for anyone to trust this theory enough to base a planning policy around it, additional complications must be modeled to examine its unintended consequences. The best way to do that is to implement his theory in software model and then integrate that model with current state of the art modeling techniques to fill in some of the missing pieces.
State of the Art of City Modeling
The study of urban environments has become a wide and varied dicipline. Contemporary models reflect the fact that cities are composed of many complex actors who make decisions at multiple scales to achieve varied goals. It is widely recognized that from these actors emerge many patterns and behaviors which act like bottom up emergent systems such as the economy and traffic patterns. It's also noted that these actors and bottom up systems interact with top down systems that attempt to apply order to the chaos, such as the SEC and traffic plans. The modeling techniques that try to capture all this can be clasified into three main research branches of Location Theory, Social Physics, and Spatial Morphology (Batty 2008).
Let's look at these branches more. Pierre Frankhauser in his recent article "Fractal Geometry for Measuring and Modeling Urban Patterns" (Frankhauser, 2008) embodies the branch known as spatial morphology. He recognizes that many city grids will look similar or different to our eyes, but it is difficult to convert this to emperical evidence. He puts forth a "fractal order parameter" for studying the fractal order in urban land use patterns. Using this parameter he is able to establish a scientifically precise way of contrasting land use in different cities. However this approach does not attempt to describe how how such patterns emerge.
By contrast the Social Physics branch places emphasis on understanding the evolution of these patterns. Mark Birkin discussed a way to integrate two of this branch's most popular techniques: agent based modeling and spatial interaction theory (Birkin 2008). Spatial interaction breaks up regions and then uses a system of partial differential equations to estimate how connections between these regions spread demand across the city. It is often applied to traffic and has been used successfully for years to estimate the required size of roads and other transit systems. They look at the system as a whole and find an equilibrium in order to answer questions about smaller entities (top-down approach). Agent based systems by contrast start with the actors, give them rules for behavior, and then see what their combined actions can tell us about the system as a whole(bottom-up approach). By combining them Birkin is able to present a closed loop iterative system where agents query the spatial interaction model to find information about their local infrastructure, then they adapt this infrastructure to suit them (see Figure). In this way we see that using both of these aproaches in tandem allows us to examine both the top-down and bottom up forces to model a dynamic system.
Figure: Hybrid Agent-based/Spatial-Interaction model cycle
Meanwhile Juval Portugali argues for bringing a form of location theory back into the fold. Like Birkin, he argues that most current agent based and cellular automota models focus too much on the simplistic behavior of agents and the micro level. Both researchers seek to solve this by closing the loop to offer feedback to the larger structure. However where Birkin uses spatial interaction, Portugali emphasises complexity theory and cognitive theory in the framework of SIRN (Haken an Portugali 1996, Portugali 2002). He does this by building two cognitive models (The city, A city) in the mind of every agent. These models consist of "forms" which Portugali resurects from location theory. He claims this approach will bring back the understanding of how "local processes give rise to global structures and how the latter feed back and affect local processes and so on in circular causality" which he notes as a main insight of location and complexity theory (Portugali 2008).
Figure: SIRN based agent based cycle. (Reproduced from Portugali 2008)
These three examples neatly illustrate the main branches of urban modeling. These branches have consistently described efforts in this field since the 19th century(Batty 2008). Capturing the essence of these branches should make it easier to integrate any other current or past technique with our model.
In this research we will be presenting a structure to capture the essential pieces of these branches and applying this structure to implement Helie's model. Follow-up research in this series will show the results of applying the techniques described above on Helie's theory.
Model Structure
General Model Structure
What lessons do we have to learn from the above techniques. What would a structure that could incorporate all of them look like?
We here assert that there are levels of action to be modeled, common across these techniques. They are: Planner, Developer, and Citizen. Together with an Grid class, these four will be our fundamental classes. The first three combined represent the fundamental actions that are performed on the environment. Meanwhile the Grid class represents the state of the city. Here we present a structure showing these classes in action.
Figure: Complex City Grid framework class diagram. Note: methods to modify the Grid object are package level and must be accessed through a Planner object.
These classes are chosen because they have fundamentally different roles. The Planner class handles top down parts of building infrastructure, and as such the methods include buildRoad, approvePlot, and buildSubway. There may be one or many of these objects.
The Developer class represents bottom up actions. It will typically act as an agent attempting to build things at the plot to block level (i.e. filling roles similar to that of an company or landowner). There may be zero (e.g. a static model) or many of these.
The Citizen class represents actions conducted by an individual, ranging from the concrete (search for housing) to the more abstract (search for life meaning) depending on the modeler's goals. Their role is to use the infrastructure. As such they will make no direct requests to change the infrastructure. There may be zero to many of these.
Finally the Grid class initiates no actions, but rather tracks the state of the city. This includes not only the physical state of the streets and plots and such, but also compiles and aggregates the states of the other objects for further anslysis. Because this corresponds to an objective reality, there can only be one instance of this class.
It's important to note that the Grid has certain methods restricted to the package. Some of these methods are exposed via public functions in the Planner Class. It is done this way so that the planners can accept or reject development, or to perform some other modification before the development is allowed (e.g. demolishing a building before making a new one). It acts as a gate-keeper to changing aspects of the city. The Developer can initiate changes to the Grid, but they must go through the Planner. This is why a model must contain at least one Planner to conform to this spec. Depending on the intent of the model, the Planner might take no action at all, but just forward this action on to the grid. However by maintaining it's role as gatekeeper of the infrastructure, we leave space to add more to the planner's role later.
We will refer to this structure as the Complex City Grid Framework. Next we show how to use it to implement Helie's theory.
Model Structure Applied to Helie's theory
To model Helie's theory within the framework presented here, we implement the class structure diagramed above. We are making some simplifying assumptions, so we will not need any Citizen objects. For more detail on this, refer to the attached source code (Wood 2009).
Figure: Class structure
The job of a Developer object is to examine the grid and determine where it wants to place a plot to develop. It examines the grid to see if a plot overlapps existing structures, how much a plot would cost using the grid object's overlapsExisting(), and cost() methods respectively.
The key method of the Planner class is addPlot. When called by a developer, the addPlot method places the proposed plot in the grid as long as it does not overlap existing plots or roads. Before returning to the developer, the planner checks the state of the grid to see if it is now too complex to get across town. It is considered too complex if it takes more than 4 intersections to traverse a given section. The planner then creates A higher ranked road is then created, surrounding the existing development.
Roads are assigned a rank. A higher ranked road has the right of way. So if a road connects two points with 5 steps to get between, and this road is then replaced by a higher ranked road (see Figure) the new road would only have 1 step between these same points.
Thus Developer class objects ask the Planner class objects to add a Plot to the grid. The planner class says yes nearly always, but adds and expands roads before it accepts any other requests.
How do these classes interact? The developer initiates the cycle. First it chooses a size plot to build at random. Then it queries the Grid to determine the price of all the available plots. It picks at random from the lowest cost available location and makes a request to the Planner object to add it. The planner then accesses the grid's package methods to add the plot and the roads required to surround it. Before returning control to the developer, the Planner checks if higher ranked roads are required as described above. We show all of this in the sequence diagram below.
![](docs/pics/sequence_diagram.png)
Figure: Sequence diagram
One thing which became clear in development was the need for the planner to exercise a small amount of foresight. It turned out it was possible to develop a plot in a position which would prevent later expansion of the roads (see Figure). To prevent this development we added the concept of planned roads. When there is a corner with two ranked roads meeting, we treat the extension of both roads as a planned road. New plots are not to be created intersecting these roads, and plots that are built must leave space for the road to be widened.
![](docs/pics/plannedroads_off.png)
![](docs/pics/plannedroads_on2.png)
![](docs/pics/plannedroads_on.png)
Figure: Planned Roads - No planned roads (left) showing no paths to extend roads. Planned roads before extension (center). Planned roads after extension (right).
Discussion
In this way we have presented a Helie's theory as a cellular automata model implemented in the Complex City Grid class structure. Now we are able to explore both the theory itself and the advantages of implementing a theory in this framework.
To start with, lets explore the intriguing consequences of Helie's model by taking a closer look at plot we've generated below (see Figure).
![](docs/pics/model_villiage.png)
Figure: Simulation of progression of model from villiage to town to city.
This progression shows a simplistic, almost random development pattern. Yet because of the Helie's rules implemented in the planner class the result is a usable road pattern. More impressively, the structure is dense and the roads are drivable at every step. No roads need to be built in advance of development, so there is no chance of a road going to waste. If all development was stopped at any point, the roads would still be useful and the neighborhoods still dense. There are no intermediate stages where the planner must invest in infrastructure in the hope that development will eventually come. This makes this strategy arguably more resiliant to budget crunches and recessions. So we see this approach avoids many traps of over-planning.
Even better, it also avoids the failures of under-planning. When development is un-planned, fixing traffic patterns after they emerge is often only attainable by demolishing established neighborhoods to widen the street or insert a bypass. Here we avoid this by expanding infrastructure as we grow, Therefore we only expand roads on the outside of existing development. We make room for the wider roads by telling new development where they can build, not by adjusting existing plots. This means there should be almost no cases which require modifying existing buildings or neighborhoods to make room for road expansion.
Yet as we look closer we notice some differences between helie's model and the software implemented version. Most notably, at the City stage of development we see no new sectors defined outside our 2nd level ring road (see Figure). We find that under truly random development patterns, the structure forms fewer clusters less than predicted. More rules may be needed to produce patterns like those on the left.
Figure: Helie's example (left) vs. software model result (right) for city level structure.
By implementing it in software we are able to show how flexible the idea is. By changing parameters in the code we can build the city the code presented here we are able to show what happens when we change the size and shape of the plots, or change the threshold of complexity that triggers a ring road. We can look at the resulting structure and instantly judge if it still achieves Helie's goals of economic flexibility (always places to develop), navigability (simple routes), and speed regulation (short streets). In other words because we implemented the idea in software we can explore how robust Helie's theory is by visualizing the structure that emerges when we vary these parameters.
Because software must be precise, the process of implementing the theory identifies weaknesses and ambiguities in the theory. We learned about the need for planned roads, which was not immediately clear from the essay. Also we had to formalize the notion of what it meant by "4 steps to get out of a sector", using intersections as steps, and sectors being defined by the closest road one rank above the one you are examining. By defining the elements precisely, we understand the theory and make it stronger.
Finally because we have this software model we can integrate other modeling techniques to answer more complex questions. For instance there is an implicit hypothesis in Helie's article that a road structure grown as described would be able to handle all traffic increases in the city's future. I.e. there should never be a case where we need to go back and demolish buildings to expand a road, or clear development to make room for a bypass. Would this hypothesis hold true under the case of more realistic city modeling?
To test this hypothesis we must integrate more sophisticated modeling techniques. The plan for achieving this is described in the next section.
Next Step
Testing the hypothesis of adequate traffic flow is a typical application of spatial interaction theory. Since the structure presented here also acomodates agent based design, first of which will cover integrating the hybrid agent based and spatial interaction techniques described by Mark Birkin (Birkin 2007).
Birkin started with a standard, doubly constrained spatial interaction model, and transformed it into an iterative model of quasi-doubly constrained form. Because the QDCIM was iterative, he used it to generate the cost structure of inform an agent based microsimulation model. In practice, the results of this new microsimulation model failed to match the results of the QDSIM. His conclusion was that the parameters in the model failed to apply when moved from the meso to the micro scale.
Yet in this context, implementing both of these models will make an interesting exercise for our . In the next paper we plan to implement the microsimulation model using the Citizen class, and the QDSIM in the Planner class. Following that, two additional papers are planned, incorporating Frankhauser's fractal parameter and Portugali's cognitive models respectively.
Conclusion
We have here presented an implementation of Helie's. Preliminary results show encouraging evidence that a usable structure can be imposed with the minimalist rule set Helie describes. We have also argued that the best way to test this theory further is to integrate other modeling techniques. We have presented our initial stab at a framework that allows us to do just that, here named the Complex City Grid framework.
It is our belief that Integrating more techniques with this model will allow us to refine this framework. We have described the next step of incorporating a social physics model. After sufficient refinement, this framework may prove to be robust and flexible enough to allow research groups to work completely separately, but later to come together later and easily combine their results. This is the hope of the this research series.
Bibliography
* Batty M, Xie Y (1996) Preliminary Evidence for a theory of the fractal city. Environment and Planning A 28: 1745-1762
* Batty M (2008) Fifty Years of Urban Modeling: Macro-Statics to Micro-Dynamics. In: Albeverio S, Andrey D, Giordano, P, Vancheri A (eds) The Dynamics of Complex Urban Systems, an Interdisciplinary Approach, pp 1-20
* Birkin M (2008) Hybrid Geographical Models of Urban Spatial Structure and Behaviour. In: Albeverio S, Andrey D, Giordano, P, Vancheri A (eds) The Dynamics of Complex Urban Systems, an Interdisciplinary Approach, pp 95-109
* Frankhauser P (2008) Fractal Geometry and Modelling Urban Patterns. In: Albeverio S, Andrey D, Giordano, P, Vancheri A (eds) The Dynamics of Complex Urban Systems, an Interdisciplinary Approach, pp 214-243
* Helie M (2009) The Complex Grid. http://emergenturbanism.com/2009/02/16/the-complex-grid/
* Portugali J (2008) A Structural-Cognitive Approach to Urban Simulation Models. In: Albeverio S, Andrey D, Giordano, P, Vancheri A (eds) The Dynamics of Complex Urban Systems, an Interdisciplinary Approach, pp 357-372
* Wood M (2009) The Complex City code. http://sourceforge.net/projects/complexcity/ https://complexcity.svn.sourceforge.net/svnroot/complexcity/tags/release0.1