CIM-St
A Design Grammar for Street Cross Sections
José Nuno Beirão1 , Rui de Klerk2
1,2
Faculty of Architecture, University of Lisbon
1,2
{jnb|ruideklerk}@fa.ulisboa.pt
The design of streets plays an essential role in shaping the quality of our cities. In
particular, the design of a street's cross section determines in many aspects the
realm of its use, enhancing or reducing its ability for being walkable streets or
traffic oriented streets. This paper shows a street cross section design interface
where designs are controlled by an ontology and a parametric design system
supported by a shape grammar. The ontology provides a semantically ordered
vocabulary of shapes, symbols and descriptions upon which the grammar is
defined. This paper focuses on the grammar definitions and its translation into a
design oriented interface.
Keywords: Parametric Design, Ontologies, Compound Grammars, Street Cross
Section, Urban Design Systems
1 INTRODUCTION
CIM-St is an extension to a City Information Modelling (CIM) tool, dedicated to the (semi-)automatic
generation of street cross sections of street types selected by the designer.
The design system combines computational ontologies (Gruber, 1995) with a compound grammar
(Knight, 2003), an extension of the shape grammar
formalism (Stiny & Gips, 1972). The former describes
and structures knowledge about a specific knowledge domain (in this case, the city) and are used to
inform and control the design generation process,
ensuring the semantic accuracy of the final design.
The compound grammar, on the other hand, combines generic shape rules (Beirão et al., 2009) enhanced with description functions (Stiny, 1981) that,
informed by the ontologies, select which rule to apply and provide meaning to the designs. The com-
pound grammar follows a procedural structure and
is composed of two parallel grammars, one that generates the street section and another that generates
the corresponding plan view.
The combination of shape grammars with ontologies results in a generative design system with
analytical capabilities, ensuring the production of
valid design solutions at the end of the generative
process (Grobler et al., 2008). The knowledge base
of our system was built from part of the Networks
ontology, itself a sub-ontology of the City ontology
(Beirão, 2012), and provides a taxonomic structure of
the concepts of the street system and transportation
networks.
In this paper, we will show that the semantics
of the design system is supported essentially by the
ontology structure which also controls the sequence
of procedures through its hierarchic structure, while
SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 619
shape rules are very simple ones, essentially additions of parametric quadrilaterals where the parametric variation is provided by the ontology depending on the specifications of the shape class.
2 THE NETWORKS ONTOLOGY
The networks ontology describes networks within
the City domain. The most representative one is the
streets’ network, not just because it describes one of
the strongest morphological factors in urban morphology, but also because it is the physical support
of most of other networks - public transportation; bicycle network; infrastructural networks, etc.
The street network is composed of several subontologies (Figure 1), a set of street names (SN - Street
Nomenclature), a set of descriptions defined in terms
of the role of the street as part of the Transportation Network (TN), a set of street descriptions (SD) describing the partial components of a street section for
each basic street type, and a set of street parametric components (SC) that combined according to the
provided descriptions will generate a street section
in two types of Euclidian representations - plan view
and section.
620 | eCAADe 35 - SPACE PERFORMANCE - Volume 2
Conceptually, as a design interface, the system was
developed considering that a designer soon after laying out the main ideas for a master plan will design the streets considering as input the width of the
street section. Therefore, the initial shape in a street
section design generation will be an abstract section
composed of two opposite facades on opposite sides
of the street at a distance corresponding to the street
width. Technically, in terms of shape generation the
initial shape is the center point of the street section.
However, the generation process starts with the generation of a street description by means of a description grammar. The outcome of the description grammar will then inform the compound shape grammar
which will, in turn, be responsible for generating the
representation of the street profile. A parallel shape
grammar generates the plan view of the same street
profile.
3 GENERATIVE PROCESS
The street section design starts from a raw profile inherited from a plan design (not addressed in this paper). This raw profile contains the following information: building section on both sides of the street, a
center point half distance between them and a hierarchic value which constrains the association possibilities with the street types in the sub-ontology SN
(Figure 2).This hierarchic value is obtained from a basic axial representation of streets by means of their
centerlines which should have been already generated as a rough urban plan. This axial representation
simply classifies four types of street axes (from a1 to
a4) each admitting a consequent transformation to
a limited subset of the total set of SN and TN street
types. The transformation of each raw profile into a
coherent and valid street profile is done in four steps:
the selection of the type of street to be designed (limited to the previously mentioned subset); the definition of the components present in the final street profile; the specification and generation of each component’s geometrical representation and, finally, the assembly of the final representation of the street profile
and its evaluation.
Figure 1
Structure of the
sub-ontologies
used in the CIM-St.
Figure 2
Raw profile of the
street, where
coordinate x0 is
equal to half the
width of the street.
The hierarchic value
was omitted
because TN
ontology is not yet
implemented.
3.1 Street Type Selection
SN provides a vocabulary of street types: Street (st),
Avenue (av), Boulevard (bv), Main Street (ms), Promenade (pr), Grove (gr), Lane (la), Alley (al), Cul-de-Sac
(cs) and Ring Roads (rr). In a first step, a description
rule replaces the hierarchic information given as label associated with the street centre by a street type,
for instance, Street, and associates the label “st” with
the street center. Technically, it erases the hierarchic
label (any between a1 and a4) and adds “st”. The hierarchic label restricts the list of admissible street types
for a given raw profile based on its width, setting it as
a ceiling for the minimum possible width of the minimum description of each street type. In terms of the
design interface, all the user is required to do is select
one of the possible street type options from a pulldown menu in the interface.
TN is an additional classification given in terms
of the role of the street as part of the transportation
network. Adds a second classification given from another semantic viewpoint. This classification allows
a user to define the role of the street while defining
the role of the street from a transportation oriented
viewpoint. Transportation Network (TN) as is defined
in Beirão (2012) is a five-level hierarchic classification
of car oriented streets that should be combined with
SN street types in order to have a full street classification.
Considering that the classification provided by
TN is essentially transit oriented while the classification given by SN is essentially based on a cultural
description of a street that expresses its qualities in
a name given in a particular language, we can say
that TN provides a transit oriented structure while
SN provides a human oriented viewpoint. The idea
is that by giving different weights to the classifications the system may privilege one or the other approach. However, till now, none of the TN options
have been yet implement, so we will omit more information about this sub-ontology. The reason for
omitting this part of the ontology was to skip some
computational complexity that would only be focusing on car oriented planning, factor that is nowadays
criticized as being responsible for destroying public space quality since the advent of modernist planning. However, this implementation has not been
forgotten as we will argue in the discussion section.
3.2 Street Description
At a second step, a description rule establishes the
minimum description of street components for each
street type. For instance, a Street (st) is composed
at least by two sidewalks and a car lane in the middle. Street Components (SC) is a set of street profile components such as the ones defined in Table 2.
Note that in Table 2 street components are ordered
as follows: 1- street parking; 2 - sidewalks; 3 - bicycle
lanes; 4 - bus lanes; 5 - car lanes; 6 - green stripes; 7
- noise protection; 8 - tree alignments; 9 - tram lanes;
10 - canal; 11 - leisure walkway; 12 - protection rails.
The integer numbers associated to the street components will be used as indices in the descriptions.
The rule can be written as:
D1 : st →< 2|5|2 >
Street descriptions are composed of four main elements: symbols “<” and “>” marking the boundaries
(beginning and end, respectively) of the street description; a sequence of integer numbers like “2” and
“5” (as in the description rule D1) representing different street components and their order in the street
profile; and the symbol “|” working as a splitter of
the description, marking a separation between street
components. If a street is composed of a single component, as in the case of a narrow pedestrian street,
no splitters are required in the description.
The minimum street description can then be extended by adding other street components. For instance, in a Street (st) we may add a bicycle lane (D2)
or a parking lane (D3) at the side of each sidewalk.
D2 : 2|5 → 2|3|5
D3 : 2|5 → 2|1|5
SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 621
D4 : 5 → 5|5
Rules D2 and D3 can be applied only once on each
side of the street while rule D4 can be applied many
times until a total street width is “filled up”, adding as
many car lanes as required. By applying such rules,
we may obtain variations of the street type Street (st)
with formats like < 2 | 3 | 5 | 1| 2 >; < 2 | 3 | 5 | 3 | 2 > or
< 2 | 3 | 5 | 2 >. Other options can be obtained. Note
that rules D2 and D3 can be applied symmetrically as
follows:
D2 : 5|2 → 5|3|2
D3 : 5|2 → 5|1|2
The Street Descriptions (SD) column in Table 1 prescribe which adjacent components are admissible,
according to the profile schemas of Table 2, therefore
specifying which are the valid adjacencies accepted
in a street description. So, the rules shown above produce street descriptions which are always symmetric
and define what will be the components of the street
cross section to be generated. In order to develop
non-symmetrical street layouts we added a rule that
allows overriding the predefined street descriptions
at any point:
D5 : |→|x| where x is a variable representing
any street component that respects the adjacency
constraints mentioned above.
The reader should keep in mind that we do not
show the complete set of street description rules and
therefore should imagine possible additional rules
available for applying other street components not
mentioned in the examples above.
Table 1
Partial
representation of
the SN object class
622 | eCAADe 35 - SPACE PERFORMANCE - Volume 2
Parallel to the generation of street descriptions, the
system generates a detailed description of each component’s parameters. Table 1 shows a column indicating profile parameters which are user input variables constrained within a range of accepted standard values taken from well-established urban design standards (the reader may find additional information on this topic in Beirão (2012); for the purpose
of this paper the used values are the same as found
this latter reference, mostly taken from Pedro (2002)).
For instance, sidewalks are composed by the following set of parameters: {w, e, d, h} where the total sidewalk width is equal to e + w, and w = s + d including a tree alignment at d distance from the sidewalk
border. The parameter w which may be considered
the usable sidewalk width can variate between 1,25
and 5 meters. In the computer implementation, the
maximum limit was actually made flexible to accommodate automated adjustments because the sidewalk width is actually liable to be the most flexible
parameter. The value e, is particularly important in
terms of street performance because it is the value
that provides a space for activities developed inside
the buildings to ‘drool over’ the sidewalk contaminating the public space with the activities found inside the private spaces; for instance, a fruit stand or a
Cafe’s esplanade (Gehl, 2011; Barton, Grant, & Guise,
2010; Higueras, 2006). So, parallel to the street description rules for any situation where, for instance, a
sidewalk (“2”) is generated we will have a description
rule generating the description of the sidewalk:
C1 : 2 ← {w, e, d, h} where the parameters w,
e, d and h are all user input.
Additional description rules for other street components can easily be defined following Table 2.
Through this example, the reader can understand that the total width of the street can be easily checked automatically while generating the street
description providing information whether the street
cross section is already fitting the total street width or
not. Until this point it is also obvious that the whole
procedure is strictly symbolic.
3.3 Component Specification and Representation
At a third step, Street Component labels are replaced
by their representations. First, the components are
specified as one of their sub-types (when they have
one), as in the differentiation between “lateral” and
“central” sidewalks. These specifications are the result of the component’s position in the description,
options introduced by the designer or restrictions
defined in the ontologies, such as admissible adjacent components. Lateral sidewalks, for instance, appear in the street description immediately after or
immediately before a description boundary symbol
(i.e. “< 2 |” or “| 2 >”, respectively), while central sidewalks always appear between description splitters (“|
2 |”). Some street components (2 - sidewalks; 6 green stripes; 7 - noise protection) still allow a further
level of specification through their combination with
other components, as in the case of sidewalks with
tree alignments. These levels of specification correspond to user input and may be considered as part
of the platform’s design flexibility.
To avoid ambiguity, the ”_” symbol was introduced to link associated components’ indices. If we
consider the following partial description ”| 2_8 | 6
|”, we can undoubtedly state that the tree alignment
(”8”) is part of the central sidewalk (”2”), despite being placed next to a green stripe (”6”). Adding tree
alignments to sidewalks, therefore, is as simple using
the following description rule:
D6 : 2|→ 2 − 8|
, while adding tree alignments to green stripes and
noise protections follow similar rules:
D7 : 6|→ 6 − 8|
D8 : 7|→ 7 − 8|
Description rules D6, D7 and D8 could be generalized
as a production system (Gips & Stiny, 1980) with variable a and a single rule, where: a | → a_8 | and a is
a component that has no restrictions regarding the
addition of trees.
After the specification of the street components,
the system is ready to generate their representations
accordingly, following a tree derivation of the com-
SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 623
Table 2
Partial
representation of
the SC object class.
624 | eCAADe 35 - SPACE PERFORMANCE - Volume 2
pound grammar using a simple set of parametric
shape rules. Street components’ shape stem from the
center point of the street which, as we will see in the
next step, will be moved to its final position according to the street descriptions generated in the previous steps.
The shape rules applied in this process are of two
kinds:
(1) An addition rule adds an insertion point and
respective label for each description; the placement
coordinates of the point correspond to a translation
given from the street center point.
(2) A rule erases the label and replaces it with the
correspondent street component.
Figure 3
Parallel shape rules
with section and
plan
representations. R1
positions
components‘ labels
at the correct
location; R2
replaces labeled
points with both
the components’
section and plan
representations.
3.4 Profile Assembly and Evaluation
The global representation of the street cross section
comes with the verification of the total width of the
street together with the semantic accuracy of the
profile, which is ensured by the ontologies during the
generation process.
The last step mentioned in the previous section,
distributes the representations of the street components along the profile of the street, according to
the final description including already all the options
given by the user. In fact, due to the semantic structure given by the ontology the generated cross section contains in addition to all the morphologic description any further qualitative information associated with the options that might be considered useful for analytical purposes. Furthermore, the relationships between the street components and the cross
section as a whole define spatial relations within the
street space that might be evaluated differently according to the purpose of the street within the plan or
simply as a definition of public space quality. Therefore, we added a set of analytical tools that provide
additional information about the generated profile
that could express some of its qualities.
The analysis implemented until now are simply based on morphologic information and are composed of two simple graphics summarize in two pie
charts. The first graphic gives a chart on street component impact. The color code gives an immediate overview of the distribution of component types
differentiating those dedicated to people (in greenish tones) from those dedicated to traffic (in reddish
tones). This gives some information to the designer
about whether the street is essentially a pedestrian
or a car oriented street. The second pie chart indicates a rough measure of how much trees cover sidewalks. This value is calculated considering both the
tree width inputs in the user interface and the total width of sidewalks. The obtained chart is a very
rough representation of a relation of tree coverage
and available sidewalk space which might be argued
to lack important information such as tree type or distance between trees. Still, the chart provides a first
impression to the designer about a possible effect of
tree coverage along a street.
4 USER INTERFACE AND OUTPUTS
CIM-St interface for street profile design was meant
to be as simple and intuitive as possible, posing simple and direct questions to the users that will generate their designs and providing the necessary parameters in order to edit them. It was also meant to
provide enough flexibility for users to compose their
own street descriptions at will, in a simple and expedite fashion, through the direct manipulation of
the symbols in the street description. (Klerk & Beirão,
forthcoming)
Working mostly at the symbolic level, using production rules to define and manipulate descriptions
and set components’ parameters, allowed us to sim-
SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 625
plify not only information processing but also user interaction with the generative system. Simple, objective questions that can be mapped to Boolean or enumeration answers became the primary design mechanisms, allowing users to design at a semantic level
using natural language. Answers to these questions
target different levels of the ontology maintaining semantic relations and controlling the application of
the compound grammar’s rules.
Should the user desire a more direct approach to
the generation of the design, or if the street profile
required is not standard, the option to override the
description enables users to directly specify the type
of street components to use and where they will be
placed in the profile. This translates into controlling
the procedures of the grammar. In the interface, the
user simply introduces the street component index
where it is considered necessary.
The system was implemented with Grasshopper
3D mainly for educational purposes, so that architecture and urban design students willing to understand the inner workings of the application could
easily “take a look under the bonnet” and even modify or extend the application at will. Ontologies were
represented using XML format and stored in external files which are fed into the system using a custom
XML parser (refer to Klerk & Beirão (forthcoming) for
more information). As for the user interface itself, we
decided to implement it using Andrew Heumann’s
Human UI [1] add-on for Grasshopper 3D, giving it
a clean and responsive look with dynamic updates
and a dedicated pop-up window with visual analytics (Figure 4, right). The resulting design is displayed
in Rhinoceros front viewport (Figure 4, left) and can
be “baked” into the CAD application for further editing.
Users control the generation of the design
through CIM-St’s main window, starting with the selection of the type of street they desire and its total width. A series of simple, pre-defined questions
and parameter sliders will allow them to quickly customize their design. The questions posed to the users
are related with the existence of street parking and its
626 | eCAADe 35 - SPACE PERFORMANCE - Volume 2
type, if there are any bicycle lanes (one or two-way), if
there is a canal, if the system should use Green Stripes
to adapt any remaining space of the street and if it
should automatically add Tree Alignments to Sidewalks larger than 5 meters. A tab with sliders to control specific components’ parameters is also available
in the interface. Still in the ”Definition” menu, users
may override the given street description as mentioned above; on the ”Extras” menu, they will find
the controls for secondary elements (trees, acoustic
panel, buildings) and visualization options. Additionally, CIM-St provides a pop-up window with visual analytics, providing real time information to aid the design decision process, as mentioned above.
A preliminary study with graduate and undergraduate students taking the course of Parametric
Urban Design at the Faculty of Architecture, University of Lisbon (2016-2017), showed the interface to be
“clear and intuitive”, “user friendly and understandable”, with a “concise” and “visually appealing layout”
that “can be used easily” (user feedback).
Figure 4
CIM-St user
interface: canvas
(a); visual analytics
(b) and user input
menus (c).
5 DISCUSSION AND FUTURE WORK
The generative system behind CIM-St allows it to support designers in the rapid creation of large quantities of street profiles, relieving them from repetitive tasks and promoting the test and comparison of
many different solutions, leading to more qualified
design solutions.
CIM-St was thought to be a design tool containing additional information to support design decision during the ideation phase. During the development of the tool as is presented here and even during
the writing of this article, we were able to raise our
awareness on possible improvements or additional
features that can be easily introduced while providing additional information to support the users. As
such, in this section we provide an extended discussion on these topics.
As mentioned in section 3.1 the implementation of the TN sub-ontology is still missing. The implementation of this sub-ontology will allow introducing better evaluation criteria while distinguishing
or balancing information between traffic oriented
streets and pedestrian oriented streets. This addition will introduce the interesting topic of deciding how to weigh the two different vocations which
cannot be treated linearly because the topic is essentially network oriented. As such, this particular topic, although stressing its underlying interest,
should be carefully treated including the development of appropriate methods to approach it which
should certainly include topologic analysis as part of
the method.
At a representation level, it is evident that the
system would profit from having the generation of
the street cross section together with a partial plan
representation, let’s say, an extension in plan about
10 meters in length, which could provide the user
also a plan view of the street produced by that cross
section. The use of the plan has not been implemented yet but is foreseen to provide further possibilities in terms of design information.
The design interface already considers relatively
abstract information about the buildings containing
the street. Such information might be added to the
representation model and used for analytical purposes. So, more evident and probably easier to implement than the previously mentioned issues, there
are topics of analysis that can be promptly added to
the system. Here is a list of already planned work:
• A street parking indicator inspired on
the Parking Performance Index (PPI) of
Berghauser-Pont and Haupt (2010), using
the information gathered from the use of the
street parking component (“1” in Table 2). At
least, our street profile can set the assump-
tions regarding the street’s parking capacity
need to calculate PPI.
• Evaluating the potential of the sidewalks to
support street life based on its width and
already mentioned supporting theory. This
topic could be evaluated just roughly from the
morphological properties of the sidewalk but
more accurately by adding information about
qualities of the ground floor such as transparency and building porosity. In fact, the
tools shown here could be easily crossed with
the tools found in Beirão and Koltsova (2015)
providing positive inputs in both research approaches.
• Evaluating the canyon effect of the street profile together with the tree coverage. The
reader should understand that the system developed until now allows the user to input
the measures of trees - trunk and canopy which although not indicative of a particular tree type, allows the designer to set the
ideas about the kind of tree form planned for a
space providing evidence that might support
such decisions.
• Introducing street components with hybrid
functions. Presently, it is not possible to [explicitly] create street profiles with areas sharing different functions, such as a predominantly walkable street that allows a reduced
level of traffic to pass through it. This happens because current street components are
function-oriented and there is no option available to inform the system that a certain component may share some properties from another.
The system might also be improved by establishing a connection between the generated representations (which are low detail representations of street
profiles) and BIM providing constructive detail and
hence including the detail design phase in the design flow. As this intention can be easily obtained by
simply connecting this representation with already
existent IFC objects available in commercial software
SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 627
we decided that it could be interesting to add a kind
of pre-detailing sub-ontology where schematic constructive intentions could be added to the design; for
instance, setting permeability characteristics of pavements which may allow the calculation of additional
quality indicators like the street’s surface permeability index, information that may contribute towards
the design of more sustainable streets.
As a conclusive statement in this section, we
would like to stress that many of these features are
so easy to implement that we plan to have them
ready before the end of the year. After concluding
such tasks, the research will focus on the relations
between street morpho-types and building morphotypes to try to measure their mutual positive synergies.
6 CONCLUSIONS
The design interface described in this paper was implemented on a parametric visual interface following a compound grammar mostly composed of symbolic rules operating on ontology descriptions. The
semantic control over the design generation is obtained through the ontology which controls the relationships between the components of street profiles. The result is an elegant grammar composed of a
few description rules and two parallel shape rules replacing a description with an equivalent shape, one
generating the cross section representation and the
other the respective plan representation. The implementation follows the simplicity of the grammar and
puts its efforts on the interactivity of the design interface.
7 ACKNOWLEDGEMENTS
This work is integrated in the “Measuring Urbanity:
densities and performance of extensive urban fabrics. The Portuguese case” research project at the Research Centre for Architecture, Urbanism and Design
(CIAUD) at the Faculty of Architecture, University of
Lisbon (FAUL). The first author would like to thank for
the research grant CIAUD_BI_09/EAT/04008, which
made this work possible.
628 | eCAADe 35 - SPACE PERFORMANCE - Volume 2
REFERENCES
Barton, H, Grant, M and Guise, R 2010, Shaping neighbourhoods: for local health and global sustainability,
Routledge
Beirão, J 2012, CItyMaker. Designing Grammars for Urban
Design, Ph.D. Thesis, TU Delft
Beirão, J, Duarte, J and Stoufs, R 2009 ’An urban grammar for Praia: towards generic shape grammars for
urban design’, Proceedings of eCAADe 2009, Istanbul,
pp. 575-584
Beirão, J and Koltsova, A 2015, ’The Effects of Territorial
Depth on the Liveliness of Streets’, Nexus Network
Journal, 17, pp. 73-102
Berghauser-Pont, M and Haupt, P 2010, Spacematrix:
space, density and urban form, NAi Publishers
Gehl, J 2011, Life Between Buildings: Using Public Space,
Island Press, 6th ed
Gips, J and Stiny, G 1980, ’Production Systems and Grammars: A Uniform Characterization’, Environment and
Planning B: Urban Analytics and City Science, 7, pp.
399-408
Grobler, F, Aksamija, A, Kim, H, Krishnamurti, R, Yue,
K and Hickerson, C 2008, ’Ontologies and Shape
Grammars: Communication between KnowledgeBased and Generative Systems’, in Gero, J and Goel,
A (eds) 2008, Design Computing and Cognition ’08,
Springer Netherlands, pp. 23-40
Gruber, T 1995, ’Toward principles for the design of ontologies used for knowledge sharing?’, International
Journal of Human-Computer Studies, 43, pp. 907-928
Higueras, E 2006, Urbanismo Bioclimático, Gustavo Gili,
SL
Klerk, R and Beirão, J forthcoming, ’CIM-St: A Parametric
Design System for Street Cross Sections’, in Çağdaş,
G. et al. (eds) forthcoming, Computer-Aided Architectural Design: Future Trajectories, Springer Nature Singapore Pte Ltd.
Knight, T 2003, ’Computing with emergence’, Enironment and Planning B: Planning and Design, 30 (1), pp.
125-155
Pedro, J 2002, Programa Habitacional: Vizinhança Próxima, Laboratório Nacional de Engenharia Civil
Stiny, G 1981, ’A note on the description of designs’, Environment and Planning B: PLanning and Design, 8, pp.
257-267
Stiny, G and Gips, J 1972 ’Shape Grammars and the Generative Specification of Panting and Sculpture’, Proceedings of IFIP Congress 1971, pp. 1460-1465
[1] http://www.food4rhino.com/app/human-ui