Design domains, ontologies, and generic grammars

The term “design domain” refers to a formal or conceptual field that may be the subject of a design activity, such as urban design, chair design, or bottle design. The main difficulty, however, lies in the formal definition of a design domain. Such definition should be able to clarify which are the objects of a design domain, classify them correctly by clearly stating their types, parts, and relations. This is important to enable a structured look into the morphological and topological aspects of the domain, and to develop rules acting on such objects and relations, either symbolic relations or spatial relations.

Such a structured description of a design domain can be accomplished by characterizing the domain's ontology. In computer science and specifically in the field of knowledge representation, ontology is the set of specifications of a domain's conceptualization (Gruber, Reference Gruber1993). More accurately, ontology describes a domain in terms of the “objects” (or individuals) of which it is composed, object arrangements in terms of a structured classification identifying the “classes” and “subclasses” of objects composing the domain (taxonomy), their “attributes,” and the expressed “relationships” among them (topology).

“Objects” or individuals are singularly identifiable entities that may be instantiated or manipulated as such. In a shape grammar-based (Stiny, Reference Stiny1980) representational structure, objects may be represented by labeled shapes which typically have a geometric component (a shape S) and a symbolic component (a label L). The shape part or the label part of a labeled shape may be empty. Labels without a shape part are simply abstract classifiers or symbols, concepts that may or may not be related with shapes. Unlabeled shapes are abstract shapes without semantic value other than their geometric properties. Labeled shapes are geometric entities attached to a concept and therefore we say they are semantically meaningful shapes. In addition, in the case of more complex objects, labeled shapes may be articulated and complemented by descriptions, adding other layers of information (Stiny, Reference Stiny1981).

“Classes” are types of objects organized in terms of a dependency structure based on object typology. Objects with shared characteristics are organized into common classes. Complex objects in a class may be composed of simpler objects belonging to a subclass or several subclasses thereby defining dependency relationships. Objects which are not composed of other objects are called primitives. Furthermore, objects in classes can be represented by shapes, labels, or labeled shapes depending on the kind of representational criteria used for classification in the ontology structure. Hence, a class C is represented by a vocabulary of shapes S and labels L. Formally,

(1)$$C_i = \{ S_i\comma \,L_i\}$$

where i is a class identifier index.

“Attributes” are characteristics, properties, or parameters of objects in a class. To avoid confusion, note that attributes correspond to properties that may be common to objects in several classes of the ontology (e.g., point coordinates), while labels are specific of a particular class in ontology (e.g., positions of protected arboreal species may be given by attaching a label or a symbol representing a particular tree species to a point in the right location).

“Relationships” express the dependency structure between objects and consequently also between classes.

In geometrical terms, primitives are points, lines, surfaces, and solids, with zero, one, two, or three dimensions, respectively. Each of these primitives is bounded by primitives of the dimension immediately below. As such, solids are bounded by surfaces, surfaces by lines, and lines by points. Points have no boundary, so, at the end, all primitives are defined by points, considered the primal of the primitives. The main attribute of primitives is their positions in the design space, defined by coordinates in a given reference system.

In the “urban design domain,” the ultimate object is the city, its parts, and the relations among parts. This structure should contain all the concepts needed to describe cities as they are and cities as we intend them to be, in other words, describe the transformations that may be applied or that we admit possible within a city while following some goal, which we will call “development vision.” The term “urban design” stresses that the domain describes not just the urban space “as it is,” but also “as it is planned or envisioned to be,” including the actions and processes that acting upon existing objects transform them into new objects according to established planning rules. Figure 1 shows a classification structure developed for the domain of urban design. The larger object – the city – is divided into five main groups of object classes, which are called systems. These systems represent different ways of seeing the city and contain the main urban elements, which we are able to deal with, more or less independently from one another: (1) the city seen as a street system; (2) the city as a built system; (3) the city as a property system; (4) the city as a physical system; and (5) the city as a system of focal points. These systems can be independent topics of analysis involving subjects that are usually addressed in a reasonably autonomous fashion, such as network analysis (Hillier et al., Reference Hillier, Hanson and Peponis1987; Marshall, Reference Marshall2005) and urban morphology analysis (Muratori, Reference Muratori1967; Coelho et al., Reference Coelho, Costa, Leite, Silva, Trindade, Pereira, Proença, Fernandes and Monteys2013), to list the most common. Each system is composed of object classes organized according to their expressed relationships. For instance, considering the street (or public open space) system, we have as a top class axial representation of the network (AN) followed by classes which are pure classifiers of streets: transportation network (TN) and street nomenclature (SN). We call pure classifiers to classes with an empty shape set, containing only labels which describe concepts that should be classified independently, even though such concepts may be attributed to shapes by means of rules. For instance, the class TN represents street classification seen for their role in the TN, and we may find class object instances such as high-speed roads, distribution streets or, more specifically, local distribution or local access streets (Fig. 2). The class SN represents street types as usually identified in common languages,Footnote ¹ such as “alley”, “boulevard”, and so on (Fig. 3). Each street type in TN and SN classes has a street description (SD) consisting of the minimum set of street components (SC) indicating the number of car lanes, sidewalk areas, or other components of a street section. In other words, this is a formal description of a street section. The street section may be enlarged according to permissions set in terms of vicinity rules between SCs and within a variation range established for each parameter in a SC (Fig. 4). For instance, “canal” (⑩) is included in the set to cover streets in The Netherlands, where canals may participate in the definition of street profiles.

Fig. 1.

Ontology proposed for the urban design environment, which is one among many that can possibly be developed for this domain. Primary relationships are indicated by a continuous line. Secondary relationships are represented by a dashed line.

Fig. 2.

Generic grammar for urban design: transportation network (TN) and street descriptions (SD) for selected street types within TN. This ontology allows for variations and comparison with Marshall's classification in terms of stratification by speed and connectivity route types according to structural role of streets within the network.

Fig. 3.

Generic grammar for urban design: street nomenclature (SN) and street descriptions (SD) for selected street types in SN, and its comparison with Marshall's route classification in terms of stratification by speed and connectivity route types according to their structural role in the network.

Fig. 4.

Generic grammar for urban design: street components (SC). This table shows the 12 street components that once combined allow for the generation of almost any street type within a city network (only three are shown). The table includes details of the variable parameters and rules to combine them according to the permissions set as street descriptions (SD) – see the two previous tables.

The structure explained above defines relationships among all objects in the ontology and consequently also relationships among classes. The relational structure between objects and classes predefines the way objects may be used in design rules.

Production systems, patterns and grammars

Gips and Stiny (Reference Gips and Stiny1980) proposed a uniform characterization of Post's production systems (Post, Reference Post1943) by underlining that their common structure was composed of: (1) the objects they process, (2) their definitions, (3) their interpretative mechanism, and (4) the objects they generate. Through this uniform characterization we can see most algorithmic structures as production systems defined by rules with the format u → v, where u and v are objects from a uniform class C of well-defined objects, and C may be seen as any subclass of labeled shapes of the form C _i = {S _i, L _i} in an ontology defining a particular design domain or part of a design domain (sub-ontology). In such cases, the production systems are shape grammars (Stiny & Gips, Reference Stiny and Gips1972) operating with shapes belonging to a particular class of well-defined objects in a design domain. In fact, they are discursive grammars (Duarte, Reference Duarte2005) as we will explain below. Technically, a discursive grammar consists of a shape grammar, a description grammar (Stiny, Reference Stiny1981), and a set of heuristics, which are used to guide design generation toward designs with desired properties, by comparing the description of the evolving design with the description of the desired design, and then deciding which rule to apply next.

Another form of algorithmic structure was introduced in the late 1970s by Alexander et al. (Reference Alexander, Ishikawa and Silverstein1977) through the concept of a pattern language. At an abstract level, each pattern is composed of a predicate condition for which a set of generic time-tested solutions may be applied as a consequent action. The predicate condition is also said to correspond to recurrent phenomena in a design domain (urban or architectural design), hence implying that typical design problems within these design domains may have already typical, generic time-tested solutions. In this definition, the form u → v is transformed into a more ambiguous format, predicate → consequent, where u and v become more complex concepts involving some, also complex, set of transformations of the predicate conditional state into a consequent state. Patterns in this context describe generic design operations and designs are arguably the results of the application and instantiation of particular sequences of patterns. Sequences are not predefined but desirable relations with other patterns are described, both in the predicate and in the consequent parts of each pattern, thereby reinforcing the algorithmic structure of the pattern language.

Such particular forms of algorithmic design, patterns and shape grammars are said to encode languages of design because they define formally the syntactic rules of a particular design space in a design domain. These rules can be used to generate designs and the set of all the designs that can be generated from such rules form a design language. Both forms have their strengths and weaknesses. The accuracy and focus on syntactic rules in shape grammars (such as in linguistics) raises many issues regarding semantics (Fleisher, Reference Fleisher1992) as well as difficulties in computer implementation (Gips, Reference Gips1999), while the vague descriptions of patterns lack accurate formalization but are open to semantic interpretation and to varied forms of implementation. Two particular aspects of patterns may be underlined. First, the computer implementation of a pattern can be often defined by a shape grammar and, surely, by some form of the production system, although such a production system may need a rather complex interpretative mechanism to encode all the semantic subtleties of the pattern. Second, semantics in a pattern language is also guaranteed by the relational structure defined among patterns. We may say that there is a specific ontological structure underlying a particular pattern language. As a result of the preceding observations, we propose that a generic grammar is composed of a set of different kinds of production systems operating on objects from an ontology describing a particular design domain. In the following sections, we will illustrate the concept of generic grammar by describing one for the domain of urban design.

Generic grammars for the urban design domain

In 2012, Duarte and Beirão (Reference Duarte and Beirão2012) described an algorithmic approach to urban design that used Alexander's et al. (Reference Alexander, Ishikawa and Silverstein1977) Pattern Language and Stiny and Gips’ (Reference Stiny and Gips1972) shape grammars that they had been using in teaching and in practice. The basic idea was that following contextual analysis, certain patterns would be triggered, forming a program for urban intervention, and then such patterns could be formalized in a flexible urban plan using shape grammars. Later on, in “City Induction” Duarte et al. (Reference Duarte, Beirão, Montenegro, Gil, Müller Arisona, Wonka, Aschwanden and Halatsch2012) formalized the underlying methodology with the aim of developing a supporting computer platform. In addition to the use of patterns and grammars, it was proposed the development of an ontological structure (Gruber, Reference Gruber1993) to describe the urban environment and the development processes, and space syntax (Hillier & Hanson, Reference Hillier and Hanson1984) to characterize affordances of urban solutions.

In CItyMaker (Beirão, Reference Duarte and Beirão2012), Beirão defines a common structure for Urban Induction Patterns (UIPs). UIPs are presented as algorithms for urban design involving a structure inspired by Gamma et al. (Reference Gamma, Helm, Johnson and Vlissides1995) that include shape grammars as template codes for describing typical urban design operations. Inspired by Alexander and more closely by Gamma et al. (Reference Gamma, Helm, Johnson and Vlissides1995), an UIP is composed by the following parts: “Name/Intent/Also Known As/Known Uses/Description/Structure/Predicate/Consequent/Discursive Grammar/Related Patterns” (Beirão, Reference Beirão2012, Appendix 2 – A Library of Urban Induction Patterns).

Name/Intent/Also Known As correspond to Gamma's definitions. Name states the pattern's algorithmic behavior in a reasonably self-explanatory short statement; Intent gives a brief explanation of the pattern's algorithmic principles; and Also Known As gives an alternative name also short and self-explanatory. Known Uses illustrates the algorithm's application in a way similar to Alexander's “archetypal illustration” including an additional explanatory statement or summary. Description gives a simplified verbal description of the pattern's algorithm. Structure provides a visual relation of the object classes used by the algorithm and a short graphic pseudo-code stressing the algorithm's main purpose. Predicate describes the underlying conditions upon which the pattern can be applied. In other words, it accurately describes the initial conditions for the application of the UIP, giving information on which class C _i to find the initial shapes and labels upon which rules may be applied – the matching conditions. Consequent gives a description of the expected results. Gamma's sample codes are replaced in this structure by a Discursive Grammar, which formally gives the rules regulating the generative behavior of the pattern – the design action itself. Related Patterns work much in the same way as in Alexander et al. (Reference Alexander, Ishikawa and Silverstein1977) and Gamma et al. (Reference Gamma, Helm, Johnson and Vlissides1995), but in this case the state-specific relationships between object classes or, in other words, to what object classes can a pattern be applied and what patterns may be applied to objects resulting from a pattern's application. These are, in fact, general matching conditions stated at the class level.

By using this formalism, CItyMaker presents a generic grammar for designing urban plans. The author argues that this generic grammar is composed of 45 UIPs that combined in different ways can produce different urban plans involving different languages of design. Each pattern can be constrained within the set of options defined by its rules and also within the variation range of their parameters. It can be argued that this set of patterns constitutes a pattern language involving a wide spectrum of design solutions approximately in the same way as proposed by Alexander et al. (Reference Alexander, Ishikawa and Silverstein1977). A specific urban design language may be obtained by choosing particular arrangements of patterns. A specific design instance may be obtained by choosing from this specific urban design language, a particular rule sequence, and specific values to assign to their parameters.

Note that the term “language” has slightly different meanings in the context of Alexander's pattern language and Stiny's shape grammars, but they both hold and are related in our concept of generic grammars. For Alexander, a set of patterns forms a language that can be used to specify the ingredients of designs that are appropriate for given contexts whose features trigger just certain patterns. Once made, a pattern is triggered and included in the design brief, it may be instantiated in the design. For Stiny (Reference Stiny1980), the set of designs that can be generated following the rules of a given shape grammar form a design language. We manipulate the pattern language associated with a generic grammar to define a less generic pattern language by choosing to use just some patterns. Then, we use this sub-pattern language to formulate the design brief. Then, we manipulate the generic sub-grammars associated with the selected patterns, by selecting some rules and constraining rules’ parameters to define specific sub-grammars. Finally, we use these specific grammars to derive the design. These steps do not necessarily need to be performed in this rigid linear order, as designing might imply to proceed back and forth, until the problem, the solution, and the language are defined. The meta-language for designing defined by a generic grammar defines a very large design language formed by all the designs that can be generated by all the sub-pattern languages and all the specific grammars that can be defined from the generic grammar.

As a way of illustration, let us consider just a few patterns and some basic urban design operations. In a urban design, a designer needs to pass through a long sequence of design decisions. Roughly, designers follow four different levels of design decision which may or may not be applied consecutively (Beirão & Duarte, Reference Beirão, Duarte, Stolk and Brömmelstroet2009) but are somehow scale dependent: (1) the wider level involves rules defining the plan guidelines through broad compositional guidelines that anchor together some significant landmarks in the territory; (2) another level lays down the grids ruled by the compositional guidelines; (3) the next level defines rules for defining urban units, such as neighborhood, urban blocks, and urban plots, together with minimum program requirements of neighborhoods regarding public facilities and open spaces; (4) the last level involves rules for qualifying the urban environment, such as public space design and façade design constraints, including material aspects in both cases, among other aspects. If we look simply at the street layout without much consideration for other aspects of the design, we will be applying rules involving objects taken from the “network” part of the ontology (Fig. 1). Therefore, rules will operate on objects from classes AN, SN, TN, NO, SD, CR, and SC. Rules are arranged in the form of UIPs with the structure and algorithmic description found in Table 6 in CItyMaker (Beirão, Reference Duarte and Beirão2012, pages 117–121). This table contains a structure that embeds the typical procedures designers need to follow to develop an urban plan. The structure can be found in the subsections of the table which give subliminal information on the sequence of decisions that should be taken to design a complete urban plan: (A) creating compositional guidelines, (B) creating grids, (C) street network transformations, (D) creating public spaces, (E) creating urban units, and (F) detailing spaces. The amount of possible combinations is potentially very large, so developing an example requires reducing the full potential of the grammar. Still, the grammar allows designing from very generic plans to detailed representations of public spaces, depending on which UIPs are used.

In the development of an urban plan, a designer starts from a set of representations depicting preexisting conditions, which usually are available from a geographic information system (GIS). Such representational structure is usually very complex but for the purpose of a design process we will consider it a set of preexisting labeled shapes – the context – represented as set E. One may imagine an entire representational structure within the bounds of set E that could be used to trigger different sets of transformation rules based on existing attributes of the context. In fact, the representational structure is that of the GIS system and it provides information regarding the pre-existing environment.

In any kind of urban plan, designers use contextual elements as references for making design decisions. While selecting these elements, according to some criteria, including idiosyncratic intentions, the designer interprets the context and assigns meaning to the place. In our generic grammar, references are used as initial shapes of the design process. The first patterns (UIPs) that can be used are those that contain rules whose left-hand sides match on a reference shape R _ef. The designer may consider preexisting shapes as erasable shapes (e.g., buildings to be demolished) and label them with E _er., or as reference shapes, that is shapes to support the initial moves of the design process, and label them with R _ef. These shapes are so marked by using simple selection methods. Embedded in the selection process there is a classification rule which transforms an object e ∈ E into either an E _er shape or a R _ef shape, where E _er, R _ef ∈ E. Additionally, a closed polygon I is set by the user to define the limits of an intervention area. This polygon represents the rule application space or, to be more precise, new shapes can only be generated inside I, although rules may act based on references found outside the intervention area. The intervention area I can also be used as an initial shape.

Implementing and applying a generic grammar for urban design

In this section, we will present the implementation of the simplified grammar presented above into a computer platform, and provide a short example of its application to a possible design situation, starting from a preexisting context where an intervention area I has been defined. The design shown and described on the following pages was generated using the interactive interface available in CItyMaker. This software translates patterns firstly encoded as shape grammars and converts them to parametric design patterns, a necessary step to facilitate computer implementation. This conversion sacrifices embedding, an important property of shape grammars, by which shapes that were not explicitly designed can be identified (e.g., a square resulting from the intersection of two squares). The obtained parametric design patterns are reusable in different types of context and amenable for designers to produce their own solutions. Nonetheless, such a conversion still allows us to demonstrate how the concept of generic grammars provides a valid theoretical framework for structuring the urban design process.

Figure 5 shows the initial steps of a design session using CItyMaker to apply the simplified generic grammar to a particular site. Figure 5a shows only shapes from E, the shape set representing the context, and I, the intervention area. The area pictured in Figure 5 is an industrial area close to the World Heritage town of Sintra, located some 30 km to the west of Lisbon, Portugal. This industrial area has long been famous for its stone quarries and stone transformation industries. Over time, such activities attracted several other industries, mainly in the construction field. However, the initial rural structure of the territory is still patent in the organic tissue of the three village centers contained in the area as well as the regular original latifundium structure. Nowadays, these village centers define a polycentric nuclei structure gravitating around the industrial areas. The regular property structure still underlying the industrial areas is not the outcome of a planning operation but simply the result of the occupation on demand of the old rural structure (latifundia). However, the occupation of the rural structure by the industry followed no plan and created several quarry spaces resulting in an overall chaotic appearance. At present, the local industry is traversing a period of economic crisis resulting in the abandonment of some quarries and factories. The municipality seeks solutions for these spaces but finds no secure answers due to the crisis and especially to the overall shrinking scenario (population decrease, aging, and investment shortage). Some of the development visions that seem more sustainable gravitate around environmental requalification toward a mixed industrial–recreational park and/or the promotion of housing for the elderly and public facilities, integrated into a large green park.

Fig. 5.

Initial steps of a design session using the computer platform to apply the simplified generic grammar to a particular site: (a) Design context: the intervention area is shown in light gray and buildings that can be erased in dark gray. (b) A “buffer” zone around existing houses to be maintained is subtracted. (c) Addition of new streets defining a grid of ”islands” using the ManualGrid pattern. (d) Application of a regular grid pattern to each “island.” Each grid is rotated according to the longest edge of the corresponding “island.” (e) Plots along the streets are retained, whereas others are filtered out. (f) A possible solution following the selection of two village centers and the connecting street as attractors and a growth input expressed in terms of the number of dwellings.

The criteria used for defining polygon I shall not be questioned here, although it could be the result of some sequence of analytical procedures on the context using available GIS information. In fact, it is not the aim of this paper to explain the motivations and principles behind design solutions, nor the results as responses to such principles, but simply to illustrate the operational aspects of the generic grammar and its field of application. The first steps of the design process are a subject of human decision based on the available information or the result of programmatic specifications defined by a programming algorithm (Montenegro et al., Reference Montenegro, Gomes, Urbano and Duarte2011). Some existing buildings found inside the intervention area are preserved and others are demolished based on information available in the GIS database (DB). For instance, buildings with a footprint smaller than 20 m² or in ruinous condition or abandoned factory plants are to be filtered out or erasedFootnote ² from set E and, therefore, buildings in such conditions will not constitute a limitation for the next design steps. This selection is performed through simple query procedures like those used in common GIS software, here replicated using filter-based design patterns as explained further below. The buildings to integrate into the design define buffer areas, which are subtracted from the intervention area I (Fig. 5b). Alternatively, one could simply subtract the corresponding plot areas.

The design described on the following pages was developed in a design environment composed of CAD software and a parametric visual programming interface (VPI). In this case, the CAD software was Rhinoceros with the plug-in Grasshopper as the VPI. The VPI was extended with the plug-in Slingshot to establish communication with a Postgres DB, connected to a GIS, and to an urban measures calculator (UMC). The design was obtained using a sequence of parametric design patterns programmed in Grasshopper corresponding to the following descriptions:

Analysis patterns (AnalysisPatterns)

Analysis patterns are of particular interest in terms of planning because they supply real-time information on the properties of the design being generated. In addition, any urban analysis that can be defined using the representation model provided by the DB can be set in the design interface by programming it in the available VPI as an AnalysisPattern. The patterns implemented so far calculate the most common indicators that inform decision-making while designing. The most essential of such patterns are density-based patterns. These patterns were based on Spacematrix by Berghauser-Pont and Haupt (Reference Berghauser-Pont and Haupt2010) and they calculate urban indicators, such as building intensity (FSI – floor space index), coverage (GSI – ground space index), average building height (L), spaciousness (OSR – open space ratio), and network density (N). We started by implementing patterns that calculated these indicators because most plans and regulations use density-based indicators to express goals and constraints.

The use of the indicators mentioned above requires knowledge of the Spacematrix theory. The patterns can be applied to calculate density indicators at “district” or “island” aggregation levels. For instance, as a typical workflow, embodying a contextualized design vision, we could consider the following procedural sequence: (1) calculate the average density of the existing blocks or islands (FSI and GSI) and average block size; (2) generate new urban blocks with identical density indicators set as block regulations; (3) define a phased occupation based on three urban elements set as attractors [e.g., two village centers – two-point attractors – and a road connecting both – a curve attractor (Fig. 5f)]. Attractors may influence design features differently by having different weights assigned. Figure 6 shows a design variation for the same site based on changes of attractor weights.

Fig. 6.

Variations of planned block distribution according to changes in the weight of the attractors.

Formal definition of generic grammars

After providing basic definitions of generic grammars and the underlying concepts and showing how these grammars can be implemented and applied in the urban design domain, we are in a better position to introduce more elaborate, formal definitions. As mentioned in Section 3, rules have the generic format

Shape grammars, as stated by Gips and Stiny (Reference Gips and Stiny1980), are production systems where u and v are labeled shapes and u → v applies a transformation t(u) to any similarity transformation of u (translation, symmetry, rotation, or scale) found in a design d such that

(2)$$d_1 = [d - t(u)] + t(v)$$

in other words, the design d ₁ is the result of subtracting a similarity transformation of the shape u from a design d and adding the corresponding transformation of the shape v. In a parametric environment, the shape u corresponds to any assignment of values g(u) to the parameters of shape u (Stiny, Reference Stiny1980). Therefore equation [2] becomes

(3)$$d_1 = [d - t(g(u))] + t[g(v)].$$

Parametric shape grammars may operate on objects found in the ontology shown in Figure 1. They are constrained by the semantic structure embedded in it, producing semantically consistent designs where representations are composed of shapes and symbols representing parts of the urban environment and other descriptions that convey semantic consistency to the overall design. Typically, urban design patterns are defined by shape grammars operating within a single class of the ontology. These are algebras of the format γ _i = {S _i, L _i, R, I _i}, where S _i and L _i are shapes and labels from an object class C _i, I _i is an initial labeled shape in the same class, R is a set of rules R of the form u → v that apply to objects u and v from class C _i. Designs produced by such patterns are kept within the same class of the ontology (γ _i → γ _i). An urban design pattern is triggered when its initial shape is placed in the design as a result of the instantiation of previous patterns by the corresponding shape grammar. These are the most common urban design patterns in an Urban Grammar Γ′ (Fig. 7). Patterns initiating the design generation process are called initial patterns. In urban design, initial patterns have as their initial shapes a preexisting object E in the existing urban context, set as a reference object R _ef. Rules of these kind transform E into some object u where u is a labeled shape belonging to a class C _i.

(4)$$E \to u\comma \,\; u\; \varepsilon \; C_i = \lcub {S_i\comma \,L_i} \rcub.$$

Fig. 7.

The Universal Urban Patterns Grammar and all its sub-grammars.

These rules allow the start of design generation from a particular object class C _i(E → γ _i); in other words, they initialize a specific type of urban objects in the design. It also means that the patterns that were previously referred to, those operating within the same object class, can now be applied. In addition to patterns of the form (4), some patterns can transform objects from one class into objects of another class. For instance, urban blocks (BL) can be transformed into buildings (BD). There are two types of these patterns. The difference between them lies in whether the rules transform objects from an upper level of the ontology (or level of abstraction) into those of a lower or vice versa, that is, whether they have the format (γ _i → γ _j) or (γ _j → γ _i). The former defines the semantic relation u has v; while the latter defines the relation v is part of u. In the former, rules assume the format:

(5)$$u \to v\comma \,\; u\; \varepsilon \; C_i \wedge v\; \varepsilon \; C_j\; \vert \; pr(C_i\comma \,C_j)$$

where pr stands for the primary relations given in Figure 1 constraining C _i to be of a higher level of abstraction than C _j, the semantic relation is u has v and the algebra γ _i permits one to apply a new algebra γ _j allowing for further detailing of the design. Conversely, the relation v is part of u produces rules of type:

(6)$$u \to v\comma \,\; u\; \varepsilon \; C_j \wedge v\; \varepsilon \; C_i\; \vert \; pr(C_i\comma \,C_j)$$

where an algebra γ _j allows to further develop parts of the design pertaining to an upper level of abstraction by generating new objects from an already opened algebra γ _i. These rules allow for fine-tuning the design enabling what in “design thinking” theory could be called corrective feedback loops. The several classes in the ontology help keeping the semantic structure clear but they also provide a clear means to separate design phases.

The idea behind the “Pattern Language” concept (Alexander et al., Reference Alexander, Ishikawa and Silverstein1977) was to define an algorithmic approach to architectural and urban design by providing common design instructions to solve well-known design problems. These instructions define verbal descriptions of the conditions required to apply a solution, also described verbally. In this paper, patterns describe typical urban design operations both verbally and algorithmically in the form of a discursive grammar (Duarte, Reference Duarte2005) by specifying the rules (R) that generate such design operations. In this case, patterns specify the objects they operate on, the classes they belong to, the class of objects they can generate and sometimes some constraints on shape attributes, thereby defining predicate conditions for pattern application and providing semantic guidance to rule application. Furthermore, patterns also state that their consequents belong to specific classes or are constrained to specific objects, attributes, or parameter ranges. The whole set of urban design patterns forms a generic grammar for urban design which can be applied in, possibly infinite, many different contexts.

In more detail, the complete set of patterns defines a generic grammar for urban design – the Urban Patterns Grammar Γ. Considering a hypothetical system where additional design patterns γ′ may be customized by the grammar user, the union of all grammars in the Urban Patterns Grammar Γ with all customizable grammars γ′ defines a theoretically infinite set of grammars that can generate any kind of urban design – the Universal Urban Patterns Grammar, Γ_∞. The Urban Design Patterns, called UIP in CItyMaker (Beirão et al., Reference Beirão, Duarte, Stouffs and Bekkering2012) replicate with a fair degree of flexibility a typical urban design operation. They are given by a discursive grammar of the format

(7)$$\gamma _i = \{ G\comma \,D\comma \,U\comma \,H\comma \,S_i\comma \,L_i\comma \,W\comma \,R\comma \,F\comma \,I_i\}.$$

The discursive grammar format addresses the complexity that semantic contextualization brings to urban design problems. U is a set of urban design regulations, that is, of constraints inherited from upper-level plans or from local or national legislation. G is a set of symbolic descriptions used to describe contexts, design goals, and designs. D is a set of description rules either used to generate the design goals from a context or to describe the designs being generated. Goals are the result of an urban program formulation procedure using tools and methods described in (Montenegro et al., Reference Montenegro, Gomes, Urbano and Duarte2011). Designs are obtained starting from an initial shape I _i, and applying rules R on objects taken from a class C _i in the urban ontology composed of shapes and labels {S _i, L _i} where S _i and L _i may sometimes be an empty shape and an empty label, depending on the class they represent. The generation of designs is guided toward the defined goals by resorting to a set of heuristics H based on the sequence of decisions defined at the beginning of Section 4. W is a set of weights, symbolic, or visual markers used to qualify formal descriptions, in order to assign meaning to shapes or to provide control devices over the generations of designs. F is a set of functions used to impose constraints on the way both description and shape rules can be applied, thereby providing additional control devices over design generation. For instance, they may relate regulations in U to symbolic descriptions in D or shape descriptions in S.

Implementation and methodological issues

Shape grammar implementations are usually confronted with difficulty in finding interpreters advanced enough to provide a friendly interactive environment for designing and for developing complex designs involving complex semantic conditions. Furthermore, any shape grammar implementation requires a deep discussion of the role of emergence within the design environment, and especially on the semantic control of emergent shapes in the design. Contrarily, parametric design interfaces are well developed and provide very interactive platforms, some of them quite in tune with what has been established through “design thinking” theory as responsive practice – continuous cyclical responses to trial design moves. Schön's see-move-see cycle (Reference Schön1983) shows with particular accuracy the importance of visual stimuli to design decision. Considering that parametric design environments generally provide the required stimuli that most designers request from a design platform, we decided to adapt the generic shape grammar concept to a generic parametric pattern concept as described in Section 4. The obtained structure forms what we could call a City Information Modeling (CIM) platform because it comprises the access to geographic information, spatial analysis tools, and parametric design tools.

Following an analogy with BIM (Building Information Modeling), CIM integrates into a single platform, urban design, and assessment tools. Broadly, a CIM platform is in accordance with the structure diagrammed in Figure 8 and described in the following. DB is a geographical database that can be read by a GIS or by a design interface composed of CAD software and a VPI that reads data from and writes data to DB. The two shaded areas represent the distinction between existing contextual data (light gray) and new design data generated by the design interface (dark gray). The CAD + VPI platform is structured as a programmable parametric design interface that uses a generic grammar for the generation of urban designs. The generic grammar is defined as described in the previous sections and is composed of several “urban design patterns” implemented as parametric design patterns in the VPI. Different combinations of “urban design patterns” with different input data produce different urban plans which can then be subjected to an evaluation in context using the UMC module. The UMC module, in association with the VPI, calculates the urban indicators that correspond to the urban models being generated. This process occurs in real time as indicators are immediately updated whenever changes to the design are introduced by changes in the input.

Fig. 8.

Diagram of the basic structure of a City Information Modeling (CIM) platform: DB, date base; GIS, Geographic information system; CAD, computer-aided design; VPI, visual programming interface, UMC, measures and calculations unit.

The implementation described above calculates density indicators of plans following the premises defined by Berghauser-Pont and Haupt (Reference Berghauser-Pont and Haupt2010). The parametric platform described above allows the user to generate urban plans by composing urban patterns and by choosing the values of parameters associated with the patterns. It also provides the user with immediate feedback expressed in terms of urban indicators, thereby enabling a control of the outcome. The urban plans produced with this platform are flexible as the platform can be used to regenerate alternative solutions by manipulating patterns and parameters.