Cross-Domain Building Models—A Step towards Interoperability

Abstract

Buildings have a multifunctional character, which makes it hard to define just one model for all their diverse functions. As these diverse functions are addressed by actors of different perspectives and domain backgrounds, the possibility to exchange available building information would be desirable. Two main models for the creation of building information are Industry Foundation Classes/Building Information Modelling (IFC/BIM) and City Geography Markup Language (CityGML). As the importance of information interchange has been recognized, several authors have tried to develop intermediate models for the information exchange between IFC/BIM and CityGML, e.g., the Unified Building Model (UBM), the BIM Oriented Indoor data Model (BO-IDM), the Indoor Emergency Spatial Model (IESM) and the BIM-GIS integration model for Flood Damage Assessment (FDA model). Nevertheless, all these models have been created with a certain use in mind. Our focus in this article is to identify common elements amongst these proposed models and to combine them into one “core model” that is as simple as possible, while simultaneously containing all important elements. Furthermore, this base model extracted from proposed intermediate models can then be expanded to serve specific use requirements, while still being exchangeable. To show this cross-domain character of the core model, we validated the resulting model with two cases of use (production environment/maintenance and 3D digital cadaster).

1. Introduction

Buildings might be amongst the world’s most multipurpose objects. Thus, there are various definitions, models, concepts and standards aimed at finding a way to represent buildings with all their forms, functions and purposes.

A compact list of functions has been developed by the Open Geospatial Consortium (OGC) as part of the City Geography Markup Language (CityGML) standard [1] in form of code lists divided into the two categories “class” and “function/usage” (Annex C–C.1. “Building module”). An example for a building class is “schools, education, research” (1100) whereas an example for a “function/usage” is “research establishment” (2110). In CityGML, every building, building part and every room all have their own definable class as well as function/usage, which helps with structuring multifunctional buildings and building spaces. In addition, this multifunctional character of buildings makes it complex to define just one virtual model for buildings that serves all the needs for different functions, domains and perspectives. Each of the currently developed models has a different emphasis on specific parts of the building, depending on the author’s perspective and aim. For instance, a well-defined summary on possible modelling topics or perspectives of buildings can be found in INSPIRE’s Annex III theme ‘Buildings’. It defines the purposes of buildings as “living and working place for people”, as “risk for people” (fire, flood, etc.), as “protectable objects” and as “consumers of natural resources”.

However, to create a virtual building model that serves the needs of the specific user perspective, current modelling approaches focus on the requirements of their single task such as e.g., emergency evacuation, energy modelling or navigation purposes including their specific requirements (see also Section 2). On the one hand, this high level of specialization copes with the detailed requirements of their individual case of use. On the other hand, this makes it difficult to use or even exchange data across domains (which have different perspectives on a single building). A result might be that the building information has been collected, but is too specialized for a transfer to another responsible party. Another possibility is that the data will be exchanged, but it has to be filtered by the receiving party for the elements needed (e.g., only structural elements). In the worst case, the data cannot be used amongst different communities and/or countries and must be acquired another time which leads to a loss of money and, in even more serious cases, loss of valuable time in critical situations.

In general, a “model” is defined as a “simplified description, especially a mathematical one, of a system or process, to assist calculations and predictions” [2]. This means that a model needs to be simplified enough to not be overloaded with information and complexity while still being useful enough. To create such a simplified description of a building, it needs several components, which are (1) concepts (objects/entities and their clear definition); (2) relationships (between the concepts); (3) attributes (e.g., IDs, values) and (4) a geometry.

Most often, building models are created, used and handled in the two domains of cartography/GIS (geographical information system/science) and AEC (Architecture, Engineering and Construction). Building models are located at the overlap of these merging domains. In the past, GIS mainly tried to model real world objects of the outdoor environment whereas AEC focused on the indoor and outdoor design of buildings prior to and during their construction [3]. Today, GIS also expands into the design processes and analyses associated with buildings, including site selections, evaluations of design proposals (e.g., energy consumption, lightning requirements), and damage assessments [4]. Simultaneously, today’s AEC has to deal with increasing building and site sizes, integration into the existing city fabric as well as facility management tasks and thus needs GIS capacities and calculations for their own tasks. These tasks that benefit from an integration of BIM and GIS include for example site selection, urban renewal projects, existing building maintenance, construction waste processing, as well as traffic noise analysis [5].

Due to these tasks, an exchange of building information in form of digital models is desired. Yet, both domains have their own highly complex standards for the creation of virtual building models. AEC mainly uses the buildingSMART Industry Foundation Classes (IFC) [6] in a creation and handling paradigm called “BIM” (Building Information Modelling) while in GIS, the Open Geospatial Consortium (OGC) CityGML model is more common. Both standards focus on different aspects of buildings and have a distinct view on them (regarding concepts, relationships, attributes and geometry).

As models of both standards now have to be increasingly exchanged and the value of doing so has been recognized (e.g., [4]), there exist various approaches for harmonizing and linking the two standards. For example, refs. [3] and [7] both did comprehensive studies on solutions for BIM/GIS integration. Ref. [3] discovered that the integration at data level (using conversion, translation and extension of existing standards) and at process level (through semantic web technologies) are the methods with the highest potentials in terms of extensibility and flexibility, but the effort in terms of time/costs to create these solutions is high.

In contrast, the authors of [7] propose to use intermediate models or “meta models” to integrate BIM and GIS at a higher level, but argue that current suggestions of meta models are most often “application-focused” and “may not suit other applications” [7]. One example for a meta model that the authors mention is the Unified Building Model [8] which was created for hospital-use cases (evacuation and allocation of spaces). Further suggestions include [7], [9] themselves and [10], who developed several meta models or “intermediate models”. The major shortcoming, as also stated by [7], is that these models all have a clear focus on a specific case of use: emergency evacuation ([9,10]), flood damage assessment [7] or evacuation and space allocation in hospital environments [8].

Each of the suggested models introduced above approaches to bridge the gap between GIS and BIM. Each model has a number of mandatory as well as optional elements available. However, ref. [7] stated that integration approaches are either limited to technical challenges or to a specific use-case. This can be verified by evaluating available optional model elements. Most of them are use-case specific (e.g., “Fire Utilities” for emergency evacuations). On the other hand, the mandatory elements are similar ones to a large degree (e.g., “wall”), indicating that these elements are not only relevant for one case, but rather important for a general exchange of building information regardless of the use-case. One example might be walls, which are important for emergency-use cases as well as 3D cadaster modelers, while fire extinguisher positions are only relevant for a few use-cases. Elements that are needed regardless of the use-case are called “common elements” in this paper.

Therefore, it is the main goal of this paper to find out, if “common elements” that are of interest for multiple domains exist, to extract them and to combine them into a “cross-domain” core model. This new model should follow the principle of “Occam’s Razor”, which is defined as “the easiest solution might be the best solution”, which means, only those elements that are available in all suggested intermediate models should be used in this core model. The core model should provide the “base information” of a building, so only the elements that are necessary for everyone. To enable the inclusion of additional use-case specific information into the “core model”, it should be possible to expand it for specific use-cases (see Figure 1).

In short, the following questions will be answered in this study:

(1)

Is it possible to derive a general cross-domain “core” building model that is use-case independent through the extraction of common elements from intermediate models?

(2)

Is this model “neutral” enough to be used as base for different use-cases, e.g., production maintenance and 3D digital cadasters?

To answer these questions, we start in Section 2 with a general overview of current building models, their place at the overlap of the two disciplines of AEC (Architecture, Engineering and Construction) and GIS and their subdivision into structure-based models (Section 2.1) and graph-based models (Section 2.2). Section 3 starts with our methodological approach to extract common elements and relationships (Section 3.1) from suggested intermediate models, while the remainder of Section 3 presents the intermediate models which the approach is based on to suggest one “core model”/“meta model”. Section 4 presents the results of this process and the extracted model with its identified concepts and relationships. As the core model should provide the “most basic elements that a building is made of and that are needed when digital building information is needed”, some elements for specific use-cases might be missing. Therefore, we discuss the expandability of this core model based on two conceptual examples: Production environment/maintenance (Section 4.3.) and 3D digital cadasters (Section 4.4). Section 5 discusses possible shortcomings and future development possibilities for the suggested core model. Finally, Section 6 provides a conclusion.

2. Literature Review

Using GIS, surveying, indoor navigation and photogrammetry methods for indoor environments has gained increasing attention (e.g., [11,12,13]). Within maps, buildings still are mainly represented as footprints or extruded volumetric shapes, often neglecting the existence of indoor spaces. With increasing computational power and technological advances such as virtual reality (VR)/augmented reality (AR), scanning technologies (e.g., via apps or lidar) and indoor positioning techniques (e.g., Bluetooth LE, ZigBee), buildings more and more come to the fore in maps. A building as a physical object is at the overlap of two disciplines: architecture (or broader: AEC—Architecture, Engineering and Construction) and GIS/cartography. Ref. [14] state that each of these disciplines.

“[...] starts where the other ends. Architecture means creating space on the basis of the territory, cartography is documenting this territory for further intervention and this process leads to a circular flow of interdependency, where each discipline could be seen as the basis for the other one and vice versa”.

Thus, it can be stated that both disciplines need each other to perform their building-related tasks properly. However, their modelling tasks kind of flow into different directions: While an architectural workflow starts with an abstract design and gets more and more detailed, cartography often begins with an overflow of information that needs to be abstracted and generalized [14]. For buildings, cartographic “documentation” starts where architectural “creation” ends [14]. While the outcome of the architectural processes is a life-size/full scale building, cartography always deals with generalized digital models of reality (Figure 2). Even if a digital architectural model could be imported and directly used as it is in a cartographic application due to increasing computing power, it still should be generalized and abstracted because abstraction does not only reduce information overload, but also helps with quality assurance tasks [15]. However, modern GIS and AEC grow more and more together and go quite further than architecture/AEC just contributing to new creations and cartography/GIS just mapping reality.

To create an abstracted digital model of a building, there are several possibilities. As previously discussed in [16], building modelling can be categorized into two phases, the “design phase” and the “as-built phase”. In the design phase, there are mainly AEC users involved, while in the as-built phase, GIS users model the building. As AEC users model the building digitally from scratch, they end up with highly detailed building models. To get the models for a use in GIS, it is possible to transfer the data into GIS with the challenges e.g., that some of the data might not be up to date and the different uses of spatial reference systems (SRS). In addition, there is the possibility to re-model the building digitally with or without the use of current scanning techniques (e.g., [17,18,19]) or, as suggested by [16] to involve “local experts” with volunteered geographic information (VGI) techniques.

Whatever method is chosen, in the GIS-domain, you end up with a generalized model of the building at the end of the processes. Figure 3 shows the taxonomy of indoor spatial models, as suggested by [20]. They define two main categories: “geometric-based approaches” and “symbolic-based approaches”. In a geometric-based approach, the indoor space is modelled using geometric forms (cells) with different characteristics or as boundary-based models (e.g., CAD). The main shortcoming is that the spaces do not have any kind of semantics assigned to them which makes all kinds of queries very hard if not impossible [20].

Symbolic-based approaches, on the other hand, can further be separated into “set-based symbolic models” and “graph-based symbolic models” (ibid.). Examples of set-based symbolic models comprise hierarchical models and object-oriented approaches like IFC (ibid), which contains the geometry and the semantics of objects. Graph-based approaches represent the indoor space as a graph with nodes (points of interest) and edges (connectivity). Graph-based approaches can be based on a layout (derived from the physical building structure e.g., from the set-based symbolic models) but might also be layout-independent (e.g., sensor space) (ibid).

In our opinion, set-based symbolic models have an important priority amongst the other models, as the other models (with the exception of the layout-independent graph models) can be derived from the physical building structure (set-based symbolic model) through algorithms (Geometric: e.g., [21,22]; Graph-based: e.g., [23,24,25,26,27]).

In the following, we will present selected structure-based building models with semantics (set-based symbolic model) which can serve as base layout for the creation of graph models and geometric-based models. Furthermore, approaches for the derivation of other models from structure-based building models are discussed.

2.1. Structure-Based Building Models

In recent years, building models created and used in the process of building design and construction (see also Figure 2) do not get obsolete once the construction is finished. Rather, Building Information Modelling (BIM) developed as a paradigm to support building management during the whole lifecycle, starting with its design and ending with the demolition of the building. This way, BIM can also support the responsible parties during refurbishments and with facility management (e.g., [28,29,30,31]). In the architectural context, it is especially important to have one model for all stakeholders as many different actors are involved in the context of its creation (e.g., architects, engineers, surveyors, builders) [32]. Thus, a model that serves all these different requirements during the whole lifecycle of a building needs to be highly complex and flexible. The agreed standard to manage all this information is buildingSMART Industry Foundation Classes [6] and was developed to “describe, exchange and share information typically used within the building and facility management industry sector” [33]. Due to its purpose as multi-domain model with planning aspects, IFC is very complex and contains a total of around 900 classes [34]. From these 900 classes, around 100 classes are supported by e.g., Autodesk Revit [35]. The IFC standard goes hand-in-hand with a second standard, ISO 6707 (Building and civil engineering) which describes the terminology of building and construction engineering works and is used e.g., to define the terms used in IFC to ensure the same semantic understanding of terms for all actors using the standard.

The most prominent standard for building models found and discussed throughout the GIS domain is OGC CityGML (OGC 12-019, [7]). CityGML is a standard that can be used to describe and exchange city geometry and semantics. One part of CityGML models’ buildings based on the Geography Markup Language (GML-ISO 19136:2007/OGC 07-036). CityGML models can be defined with five different “Levels of Detail” (LoDs) whereas LoD0 is only a flat polygon of the building and LoD4 describes the full internal and external building in terms of geometry as well as semantics. The main purpose of CityGML is modelling cities for visualization and data exchange tasks.

Additional modelling approaches for buildings include BISDM and FISDM for planning and (facility) management purposes; IndoorGML, BO-IDM, IndoorOntology::Production [36] for navigational purposes; INSPIRE BU and GreenBuildingXML for energy simulation and estimation; IESM for emergency response tasks; as well as Google building information for administrative tasks.

As buildings are part of public space and are vulnerable objects in cases of floods, earthquakes or other disasters, collected data on them should be shareable especially for emergency response tasks. Furthermore, interoperability in terms of buildings could also facilitate tasks like cross-border work on e.g., energy modelling, noise propagation, infrastructure planning. There are already some standards for building modelling available at national and international level with the aim to facilitate data exchange. In Austria, for example, there are at least three different frameworks to be considered:

• At European level:

  ○

  (1) EU INSPIRE Data Specification on Buildings (D2.8.III.2) [37] and

  ○

  (2) DIRECTIVE 2014/24/EU on public procurement [38]

• At national level:

  ○

  (3) ÖNORM A 6241-1 on Technical Drawings for civil engineering (CAD Drawings and BIM) [39]

2.2. Geometry Derivation for Graph Models and Other Models

Another approach to model buildings is to model them via graph models instead of structural spaces. A number of papers follow the idea to model the indoor space with the help of graphs, including [40,41,42,43]. In particular, refs. [36,44,45] use a graph-based representation to track objects present in the indoor space. Most of these models rely on the dual graph approach ([46,47]) that uses a node-relation structure. The node-relation structure is based on the Poincaré Duality Theory. According to the authors of [23] the dual graph has benefits, such as: (a) geometry and topology are part of the model (b) an automated generation is possible (c) indoor route calculation can be conducted (d) the model supports dynamic changes as well. Nevertheless, the dual graph has some drawbacks that should be addressed. First, the integration of semantics in such a model is quite difficult, e.g., pedestrian peculiarities, and the representation of semantics in terms of accessibility is limited (e.g., personal accessibility restrictions). In addition, the location of a person acting in the indoor space is limited. As the determined position is snapped to the graph, there exist inaccuracies in comparison to the real position of the person.

A general approach for modeling indoor spaces with the help of graphs is presented in [24]. Their paper highlights a methodology to develop a graph for navigation purposes of indoor spaces at hand, which integrates semantic and geometrical information. The process is described as being fully automated, and of being capable to compute the navigation graph based on building plans and functions of the indoor space. This work is partly based on hierarchical graph approaches for indoor space (including hierarchical subdivisions) published by [48,49,50]. Ref. [24] utilize ontologies and the concept of affordances [51]. Affordances describe the actions that are provided by objects, in relation to the utilizing object (e.g., person) and context. Based on preliminary work [52] the principal entities of an indoor space are determined: room, corridor, stairwell, elevator, wall, door and doorway. In addition, the following affordances are provided: containment, passage, connection, obstructing, portal, and portal covering.

IndoorGML ([53,54]) is an open standard that provides a data model and XML schema for spatial information with respect to indoor spaces. The realization is based on GML 3.2.1. In general, an IndoorGML indoor space is based on the notion of cellular cells that represent the smallest unit in the indoor space. In addition, the standard classifies the indoor space into navigable (i.e., rooms, corridors) and non-navigable cells (i.e., walls, obstacles). The topological information is realized using the node-relation graph [47]. Of particular interest is the multi-layered representation of indoor spaces in IndoorGML, supporting different representation layers having different cellular spaces (e.g., topographic layer, WiFi, or RFID coverage). The connection of indoor and outdoor is realized via anchor nodes. IndoorGML is—according to [53,54]—tailored towards indoor navigation and the exchange of indoor network models for navigation purposes.

3. Methods

As shortly discussed in Section 1, there exist different intermediate models that aim at the harmonization of CityGML and IFC/BIM. In this study, we analyzed four models that are well known and all are UML-based: Intermediate unified building model (UBM) [8] (Section 3.2), BIM Oriented Indoor Data Model (BO-IDM) [9] (Section 3.3), Indoor Emergency Spatial Model (IESM) [10] (Section 3.4), as well as BIM-GIS integration model for Flood Damage Assessment (FDA model) [7] (Section 3.5). All of the models have in common that they are UML-based intermediate models that aim at the transformation between CityGML and IFC/BIM. Their purpose, background and elements will be presented in Section 3.2, Section 3.3, Section 3.4 and Section 3.5.

Each of four chosen models has been developed and proposed to serve a specific purpose. This kind of specialization is important for focusing on the relevant parts of a building including the geometry and semantics. However, buildings are multipurpose objects that do not only serve one single requirement. Complementary, digital building models—the ‘digital twins’ of a building—should also be multipurpose objects in form of an abstraction into the “greatest common divisor”.

In the past, data have been collected for one purpose only. On the one hand, this had the advantage that the collection was defined to exactly fit all the needs for the specified case of use. On the other hand, the data acquisition was the bottleneck of a project as it was expensive and time consuming. Today, with new sensors, social media and volunteered geographic information (VGI), the situation has shifted from data being sparse to a data-driven geography [55], where data are available for free (OpenData) [56]. However, data is therefore not “customized” to fit the user’s specific use-case as it might initially have been collected to serve another purpose.

Even if models of the same object are developed for different tasks, they still might have some kind of “greatest common divisor” that is useful independent of any specific use-case. One example would be the definition of a model for a river, where an agreement on the geometric (line or polygon) as well as the semantic aspects (e.g., name, depth, quality) needs to be made. An example for a meta model has been suggested for energy modelling [57]. The same also applies to building models. Thus, a “core model” or “meta model” of a building is needed which should be as easy as possible with agreed parts and attributes. If needed, the model should be expandable for different tasks by the users of the specific discipline. In this publication, we will only focus on a common agreement on the semantic aspects of a building, not on the geometric implications and representations.

As IFC-based models are semantically-rich and become more available ([58] (p. 76)), there has been much effort into the harmonization between IFC-based AEC models into a GIS based environment. In the following, we will shortly discuss four intermediate models that are the base for the extraction of the core model.

3.1. Extraction Approach

While each of the four models presented in this article has its own purpose and has been defined based on the specific requirements for the given tasks, it is clearly visible, that all of them also have several elements that are basically the same. We followed a two-step approach similar to [8]: The models have been analyzed according to elements and concepts that are similar ones in a semantical way. In this phase, the defined relationships have been omitted. After this first extraction, in a second step, the relationships have been redefined based on a common understanding of their hierarchy (see Figure 4). The approach used in this publication does not aim at innovating the field of building models. We rather try to integrate recent advancements in the field into one model. The basic requirements for this integration model have been:

• Open to existing approaches and models
• Cross-domain definition of shared elements based on existing and accepted approaches
• Lightweight model that only contains the most used elements

Stage 1: Extraction. During the extraction stage, all the model elements have been analyzed according to their containment of similar concepts. This has been done using a table where all the UML-classes were matched and counted and then sorted according to their occurrence throughout the four models (Section 3.2, Section 3.3, Section 3.4 and Section 3.5). Only classes that have been available throughout all four models have been considered “common elements”. The following table (

Table 1. Common classes amongst different intermediate building models.

BO-IDM	IESM	UBM	FDA Model
Building	Building	UBMBuilding	Building
Storey	Storey	UBMStorey	BuildingStorey
Stairs	Staircase	UBMStair	Stair
Space	Space	UBMSpace	Space
Slab	Slab	UBMLevel	Slab
Door	Door	UBMDoor	Door
Window	Window	UBMWindow	Window
Wall	Wall	UBMWall	Wall

) contains the results of this stage. During the extraction stage, only structural elements have been considered (e.g., geometric classes from FDA have not been analyzed). From a total of 18 classes from BO-IDM, 31 from IESM, 26 from UBM and 43 from the FDA model, 8 have been found to be similar or identical (see Table 1).

Columns and beams have only been found in three of the models except for IESM, a roof could not be found in BO-IDM. Elevators have been defined by only two of the models and again two of them contained the concept of a “Site”. For the naming, we will stick to the names defined by the BO-IDM as the names are short and clear.

Stage 2: Relationships. The next step was the definition of common relationships between these eight elements. While the relationship between a building, a storey and a space is very clear, other elements have been defined differently within each model:

(1)

A building contains one or more storeys, but a storey can only belong to exactly one building.

(2)

Storeys contain spaces, for three models, at least one space is required, one model defined the space as optional. For all models, a space can only belong to one storey.

(3)

Stairs: A staircase can be part of the building, part of one or two storeys or part of a space and can be optional or required. One agreement throughout all models is that stairs can only belong to one building at a time.

(4)

Doors and windows: Doors and windows are always on the same level of the definition but differ in the hierarchy. For two models, doors and windows are part of the storey, whereas for one model, they can be part of a space, for one, they are part of the building. In three models, windows are optional, whereas two models define doors as mandatory elements.

(5)

Slab and wall: Two models agree on the definition of slabs and walls as mandatory elements as part of the storey. In one model, they can be part of the storey or space, whereas one model defines them as part of the building.

3.2. Intermediate Unified Building Model (UBM)

The unified building model (UBM) introduced by [8] for emergency plans as well as “patient ward placement” planning. UBM is an intermediate model that is implemented in ArcGIS and that integrates IFC and CityGML building models. Therefore, both models were compared in detail, overlapping parts were merged, new objects were added (both indoor and outdoor objects) and the relationships were refined. The benefits of the UBM are that the IFC and CityGML domains can interact with the UBM without loss of data, that the UBM facilitates the conversion from IFC to CityGML and vice versa, as well as that the UBM enables access to both of these domains [8]. The Unified Modeling Language (UML) is used as modeling language for the UBM that is developed in the different LODs (1–4) in accordance to those of CityGML [8]. Ref. [8] El-Mekawy et al. (2012) focused on the constructed elements of a building. Their main element is the UBMBuilding which consists of one or more UBMStoreys. A UBMStorey might have UBMSpaces and UBMBuildingElements. The UBMBuildingElements are defined as UBMCovering (a closing level with the two subtypes UMBRoof and UBMCeiling), UBMLevel (a bottom level of a space the two subtypes UBMGround and UBMFloor) and UBMWall (a surrounding or subdivision of a space with the three subtypes UBMCurtainWall, UBMInteriorWall and UBMExteriorWall) concepts. To have access to the UBMSpaces, there is the element of UBMOpening (UBMWindow or UBMDoor). Additionally, there are UBMBuildingInstallations with five additional subcategories.

3.3. BIM Oriented Indoor Data Model (BO-IDM)

The BIM Oriented Indoor Data Model (BO-IDM, [9]) is an intermediate model based on IFC with a less complex structure than the IFC standard itself. The model addresses seven technical requirements, namely to preserve the object semantics of the BIM, to eliminate BIM classes representing elements such as holes in walls, to preserve the topological relationships of the BIM, eliminate the separate spatial relationship classes, convert 3D BIM geometries into the target domain, implement only attributes that are necessary for the target domain and to introduce a spatial reference system (SRS). In contrast to IFC, it uses ISO 19107 compliant geometries. The BO-IDM contains 18 classes that represent buildings. The top class is building, which may have several storeys. Storeys may contain columns, beams, spaces, walls, slabs, doors, stairs, elevators and windows. A Storey itself may be connected to another storey by stairs or elevators. Ref. [9] validated their model using the ArcGIS Geodatabase.

3.4. Indoor Emergency Spatial Model (IESM)

The Indoor Emergency Spatial Model (IESM) is a model developed by [10] and implemented using Esri ArcGIS. Its main purpose is to use the information provided by IFC, integrate it with specific required information on the environment such as sensors and make them available to first responders in the case of an emergency. As necessary dimensions for the definition of the IESM, ref. [10] list indoor building information, outdoor emergency information and dynamic and semantic building information. The Indoor Emergency Spatial Model (IESM) is a simplified form of the standard IFC model. Though the IESM contains the important (indoor) building information, it represents a more appropriate access to indoor emergency response and management for emergency responders and decision makers by removing the unnecessary complexities of IFC [10]. Additionally, [10] expanded their model towards the other two dimensions, namely outdoor emergency information and dynamic and semantic building Information for a more sophisticated representation of all elements needed for emergency tasks.

As for the other two models discussed before, also the IESM starts with the definition of a Building as the central element. Directly within the Building, there might be Elevators and Staircases and there has to be one Site and one Roof. A Building can consist of one or more Storeys (vertical bounded space), that may contain (physical or theoretical bounded) Spaces and must have at least one Door, one Window, one Wall and one Slab. Additional classes are provided for emergency elements such as Water Resources, Outdoor Hazards, the Indoor Graph Network that is connected to the Road Network. Indoors in a Storey, there might be Fire Utilities (Fire Hose Racks, Hydrants, Hookups), Environment Detectors (Smoke Detectors, Heat Detectors) as well as Emergency Utilities (Gas Pipes, Electric Shutoffs) [10].

3.5. BIM-GIS Integration Model for Flood Damage Assessment (FDA Model)

Ref. [7] developed a BIM-GIS integration model for the “assessment and 3D visualization of flood damage to buildings” based on GML and implemented using ArcGIS. One of their data requirements is the concept of “Building components” which consists of the architectural parts of a building, e.g., storey, walls, stairs, floors, roof, doors and windows. In total, they defined seven packages with one of them being the buildings [7]. For this building model, a “site” is the top-level element, which is the parcel that contains a building. A site does not have to contain a building. The building itself can have its own geometry (polygon, footprint). Furthermore, a building consists of at least one BuildingStorey that is an aggregation of Solid or MultiSurface elements. Additionally, a building might contain some BuildingElements, such as Coverings, Openings and other elements (e.g., Roof, Beam, Column, Slab, Wall). Spaces in this model can also be part of a building and can be represented either as Solid or as MultiSurface.

4. Results and Application Examples

4.1. Description of the Core Model

The resulting model (see Figure 5) consists of the eight elements identified in Section 3.1. A building in our core-model definition consists of the class Building, which contains at least one Storey. A Storey contains at least one Space, one Door, one Wall and one Slab. A Window is an optional element, as there exist Storeys that do not contain a single Window. Spaces, Windows, Doors, Walls and Slabs can only be part of one Storey and a Storey can only belong to one Building. Stairs are a special case, as they are usually connecting two Storeys in a Building. Nevertheless, a Stair may also be connected to several Buildings as they might serve as connecting element between Buildings. Stairs are connected to the Storeys they connect (usually more than one). Since in Buildings we find Stairs that connect different levels in one single Storey, the cardinality of Storeys and Stairs is set to one or more than one.

Our approach has been helpful to find the common elements independent of any case of use. So far, we extracted a common model and the corresponding relationships, but a clear definition of every element is missing. To do so, we take the definitions of the ‘ISO 6707-1:2017—Buildings and civil engineering works—Vocabulary—Part 1: General terms’ into account:

• Building (3.1.1.3): “construction works that has the provision of shelter for its occupants or contents as one of its main purposes, usually partially or totally enclosed and designed to stand permanently in one place”
• Storey (US: story; 3.2.1.2): “space between two consecutive floors or between a floor and a roof”
• Space (3.2.1.1): “area or volume bounded actually or theoretically”
• Stairs (GB: staircase; 3.3.5.22): “construction comprising a succession of horizontal stages that make it possible to pass on foot to other levels”
• Window (3.3.3.5): “construction for closing a vertical or near-vertical opening in a wall or pitched roof, which will admit light and can provide ventilation”
• Door (3.3.3.3): “construction for closing an opening intended primarily for access or egress or both”
• Wall (3.3.2.46): “vertical construction that bounds or subdivides a space and usually fulfils a loadbearing or retaining function”
• Slab (GB: pavior; 3.3.5.12): “thick, flat, or shaped component, usually larger than 300 mm square, used to form a covering or projecting from a building”

This model is not meant to be able to cover all elements for every case of use. It is more to be seen as the “minimum elements that make up a model capable of representing indoor features”. In an ideal case, no element can be removed without making the core model useless. For some use-cases, these proposed objects might be enough straight away to create a digital building model and have sufficient information. For others, it might be necessary to expand the model to include more elements that might be needed. The principle of this expandability is presented in Section 4.2, two examples will be given in Section 4.3 and Section 4.4.

4.2. Core Model Expandability

As shown in Section 4.1, a building model can be defined using eight different elements. However, different applications might have different requirements, such as for emergency tasks, additional information on materials, sensors and utilities might be needed. Similar to the outdoors, a combination of several layers of information should be possible. While in the outdoors, several layers of information are available that can be combined to generate new knowledge, the building model should also be used as kind of the “infrastructure” that brings the information together. It should not be the task of the emergency modeler to gather information on the building structure and layout. Rather, the emergency modeler should be able to focus on the analysis of the best paths, identify shortcomings, etc. The same also applies to other use-cases that need building information. Additionally, where different people work on similar topics, it should be possible for them, to define “domain-specific expansions”. Expansions of the suggested core model could be in terms of (1) emergency response; (2) planning and management; (3) navigation; (4) energy modelling and (5) 3D cadaster visualization.

Such an expansion can be done in terms of e.g., further classes or additional attributes that can be defined. The advantage is that an emergency response modeler does not have to acquire the building information from scratch but can use the same core data as the energy modelling expert uses. If then, at one point, a new building is planned, the same core model might be used for the planning department.

To make this principle more concrete, two exemplary use-cases will be described: (1) maintenance tasks in production environments including navigation tasks (Section 4.3) and (2) 3D digital cadasters (Section 4.4). These two application examples give a general overview on the topic. The second part is about how building models in general can be useful for this use-case. The last part describes how the core model approach–suggested in this publication–can be useful for this use-case. However, these approach examples are theoretic considerations of the usefulness from the author’s perspectives that have experience in the application fields. We will validate the two application examples in a future implementation.

4.3. Application Example: Production Environment/Maintenance

General overview. Indoor environments are not static. Studies show that for many tasks and application contexts, it is essential to regard the environment as a dynamic one (e.g., [23,26,36]). This is especially true for large production environments. To finish a single product, the raw material and intermediate production goods need to undergo several manufacturing steps. As workflows may require a great degree of flexibility, there is no static assembly line to finish the products. Rather, the workers need to bring the raw material as well as the intermediate products to the machines determined to perform the desired task. In an ideal case, the worker takes the raw material, brings it to the several machines and gets the finished product in the end. In reality, this task is far more complex as there are many more parameters to be considered: Firstly, machines can only process a specific amount at a time and it takes a specified time for the machine to process it. Thus, it might happen that there is a bottleneck at one machine, while another machine or process is idle. Secondly, a machine cannot run 24/7. There might be downtimes that are planned as service intervals to change of wear parts, but there can also be some unexpected downtimes due to breakdowns or other incidents. Thirdly, the company can buy new machines and exchange it for another one. Though, in terms of power connections and layout, not every machine can be placed anywhere. This might result in machine A being replaced by B, but at the place of machine C. Thus, B and C will still be in the building, but B switched position with C. Lastly, there might be some kind of priority amongst the manufacturing of goods: One charge might be more urgent than a second one and needs to be processed with a higher priority.

Use of building information for this use-case. These different things need to be considered at all times. To make the allocation of goods and monitoring of the production status easier, ref. [36] developed an indoor navigation ontology that defined all relevant features needed for autonomous navigation in production environments. Based on this indoor ontology, a routing in the production environment can be implemented. To model the movements of the goods and evaluate, based on the ontology, the “optimal” paths, a network (i.e., a graph) is utilized [45]. Currently, the graph is extracted automatically from the 2D-plan—in conjunction with the relevant indoor objects including the walls—as separator between indoor and outdoor. Based on the abstract defined ontology each indoor object is evaluated and the semantics of each object is added as integral part of the dataset. Ref. [36] extract the navigation graph in an automated manner from CAD data. In literature, besides CAD also 2D-GIS or 3D-GIS data may serve as basis for indoor data or navigation graphs in general.

Benefits of the core model (with extension) in the production environment. The core model can provide basic elements for this use-case for the definition of physical boundaries of the production halls. Nevertheless, further elements need to be defined, such as machines and restrictions (e.g., clean room areas). This can be done either by the definition of further classes or by additional attributes (e.g., “IsCleanRoom?” for spaces). These physical boundaries can be further utilized—especially in conjunction with their semantics for different purposes. In the case of semiconductor industry (e.g., [45]). An example is quality control and/or incident management. If an incident happens (e.g., water leak in the clean room) one could identify which objects have been in the vicinity of the affected area. Here the Euclidean distance cannot be utilized as appropriate metric, as the notion of nearness is affected by existing airlocks, doors or similar. Additionally, ref. [45] utilized such a basic indoor space model amended with semantic information to calculate the optimal paths for each single production asset, with respect to quality issues and just-in-time delivery at the next production step.

The benefits of the object-oriented indoor space model in this application context are as follows. As building data based on CAD lack topological (and object) information it is hardly possible to amend these data with semantic information. Hence, the automatic context- and affordance-driven computation of optimal asset paths from one manufacturing step to the next would not be possible. In addition, any automatic manufacturing decision support based on spatio-temporal analysis would not be possible without an accurate building model. In contrast to pure CAD data it is possible to determine doors, their inherent semantics (one directional, bi-directional, access restriction, air lock, etc.). In addition, the semantics of walls and be defined—e.g., for their permeability for radioactive radiation. Hence, the semantic information in conjunction which an indoor model determines the notion of nearness in indoor spaces.

4.4. Application Example: 3D Digital Cadaster

General overview. Another example for the use of the core building model is to adopt it for implementing a 3D digital cadastral system. Shortages of space and intensive settlement pressure in urban areas has led to complex urban developments in form of high-rise buildings and underground structures. A current 2D cadaster might not be able to fully record, manage, and visualize spatial complexities of ownership rights defined in modern structures (e.g., [59,60]).

In general, 3D digital management of ownership rights, restrictions, responsibilities (RRR) is predicated on two types of 3D spatial objects, namely 3D legal objects and 3D physical objects ([32,61]). 3D legal objects provide the invisible spatial extent of RRR defined within buildings.

Use of building information for this use-case. Physical objects are ancillary to disambiguating the spatial extent of 3D legal objects for the inexpert owners. In light of this, several researchers have recently proposed various approaches for implementing integrated legal-physical models for buildings (e.g., [62,63,64,65,66]). For instance, ref. [32] extended a BIM-based physical data model with legal data elements for managing RRR in a 3D digital environment. They considered basic physical components, namely interior walls, exterior walls, sliding doors, single-flush doors, awning windows, fixed windows, stairs and slabs for modelling the physical view of buildings. Additionally, “space” elements have been specialized to model 3D legal objects. These elements correspond to the resulting elements within the core model. Further differentiations into interior/exterior walls, sliding doors/single-flush doors, awning/fixed windows can be done via the definition of subclasses or further attributes that can be used for the implementation. Another study using BIM for 3D cadasters has been conducted by [60]. Here, the authors didn’t state which elements their model included, but visual examination of the results suggest that they have used similar elements. Nevertheless, as a BIM contains not only physical but also planning elements and can be very detailed, a filtering and thinning of elements is highly recommended.

Benefits of the core model (with extension) for 3D digital cadasters. The core model proposed in this article can be also extended with legal objects, which could lay the foundation for 3D digital management of RRR arrangements inside buildings. This extension should be predicated on the legal concepts defined in the international Land Administration Domain Model (LADM) standard. Figure 6 represents the core model enriched with relevant concepts from the LADM standard. In the extended model, “Space” from the core model can be used to represent the concept of building units (LA_LegalSpaceBuildingUnit) which specify legal spaces inside buildings. The physical elements of the core model (i.e., Wall, Door, Window, and Slab) can be used to better communicate legal arrangements. These elements can be used to communicate spatial location of a legal boundary, which is defined by “LA_BoundaryFace” in LADM, referencing physical structures. Therefore, we defined association relationships between these elements and “LA_BoundaryFace”, which are represented by green lines in Figure 6. The physical elements are sometimes part of 3D RRR arrangement. Therefore, we also created association relationships, represented in red lines, between these elements and “LA_BAUnit” entity. The “LA_BAUnit” entity refers to the concept of basic administrative units which comprise a group of spatial units associated with the same RRR information. Our extended model provides the ability to group legal spaces and physical elements into basic administrative units. This would provide the ability to manage complex ownership arrangements, such as common properties, which not only include legal spaces but also physical structures spanning through various parts of the building.

5. Discussion and Outlook

In the present study, we tried to answer the following questions:

• Is it possible to derive a general cross-domain “core” building model that is use-case independent through the extraction of common elements from intermediate models?
• Is this model “neutral” enough to be used as base for different use-cases, e.g., production maintenance and 3D digital cadasters?

To answer these questions, we extracted a common model from sophisticated and accepted intermediate models that have been defined in terms of specific use-cases with specific requirements. The extraction included the following steps: The first step into the creation of the core model was the extraction of “common elements” from proposed intermediate building models (BO-IDM, IESM, UBM, FDA model) from various domains. It has been shown, that eight elements have been similar throughout all models (building, storey, stairs, space, slab, door, window and wall) which occurred throughout all the intermediate models. These have been extracted and clearly defined (according to [67]) to get a base for the model. The next step was to identify the relationships between these elements and to define them for the new model. The outcome core model was then used for two theoretical validation concepts (production maintenance and 3D digital cadasters) where we tried to figure out how a building model is useful in the scenario in general and how the “core model” can provide additional benefits. Furthermore, these examples showed that the extracted elements can be useful for both cases of use. Furthermore, we showed the principle of extensions, where the core elements stay the same, but can be expanded with further elements and attributes. This assures that every use-case can define as much information as needed while the “core information” stays the same and could be extracted for the use of another use-case.

To answer the first question, the outcoming core model looks promising in terms of cross-domain common elements. As a result of this analysis, it became evident that some elements are recurring throughout different modelling approaches whereas other elements have been included and adapted to the specific use-case requirements. The eight elements that have been extracted make up the base for the new model. Although the extraction of the eight elements has been comparatively easy, the relationship definition was not that straightforward. All models had different ideas of what would be optional and mandatory and what element has which sub-elements.

The main finding was the existence of the eight identified “common elements” that have been found in each of the four intermediate models. It is interesting that some elements that we thought of being “very important” did not occur in every intermediate model. Examples are “Beam” and Column” that occurred in each of the models except the IESM or “elevator” which was present in BO-IDM and IESM, but not in UBM or the FDA model. Further elements include for example “opening”, “building element”, “roof” and “site”. In this publication, we concluded from that outcome that these elements are not needed in every use-case and thus, did not count them as a use-case independent “common element”. It was surprising that these elements amongst others were not needed for every use-case.

To identify possible common elements, we decided to choose the approach of the “most used elements” of the four intermediate models. This process of purely “counting the elements” might possibly return either more or less elements than really needed. However, as all the chosen intermediate models are expected to be very carefully defined and sophisticated models, they should not have major elements missing. At the first look of the outcoming elements, we concluded that most of the elements were the ones we would have expected to be the outcome, but as stated earlier, this approach also excluded some elements that we would have thought to be important (e.g., beam and roof). This leads to the question if these elements are as important as we thought they would be and are now missing or if these elements are not as important as we thought. This topic cannot be answered here and might need to be answered either during implementations and tests or with expert discussions. Additionally, it would help to do validations with different use-cases to verify if the identified “core elements” really are sufficient as a core.

Regarding the second question of figuring out the possible usefulness of the neutral core model consisting of eight elements, we discussed the option of extensions for different use-cases and the general possible benefits of the model for the creation of navigation networks within production environments as well as for 3D digital cadasters. However, these use-cases have been considered in a theoretical manner only so far. The considerations give a first idea of how the model might be used and provide examples of possible extensions.

The next step will be to implement a core model and validate the use quantitatively. Further use-cases might also include energy modelling, facility management and emergency response scenarios. In our opinion, the defined core elements will be found in every of these scenarios, but there might be a need for further (sub-)object classes or additional attributes, which need to be defined as extensions. Their precise definition will be subject of future work. To not only show the use of the model in theory, but also in practice, a further step should include the implementation of one exemplary model. So far, the model can therefore only be a suggestion on the structure of a core building model, as no practical validation with data has been performed, yet.

Furthermore, a building model does not only consist of common elements. A building model consists of (1) concepts (objects/entities and their clear definition); (2) relationships (between them); (3) attributes (IDs, values, etc.) and—for the use of especially 3D models—(4) a geometry. Up to now, we thoroughly analyzed and suggested solutions for (1) and (2). Further work should also be done in terms of (3) the attributes and (4) the geometry. Attributes are very important as they provide further information, whereas one might be very careful in their definition. This can be compared to attributes in metadata: Here, attributes are useful and necessary, but users might tend to not fill them in if there are too many mandatory ones ([68,69]). The same might also apply to attributes within datasets. In terms of geometric conversion, there have been many different approaches to map between different types of building modelling approaches (e.g., [70,71,72]). As the attributes as well as the geometry or geometry conversions are not covered in this paper, this might be part of further work on the harmonization of building models.

Additionally, the core building data model should also be defined as an ontology to ensure semantic interoperability for future applications.

As we did not find a similar approach of doing harmonization, it would be interesting if this approach of finding “common elements” would also work with other features that are not fully harmonized yet.

6. Conclusions

Building models are needed throughout various domains and use-cases. It is important to have them ready as base layer to bring other information into a context (e.g., position of objects within a building), but also as object of concern themselves (e.g., for path planning in emergency cases or for floor damage predictions). Thus, building information needs to be exchanged between different actors. Hence, several intermediate building models have been proposed, each with another perspective and use-case in mind.

From these intermediate models, we extracted common elements of buildings that are important for several use-cases in this article. The goal is the definition of a certain minimum set of elements needed to create an indoor building model. Similar to the definition of the “Dublin Core Elements”, these specific elements should be “broad and generic, usable for describing a wide range of resources” [73]. In this publication, we identified these broad and generic elements for buildings based on the “most used elements”.

The definition of this core model can then be the base to exchange data: If the core elements are clear for everyone, it will be getting easier to exchange data. For example, in the following scenario: there has been a data acquisition for energy modelling including the core elements and an additionally defined energy extension. Now, the data of the same building is needed for another use-case, which might be indoor navigation. The indoor navigation modelers do not need the information included in the energy extension, but they need the core data. Thus, the energy modelers can share the core building information without sharing the energy information. This modularization makes an exchange easier. Additionally, this allows groups of experts to define their own agreed extensions without touching the core building model, but still allow them to use it. An integration in this sense also helps with the development of ‘digital twins’ (a digital ‘clone’ of a real-world object which acts like the real object in the physical world) in a way that different information layers or modules can be integrated using the ‘core model’ they share. In terms of a building model, a group of experts can create the ‘emergency response layer’ while another group can create the ‘navigation layer’. Both could be combined in case of an emergency to benefit from the integration.

The same is also true in terms of data exchange between AEC and GIS: If there is an agreement on common elements and extension modules, an exchange might become easier as everyone knows what to expect when receiving a core model from another group. This reduces the information overload during exchanges as the core model can be exchanged separately from use-case specific information. Due to this modularization, data sharing between AEC and GIS might become easier and thus provide new possibilities of collaborative work.

Therefore, the definition of this core model is one step towards interoperability and to buildings as infrastructure or context. Buildings are important in our daily lives for many different tasks and should therefore be available in an easy and harmonized way. This might exclude some elements, but sometimes, “less is more”.