CIM-St a Design Grammar for Street Cross Sections

CIM-St a Design Grammar for Street Cross Sections

CIM-St A Design Grammar for Street Cross Sections José Nuno Beirão1, Rui de Klerk2 1,2Faculty 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 pound grammar follows a procedural structure and CIM-St is an extension to a City Information Mod- is composed of two parallel grammars, one that gen- elling (CIM) tool, dedicated to the (semi-)automatic erates the street section and another that generates generation of street cross sections of street types se- the corresponding plan view. lected by the designer. The combination of shape grammars with on- The design system combines computational on- tologies results in a generative design system with tologies (Gruber, 1995) with a compound grammar analytical capabilities, ensuring the production of (Knight, 2003), an extension of the shape grammar valid design solutions at the end of the generative formalism (Stiny & Gips, 1972). The former describes process (Grobler et al., 2008). The knowledge base and structures knowledge about a specific knowl- of our system was built from part of the Networks edge domain (in this case, the city) and are used to ontology, itself a sub-ontology of the City ontology inform and control the design generation process, (Beirão, 2012), and provides a taxonomic structure of ensuring the semantic accuracy of the final design. the concepts of the street system and transportation The compound grammar, on the other hand, com- networks. bines generic shape rules (Beirão et al., 2009) en- In this paper, we will show that the semantics hanced with description functions (Stiny, 1981) that, of the design system is supported essentially by the informed by the ontologies, select which rule to ap- ontology structure which also controls the sequence ply and provide meaning to the designs. The com- of procedures through its hierarchic structure, while SPACE PERFORMANCE - Volume 2 - eCAADe 35 | 619 shape rules are very simple ones, essentially addi- Conceptually, as a design interface, the system was tions of parametric quadrilaterals where the para- developed considering that a designer soon after lay- metric variation is provided by the ontology depend- ing out the main ideas for a master plan will de- ing on the specifications of the shape class. sign the streets considering as input the width of the street section. Therefore, the initial shape in a street 2 THE NETWORKS ONTOLOGY section design generation will be an abstract section The networks ontology describes networks within composed of two opposite facades on opposite sides the City domain. The most representative one is the of the street at a distance corresponding to the street streets’ network, not just because it describes one of width. Technically, in terms of shape generation the the strongest morphological factors in urban mor- initial shape is the center point of the street section. phology, but also because it is the physical support However, the generation process starts with the gen- of most of other networks - public transportation; bi- eration of a street description by means of a descrip- cycle network; infrastructural networks, etc. tion grammar. The outcome of the description gram- The street network is composed of several sub- mar will then inform the compound shape grammar ontologies (Figure 1), a set of street names (SN - Street which will, in turn, be responsible for generating the Nomenclature), a set of descriptions defined in terms representation of the street profile. A parallel shape of the role of the street as part of the Transporta- grammar generates the plan view of the same street tion Network (TN), a set of street descriptions (SD) de- profile. scribing the partial components of a street section for each basic street type, and a set of street paramet- 3 GENERATIVE PROCESS ric components (SC) that combined according to the The street section design starts from a raw profile in- provided descriptions will generate a street section herited from a plan design (not addressed in this pa- in two types of Euclidian representations - plan view per). This raw profile contains the following informa- and section. tion: building section on both sides of the street, a center point half distance between them and a hier- archic value which constrains the association possi- Figure 1 bilities with the street types in the sub-ontology SN Structure of the (Figure 2).This hierarchic value is obtained from a ba- sub-ontologies sic axial representation of streets by means of their used in the CIM-St. centerlines which should have been already gener- ated 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 (lim- ited to the previously mentioned subset); the defini- tion of the components present in the final street pro- file; the specification and generation of each compo- nent’s geometrical representation and, finally, the as- sembly of the final representation of the street profile and its evaluation. 620 | eCAADe 35 - SPACE PERFORMANCE - Volume 2 Figure 2 have been yet implement, so we will omit more in- Raw profile of the formation about this sub-ontology. The reason for street, where omitting this part of the ontology was to skip some coordinate x0 is computational complexity that would only be focus- equal to half the ing on car oriented planning, factor that is nowadays width of the street. criticized as being responsible for destroying pub- The hierarchic value 3.1 Street Type Selection lic space quality since the advent of modernist plan- SN provides a vocabulary of street types: Street (st), was omitted ning. However, this implementation has not been Avenue (av), Boulevard (bv), Main Street (ms), Prom- because TN forgotten as we will argue in the discussion section. ontology is not yet enade (pr), Grove (gr), Lane (la), Alley (al), Cul-de-Sac implemented. (cs) and Ring Roads (rr). In a first step, a description 3.2 Street Description rule replaces the hierarchic information given as la- At a second step, a description rule establishes the bel associated with the street centre by a street type, minimum description of street components for each for instance, Street, and associates the label “st” with street type. For instance, a Street (st) is composed the street center. Technically, it erases the hierarchic at least by two sidewalks and a car lane in the mid- label (any between a1 and a4) and adds “st”. The hier- dle. Street Components (SC) is a set of street pro- archic label restricts the list of admissible street types file components such as the ones defined in Table 2. for a given raw profile based on its width, setting it as Note that in Table 2 street components are ordered a ceiling for the minimum possible width of the min- as follows: 1- street parking; 2 - sidewalks; 3 - bicycle imum description of each street type. In terms of the lanes; 4 - bus lanes; 5 - car lanes; 6 - green stripes; 7 design interface, all the user is required to do is select - noise protection; 8 - tree alignments; 9 - tram lanes; one of the possible street type options from a pull- 10 - canal; 11 - leisure walkway; 12 - protection rails. down menu in the interface. The integer numbers associated to the street compo- TN is an additional classification given in terms nents will be used as indices in the descriptions. of the role of the street as part of the transportation The rule can be written as: network. Adds a second classification given from an- D1 : st !< 2j5j2 > other semantic viewpoint. This classification allows Street descriptions are composed of four main ele- a user to define the role of the street while defining ments: symbols “<” and “>” marking the boundaries the role of the street from a transportation oriented (beginning and end, respectively) of the street de- viewpoint. Transportation Network (TN) as is defined scription; a sequence of integer numbers like “2” and in Beirão (2012) is a five-level hierarchic classification “5” (as in the description rule D1) representing differ- of car oriented streets that should be combined with ent street components and their order in the street SN street types in order to have a full street classifica- profile; and the symbol “|” working as a splitter of tion. the description, marking a separation between street Considering that the classification provided by components. If a street is composed of a single com- TN is essentially transit oriented while the classifica- ponent, as in the case of a narrow pedestrian street, tion given by SN is essentially based on a cultural no splitters are required in the description. description of a street that expresses its qualities in The minimum street description can then be ex- a name given in a particular language, we can say tended by adding other street components.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    10 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us