TY - JOUR
AU - Zhang,, Kang
AB - ABSTRACT Researchers have proposed many approaches to generate floor plans using shape grammars. None of them, however, testifies the semantic relations among rooms. This paper presents a generic approach for grammar specification, grammar induction, validation, and design generation of house floor plans using their path graphs based on the reserved graph grammar (RGG) formalism. In our approach, the connectivity of a floor plan is analyzed by user-specified graph grammar transformation rules, also known as productions. Floor plans of houses in different styles share common attributes while retaining specific features. By identifying these features, our approach validates floor plans in different styles with user-specified graph productions. A graph grammar induction engine is also introduced to assist designers by automatically inferring graph productions from an input graph set. In addition, the derivation process in RGG offers the capability of generating floor plan designs. Two types of constraints, specified as attribute-sets, are introduced to generate floor plans meeting a wide range of requirements. To evaluate this generic approach, we design a set of productions to validate and generate floor plans in the style of Frank Lloyd Wright’s prairie houses. The results are discussed, and further research is suggested. 1. INTRODUCTION Over the past decades, shape grammar approaches have been widely used to generate floor plans in different styles. Researchers design rules by analyzing buildings in a certain style to decompose buildings into relatively simple shapes, called initial shapes, and summarizing relations among shapes, called transformation rules. Different combinations of transformation rules applied to initial shapes generate floor plans in the desired style. However, the bottleneck of shape grammar approaches is that the generation process in most shape grammars has worst-case exponential time complexity [1]. Moreover, the characteristics of floor plans generated by a shape grammar vary significantly. The spatial relations among rooms can be inconsistent for plans generated from a shape grammar. Certain generated floor plans are less likely to be selected in the reality, such as a floor plan in which a kitchen connects with a bedroom. Moreover, some shape grammars only handle special shapes, others, whose algorithms have worst case exponential complexity, are only able to generate small shapes. As a result, shape grammars have not been widely used in current computer-aided architectural design (CAAD) applications. Most designers still design buildings manually or semi-automatically on CAD platforms, e.g. Revit and AutoCAD. Moreover, due to the large volume of floor plan designs generated by both scientists and designers, in one style, some designs look similar while their room arrangements are significantly different. Therefore, floor plan analysis has to be performed to address this diversity issue. Existing approaches, however, typically focus on the field of path-finding and path-planning [2]. To address the aforementioned issue, our research focuses on the analysis of semantic relations among rooms. We provide a generic approach for analyzing the spatial organization, specifying styles of floor plans, and generating designs based on the reserved graph grammar (RGG) formalism [30]. RGG is a 2D graph mechanism to model structures and concepts. It has been successfully applied in many applications, including software architecture verification [3] and rapid software prototyping [4]. It is capable of both parsing and generating graphs based on a specified set of productions. Our approach is able to validate and generate floor plans by analyzing the room arrangements from a set of given plans. It first takes floor plans in a style as the input to analyze common features among these plans. With the extracted features, a set of RGG productions could be written to define the constraints for the given floor plan style. Productions specify the relationships among rooms or areas (combinations of rooms). With the proposed RGG rules, users are able to validate whether an input floor plan belongs to the given style. To enhance the generation capability and usability of RGG, both node constraint and edge constraint are introduced for generating rooms meeting various design requirements. Unlike shape grammars, which typically focus on design generation, graph grammars have been widely studied in computer science for modeling and analyzing the syntax and semantics of graph structures. Figure 1 presents two conceptual models of the shape grammar generating process and the graph grammar reduction/derivation process in parsing/deriving floor plans. The shape grammar generating process takes initial shapes and transformation rules as inputs to generate floor plans by applying transformation rules to initial shapes in a top-down fashion. Similarly, the graph grammar derivation process derives graphs by repeatedly applying given productions. The graph grammar reduction process, on the other hand, takes path graphs and production rules as inputs to parse the path graphs by applying production rules in a bottom-up fashion. Our approach uses graph grammars to analyze spatial information among rooms. By parsing graphs with user-specified productions, it analyzes and validates the structure of input floor plans. A valid parsing result represents the input plan satisfying properties specified in the productions. FIGURE 1. Open in new tabDownload slide Two conceptual models for the shape grammar generating process and the graph grammar reduction/derivation process. FIGURE 1. Open in new tabDownload slide Two conceptual models for the shape grammar generating process and the graph grammar reduction/derivation process. In our approach, a graph grammar specification, parsing, and induction tool VEGGIE (Visual Environment of Graph Grammar Induction Engineering) [5] is introduced for designers to create/revise productions and generate/validate floor plans. An induction algorithm, which automatically infers graph productions from a given graph set, is implemented in VEGGIE for helping designers to define and induce grammars from given graphs. In summary, this paper presents a graph-grammar-based approach that automatically generates or validates floor plans conforming to a style. To validate the style of a floor plan, either generated by a shape grammar formalism or stored in any type of files, such as an image or a semantic rich file, our approach takes the path graph of the floor plan as the input. Each node in the graph represents a room and each edge between two nodes represents the connection of two rooms by either a door or an open area in the original floor plan. The induction algorithm in VEGGIE helps designers to infer RGG productions for a set of given floor plans by identifying common structures. VEGGIE then validates floor plans by parsing the path graphs with user-specified RGG productions. Each transformation applied to the input graph is treated as a local composition of rooms. Once the input graph, representing a floor plan, transforms to λ (shown in Fig. 1), the end state in a graph grammar, we consider it as a valid graph. The corresponding floor plan conforms to the grammar-specified style. Different productions validate floor plans in different styles with specific properties. On the other hand, the derivation process in RGG along with the two types of constraints we have introduced make our approach capable of generating designs meeting various requirements. This paper addresses these aforementioned problems and makes the following contributions: A generic approach for grammar specification, grammar induction, spatial organization and validation of floor plans based on the RGG formalism. A complete graph grammar for specifying and analyzing floor plans in the style of Frank Lloyd Wright’s prairie houses (or simply Wright houses). Two types of constraints, specified as attribute-sets, capable of generating customizable designs meeting a wide range of design requirements. The accuracy of this graph grammar validated via comprehensive experiments for Wright houses built by Frank Lloyd Wright in different periods and floor plans in different styles. The rest of this paper is organized as follows. Section 2 reviews the related works, including floor plans generated by shape grammars, recently proposed path planning approaches, and several typical graph grammars. Section 3 briefly introduces the RGG. Next, Section 4 gives an overview of our approach. Thereafter, Section 5 provides the detailed graph grammar approach for specifying floor plans in the style of Wright houses. Section 6 presents the induction algorithm implemented in VEGGIE and how the algorithm helps designers in creating graph grammars. Section 7 explains the derivation capability by showing generated Frank Lloyd floor plans with different requirements. Section 8 discusses and evaluates the validation results. Finally, Section 9 concludes the paper and mentions future work. 2. RELATED WORK Shape grammar has been widely studied to generate building plans in the past decades. It was first proposed by Stiny and Gips [6] for modeling spatial relations of geometries in paintings and sculptures. Stiny [7] proposed a shape grammar approach to generate Chinese lattice designs by applying rules from simple shapes. It was then expanded to the field of industrial design and architecture design. Agarwal and Cagan [8] designed a coffee maker grammar, which generates a large class of coffee makers from simple shapes. Each product consists of a filter, a base, a water storage and other components. Chen et al. [9] introduced a set of rules to generate archetypes. In their approach, different styles of bicycles, motorcycles, and cars are discussed and generated. Researchers also proposed shape grammar approaches to generate building plans in different styles, such as Palladio’s villas [10], Mughul gardens [11], and Wright houses [12]. Different arrangements of rules generate plans differently, while sharing specific properties keeping them in the same style. With the massive building data, either generated by shape grammar approaches or designers in the industry field, studies have begun to analyze the connectivity of buildings, so-called path planning problem. It has been widely discussed by GIS researchers for indoor navigation. From the source file point of view, this problem is divided into two categories. One analyzes building paths from floor plan images and the other from semantic rich files, such as Industry Foundation Classes (IFC) and CityGML. Mace et al. [13] proposed an approach to analyze and detect rooms from floor plan images. Their approach is based on the Hough Transform and associates with the image vectorization. Walls are detected by lines and doors are detected by arcs. A similar technique is used by Ahmed et al. [14] for detecting rooms from floor plan images. Their approach detects walls by separating thick and thin lines. Same authors [15], later, introduced a system to extract structural and semantic contents from given floor plan images. Lam et al. [16] proposed an approach to extract topological graphs from floor plan images for robot navigation. Instead of analyzing floor plans from images, Lin et al. [2] provided a path planning method based on IFC files. Their method extracts door-room connectivity graphs, i.e. path graphs, from IFC files by detecting rooms and doors. Strug and Ślusarczyk [17] proposed a prototype helping disabled to find a feasible route in a building. Their approach extracts building layout information from IFC files and searches candidate paths based on the layouts. Liu and Zlatanova [18] developed an algorithm to extract path graphs from floor plans in the format of CityGML. With the path graphs, our approach analyzes and validates their structures by the state of art graph grammar technology. Graph grammar is a well-established technique to model structures and concepts in a 2D fashion and a formal method that is used to specify visual programming languages (VPLs). It has been successfully applied to different applications, including mechanical parts description [19], XML validation [20], cluster analysis [21], entity-relationship (E-R) diagram validation [22], and Web pattern recognition and validation [23]. Slusarczyk [24] proposed a framework for supporting the design process by defining design requirements using hierarchical layout graph grammars. This approach represents designs as hierarchical layout hypergraphs (or HL-graphs), while considering local and global constraints. It does not analyze the different connectivities among rooms in different styles of floor plans. To our knowledge, our work is the first attempt to specify, analyze and validate styles of floor plans by a graph grammar approach. Since the path graph is a 2D graph representing the connectivity of rooms, it is natural to define floor plan styles through graph grammars. Our approach is powerful enough to analyze and validate floor plans with user-specified grammars. It can efficiently update parsing rules without changing the source code for different styles of floor plans. 3. RESERVED GRAPH GRAMMARS Extended from string grammars, graph grammars provide a 2D formal method and an intuitive tool for specifying various types of visual or graphical languages [25, 26]. There are two workflows in graph grammars: derivation and reduction, both based on a process which replaces a match (called a redex) of one side of a production in the input graph (called the host graph) with the other side of the same production. In derivation, one uses L-applications, where the redex is isomorphic to the left graph. In reduction, one uses R-applications, where the redex is isomorphic to the right graph. The derivation often serves to define a language that consists of any graphs that conform to the specified grammar. Accordingly, the reduction is mainly used to parse the structure of a graph, i.e. to check whether the graph is valid. RGG [27] is a context-sensitive graph grammar formalism. It was the first to introduce a marking mechanism to represent the context, which greatly simplifies the production format and reduces the number of productions. Since the marking mechanism is helpful for specifying various connections between rooms in floor plans, we choose RGG to perform the floor plan parsing and derivation. We formally define RGG below. Definition 1 Given a label set L, n:=(s, l, V) is a node over L, where V is a finite set of vertices; s ∈ V is a super vertex; l: V → L is an injective mapping from V to L. Within each node in RGG, a two-level structure is used to manage the connection points of edges. The structure is built up with a super vertex and vertices. As shown in Fig. 2, a node labeled ‘Statement’ has a two-level structure, where the outer square is the super vertex and the two inner squares labeled ‘T’ and ‘B’ are vertices. A super vertex or a vertex can be connected with one or more edges. The two-level structure can formally and clearly manage the connection between nodes. FIGURE 2. Open in new tabDownload slide Two-level structure of a node in RGG. FIGURE 2. Open in new tabDownload slide Two-level structure of a node in RGG. To define the RGG and its properties formally, we will introduce several basic concepts, such as a marked graph, isomorphic graphs and a redex. For simplicity, we use the notation n.V to represent the vertex set of node n and id(v) to represent the identifier of vertex v. Each vertex in a graph is assigned a unique identifier id(v). We often use (v1, v2) to denote (id(v1), id(v2)). These conventions are applicable to other definitions. Definition 2 G:= (N, E, M) is a marked graph over a label set L, where G.N is a finite set of nodes over L; G.E = {(v1, v2)} is a finite set of edges, where v1, v2 ∈ N.V ({N.V = {n.V | n ∈ N}) ∧ (v1, v2) = (v2, v1)}); G.M: V → I is a bijective mapping, where V ∈ N.V, and I is a set of integers. We use mark(v) = m to indicate that v is marked, by an integer m (m ∈ I), and mark(v) = null to indicate that v is unmarked. Definition 3 Two nodes n1and n2are isomorphic, denoted as n1 ≈ n2, iff they are defined over the same label set; ∃f ((f: n1.V → n2.V is a bijective mapping) ∧∀v ∈ n1.V (n1.l(v) = n2.l(f(v))) ∧ n2.s = f(n1.s)). Definition 4 Two graphs G1and G2are isomorphic, denoted as G1 ≈ G2, if ∃f: G1 → G2which is the parallel of two bijective mappings fnand fesuch that ∀n ∈ G1.N: n ≈ fn(n); ∀e = (v1, v2) ∈ G1.E: fe(e) = (fn(v1), fn(v2)) ∈ G2.E. With the definition of isomorphism, the definition of redex is given as follows. Definition 5 A sub-graph X of a graph H is called a redex [27] of a marked graph G, denoted as X ∈ Redex(H, G), iff ∃f: G → X which is the parallel of two bijective mappings fnand fesuch that X ≈ G; ∀v ∈ G.V ((mark(v) = null) ∧ ∀v1 ∈ H (e = (fn(v), v1) ∈ H) → e ∈ X. Replacing the redex in the form specified in the definition during graph transformation ensures no dangling edges to be created. The embedding problem deals with linking the replacing subgraph and is an important issue in L/R application. To handle the embedding problem, the context is represented by vertices rather than nodes in the productions. A marking mechanism is introduced to vertices to avoid dangling edges. Each vertex that represents the context in a production graph could be assigned a unique integer. In addition, a bijection is also needed between marks in both left and right graphs to ensure the dangling condition. Figure 3 shows a RGG production, where the vertices marked ‘1’ and ‘2’ in the production graphs are used to represent the context. By the marking mechanism, an L/R-application in RGG can be mainly divided into two steps: Deleting the redex from the host graph, except for the vertices that are isomorphic to the left/right graph’s marked vertices. Embedding the left/right graph into the host graph, where the marked vertices in the left/right graph are treated as the same as the reserved vertices in Step 1. FIGURE 3. Open in new tabDownload slide A production of RGG. FIGURE 3. Open in new tabDownload slide A production of RGG. Figure 4 shows a R-application using the production described in Fig. 3. Obviously, the embedding problem is well handled by the marking mechanism. FIGURE 4. Open in new tabDownload slide A R-application of RGG. FIGURE 4. Open in new tabDownload slide A R-application of RGG. In this work, to simplify the marking mechanism, we only mark nodes by assigning unique numbers to their vertices. A marked node represents that one of its vertices is marked and can connect with the remaining graph. In a graph grammar formalism, a parsing algorithm is necessary for the parsing efficiency. Zhang et al. [27] proposed a Selection-Free Parsing Algorithm (SFPA) for RGG, which runs in a polynomial time. It should be noted that the using of SFPA has a precondition called selection-free condition, which demands that the order of the applications of productions should not influence the parsing result. 4. OVERVIEW Our approach takes a floor plan’s path graph as the input to validate its style. Since the path planning problem is well studied by researchers, either from floor plan images or semantic rich files, e.g. [14] and [2], our study assumes that path graphs are retrievable. With user-specified grammar productions and VEGGIE, our approach parses path graphs to validate styles of floor plans. 4.1. Grammar design and floor plan validation This sub-section presents an overview of our approach for specifying and validating floor plans in different styles using RGG productions. Here, we introduce a graph grammar approach to parse and validate floor plans in the style of Wright houses. As demonstrated in Fig. 1, to validate the structure of an input floor plan, our approach takes the spatial information, i.e. the path graph, as the input. By parsing the path graph with pre-defined grammar productions, it validates whether the input floor plan satisfies the features described in the graph grammar. Designing a graph grammar is a one-time effort. Once a graph grammar is defined, it validates floor plan instances in a certain style. A set of productions, which will be introduced in the next section, are designed by analyzing Wright houses. The grammar divides a Wright house into three separate areas, i.e. a Living area (LA), a Service area (SA), and a Bedroom area (BA), according to the areas’ functionalities. By analyzing Wright houses, we summarize the specific features and draw the hierarchical chart among rooms, as shown in Fig. 5. Each room or area represents a node in RGG. An edge exists between two nodes if the two corresponding rooms/areas are connected. A floor plan consists of three areas and each area contains several sub-areas. Rooms in original Wright house floor plans are colored gray, also refer to terminal nodes in RGG. Others, also refer to non-terminal nodes, are new nodes generated by parsing input graphs. By applying productions, RGG determines if the target floor plan satisfies the properties specified by the productions. FIGURE 5. Open in new tabDownload slide The hierarchical structure of Wright houses. FIGURE 5. Open in new tabDownload slide The hierarchical structure of Wright houses. Due to the different structures, productions are varied for specifying floor plans of different styles. A running example of specifying floor plans in the style of Wright houses is given in Section 5. There are several factors that may affect the classification results. First, different terminal nodes specified in productions cause different validation results for the same floor plan, e.g. parsing a floor plan, which has a Living room, using a graph grammar that does not define Living room as a terminal node. Moreover, distinct non-terminal nodes also derive different results, e.g. classifying nodes by functionalities (Living area, Service area, and Bedroom area) or by human actions (Living area, Kitchen area, and Rest area). 4.2. Floor design generation Most existing floor plans are generated by designers manually. Although some researchers use shape grammars to automatically generate designs, the room arrangements of generated designs may be drastically different. Given several similar designs and a shape grammar, it is difficult to determine which designs were generated from the grammar. Our approach is capable of generating path graphs of designs belonging to any style. Based on the generated path graphs, designers can then generate designs manually or automatically by CAD tools, e.g. Slusarczyk [24]. More specifically, with user-specified productions, our approach generates path graphs by performing the derivation process supported by SGG. Since our approach is able to validate styles of designs, the path graphs of generated designs can be used as inputs to track from which grammar they were generated. In real-world design, designers are constrained by various requirements, such as the number of bedrooms, the number of bedrooms connecting with bathrooms, the types of rooms connecting with a living room, or rooms with windows. In traditional designs, these constraints are considered by designers during the design process. To generate the designs fulfilling various constraints, we need a specification mechanism to guide the generation process in a way that satisfies given requirements. Our approach is extensible and can incorporate constraints to control generated designs. In our current implementation, we introduce two types of attribute-sets as constraints, one for nodes and the other for edges. The node constraint specifies the number of times a type of room, e.g. bedrooms, in a generated design. The edge constraint specifies the number of times a type of connection, i.e. sub-structures, existing in a generated design, such as the number of bedrooms each connecting with a bathroom. The node constraint is specified by a set of two attributes <a, n>, where a is the name of a node, representing a room, and n is the number of occurrences of a in a generated design. The edge constraint is specified by a set of three attributes <a, c, n>, where a and c are the two ends, representing two rooms, of this edge instance, and n is the number of occurrences of the edge instance in a generated design. If n is specified as 0, our approach treats this edge/node instance non-existent and would not execute the corresponding production. The constraints are independent, and the combination of different constraints is powerful enough to generate designs meeting various requirements. For example, with the requirements that a floor plan must consist of three bedrooms and two of them each equipped with at least one bathroom, attribute-sets <<Bedroom, 3>, <Bedroom, Bathroom, 2>, <Bathroom, 2>> could be used to generate designs fulfilling the requirements. Since our generation process is strictly based on both constraints and graph grammars, the generated designs are well controlled and organized. Figure 6 shows two graphs having different numbers of bathrooms while satisfying the same constraints <<Bedroom, 3>, <Bedroom, Bathroom, 3>>. The dotted lines in Fig. 6 represent the connections to other nodes. If the designer requires a specific number of bathrooms in the generated designs, a node constraint on bathrooms could be added. For example, we could specify our graph grammar to require that each bedroom can at most have one bathroom (<<Bedroom, 3>, <Bedroom, Bathroom, 3>, <Bathroom, 3>, <Bathroom, Stairs, 3>, <Stairs,2>>). Designers should, however, specify a minimal number of constraints to avoid unnecessary processing time. FIGURE 6. Open in new tabDownload slide Two graphs satisfying the constraints <<Bedroom, 3>, <Bedroom, Bathroom, 3>>. FIGURE 6. Open in new tabDownload slide Two graphs satisfying the constraints <<Bedroom, 3>, <Bedroom, Bathroom, 3>>. An overview of the algorithm for validating edge/node constraints during the derivation process is presented in Algorithm 1. At the end of the derivation process, a validation method is also needed to check whether the generated graphs fulfill all given constraints. An unsatisfiable constraint, e.g. requiring a kitchen to be connected with a bedroom, may lead the algorithm to an infinite search space. A proper threshold should therefore be set to the maximal number of iterations allowed for the algorithm. Algorithm 1 Validating constraints Line Function validateConstraints (Production p, NodeConstraints nc, EdgeConstraints ec) { 1  NodeConstraints tnc ← nc; 2  EdgeConstraints tec ← ec; 3  Nodes removedNodes ← p.LHS.nodes - p.RHS.nodes; 4  // find nodes not on RHS but on LHS of the production. 5  Nodes newNodes ← p.RHS.nodes – p.LHS.nodes; 6  Edges removedEdges ← p.LHS.edges – p.RHS.edges; 7  Edges newEdges ← p.RHS.edges – p.LHS.edges; 8  for Node n in removedNodes 9   if tnc.nodes contain n 10    tnc.get(n).num ← tnc.get(n).num + 1; 11  for Node n in newNodes 12   if tnc.nodes contain n 13    if tnc.get(n).num = 0 14     return FALSE; 15    else 16     tnc.get(n).num ← tnc.get(n).num - 1; 17  for Edge e in removedEdges 18   if tec.edges contain e 19    tec.get(e).num ← tec.get(e).num + 1; 20  for Edge e in newEdges 21   if tec.edges contain e 22    if tec.get(e).num = 0 23     return FALSE; 24    else 25     tec.get(e).num ← tec.get(e).num - 1; 26  nc ← tnc; 27  ec ← tec; 28  return TRUE; } Line Function validateConstraints (Production p, NodeConstraints nc, EdgeConstraints ec) { 1  NodeConstraints tnc ← nc; 2  EdgeConstraints tec ← ec; 3  Nodes removedNodes ← p.LHS.nodes - p.RHS.nodes; 4  // find nodes not on RHS but on LHS of the production. 5  Nodes newNodes ← p.RHS.nodes – p.LHS.nodes; 6  Edges removedEdges ← p.LHS.edges – p.RHS.edges; 7  Edges newEdges ← p.RHS.edges – p.LHS.edges; 8  for Node n in removedNodes 9   if tnc.nodes contain n 10    tnc.get(n).num ← tnc.get(n).num + 1; 11  for Node n in newNodes 12   if tnc.nodes contain n 13    if tnc.get(n).num = 0 14     return FALSE; 15    else 16     tnc.get(n).num ← tnc.get(n).num - 1; 17  for Edge e in removedEdges 18   if tec.edges contain e 19    tec.get(e).num ← tec.get(e).num + 1; 20  for Edge e in newEdges 21   if tec.edges contain e 22    if tec.get(e).num = 0 23     return FALSE; 24    else 25     tec.get(e).num ← tec.get(e).num - 1; 26  nc ← tnc; 27  ec ← tec; 28  return TRUE; } Open in new tab Algorithm 1 Validating constraints Line Function validateConstraints (Production p, NodeConstraints nc, EdgeConstraints ec) { 1  NodeConstraints tnc ← nc; 2  EdgeConstraints tec ← ec; 3  Nodes removedNodes ← p.LHS.nodes - p.RHS.nodes; 4  // find nodes not on RHS but on LHS of the production. 5  Nodes newNodes ← p.RHS.nodes – p.LHS.nodes; 6  Edges removedEdges ← p.LHS.edges – p.RHS.edges; 7  Edges newEdges ← p.RHS.edges – p.LHS.edges; 8  for Node n in removedNodes 9   if tnc.nodes contain n 10    tnc.get(n).num ← tnc.get(n).num + 1; 11  for Node n in newNodes 12   if tnc.nodes contain n 13    if tnc.get(n).num = 0 14     return FALSE; 15    else 16     tnc.get(n).num ← tnc.get(n).num - 1; 17  for Edge e in removedEdges 18   if tec.edges contain e 19    tec.get(e).num ← tec.get(e).num + 1; 20  for Edge e in newEdges 21   if tec.edges contain e 22    if tec.get(e).num = 0 23     return FALSE; 24    else 25     tec.get(e).num ← tec.get(e).num - 1; 26  nc ← tnc; 27  ec ← tec; 28  return TRUE; } Line Function validateConstraints (Production p, NodeConstraints nc, EdgeConstraints ec) { 1  NodeConstraints tnc ← nc; 2  EdgeConstraints tec ← ec; 3  Nodes removedNodes ← p.LHS.nodes - p.RHS.nodes; 4  // find nodes not on RHS but on LHS of the production. 5  Nodes newNodes ← p.RHS.nodes – p.LHS.nodes; 6  Edges removedEdges ← p.LHS.edges – p.RHS.edges; 7  Edges newEdges ← p.RHS.edges – p.LHS.edges; 8  for Node n in removedNodes 9   if tnc.nodes contain n 10    tnc.get(n).num ← tnc.get(n).num + 1; 11  for Node n in newNodes 12   if tnc.nodes contain n 13    if tnc.get(n).num = 0 14     return FALSE; 15    else 16     tnc.get(n).num ← tnc.get(n).num - 1; 17  for Edge e in removedEdges 18   if tec.edges contain e 19    tec.get(e).num ← tec.get(e).num + 1; 20  for Edge e in newEdges 21   if tec.edges contain e 22    if tec.get(e).num = 0 23     return FALSE; 24    else 25     tec.get(e).num ← tec.get(e).num - 1; 26  nc ← tnc; 27  ec ← tec; 28  return TRUE; } Open in new tab As an example, we use a set of productions, presented in Fig. 7, to generate graphs with different requirements specified as attribute-sets. Several generated graphs are presented in Fig. 8. The graph in Fig. 8a requires that A only connects with C by specifying attribute-set <A, B, 0>. With attribute-sets <<A, B, 3>, <A, 1>, <B, 3>> as constraints, the graph in Fig. 8b is generated by applying production a once, b once, and c twice in Fig. 7. Applying the production b here does not conflict with the attribute-sets since the attribute-sets only require one A connecting with three B without specifying that A cannot connect with C. The graph in Fig. 8c, where attribute-sets <<A, B, 2>, <C, 1>, <B, 2>> are attached, is generated by applying each of these three productions once. The examples testify that the two types of attribute-sets are robust to handle various design requirements. FIGURE 7. Open in new tabDownload slide A set of RGG productions. FIGURE 7. Open in new tabDownload slide A set of RGG productions. FIGURE 8. Open in new tabDownload slide Graphs generated by productions specified in Fig. 7 with different attribute-sets, (a) with attribute-set <A, B, 0>, (b) with attribute-sets <<A, B, 3>, <A, 1>, <B, 3>> and (c) with attribute-sets <<A, B, 2>, <C, 1>, <B, 2>>. FIGURE 8. Open in new tabDownload slide Graphs generated by productions specified in Fig. 7 with different attribute-sets, (a) with attribute-set <A, B, 0>, (b) with attribute-sets <<A, B, 3>, <A, 1>, <B, 3>> and (c) with attribute-sets <<A, B, 2>, <C, 1>, <B, 2>>. 5. VALIDATION OF WRIGHT HOUSES The well-established theoretical background of graph grammar provides a natural and powerful syntax-definition formalism [25] for VPLs. Our approach starts from parsing a path graph and gradually abstracts the graph to a less complex one. During the deduction, it searches for any structure identical to the right graph of a production in the grammar and replaces the structure by the left graph of the production. In our graph-grammar-based application of floor plan design, each node represents a room or an area in the input floor plan. An edge between two nodes presents the connectivity between the two rooms/areas. More specifically, there are two types of nodes, terminal nodes and non-terminal nodes, in the grammar. A terminal node, similar to a leaf node in the tree data structure, represents a specific room in a floor plan. A non-terminal node represents a set of abstracted rooms or an area generated while parsing RGG productions. To define a graph grammar for specifying floor plans of a certain style, we first analyze floor plans of that style by dividing each plan into several areas in a hierarchy. Each area contains rooms with identical features, such as a similar functionality. We then abstract the connectivity between rooms into graph productions for each area. As an example, we introduce a set of graph productions for specifying floor plans in the style of Wright houses. Frank Lloyd Wright is widely known as a modern architect, who had a distinct vision for American style houses and was the founder of organic architecture. He believed that structures should be in harmony with humanity and its environment. For every component attached to a structure, the effect on the structure should be considered. Wright emphasized the importance of the integration between a structure and its natural surroundings. Fallingwater, as the most representative organic house designed by him, was built partly over a waterfall. Wright was recognized as ‘the greatest American architect of all time’ by the American Institute of Architects in 1991. Besides houses, He also designed other structures, including churches, banks, museums, and hotels, etc. He is also known as the founder of the ‘Prairie’ house, which is the first uniquely American architectural style. Houses of this style are recognized by horizontal lines and low-perched roofs. Most of his houses were designed as American middle-class family homes. Although houses are varied in their materials, sizes, etc., the composition of rooms is consistent, including a Living area, a Service area, and a Bedroom area. Koning and Eizenberg [12] introduced a shape grammar approach to automatically generate Wright houses. The authors identify the following: The design is divided into function zones demoted by the tones in the drawings. These zones include a living area consisting of, for example, a living room, dining room, library, and entry and reception area; a service area consisting of kitchen, pantries, servants quarters, and main floor bedrooms; a bedroom area consisting of upper-level bedrooms, bathrooms, and so on. Following this guideline, their approach generates three areas according to functionalities. They consider a house of this style consisting of a Living area (LA), a Service area (SA), and a Bedroom area (BA). A LA, as the center of the house, connects with the other two areas (for a double-storied house, the BA shares stairs with the LA). Our graph grammar starts from terminal nodes, representing rooms in floor plans, in the low-level to abstract nodes into high-level areas by performing the reduction process. It then merges areas into a house. We identify 67 floor plans of Wright houses, designed by Frank Lloyd Wright [28], and manually summarize the following features: A LA in the center connects with a BA and a SA. A Laundry is connected with a Kitchen. Servants quarters are connected with a Kitchen. Certain Bedrooms are connected with another Bedroom. We illustrate the following graph productions, which include the above features, for specifying floor plans of this style. Our graph grammar follows Koning and Eizenberg’s shape grammar approach to derive three areas, LA, SA and BA, from an initial floor plan. A LA includes a Living room, an Entry, a Dining room, and Living subareas (LSubs). As presented in Fig. 9, a Living subarea described in Production 1 represents one of Terrance, Porch, Lavatory, Library, Reception, Music room, and Study room connected only with a Living room, not with any other room. A Living room and an Entry share the same property that a room connecting with the Living room can also connect with the Entry, e.g. a Kitchen can connect with a Living room or an Entry, for houses of this style. Production 3 abstracts a Living room into a LA. Production 4 merges a LA and an Entry with both nodes marked. The connectivity remains after applying R-applications. Production 5 then merges a LA and LSubs with the LA marked, since LSubs only connect with the LA. FIGURE 9. Open in new tabDownload slide Graph grammar productions for specifying Wright houses. FIGURE 9. Open in new tabDownload slide Graph grammar productions for specifying Wright houses. Since most Wright houses are double-storied, the upper-level BA and the low-level LA are connected by Stairs. Stairs from both floors are merged by Production 23. Each Bedroom is treated as a Bedroomspace. A Bedroomspace connects with BSubs, which refer to Closet and Balcony, as defined in Production 2. Since two connected Bedrooms exist in certain houses, we separate these two connected Bedroomspaces into two independent parts connecting with Stairs as specified in Production 11. Each Bedroomspace then abstracts to a BA by Production 14. Productions 12, 13 and 14 guarantee that the number of bathrooms is less or equal to the number of bedrooms in a generated plan. Since one or more Bedrooms exist in a house, Production 15 merges two BAs, connecting with Stairs, into a BA. Another distinguishable feature in Wright houses is that Laundries always connect with Kitchens. Since both rooms are part of the SA, they should always be neighbors. Production 16 abstracts a Kitchen to a SA. Production 17 then specifies that a Laundry connecting with a SA is merged into the SA. Moreover, servant bedrooms are located beside a Kitchen. Wright [28] outlines that: So I declared that whole lower floor as one room, cutting off the kitchen as a laboratory, putting servants’ sleeping and living quarters next to it, semi-detached, on the ground floor, screening various portions in the big room, for certain domestic purposes-like dining or reading, or receiving a formal caller. FIGURE 10. Open in new tabDownload slide Additional productions specifying single-storied Wright houses. FIGURE 10. Open in new tabDownload slide Additional productions specifying single-storied Wright houses. We, therefore, define Productions 18 and 19 to specify SAs. A Kitchen connects with several Servantspaces or Servantspace-Bathroom structures. Pantries and Dining rooms exist in certain houses. We define the Productions 20, 21 and 22 to abstract them between a SA and a LA. After parsing a valid path graph, our approach abstracts the graph to several areas, i.e. a LA in the middle connecting with a BA and a SA. It, then, parses this abstracted graph using Production 24 to obtain a Floorplan. In theory, Floorplan should be the accepted as the final node. However, due to the limitation of VEGGIE that requires λ to be the final state, we define Production 25 to abstract Floorplan to λ, implying that the input has passed the validation of the grammar. For single-storied houses, which are relatively rare in Wright houses, BAs directly connect with a LA instead of Stairs. We, therefore, define several additional rules, as shown in Fig. 10, to validate these single-storied houses. FIGURE 11. Open in new tabDownload slide VEGGIE production specification interface. FIGURE 11. Open in new tabDownload slide VEGGIE production specification interface. A graph grammar specification, parsing and induction tool VEGGIE (a Visual Environment of Graph Grammar Induction Engineering) is introduced as a visual tool for specifying and validating floor plans. Our approach takes the path graph of a given floor plan as the input. By parsing the path graph with user-specified productions, it analyzes and validates the semantic information of the target floor plan in VEGGIE. With these productions, we parse input floor plans in VEGGIE to validate Wright houses. Figure 11 represents a screenshot of the grammar specified in VEGGIE. On the interface, LHS means the left-hand side and RHS represents the right-hand side of the production. With the aforementioned productions and VEGGIE, we analyze and validate semantic structures among rooms and confirm the style of input floor plans. FIGURE 12. Open in new tabDownload slide VEGGIE parsing result. FIGURE 12. Open in new tabDownload slide VEGGIE parsing result. As an example, we introduce this set of productions to parse the floor plan of a house designed by Frank Lloyd Wright in 1900. To simplify the path graph, we consider every Bedroom or Bathroom connecting with the Hallway as being connected with the Stairs. FIGURE 13. Open in new tabDownload slide Production rules generated by the graph grammar induction engine. FIGURE 13. Open in new tabDownload slide Production rules generated by the graph grammar induction engine. With the defined grammar productions and its path graph, we use VEGGIE to validate the input plan. After applying a set of R-applications, VEGGIE transforms the path graph into the final state, λ. Figure 12 shows the path graph of the input floor plan. The terminal nodes in the blue rectangle represent the LA, those in the orange rectangle represent the SA and those in the green rectangle represent the BA. By parsing the graph with RGG productions specified in Fig. 9, VEGGIE validates the graph and marks it as a valid floor plan. FIGURE 14. Open in new tabDownload slide Path graphs of Wright houses: (a) for Charles S. Ross Houses, designed by Frank Lloyd Wright in 1902; (b–d) generated by the graph grammar specified in Fig. 9. FIGURE 14. Open in new tabDownload slide Path graphs of Wright houses: (a) for Charles S. Ross Houses, designed by Frank Lloyd Wright in 1902; (b–d) generated by the graph grammar specified in Fig. 9. 6. RGG INDUCTION Graph grammars are typically difficult to construct for people without sufficient background knowledge. Even experienced experts may take days to analyze characteristic features and design production rules for houses of a certain style. Designing a set of grammar productions is a one-time work while it is challenging to come up with a proper grammar which satisfies all requirements. To simplify the grammar design process, our approach includes a grammar induction engine for semi-automatically generating grammars. A machine learning based context-sensitive induction algorithm is implemented in VEGGIE to infer production rules from a given graph set [5]. The algorithm is extended from SubdueGL, a context-free induction system. The SubdueGL induction system implements a sub-graph discovery approach that generates candidate subgraphs based on a sub-graph growth process. The grammar induction engine takes path graphs of floor plans as a training set to search representative sub-structures among inputs. More specifically, it uses a sub-graph discovery approach to compress the graph set. It first generates candidate sub-graphs that may be used to compress the graph set. A minimum description length (MDL) value is calculated for every sub-graph. The algorithm repeatedly chooses the sub-graph with the highest MDL to compress the graph set until it is fully compressed, or the algorithm reaches a certain number of iterations. We implement the automatic induction process to infer common sub-structures for Wright houses. By allowing recursions, VEGGIE infers a set of production rules from 27 floor plans, fulfilling the features of Wright houses [28]. Figure 13 presents a snapshot of the induction result. Since the induction process only identifies the common structures of the given inputs, the generated productions cannot be treated as a complete grammar. Designers need to complete their graph grammars by adapting these productions and possibly adding new productions. Of the generated productions, eight are used as part of the graph grammar for specifying Wright houses, such as Productions 4, 7 and 8 in Fig. 9. Since self-abstracting productions, such as Productions 1, 2, 3 and 6, are not considered by the induction algorithm, the induction result provides an overall 52.94% productions of the remaining productions for specifying Wright houses. The automatically generated productions facilitate grammar designers to understand common structures of given floor plans and provide an efficient approach to design graph grammars. When designing a graph grammar, designers can choose generated productions directly or refine them as part of the grammar. FIGURE 15. Open in new tabDownload slide Productions defining the special case. FIGURE 15. Open in new tabDownload slide Productions defining the special case. 7. GENERATION OF WRIGHT HOUSES Apart from validating our grammars on Wright houses, our approach is also capable of generating path graphs of Wright houses with the above productions. Two types of attribute-sets enable our approach to generate customized Wright houses fulfilling special requirements. Our approach starts from the initial state to generate Wright houses by performing the derivation process of RGG. The generated houses share similar structures with Wright houses while their room compositions and arrangements are different. To further testify the generation power of our approach, we present four path graphs of Wright houses in Fig. 14. Figure 14a is the path graph of Charles S. Ross House, designed by Frank Lloyd Wright in 1902. With different requirements, specified by attribute-sets, our approach generates different path graphs of Wright houses meeting the requirements while keeping a similar structure based on RGG productions. Graphs in Fig. 14b–d are automatically generated path graphs of the Wright houses with their own features. The graph in Fig. 14b requires that exactly two bedrooms connect with each other, according to attribute-set <Bedroom, Bedroom, 1>, for parents in one bedroom to take care of their children in another. Therefore, P11 in Fig. 9, is performed to connect two bedrooms during the derivation process. The same guideline is applicable to other graphs. The graph in Fig. 14c requires at least two servant rooms in the generated house. Thus, attribute-set <Servant, 2> is specified for generating such a house. The graph in Fig. 14d requires a pantry connecting with a kitchen and a dining by specifying attribute-sets <<Pantry, Kitchen, 1>, <Pantry, Dining, 1>>. With the generated Wright house path graphs, designers could design corresponding houses. The graphs guarantee that the connectivity of the designer-specified Wright houses follow the original style and the room arrangements satisfy the corresponding requirements. Since different room connectivity often implies houses of different styles or designed by different designers, a house, whose room connectivity following Wright-designed houses, likely conforms to his original style. With attribute-sets, our approach is capable of generating designs meeting specific requirements. It empowers designers’ creativity and improves their efficiency when designing floor plans. 8. RESULT EVALUATION To testify the feasibility and accuracy of our approach, we have evaluated the above graph grammar, specified in Fig. 9, in VEGGIE for 67 floor plans of Wright-designed houses from 1889 to 1941 [28]. According to Hitchcock [28], we divide the houses into six groups according to the periods they were built. We validate the houses in all periods and record their precisions in Table 1. The precision represents the percentage of floor plans accepted by the graph grammar among the 67 Wright houses. The experiment results show that 51 out of 67 inputs are correctly validated. Table 1. Validation results. Time-period 1887–93 1894–1900 1901–10 1911–1020 1921–30 1931–41 Total Validated houses 4 5 18 8 7 9 51 Total houses 5 6 25 10 9 12 67 Precision 80% 83.3% 72% 80% 77.8% 75% 76.1% Time-period 1887–93 1894–1900 1901–10 1911–1020 1921–30 1931–41 Total Validated houses 4 5 18 8 7 9 51 Total houses 5 6 25 10 9 12 67 Precision 80% 83.3% 72% 80% 77.8% 75% 76.1% Open in new tab Table 1. Validation results. Time-period 1887–93 1894–1900 1901–10 1911–1020 1921–30 1931–41 Total Validated houses 4 5 18 8 7 9 51 Total houses 5 6 25 10 9 12 67 Precision 80% 83.3% 72% 80% 77.8% 75% 76.1% Time-period 1887–93 1894–1900 1901–10 1911–1020 1921–30 1931–41 Total Validated houses 4 5 18 8 7 9 51 Total houses 5 6 25 10 9 12 67 Precision 80% 83.3% 72% 80% 77.8% 75% 76.1% Open in new tab As a special case, ServantSpaces in certain Wright houses share the second floor with a BA. Instead of a door, ServantSpaces in these houses connect with a Kitchen by Stairs. These houses are inconsistent with the guideline that an LA in the center connects with a BA and a SA, since the BA and the SA are connected. Although this type of plans does not follow the guideline proposed by Wright, we can increase our validation precision to 85.1% by adding a few more productions, as in Fig. 15, to accommodate this scenario. To further evaluate the capability and precision of the grammar, we take the Palladio’s villas generated by Stiny and Mitchell [10] as inputs. According to Stiny and Mitchell, two most notable properties of Palladio’s villas are complete symmetry and every room having at least two doors, one on a horizontal wall and the other on a vertical wall. Certain rooms in our grammar productions, however, are required to connect with only one room, e.g. Terrance, Library, and Lavatory only connect with either an Entry or a Living room, Closet and Balcony only connect with a Bedroom, and Laundry only connects with a Kitchen, which means there is one door for such a room. This requirement causes VEGGIE to fail in validating the path graphs of designs generated by Palladio’s villas grammar. By introducing a different set of grammar productions, specific for the properties of Palladio’s villas, VEGGIE should able to validate houses of this style. The result of our experiment shows that with a properly designed RGG our method is powerful enough to validate floor plans in any style. 9. CONCLUSION AND FUTURE WORKS Based on RGG, this paper presents a generic approach for grammar specification, grammar induction, spatial organization, validation, and generation of floor plans. Our approach takes path graphs of floor plans as inputs. On top of input graphs, a set of productions, which summarize specific features of the target style, are defined as a graph grammar. Floor plan instances are validated through a reduction process in a grammar specification, parsing, and induction tool VEGGIE with user-specified productions. In addition, two types of constraints, specified as attribute-sets, are introduced to the design derivation process. The concept of the constraint specification is general enough such that the styles of constraints could be easily extended if needed. It enables our approach to generate designs fulfilling a wide range of requirements. The generated designs help designers to use their creativity and enhance their design efficiency. We designed a set of productions for Wright houses. Specific features for houses of this style are analyzed and included in the productions. The induction engine inferred 52.94% production rules from 27 floor plans of Wright houses [28]. We then validated 67 floor plans of Wright houses with this set of productions. Our approach has an overall 76.1% precision for validating houses of this style. By introducing additional productions for covering a special case, which differs from Wright’s guideline, our precision increased to 85.1%. The accuracy is lower in the last two periods since Wright was influenced by buildings from Japan and California [28] upon the development of modern architecture and his focus shifted from the Wright house design to other structures, such as churches, schools, and banks. In our current approach, it is not straightforward to derive a graph grammar for houses of a style. Researchers have to design graph grammars semi-automatically with the help of VEGGIE induction mechanism. Although we have generated path graphs from SGG with two types of constraints, work needs to be done to transform path graphs to floor plans. We recently proposed an approach to automatically generate floor plans based on graph structures [29]. As the future work, we plan to combine this approach with the graph grammar approach to automatically validate and directly generate floor plans of a given style. We also plan to introduce different sets of productions to validate floor plans of different types of buildings, e.g. hospitals or office buildings, or determine the styles of input buildings. Moreover, with the capability of validation provided by the graph grammar, we may generate similar building designs by modifying existing designs. We also plan to use machine learning techniques to automatically recognize styles and classify input floor plans according to their style. REFERENCES 1 Yue , K. and Krishnamurti , R. ( 2014 ) A paradigm for interpreting tractable shape grammars . Environ. Plan. B Plan. Des. , 41 , 110 – 137 . Google Scholar Crossref Search ADS WorldCat 2 Lin , Y.H. , Liu , Y.S. , Gao , G. , Han , X.-G. , Lai , C.-Y. and Gu , M. ( 2013 ) The ifc-based path planning for 3d indoor spaces . Adv. Eng. Inform. , 27 , 189 – 205 . Google Scholar Crossref Search ADS WorldCat 3 Kong , J. , Zhang , K. , Dong , J. and Song , G. ( 2003 ) A Graph Grammar Approach to Software Architecture Verification and Transformation. Proc. 27th Annual Int. Computer Software and Applications Conf., Dallas, TX, USA, 03–06 November, pp. 492–497. IEEE, Piscataway, NJ, USA. 4 Zhang , K. , Song , G.L. and Kong , J. ( 2004 ) Rapid Software Prototyping Using Visual Language Techniques. Proc. 15th IEEE Int. Workshop on Rapid System Prototyping, Geneva, Switzerland, 30–30 June, pp. 119–126. IEEE, Piscataway, NJ, USA. 5 Ates , K. and Zhang , K. ( 2007 ) Constructing Veggie: Machine Learning for Context-Sensitive Graph Grammars. Proc. 19th IEEE Int. Conf. Tools with Artificial Intelligence, Patras, Greece, 29–31 October, pp. 456–463. IEEE, Piscataway, NJ, USA. 6 Stiny , G. and Gips , J. ( 1971 ) Shape grammars and the generative specification of painting and sculpture . Int. Fed. Inf. Process. Congr. , 2 , 125 – 135 . WorldCat 7 Stiny , G. ( 1977 ) Ice-ray: a note on the generation of Chinese lattice designs . Environ. Plan. B Plan. Des. , 4 , 89 – 98 . Google Scholar Crossref Search ADS WorldCat 8 Agarwal , M. and Cagan , J. ( 1998 ) A blend of different tastes: the language of coffeemakers . Environ. Plan. B Plan. Des. , 25 , 205 – 226 . Google Scholar Crossref Search ADS WorldCat 9 Chen , L. , Wang , X. and Xu , X. ( 2009 ) The Study of Transportation Design Based on Shape Grammars. Proc. 10th Int. Conf. Computer-Aided Industrial Design Conceptual Design, Wenzhou, China, 26–29 November, pp. 836–841. IEEE, Piscataway, NJ, USA. 10 Stiny , G. and Mitchell , W.J. ( 1978 ) The palladian grammar . Environ. Plan. B Plan. Des. , 5 , 5 – 18 . Google Scholar Crossref Search ADS WorldCat 11 Stiny , G. and Mitchell , W.J. ( 1980 ) The grammar of paradise: on the generation of Mughul gardens . Environ. Plan. B Plan. Des. , 7 , 209 – 226 . Google Scholar Crossref Search ADS WorldCat 12 Koning , H. and Eizenberg , J. ( 1981 ) The language of the prairie: Frank Lloyd Wright’s prairie houses . Environ. Plan. B Plan. Des. , 8 , 295 – 323 . Google Scholar Crossref Search ADS WorldCat 13 Macé , S. , Locteau , H. , Valveny , E. and Tabbone , S. ( 2010 ) A System to Detect Rooms in Architectural Floor Plan Images. Proc. 9th IAPR Int. Workshop on Document Analysis Systems (DAS’10), Cambridge, MA, USA, 09–11 June, pp. 167–174. ACM, New York, NY, USA. 14 Ahmed , S. , Liwicki , M. , Weber , M. and Dengel , A. ( 2011 ) Improved Automatic Analysis of Architectural Floor Plans. Proc. 2011 Int. Conf. Document Analysis and Recognition, Beijing, China, 18–21 September, pp. 864–869. IEEE, Piscataway, NJ, USA. 15 Ahmed , S. , Weber , M. , Liwicki , M. , Langenhan , C. , Dengel , A. and Petzold , F. ( 2014 ) Automatic analysis and sketch-based retrieval of architectural floor plans . Pattern Recognit. Lett. , 35 , 91 – 100 . Google Scholar Crossref Search ADS WorldCat 16 Lam , O. , Dayoub , F. , Schulz , R. and Corke , P. ( 2015 ) Automated Topometric Graph Generation from Floor Plan Analysis. Proc. Australasian Conf. Robotics and Automation, Canberra, Australia, 02–04 December. QUT, Australia. 17 Strug , B. and Ślusarczyk , G. ( 2017 ) Reasoning about accessibility for disabled using building graph models based on BIM/IFC . Vis. Eng. , 5 , 10 . Google Scholar Crossref Search ADS WorldCat 18 Liu , L. and Zlatanova , S. ( 2013 ) Generating Navigation Models from Existing Building Data. ISPRS—International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, XL-4/W4, 19–25. 19 Flasiński , M. ( 1995 ) Use of graph grammars for the description of mechanical parts . Comput. Aided Des. , 27 , 403 – 433 . Google Scholar Crossref Search ADS WorldCat 20 Song , G. and Zhang , K. ( 2004 ) Visual XML Schemas Based on Reserved Graph Grammars. Proc. Int. Conf. Information Technology: Coding and Computing, Las Vegas, NV, USA, 05–07 April, pp. 687–691. IEEE, Piscataway, NJ, USA. 21 Zhang , K.B. , Orgun , M.A. and Zhang , K. ( 2007 ) A Prediction-Based Visual Approach for Cluster Exploration and Cluster Validation by HOV3. Proc. Knowledge Discovery in Databases: PKDD 2007, Warsaw, Poland, 17–21 September, pp. 336–349. Springer, Berlin, Heidelberg. 22 Liu , Y.F. , Zhu , Y. and Zeng , X.Q. ( 2014 ) Application of graph grammar egg to design of ER diagrams . Comput. Eng. Des. , 3 , 065 . WorldCat 23 Roudaki , A. , Kong , J. and Zhang , K. ( 2016 ) Specification and discovery of web patterns . Inf. Sci. (Ny) , 328 , 528 – 545 . Google Scholar Crossref Search ADS WorldCat 24 Ślusarczyk , G. ( 2018 ) Graph-based representation of design properties in creating building floorplans . Comput. Aided Des. , 95 , 24 – 39 . Google Scholar Crossref Search ADS WorldCat 25 Rozenberg , G. ( 1997 ) Handbook of Graph Grammars and Computing . World scientific , Singapore . Google Scholar Crossref Search ADS Google Preview WorldCat COPAC 26 Fahmy , H. and Blostein , D. ( 1992 ) A Survey of Graph Grammars: Theory and Applications. Proc. 11th IAPR Int. Conf. Pattern Recognition. Vol. II. Conference B: Pattern Recognition Methodology and Systems, The Hague, Netherlands, 30 August–3 September, pp. 294–298. IEEE, Piscataway, NJ, USA. 27 Zhang , D.Q. , Zhang , K. and Cao , J. ( 2001 ) A context-sensitive graph grammar formalism for the specification of visual languages . Comput. J. , 44 , 186 – 200 . Google Scholar Crossref Search ADS WorldCat 28 Hitchcock , H.R. ( 1942 ) In the Nature of Materials. The Buildings of Frank Lloyd Wright, 1887–1941 . Da Capo Press , New York, NY, USA . Google Preview WorldCat COPAC 29 Wang , X.Y. , Yang , Y. and Zhang , K. ( 2018 ) Customization and generation of floor plans based on graph transformations . Autom. Constr. , 94 , 405 – 416 . Google Scholar Crossref Search ADS WorldCat 30 Zhang , D.Q. and Zhang , K. ( 1997 ) Reserved Graph Grammar: A Specification Tool for Diagrammatic VPLs. Proc. IEEE Symp. Visual Languages, Isle of Capri, Italy, 23–26 September, pp. 284–291. IEEE, Piscataway, NJ, USA. Author notes Handling editor: Fairouz Kamareddine © The British Computer Society 2019. All rights reserved. For permissions, please email: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)
TI - A Graph Grammar Approach to the Design and Validation of Floor Plans
JF - The Computer Journal
DO - 10.1093/comjnl/bxz002
DA - 2020-01-17
UR - https://www.deepdyve.com/lp/oxford-university-press/a-graph-grammar-approach-to-the-design-and-validation-of-floor-plans-C03KVhBMwy
SP - 137
VL - 63
IS - 1
DP - DeepDyve
ER -