development of space database for automated building design review systems
TRANSCRIPT
Automation in Construction 24 (2012) 203–212
Contents lists available at SciVerse ScienceDirect
Automation in Construction
j ourna l homepage: www.e lsev ie r .com/ locate /autcon
Development of space database for automated building design review systems
Jin-Kook Lee b,⁎, Jaemin Lee a, Yeon-suk Jeong a, Hugo Sheward a, Paola Sanguinetti a,Sherif Abdelmohsen a, Charles M. Eastman a
a Georgia Institute of Technology, School of Architecture, Atlanta, GA 30332-0155, United Statesb Department of Interior Design, Hanyang University, Seoul, Republic of Korea
⁎ Corresponding author at: 222 Wangsimni-ro, SeRepublic of Korea. Tel.: +82 2 2220 2645.
E-mail addresses: [email protected] (J.-K. Lee)[email protected] (C.M. Eastman).
0926-5805/$ – see front matter © 2012 Elsevier B.V. Alldoi:10.1016/j.autcon.2012.03.002
a b s t r a c t
a r t i c l e i n f oArticle history:Accepted 8 March 2012Available online 5 April 2012
Keywords:Building information modeling (BIM)Space databaseSpace semanticsBIM pre-processingBuilding design reviewDesign rule checkingIndustry Foundation Classes (IFC)
This paper presents the design and implementation of space database for developing automated building de-sign review systems. We have developed a set of four software modules for reviewing different aspects of aspecific building type — US Courthouses. IFC (Industry Foundation Classes) provides the common buildingmodel schema from which these analyses are carried out. Space objects, like other BIM-building objects,can carry their information-rich space objects and space use semantics internally to the model; we haveused instead external space database to an easily supported information base. We describe the problem ofspace database, how space objects can be automatically organized and classified within BIM systems basedon their space database, and our reflection on best practices learned from application development. All theresearch and development features noted in this paper are implemented in a software plug-in module thatconstitutes a subset of other pre-processing operations and design review systems.
© 2012 Elsevier B.V. All rights reserved.
1. Introduction
1.1. BIM-enabled building design review automation
Many benefits have been reported in the field of AEC/FM (archi-tecture, engineering, construction, and facility management) withthe wide acceptance of building information modeling (BIM) technol-ogies [3,5,13,14,23]. One of the most recent and promising directionsof BIM is to facilitate various building simulations even in earlyphases of design [10]. Conventionally, design evaluation was per-formed manually by multiple domain-specific experts and was timeconsuming and expensive, if undertaken. With BIM, such simulationscan be provided through automated interfaces, more quickly and re-liably [7,10,12]. For example, a concept design model has been usedfor estimating spatial validation, circulation and security checking,energy consumption simulation, and early cost estimate [9].
BIM supports the automatic evaluation of building design, ratherthan the manual, iterative and time-consuming evaluation of CADdrawings. However, making efficient and robust interfaces involvesa variety of technical problems. These include the requirements ofdifferent geometry to be used in different analyses, different materialproperties, and different naming conventions. This paper deals withone of those problems, with the naming conventions designatingspace object semantics. This paper lays out methods for managing
ongdong-gu, Seoul 133-791,
,
rights reserved.
space names developed by the authors for facilitating multiple auto-mated design reviews from the same model [20].
1.2. Building type-specific space objects, properties and names
In architectural projects, especially in the concept design stage, acritical building element is the space. Spaces are the primary func-tional products within a building and usually its reason for being. Re-cently, as a result of the U.S. GSA (General Services Administration)'smandatory requirements, all major architectural BIM tools explicitlyrepresent space objects, with shape and properties [10,11]. Untilthen, CADD (Computer Aided Design and Drafting) and most 3Dmodeling systems only represented space implicitly, by the walls,slabs, ceilings and other objects that bound them. In 2D, spaceswere defined by user defined and managed polygons on floorplanswith an associated space name (see Fig. 1). Now space is an objectdistinct from its boundaries, although its boundaries still determineits shape. Of course shapes can exist independent of their shape.Most architectural projects include a space program that specifiesthe space requirements, for say a school or hospital; they define aset of spaces by name and their desired properties. Only later arethe spaces assigned a location and shape.
In most space programs, each shape carries varied properties,based on the space's purpose and the intent of the space model[2,4]. The most fundamental properties of a space are a name andarea. Depending upon the intended use of the building model, aspace may optionally have defined its access points (for accessibility,fire exits and circulation considerations [15]). For human factor con-siderations, the planned subspaces of a space are of importance,
Fig. 1. Transitions from a mere geometry to the ifcSpace to the information-rich Space Database enabled by the mapping with external domain-specific space database.
204 J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
along with furnishings and equipment, for example to distinguish thedifferent areas within an emergency care section of a hospital [6]. Foracoustic considerations, sound sources within a space, sources of ex-terior conducted noise and the sound absorbing material propertiesof bounding materials are important attributes. For energy analysis,the spaces are grouped into zones, and the internal load generationcharacteristics of the space type are defined, based on people, equip-ment and lighting. Space types and areas are also used for preliminarycost estimation. In each of these applications, the most crucial andcentralized specification of a space is the space name, whether it isa high-level space with sub-spaces, or a low level sub-space. Thespace name characterizes its function and occupants, and the furni-ture and equipment it houses.
We are working within a process framework defined by GSA, an or-ganization facilitating the construction industry transition to BIM [11].GSA manages a portfolio of nation-wide federal government buildings.One of the major building types managed by GSA is the US Courthouse.A courthouse provides all the spaces needed to carry out the functionsof US courts, including grand jury activities, multiple types of court-rooms, jury facilities, US Marshals' security areas, and all the adminis-trative roles needed to support court activities [8,22]. There areseveral factors that distinguish a building type. The most salient factoris the type of space, and such space type is usually identified by spacenames. For instance, if a building model has an “office” or “lobby”,there is no clue to determine a specific building type; however, if a“courtroom” or “Judge's chamber” is found in the building model, it isdefinitely designed as a courthouse. Obviously these domain-specificspace names havewell-structured definitions and functions that are un-derstood by experts in such specific building types.
However, those building type-specific spatial semantics are notrecognized by computers without additional interpretation. The au-thors have reviewed over 10 actual building projects and over 20 con-cept design models using automated design review systems theyhave developed and/or interfaced. While working on these projects,
the authors have encountered several problems that hinder the im-plementation of automated design reviews with building modelsdue to the lack of semantics on spatial objects. This paper addresseshow we resolved the problems based on the development of spacedatabase, and discusses a generic approach using a complicated andspecialized building type as the example: US courthouses.
1.3. Computational problems in space names
The proper use and assignment of space names to spaces at first ap-pear straightforward. It has always been a basic planning activity infloorplan layout and now in buildingmodeling. However,we have iden-tified several problems that must be addressed in their assignment:
1. Taxonomic problem: Until now, space names have been used infor-mally, between users that can evolve their own conventions. How-ever, such assignment as “Larry's office” is not currentlyinterpretable; the computer does not know that Larry is CEO ofthe company for which the building is being constructed. Whilesome names are generic (elevator, corridor, restroom, office)many are building type specific (courtroom, radiology suite,boarding gate). Some spaces are part of other spaces. A judge'schamber suite includes clerks' office, reception, conference roomand other spaces. A radiology suite includes exam room, waiting,reception spaces and scheduling office. Other spaces are classifiedby their use. For example district courtrooms are different in re-quirements from bankruptcy courtrooms, or appeals courtrooms,but sometimes it is necessary to refer to “all courtrooms”. Withthe advent of BIM, users have recognized that space names needto be systematized.
2. Multiple space classification problem: Spaces are classified for manydifferent purposes: for early cost estimation, for interior furnitureassignment, for HVAC internal load assignment, for rental alloca-tion, and others. Currently, these classification assignments are
205J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
made manually by different groups. With BIM, a single space mayneed to have many classification assignments. Assigning theseclasses manually in multiple projects of the same type quickly be-comes a waste of time and a potential source of errors.
3. Uniqueness problem: Spaces often are named but not indexed. Thusthere may be many offices but no way to define the areas or otherproperties that are associated with given office instances. Whilesome spaces often have a room number index (2nd bedroom), corri-dors, elevators, mechanical spaces and other spaces thatmay need tobe referenced are often not uniquely named in current practice.
4. Lexical problem: User assigned names currently involve many acro-nyms, synonyms, omissions, errata, and ambiguities, even withinthe same project. Even computer parsing with “close to” and ex-tensive synonym lists cannot resolve all space names and peopleoften need help also because they cannot resolve the intent for ex-ample of a space marked “M” that usually means “Men's toilet” or“Mechanical”.
2. Approaches
2.1. Space database
BIM enables the buildingmodel, including the space objects, to storerich property data. BIM models contain a space object with not only its3D geometry and relations but also its spatial properties readable byboth humans and computers. However, even more spatial informationis required in actual design review tasks, and most of them are highlydomain-specific. Fig. 1 briefly illustrates the evolution of the buildingmodel representations in terms of the space object. Our focus is on thesecond transition from IfcSpace object to the information-rich space ob-jects for automated building design review systems.
In the lifecycle of a building, one of the initial data for a new buildingproject in “feasibility study” stage is a document that describes the spa-tial programming of space types, with quantities and areas. The spatialrequirement document varies by building project type, budget andother external factors. For example, GSA has a very well-defined designprocess spelled out in the P-100 Design Guide for their Public BuildingService (PBS). It describes how PBS assigns spaces and calculates areasbased on a modified interpretation and implementation of ANSI/BOMA [1,18]. However, it mostly defines general purpose GSA spacetypes rather than specific space object names. Such building-type spe-cific spatial programming data is handled by each tenant. For instance,U.S. Courts provide a guide for new courthouse projects reflecting bestpractices from past projects, called the U.S. Courts Design Guide. U.S.Courts also have its own spatial requirements for new courthouse pro-jects, called AnyCourt requirements [22]. The former defines buildingtype (courthouse)-specific requirements, and the latter describes theproject-specific requirements.
Based on these documents as well as the external domain-specificspatial dataset, this paper describes the multiple terms and informa-tion associated with space objects for enhanced BIM-enabled auto-mated design reviews. We call the issue ‘space database’, and thispaper discusses pragmatic issues and our best practices learnedfrom actual application development. The challenge of space databaseis that the semantics are broad and varied based on the space's func-tion, accessibility, number of occupants, environmental, power andother utility needs and other function-specific criteria. Space namesor codes are used to determine early-stage area cost properties, inter-nal energy loads, lighting standards, air change requirements andother space-specific performances. All of this data seems initiallymost naturally handled by the user with explicit entry. While thismay work for small scale or simple facilities, it results in major book-keeping, consistency requirements and other types of overhead. Thispaper outlines a method of space name management that the authorteam has developed in work sponsored by the GSA related to auto-mated review of building models of courthouse designs.
2.2. Information-rich space object
Here we identify a general approach for establishing information-rich space objects.
1. Developing an external space database which contains all requiredexternal space information that cannot be derived directly fromthe building model, but necessary for the design review for the tar-get building type. This space database can be defined by domainexperts of the given building type.
2. This external data can be actualized based on a set of standardspaces, called a master name table. The database system can derivecompatible space names that respond to a design review's queries:e.g. name datasets for different types of views: spatial validationview, circulation checking view, or energy analysis related view,etc. File formats are commonly XML or spreadsheets.
3. Mapping this external database with the spaces and base proper-ties in a given building model. There are many technical mappingproblems here, thus we also focus on the related issues.
4. The content of an external space database is highly building type andproject-specific. In other words, only domain experts or the partiesconcerned in each field know the best practices, thus other buildingtype examples are introduced in this paper but not developed in de-tail. However, based upon actual space database we developed fortheU.S. courthouses, this paper depicts a genericway for establishingspace database applicable to other building types and applications.
In terms of a BIM-enabled application, Fig. 2 presents two simpli-fied major datasets with their properties and one-to-many relationbetween them. IFcSpace instances faithfully deliver a set of space in-formation defined by architects; the pre-defined external spatialdataset will be appended to the space instances to provide aninformation-rich spatial dataset. It shows an integrated mapping forall applications, but different mappings should be applicable for dif-ferent purposes. For example, only energy calculation-related spatialdata such as energy load factors and occupancy rates of a standardspace will be appended to actual space objects for the energy review.
2.3. Pre-processing on BIM models
The BIM model pre-processing module attempts to remove ambi-guities in space objects from building model inputs, and appendsdomain-specific, building type-specific and application-specific databased on the external space databases. In other words, to build spacedatabase means that a base input data from a BIM model is processedand regenerated as derived input data for various applications—in thiscase for automated design review systems. The output data from thismodule is successfully imported and computed by these design re-view systems. It generates plausible and more precise results com-pared to the pure input dataset without pre-processing (seeTable 2). Fig. 3 illustrates an overview of the space database and itsrole in pre-processing, for each of automated design review applica-tions. The diagrams in gray are outside of the scope of this paper.
3. A definition of the space database
3.1. Definition of a given building model
For the definitions, let B be a given building model, and S be a fi-nite set of space objects. All given space objects from B could be sim-ply represented by a set production as follows:
S ¼ si 1≤i≤n;n ¼ number of space objects in a given building Bj gf ð1Þ
- Where s1, s2, s3, …, sn are space object instances in B.The elements si can be represented by a binary name set {aggrega-
tion_name, space_name}. Of course, spatial aggregation can be
Fig. 2. Mapping between the external spatial dataset and ifcSpace instances.
206 J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
multiple while the quantity of space name is one. In other words,aggregation_name is multi-layer, but we assume that it should be inthe same layer with others so that its aggregation name quantity is al-ways one as well. LetMC be a set of spatial aggregation names andMSbe a set of space names. They are all from the given building model B.
MC ¼ mci 1≤i≤n;n ¼ number of names f or the classif ications in a given building Bj gfð2Þ
MS ¼ msi 1≤i≤n;n ¼ number of names f or the spaces in a given building Bj gf ð3Þ
- Where names are: ∑*, a set of letters or symbols to represent thename alphabets.
Fig. 3. An overview of the space database and its role in an automated design rev
Therefore si can be defined by an ordered pair from MC and MS asfollows:
si ¼ mcj;msk� �
ð4Þ
- Where mcj denotes any of elements from MC, and msk means ele-ments of MS.
3.2. Building type definition and its master name table
The master name table for a specific building type also consists of apair of names. The main difference from the given building model'sname set is that the master name table always has finite, static and
iew framework. The diagrams in grey are outside of the scope of this paper.
207J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
pre-defined with building type-specific standardized names. Let T be aspecific building type, and T can be defined by space objects that meetthe unique name requirement: all space objects in T have uniquenessquantification so that they match each space object's spatial properties.
T ¼ ssi 1≤i≤n;n ¼ number of space objects in the specif ic building type Tj gfð5Þ
- Where ss1, ss2, ss3, …, ssn are standard space object instances in T.Given spaces object set S is undetermined finite set, but for T, all ssi
should have uniqueness quantification. The standard spaces ssi canalso be represented by a pair of spaces {aggregation_name, space_name}. Let TC be a set of spatial aggregation name and TS be a set ofspace name. They are all from the specific building type T. Their ele-ments can be represented by tci and tsi as follows:
TC ¼ ∃!tci 1≤i≤n;n ¼ number of names f or the standard classif ications in Tj gfð6Þ
TS ¼ tsi 1≤i≤n;n ¼ number of names f or the standard spaces in Tj gfð7Þ
- Where names are: ∑ * , a set of letters or symbols to represent thename alphabets, and all tci have uniqueness quantification: ∃! tci.
All spaces in T are unique because one of its elements tci is alwaysunique. Therefore, a standard space object si can be represented:
ssi ¼ tcj; tsk� �
ð8Þ
Another important dataset is spatial property set. If we let SP bethe spatial properties set which contains adequately populated exter-nal spatial properties on si, it could be defined as:
ssi∈T→ssi ¼ tcj; tsk; SP� �
ð9Þ
The elements in SP are building type and domain-specific spatialdata from external knowledge base, such as occupant code, ANSI/BOMA category, security level, energy zone, cost-related aggregation,etc. In case study sections, we describe actual spatial properties withexamples we have developed. SP is subject to be updated and man-aged by external experts, and we also have implemented an interfacefor it. The space object elements in T always have a link to variousproperty elements in SP, while the given space objects from B havenot. If all the elements in B successfully make the links to externaldataset SP, the review systems can recognize spatial structure appro-priate to its reviews.
3.3. Spatial mapping between target model and master name table
Developing a space database means developing a process that de-scribes a state understandable to computers with an information-richset of spatial elements and their relationships within a given buildingmodel. A space object si consists of a pair of names mcj and msk. Thusthis will be defined by an operation which performs spatial mappingusing the name set. Let Mapping() be the operator:
Mapping mcj;msk� �
→si ¼ tcj; tsk; SP� �
ð10Þ
- Input: a given space object's pair of names from B.- Output: a space object with associated spatial properties from T.
The main purpose of mapping is to obtain the appropriate spatialproperty set SP, and SP can vary not only from its space name tsk,but also a standard aggregation name tcj. For example, space grouping
issues for area calculation, energy or cost related aggregations couldbe mostly determined by its aggregation name. Therefore name map-ping operators could be handled separately: CMapping() andSMapping(). The former determines spatial properties only by agiven space's aggregation name, and the latter retrieves spatial prop-erties only by space name. These mapping operators are actuallyimplemented by several well-known algorithms, and we tried to re-solve several ongoing string matching issues in low level.
A separate mapping for each application is also plausible andhandy in actual implementation. However, we deal with them to-gether for clarity in the definition. For instance, spatial property setSP can be specified by various purposes: SPprogram, the properties forspatial program validation, SPenergy for energy related properties,and so on.
If all si from a given building B are mapped with abstract space ob-jects for a specific building type T, it is processable to computers withan information-rich set of spatial properties and their relationshipswithin a given buildingmodel. If all si withmcj andmsk, satisfy follow-ing condition:
CMapping mcj� �
→tcj∧SMapping mskð Þ→tsk ð11Þ
Then all given space objects in B will be mapped with mastername table and its associated spatial properties as follows:
∀si∈T→∀si ¼ mcj;msk; tcl; tsm; SP� �
ð12Þ
Now all the space objects from the model build space databasewithin its building type-dependent and domain-specific dataset.This additional information set is utilized in the automated design re-view tasks.
4. A case study: space database for the US Courthouses
4.1. Courthouse-specific space database
When a building design review system processes a space from thegiven US courthouse model, e.g. a space object named District JudgeChambers Suites; all associated data for that space can be retrievedfrom the model. They mostly denote geometric representations witha predefined spatial structure and its spatial properties added by ar-chitects, as described in the previous section within the IFC scheme.However, domain experts recognize that the space name connotesmuch more associated information, and they are sometimes evenmuchmore important issues to be reviewed. For example, courthouseoccupants perceive that District Judge Chambers Suites is an officialname for a spatial aggregation (e.g. a department) which containsmany subspaces, and its designated security level should be ‘restrict-ed’. People who are interested in building operations will notice thatits Agency Bureau code is ‘1041’, and its ANSI/BOMA space category is‘Office Area’. Table 1 illustrates some relevant examples using somecourthouse spaces. While this dataset is essential for automated de-sign review, a computer cannot accomplish the same task as a domainexpert and infer this data automatically. Space database enables de-sign review systems to acquire this kind of information that couldnot be transferred from the IFC model.
If people in charge of producing the model using BIM design toolsare knowledgeable about all the datasets, and manually input the dif-ferent mapped names into the BIM model, a perfect BIM model willbe created for next phase uses such as the automated design reviews.However, this is almost impossible because there are several differentbuilding types, and even similar building types have different project-specific requirements on spatial programming. Also, applications likeenergy analysis have different space types with their own specializedsemantics, requiring expertise for their assignment. There are several
Table 1Space object examples for the courthouse building and their space database populated by architects using BIM design tools, and could be added by domain experts.
Given space BIM design tool Domain experts/reviewers: owners/users/operators etc.
Magistrate Judge Courtroomand associated spaces
-A space object (IfcSpace)-Globally unique id-Basic spatial data-Geometric representations-Quantity data-Area, height, volume…
-Associated building elements-Walls, doors, windows…-Spatial structure relations-Floor, adjacent spaces-Property sets…
-A classification name (expecting multiple subspaces)-An aggregated space which contains: Magistrate Judge Courtroom, Trial jury room, Public waiting area, etc.-Security level differs from its subspaces type-Agency Bureau code is 1042-ANSI/BOMA category is Office area-Energy related zone (e.g. internal heat gain) can be assigned-A type ‘GSA courtroom’ will be used for early cost estimate
Courtroom -An elementary space name-Cannot determine additional information until specific type is classified: District, Magistrate, or BankruptcyJudge Courtroom-Space name should specify it, or its classification required
Press/media room -An elementary space name-A space under the department “Court Shared Support Space”-Security level must be public, etc.
208 J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
actual guide lines for this issue, e.g. [GSA BIM Guide, 2009], and indus-try's ongoing activities in several parties such as [17]. All other re-quired building type-specific and domain-specific information forautomated building design review systems could be handled by anexternal application, such as a space database for the specific buildingtypes loaded into the BIM tool. In practical development, one of thetop priorities was how to let the design review system obtain spatialproperties in a way that a domain expert perceives space objects in abuilding. This aims to augment the benefits of BIM through the addi-tional and external knowledge base of building type-specific spatialinformation, captured from the domain experts and encoded intothe model through its space names.
4.2. Master name table for the U.S. Courthouses
Considering different interests and goals between people involvedin the interoperable tasks, we offered a pair of space names for allspace objects in the model, and they are: 1) (elementary) spacename, and its 2) aggregation name. In the actual US Courthousemodel cases, every single space object in an IFC model has a binaryset of names: space name and aggregation name, and they constituteone of the minimum modeling requirements for various design re-view systems. Fig. 4 shows a snippet of the pair of space names andtheir properties for the U.S. Courthouses, and it is the master name
Fig. 4. An example of the master nam
table for this specific building type. The aggregation names are mostlybased on the names of Court Departments as defined in AnyCourtdocument, and elementary space names are from both AnyCourtand U.S. Courts Design Guides [22].
The automated design review system can support the functionali-ty for figuring out this name-appended spatial property, while a namebased spatial mapping operation is performed. Some properties canbe defined in the aggregation names, and some only can be deter-mined in finer-grained names: (elementary) space name. This is anexample of automatic assignments of certain set of spatial properties,after specific name-based mapping with a master name table.
4.3. Dynamic space classifications for various uses
Spatial classification is one of the long lasting problems in buildingoperation and management, and addresses various methods for cal-culating space areas. Some organizations govern space classificationsfor their own purposes—such as BOMA, IFMA, GSA PBS, and so on. Interms of space object taxonomy, unfortunately, standardization ofspace classification is not yet established because different organiza-tions have different needs, even though their priority is similar—costs and billing purposes. The most commonly accepted classifica-tions are derived from BOMA standards [1]. GSA PBS [GSA, 2009]also defined similar classifications that refer to ANSI/BOMA and
e table for the U.S. Courthouses.
Fig. 5. Spatialmapping betweenGSA PBS Space Assignment Guide, general courthouse space aggregation and the buildingmodel. This enables the calculation of various areas. (C: ConstructionArea, JU: Joint Use, FC: Floor Common, BC: Building Common, Vert. Pen.: Vertical Penetration, Int. Const.: Internal Construction Area (walls and columns).Partially from [11]).
209J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
OmniClass [19]. Fig. 5 outlines how GSA PBS standard areas can bemapped with the space aggregation for US Courthouses, mostlybased on the aggregation names in the master name table we devel-oped. It clearly shows how to calculate areas for spatial validationbased on the GSA standard.
Spatial classification issue is accompanied with a spatial granular-ity issue. In terms of the spatial structure of a given building model,the highest granular spatial classification (fine-grained) will be allthe space objects themselves, and the lowest (coarse-grained) is thebuilding itself. The level of granularity must address all distinguishingsemantics that are to be assigned to spaces. For example, if offices areto support fixed but varying lighting levels for different tasks, thenthese must be differentiated spatially, with articulation with differentspace objects. What is the level of granularity needed must be deter-mined for the set of functional reviews for a project. This should becarefully defined in the master name table and may be rooms orwork areas within rooms. We found in courthouses that most effi-cient and complete name-based mapping could be done by a well-defined aggregation name. For the US Courthouses, a carefully-reviewed aggregation name set was established with 46 namesbased on the Court Departments. The departments are aggregationsof 670 room space names with linked spatial property sets withinthis level of granularity. Aggregation names can be used as basicunique identifiers for assigning several different properties evenwithout mapping of space names. Aggregation name mapping isvery important because aggregation names from the model areunique among each other and highly specified by sub-space type. Inactual cases, all of aggregation names could be mapped with standardaggregation names in the master name table.
Fig. 6 shows examples of some visualized dynamic spatial group-ings facilitated by space database, established by the mapping withmaster name table which defines 670 different space types withproperties. A given model's space objects have several identifiers forspatial classifications, such as security levels, departments, ANSI/
BOMA categories, energy zones, cost calculation purposed spacetypes, etc. This kind of visualization is an intermediate user interfacefor actual design review tasks. They are all externally added spatialproperties, mapped from the master name table assigned to eachspace.
4.4. Implementation of master name table and spatial database system
Establishing space database system consists of several sub mod-ules: external space database management system using web inter-faces, a module for converting DB into the design review system,spatial data retrieval module from the IFC model, and the actual spa-tial mapping module in the design review system as a part of the pre-processing module. We adopted Solibri Model Checker (SMC) [21] forthe platform, and actual space database has been implemented in theSMC data structure for automated design review based on several ex-ternal datasets (see Fig. 3).
The main purpose of the master name table is twofold: 1) estab-lishing standardized space names for a specific building type, and 2)associating them with properties from domain- and building type-specific spatial knowledge for use in different applications requiringvaried spatial semantics. Architects and engineers are strongly en-couraged to define and coordinate the space names used in develop-ing building models, to manage the compliance with the namingconventions defined in the master name table. A lot of coordinationwork was required for the GSA project, more than could be accom-plished by any single party, as several tenants require specializedspace types such as US Courts, US Marshal, US Attorney, GSA, etc.However, once the master name table is established, it becomesvery useful and reusable with agreement of all stakeholders.
For a different type of building, similar tasks will be required forestablishing the master name table. Reflecting practical and conven-tional naming styles, we also put around 240 synonyms and acro-nyms for the U.S. Courthouses master name table. They are very
Fig. 6. Some dynamically generated spatial grouping examples: 1) a given model's plan view, 2) departments view (same aggregation names), 3) security level view, 4) energy zoneview, 5) cost-related aggregation view, and 6) ANSI/BOMA categories view with area calculation. (Snapshots from the module implemented in SMC).
210 J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
versatile in the actual name mapping, and to capture the model's prede-fined spatial design intent from architects without reworking by manual.
We developed a database system for managing the master nametable in a computer-readable and manageable structure. A typical re-lational database design is applied for developing the master nametable as partly illustrated in Fig. 4. We realized that unique spacename strings numbered around 445, and their combination {aggrega-tion name, space name} made up a total of 670 spaces. These stringsare stored in a database table named “name_entity”, and other rela-tional tables are made in several 1-to-many or many-to-many rela-tionships. For example, a name entity “manager (office)” is verycommon, but once one of the other aggregation names contains it, itbecomes unique: e.g. {probation, manager}, {district clerk, manager},etc. However, unfortunately, name entities do not always have 1-to-many relationships. Some cases require many-to-many relationshipsdue to their duplicated usages: a name entity could be an aggregationname and a space name. Also tables or fields for the synonyms, acro-nyms, space name keywords, and not allowed keywords were addedreflecting actual naming practices, and they resolved most of the lex-ical problems we encountered in Section 1.3. Most importantly, there
Fig. 7. An exported data view example: computer-read
are many associated fields and tables for mapping the spatial namedefinitions with variety of required spatial properties.
The benefits from using space database system are as follows:
- Building type and domain experts can manage space names andthe associated broad range of spatial properties consistently,using easy web interfaces. Space database can be managed by con-cerned experts.
- A project-specific or analysis specific customized name set can beconveniently generated using a master name table defined in thedatabase.
- New names, synonyms or acronyms for new type of spaces can besimply collected and added to the database.
- Most important of all, the database system can generate severalcompatible formats of spatial data responding to the design re-viewers' on-demand queries: e.g. dataset for different types ofviews: spatial validation-specific dataset, circulation checking spe-cific dataset, or energy analysis related dataset, etc. Formats arecommonly XML or spreadsheets, and they are successfully con-verted into ready-to-use forms. Fig. 7 is a snippet of an exported
able aggregation names and associated properties.
Table 2Actual cases of spatial mapping: all showed 100% mapping result based on the pro-posed pre-processing method in this paper.
Actualbuildingmodel
Numberof spaceobjects
Num of name set:classification–space
Mapping withoutpre-processing
Mappingwith pre-processing
A 739 29–276 24–89 (82%) 100%B 1170 62–410 40–69 (64%) 100%C 420 23–122 13–30 (56%) 100%D 1279 41–166 35–60 (85%) 100%
211J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
spreadsheet format that is actually used in establishing spacedatabase.
4.5. Implementation of spatial data retrieval and mapping module
The spatial data retrieval and mapping module within space data-base mainly aims to resolve the data retrieval problem as introducedin the previous section. In actual development, however, we learnedthat heterogeneous BIM design tools support the definition of aggre-gation names in different ways. But they are still in the scheme of IFC,thus we simply put several BIM-tool specific modules for retrievingthe space name set (e.g. space name and its aggregation name forcourthouses) for all space objects in the model. This is technicallysimple but very critical to proceed into design reviews, and wemade another pre-checking module to check whether the modelhas the correctly defined name set or not.
This is the most practical and technical part in actual implementa-tion. Name-based mapping means that a given string set should bemapped to one of the standard names we defined in space database.There are several open algorithms and libraries for handling thestring matching problems such as Levenshtein Distance [16]. Wealso used a keyword based mapping method (sub-strings) for captur-ing complicated courthouse specific space names, with not allowedsub-strings. Moreover, synonyms and acronyms are also attemptedin the matching process. As a result of the series of mapping methodswe have developed, maximum space name sets are mapped withstandard names as shown in Table 2, even though they have errata,abbreviated names, etc. If BIM design tools or IFC translators filterthe names and transform them into standard names, or BIM toolsonly allow assigning pre-defined names, this might not be a problem.However, it could bring up other issues in terms of limited represen-tation of design intent or knowledge. Table 2 depicts the final result ofthe spatial mapping between space database and actual space objectsin the model. The 100% mapping result means that the space objectsin the model are recognizable, and the model is ready to be processedin automated building design review systems.
5. Summary
This paper introduces the issues associated with space names thatwe have encountered in interfacing multiple applications. We alsopresent the practical issues for developing space database that wehave experienced in the actual software implementation for the BIMenabled automated design review project. We called this a pre-processing for BIM models with the purpose of establishing the spe-cific space database needed for an interfaced application. As shownin Table 2, all project model data has been passed into the design re-view and/or checking tools with richer spatial information enhancedby external space database. Another valuable advantage of the devel-opment is the fact that the pre-processing module enables us to takeout all uncertainties from unknown space objects in the design re-view process.
A wider set of applications has been developed for the automateddesign review project, and the space database contributed to perform
those review tasks. To sum up, here we describe what we learned inthe wide range of application development for space database.
1. A master name table for a specific building type should be estab-lished reflecting conventional best practices.
2. External knowledgebase should be managed by external buildingtype and domain-experts using a handy interface to re-classifythe initial base space names to other uses, for example, space-based cost estimation.
3. Appropriate spatial dataset for automated building design reviewcriteria should be exported from the database in computer read-able format.
4. For 100% of spatial mapping between a given model and mastername table, a reasonable and minimized modeling requirementshould be defined and relied on by the people who are in chargeof building model generation.
As a BIM-enabled application, this research was basically motivat-ed and implemented to realize the power of BIM. Space name is onlyone of the varying semantics needed in application interfaces, asnoted in the introduction. We also have conducted initial researchfor other types of buildings such as hospitals and laboratories and be-lieve the method for defining and applying names is appropriatethere also. We hope this has a positive influence upon establishingspace database systems for different types of buildings.
Acknowledgment
This paper is based on a research project supported by the con-tract from the BIM Initiative Program, Office of Chief Architect, UnitedStates General Services Administration (GSA). The project has beenfunded since 2006, and still ongoing under the supervision of Profes-sor Charles M. Eastman at Georgia Tech. We wish to express our grat-itude to the GSA and Solibri for their helpful cooperation for theresearch and implementation.
References
[1] ANSI/BOMA Z65.1-1996: Standard Method for Measuring Floor Areas in OfficeBuildings, Building Owners and Managers Association International, 1996.
[2] A. Borrmann, E. Rank, Specification and implementation of directional operatorsin a 3D spatial query language for building information models, Advanced Engi-neering Informatics 23 (1) (2009) 32–44.
[3] B.-C. Björk, Basic structure of a proposed building product model, Computer-Aided Design 21 (2) (1989) 71–78.
[4] P.E. Bradley, N. Paul, Using the relational model to capture topological informa-tion of spaces, The Computer Journal 53 (1) (2010) 69–89.
[5] C. Eastman, Building Product Models: Computer Environments Supporting De-sign and Construction, CRC Press, 1999.
[6] W. Charney (Ed.), Handbook of Modern Hospital Safety, Second Edition, CRCPress, Boca Raton, FL, 2009.
[7] L. Ding, R. Drogemuller, M. Rosenman, D. Marchant, J. Gero, Automating codechecking for building designs, in: K. Brown, K. Hampson, P. Brandon (Eds.), Cli-ents Driving Construction Innovation: Moving Ideas into Practice, CRC for Con-struction Innovation, Brisbane, Australia, 2006, pp. 113–126.
[8] C.M. Eastman, J. Lee, Y.-s. Jeong, J.-K. Lee, Rule-based checking of building designs,Automation in Construction 18 (8) (2009) 1011–1033.
[9] C.M. Eastman, J.-K. Lee, H. Sheward, P. Sanguinetti, Y.-s. Jeong, J. Lee, S.Abdelmohsen, Automated assessment of early concept designs, Architectural De-sign 79 (2) (2009) 52–57.
[10] C.M. Eastman, P. Teicholz, R. Sacks, K. Liston, BIM Handbook—A guide to BuildingInformation Modeling for Owners, Managers, Designers, Engineers, and Contrac-tors, John Wiley & Sons Inc., 2008
[11] GSA BIM Guide Series 2: Spatial Program Validation, U.S. GSA, www.gsa.gov/bim,2008.
[12] C. Han, J. Kunz, K. Law, Making automated building code checking a reality, Facil-ity Management Journal (September/October 1997) 22–28.
[13] K. Khemlani, CORENET e-PlanCheck: Singapore's automated code checking system,AECBytes, http://www.aecbytes.com/buildingthefuture/2005/CORENETePlanCheck.html, 2005.
[14] M.A.T. Lê, F. Mohus, O.K. Kvarsvik, M. Lie, The HITOS Project—A Full Scale IFC Test,ECPPM, 2006.
[15] J.-K. Lee, C.M. Eastman, J. Lee, M. Kannala, Y. Jeong, Computing walking distanceswithin buildings based on the universal circulation network, Environment andPlanning B 37 (4) (2010) 628–645.
[16] Levenshtein Algorithm, Vladimir Levenshtein, http://www.levenshtein.net, 2010.
212 J.-K. Lee et al. / Automation in Construction 24 (2012) 203–212
[17] MVD: The Model View Definition, IFC Solutions Factory, http://www.blis-project.org/IAI-MVD, 2010.
[18] National Business Space Assignment Policy, U.S. GSA Public Building Service,http://www.gsa.gov/portal/content/102002, 2009.
[19] OCCS (OmniClass Construction Classification System) Table 13: Spaces by Func-tion, and 14: Spaces by Form, CSI: The Construction Specifications Institute, 2010.
[20] P. Sanguinetti, S. Abdelmohsen, J.M. Lee, J.-K. Lee, H. Sheward, C.M. Eastman, Generalsystem architecture for BIM: an integrated approach for design and analysis, AdvancedEngineering Informatics (in press), http://dx.doi.org/10.1016/j.aei.2011.12.001, 2012.
[21] Solibri, Solibri Model Checker® (SMC), an IFC-based rule checking BIM toolAvail-able:, http://www.solibri.com, 2010.
[22] USCDG (U.S. Courts Design Guide), Judicial Conference of the Unites States, 2007.[23] J. Wix, K. Espedokken, Building Code and Code Checking Developments in the UK
and Norway, IAI International, 2004.