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
] 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
]), 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:
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 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
]). 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
]) 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
]; Graph-based: e.g., [23
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
]). 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
(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
]. In particular, refs. [36
] use a graph-based representation to track objects present in the indoor space. Most of these models rely on the dual graph approach ([46
]) 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
]. 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.
]) 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
]—tailored towards indoor navigation and the exchange of indoor network models for navigation purposes.
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
) 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:
A building contains one or more storeys, but a storey can only belong to exactly one building.
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.
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.
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.
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)
] 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.
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
]). 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
]). 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.
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”.