"The Information Architecture of Cities", by L. Andrew Coward and Nikos A. Salingaros, which discusses InformationArchitecture of cities ie. it thinks about cities as information processing systems. Can't recommend this highly enough.
My summary is on ThoughtStorms: TheCityAsInformationSystem or a slightly delinked version below :
City as Information Processing Architecture
It treats cities as information processing architecture.
Movements of people and goods are interpretted as information flows. But an information system is considered to be one which doesn't just move information around. It also processes it. Alternatives are evaluated and decisions are made. For example, humans make decisions about what work to do, what business to invest time and money in according to the information they are fed by the city.
Fractal Loading
Journeys accomplish a primary information exchange. But ideally (for C+S) journeys have secondary, serendipitous information exchange. For examples, a pedestrian on the way to work visits shops, sees adverts, buys a newspaper, encounters a friend and has a quick word, and may have a coffee observing the behaviour and dress of those around her. This multiplicity of dimensions of information they call FractalLoading.
The virtue of cities is this dense, fractal, multilayered information exchange. It makes cities generate economic wealth and culture. Urban city planners should try to optimize the fractal loading of information.
In contrast, traditionally city planners have tried to
- visually simplify the structure of the city
- design "plug and play" modules, abstracted from their context
in the name of simplifying and optimizing the obvious, primary information flows.
For example, cities are zoned into commercial, living and shopping districts. Joined by high-speed, but informationally 1-dimensional, long distance connections. Large roads are driven through previously complex and rich urban centres, destroying their informational ecology.
These practices are all traditionally criticised by Jane Jacobs, Christopher Alexander, Stewart Brand etc. But this paper offers another explanation of the problem. They reduce FractalLoading and therefore information exchange efficiency.
Systems Theory
Drawing on the Systems Theories of Herb Simon the paper points out that all successful complex systems are organized into hierarchies of modules at different scales. (A fractal organization) But cities which are zoned break this pattern.
Hardware and Software Complexity
The authors make a distinction between software and hardware types of complexity :
- Software complexity arises where you have a few types of homogenous modules, and a large number of potential links or flows. The complexity is in the configuration of the links.
- "Hardware" complexity arises from a wider variety of heterogenous modules with fewer links.
Von Neuman and Recommendation Architectures
The authors make a second distinction between two kinds of succesful complex, information system.
- The "von Neuman" architecture of separated functional modules (eg. memory and processing) with fixed purposes and relationships
- A "Recommendation Architecture" where similar modules explore and compete. (Similar to competitive layers in a Neural Network, especially something like Adaptive Resonance Theory)
The first of these is closer to hardware complexity, the second, software complexity.
Chaotic and Homeostatic
A third distinction is made between two dynamic trends in systems :
- chaotic ie. the usual sensitive dependency on initial conditions
and
- and that trend where complex dynamics fall into a point or basin of attraction, converging from widely different starting points
Why Hierarchies
From Herb Simon, they argue that complex systems seek hierarchies for two reasons :
- to simplify the information required to describe and build the system
- to centralize knowledge of problems and the resources to deal with them. Knowledge of problems needs to be at a high level, but execution needs to be applied at the low, local level. Thus the two levels are forced into a relationship, whier the higher controls or guides the lower.
Thus the systems need to be hierarchies of modules.
Module boundaries
Modules are defined not as spatial regions as typically thought of as modules by urban planners. (What C+S call non-modules) But by information flows. A module is a network of information, who's boundary is best defined as the place where external communication is simplified, formalized or standardized ie. is an interface. Elements within the module are highly connected / dependent but modules themselves are weakly connected.
Plug and Play
Attempts to build "plug and play" modules abstracted from their context (eg. a business park) are flawed. They typically misunderstand the nature of modules as defined above. Often urban modules are defined as a spatial region, combining many identical elements eg. office block, business parks, residential districts. These are not real modules at all. Most people interact with elements of different types ie. people live in residential apartments, work in offices and socialize in bars.
Few people travel from house to house. And few companies buy from the company next door in the business park.
On the other hand, these modules are connected to the rest of the city through simplified interfaces eg. one road for the business park. The simplicity is based on the assumption that this spatial area is a module. But it needs to be used for the high bandwidth connections between the elements and the rest of their true modules elsewhere. The result, conjestion.
No comments:
Post a Comment