BIM Data Dictionaries for Semantic Classification and Attribution of Geospatial Features in GIS

1. Introduction

The domains of architecture, engineering, construction, and operation (AECO) make extensive use of building information modeling (BIM), while geospatial domains make use of geographic information systems (GIS).

1.1. Problem Statement

BIM and GIS commonly describe similar real-world objects, but they use different vocabularies, schemes, and metamodels for semantics. Semantic metaconcepts (class, attribute, feature, relation, etc.) provide a means to define the potential semantic content and structure of an information model—the schema. The actually instantiated model represents real-world phenomena with the means and the specific perspective of the semantic schema. In digital design and construction, as well as in (geo-)spatial data infrastructures (SDIs), this leads to many aspects of semantic interoperability or mutual misunderstanding when stakeholders from various domains work together. In this context, the term semantics is very generic and refers to any alphanumeric, non-geometric, and non-graphic information. Semantic information could be stored as a class name, as a classification attribute, as an entity type, as an attribute name, as a key in a key–value pair, or as a label. From an information management perspective, the federation of schema and data itself is not problematic; rather, what is problematic is the storage of redundant semantics. Redundancy comes with the danger of inconsistency at both the schema level and the instance level.

1.2. Scope

The problem of BIM–GIS integration has been the subject of intensive research for years, including recent metastudies [1,2]. This study investigates the use of BIM data dictionaries for the semantic annotation of vector-based geospatial data in GIS to facilitate the use of common concepts in BIM and GIS to describe existing and planned phenomena. Data dictionaries are an emerging technology in the BIM domain, and they may be also used in GIS in the near future. Our approach is neither a BIM-to-GIS nor a GIS-to-BIM conversion approach; rather, it is a BIM-and-GIS approach, focusing only on the semantic dimension. However, our suggested architecture has a tendency towards a BIM-to-GIS approach, as the BIM data dictionaries are being made usable for GIS (Figure 1).

In practical engineering work with BIM and GIS, classification and attribution are the main tools used to assign meaning to objects [3] (pp. 10-15). As shown in Figure 1, this study uses three metaconcept layers to organize semantics. The instance/model level is a conceptualization of the real-world situation. The schema level provides a vocabulary for the instance/model level, and thus provides a closed “universe of discourse.” The third—and most abstract—metaschema level provides tools to organize the vocabularies of the schema level. The geometric–semantic object models of BIM and GIS provide sub-schemes of geometry to describe the position and shape, but these geometric schemes are beyond the scope of this study. Although this study actually focuses on semantics, the relationship between geometry and semantics must be briefly discussed. The specific relationship between geometry and semantics is handled differently [4]. Roughly speaking, in GIS, geometry is the primary focus, as features are geometric elements with attached attributes. In BIM, however, semantics is the primary focus, where classified objects are linked to one or many geometric representations. There are different requirements for BIM and GIS:

BIM is a prescriptive and dynamic method that uses a variety of classes and attributes, including those related to physics, design, materials, costs, and responsibilities [5] (pp. 32 f.). The semantic information to be managed is volatile. It changes significantly during the project stages of design, construction, and operation. Therefore, it is necessary to add, modify, and delete semantic model information dynamically in BIM models.

The use of GIS is a descriptive and long-term-oriented method for recording, analyzing, managing, and presenting geospatial data [6] (pp. 5-7). It primarily describes existing objects and situations. Geospatial data is often published in spatial data infrastructures (SDIs). Geospatial data must be strongly codified in spatial data infrastructures because it is used in many different ways and over a long period of time. Compared with BIM, semantic schemes in GIS are more static than dynamic.

BIM has become established in planning and construction ([7] (pp. 13–15), [8,9]). At the same time, however, geospatial data, such as data inputted into land administration models, topographic maps, site plans, terrain models, and city models—as well as all demographic, environmental, and infrastructure data—are also required in BIM projects. BIM and GIS are increasingly converging and must be used together [1,10]. Therefore, the integration of BIM and GIS is a multifaceted research topic.

1.3. Research Goals

In the professional practice of BIM–GIS integration, the joint use of semantic information from BIM and GIS is associated with a great deal of effort for conversion or redundant data storage. One reason for this problem is the incompatible standards for metaschemes, schemes, and heterogeneous instances. This is where the present research comes in.

The aim of the present study was to make data dictionaries practically usable for GIS software, despite the fact that they were originally developed for BIM software (Figure 2). This allows BIM and geospatial data to use the same terminology for the semantic description; for example, attributing the spatial information for a project with the same terminology as the BIM models is the best way to ensure all parties involved can easily share the data. However, practical implementation in GIS software shows that fundamental software design decisions have to be made at the application level. The software design options affect how newly classified geo-features can be meaningfully serialized and displayed in the GIS software.

This work analyzes whether concepts similar to BIM property servers or data dictionaries exist in GIS and how they can be used for the semantic enrichment of geospatial data. The focus in this research is on metamodels. Specific dictionaries and application schemes are not discussed. In particular, there are many publications on the mapping of IFC and CityGML schemes, and thus, these formats are only mentioned as examples in this paper. Developments in the area of the Semantic Web in BIM and GIS are frequently used in the literature to transport semantic information [11,12,13]. However, these approaches are rather academic and have not yet become widely accepted in practice. Instead, we focus on established technologies; in particular, we focus on how information can be added to GIS through classifications according to the methodology commonly used in BIM. Since the buildingSMART Data Dictionary (bSDD) [14] is the only dictionary known and used worldwide in BIM, the focus is on the use of the bSDD for classification and attribution in GIS. However, it is ensured that other dictionaries can also be used with the developed GIS classification approaches. For this reason, this study only addresses the essential metaconcepts of classification and attribution. The use of advanced metaconcepts, such as relationships, value ranges, and enumerations is not within the scope of this study. The practical implementation is illustrated using the software QGIS [15], a free and open-source software for spatial analysis and visualization of geospatial data.

The question of whether BIM data dictionaries and property servers can be used with GIS software needs to be investigated via the following research questions:

• How do the semantic metamodels differ between the BIM and GIS standards? Which standards and technologies from the GIS domain are comparable with BIM data dictionaries?
• What are the differences between the system architectures used to publish semantics in the BIM and GIS application domains?
• How can BIM data dictionaries be practically used for the semantic enrichment of geospatial data?
• Can the semantics from data dictionaries (especially multiple classification) be transferred to GIS without loss?

First, in Section 2, existing approaches to semantic BIM–GIS integration (Section 2.1) and classification (Section 2.2), as well as data dictionaries and property servers (Section 2.3), are presented. Afterwards, in Section 3, metamodels are compared (Section 3.1), and GIS data sources and their structures (Section 3.2) are described, alongside the limitations of GIS software (Section 3.3). Then, different approaches for the classification of geospatial features with data dictionaries (Section 3.4.1, Section 3.4.2 and Section 3.4.3) are developed and subsequently implemented and validated (Section 4.1, Section 4.2 and Section 4.3), with examples (Section 4.4) in Section 4. The results are presented in Section 4.5. Finally, in Section 5, a summary of the research (Section 5.1) is given, followed by a discussion of the research’s limitations (Section 5.2) and future research directions (Section 5.3).

2. Related Work

The integration of BIM and GIS has been an area of intense research for years. We first focus on work that deals with semantics and present different approaches that have already been researched. We then review the classification approaches in BIM and GIS and present standards from both domains that are relevant to semantics.

2.1. BIM–GIS Integration

One approach to transferring BIM semantics to GIS is to map between data schemes. In particular, the mapping between Industry Foundation Classes (IFCs) and City Geography Markup Language (CityGML) schemes is being investigated in research [16,17]. Such mapping can also be carried out with the ontologies of the schemes and the technologies of the Semantic Web [11,18,19]. A typical approach is to convert building models (IFCs) and geospatial data (Geography Markup Language (GML), CityGML) into the Resource Description Framework (RDF). A link ontology is then added to the construction and geospatial ontologies in Web Ontology Language (OWL) format. The conversion to RDF can either be the final goal for common queries on the data [12,20,21,22], or it can be used as an intermediate step to finally convert the data into the other format with the help of queries [19].

Another approach entails the extension of the CityGML schema by an Application Domain Extension (ADE) [23,24]. With the ADE concept, the CityGML schema can be extended, for example, by adding new concepts or extending existing concepts with additional attributes. IFC elements and attributes can be added to CityGML data.

Jetlund et al. [25] describe a more general approach where they use the abstract concepts of IFCs and ISO/TC 211 standards to increase interoperability. They converted the IFC EXPRESS schema to Unified Modeling Language (UML) and created a common UML model with GIS schemes that already exist as part of a UML. The UML model links and harmonizes concepts from different domains. Implementation schemes for BIM and GIS can be derived from the common UML schema and implemented in the corresponding specialist software. This means that no data conversion is required, as information from BIM, for example, can be entered directly into GIS software.

Other approaches aim to store and link all BIM and GIS files within containers [26,27]. No file conversion is required for this, but the reading software must be able to interpret multiple file types and links stored in a separate schema.

Many approaches aim to convert BIM data into geospatial data by processing the geometry together with the associated semantics [17,23,24,28]. To date, no research papers have been published on the semantic annotation of geospatial data using data dictionaries. However, [29] recommend using external classification systems and harmonising terms for this purpose.

2.2. Classification

Upon searching the available literature, we could not identify a single work that deals with general classification concepts for geospatial information in GIS, comparable with data dictionaries in BIM. However, there are different concepts of classification in both domains, and thus, these concepts will be compared with each other.

In the domain of geospatial data, classification is defined as “abstract representation of real-world phenomena using classifiers” (ISO 19144-1, p. 7) [30]. The construction industry defines classification as the “process of assigning objects to classes according to criteria” (ISO 22274, p. 3) [31]. While classification is seen as the result of a process in GIS, in AECO, it is a process itself. We can infer that the term classification is somehow differently used in BIM and GIS. Therefore, we first explain how the terms are commonly used in both fields and, second, which standards are relevant.

The structure of geospatial data is defined by the ISO 19100 series (Geographic Information) of standards and the Open Geospatial Consortium (OGC). Semantics are also a topic in many standards, as semantics are always associated with one or more geometries. Geometries (points, lines, and polygons) are classified and assigned additional attributes according to a static and sometimes complex data schema. This type of classification and attribution is typical of geospatial vector data, which adhere to the generic feature model [32] (pp. 161-166). Alternatively, geometries can be classified by assigning single geometries to a semantic group (a class), which is the typical approach for raster data [33] (see Figure 3). In this paper, we focus on the first method: using geospatial vector data according to a semantic schema.

Figure 4 shows the relationships between the ISO standards of the 19100 series relevant for classification. All of them refer to ISO 19101 (Reference Model: Part 1: Fundamentals) [34], which sets the fundamentals for all schemes. Describing a dataset with application schemes gives geospatial data a classification and predefined attributes. The creation of an application schema is defined in the ISO 19109 (Rules for Application Schema) [35] standard. This standard also contains the conceptual model, called the General Feature Model, which describes the creation and use of concepts. An application schema is described using feature types, which can be predefined in feature catalogs. Feature catalogs, standardized in ISO 19110 (Methodology for Feature Cataloguing) [36], are a collection of feature-type definitions (such as class, attribute, and association) for a particular domain. The content of feature concept dictionaries, standardized in ISO 19126 (Feature Concept Dictionaries and Registers) [37], can be used to define feature types by reusing or extending concepts, but this is rare. Feature concept dictionaries are collections of independent concepts such as classes, attributes, relationships, and data types.

However, the term classification can also be understood in a completely different way: the classification of a dataset by dividing the geometries into predefined categories (supervised classification) or categories determined by an algorithm (unsupervised classification) is based on existing attributes. One example is the classification of satellite images into land usage categories. This type of classification is defined in the ISO 19144-1 (Classification Systems—Part 1: Classification System Structure) [30] standard. There are hierarchical and non-hierarchical classification systems, where classes within a level must be mutually exclusive. Hierarchical classification systems can have multiple levels, but each class should be used only once. Predefined concepts from the feature concept dictionaries defined in ISO 19126 can be used for classification. The problem with this rather static classification method is that the number of possible classes is limited, and no classes can be added by further classifications. Multiple classification (wherein a feature belongs to many classes) is only possible with a hierarchical classification system, where each hierarchy level is considered a self-contained classification.

The OGC has recently recognized the need for a “Vocabulary Service Standard” to “simplify how vocabularies are shared, managed, and used across diverse systems” [38]. However, this standard is still in the early stages of development and, therefore, could not be used for this study, aiming towards a practical solution for geodspatial data in BIM projects.

Unlike GIS, BIM focuses primarily on semantics and classification is always available due to the respective data structure [39] (p. 157). However, to overcome the diversity of semantic (and geometric) concepts of native BIM/CAD software systems, the open IFC schema was developed by buildingSMART International and standardized as ISO 16739 (Industry Foundation Classes (IFC) for Data Sharing in the Construction and Facility Management Industries) [40] for the exchange of built asset models. The IFC schema is object-oriented; classes are hierarchically structured (to support polymorphism) and can contain additional information as attributes or be linked to each other via relationships. The one or many geometric representations are linked to class instances via the concept IfcProductDefinitionShape. In addition to the build in entity-classes (IfcWindow) and entity-types (IfcWindowTypeEnum), IFC has the ability to specify generic classifications using the concept IfcClassification and IfcClassificationReference. The IfcClassification entity is used to specify the reference to an external classification system. IfcClassificationReference can be used to refer to a specific class within an external classification system to classify an entity with it. The concept of IfcPropertySets offer the generic attribution of arbitrary entities. This means that multiple classifications can be attached to a digital representation of a built asset and transferred between authoring software in a standardized way. However, “standardized way” here only means that the IFC application schema provides a standardized structure. The content—i.e., the vocabulary used—is not defined by either IfcClassificationReference or IfcPropertySet.

This study focuses on the generic semantics, using IfcClassificationReference and IfcPropertySets, because in the AECO domain, classification is not only possible according to the data schema but also according to external classification systems, such as Uniclass 2015 [41], OmniClass [42], and ETIM [43]. Ref. [29] also “suggest that the national building standard should conform to international standards and, if possible, include a classification system.” Therefore, when classification is mentioned in the following sections, we are always referring to the BIM method of classification. Classification methods from GIS are not considered.

2.3. BIM Data Dictionaries and Property Server

The concept of generic classes and attributes in an application schema is very useful. However, all stakeholders within a project should still use the same terms for the same things. Data dictionaries and property servers were developed to ensure semantic homogeneity outside the schema. They are becoming increasingly common in BIM. The two terms are not always clearly distinguished from each other in the academic literature and professional work. From our point of view, the term data dictionary includes property servers.

Data dictionaries are used nationally and internationally to manage and publish data catalogs. They provide a common language and vocabulary that allows different stakeholders to effectively communicate and exchange information throughout the lifecycle of a construction project [44]. Data dictionaries serve as a standardized and structured repository of concepts that provide the meaning, properties, and relationships to define elements in BIM models [44]. They are managed in multiple languages and represent the lowest common set of classes, characteristics, and relationships in the international understanding of the concepts abstracted from the national property servers.

Property servers are used primarily at the national level (sometimes only in the national language) to define and harmonize classes, properties, and relationships and then make them available as a machine-readable and standardized data catalog. In addition, value ranges, units, dependencies, and other country-specific information can be defined in property servers. It is important to note that the concepts do not provide values. For a description of how data catalogs are created and managed in a property server, see Clemen et al. [45]. Examples of property servers include the Austrian freeBIM property server [46] and the property module of the German BIM Portal [47]. The buildingSMART Data Dictionary (bSDD) [48] is the only internationally used data dictionary to date and is described in more detail below. In addition to dictionaries, other classification systems, such as tables and ontologies, are used in the construction industry [49] (pp. 160–164).

The bSDD provides both the technology and a collection of classification systems. These classification systems describe the definitions of concepts such as classes and attributes and the relationships between them. The semantic concepts published in the bSDD are multilingual and can be used internationally via unique identifiers. The classification systems are uniformly structured according to the standards ISO 12006-3 (Building Construction—Organization of Information about ConstructionWorks: Part 3: Framework for Object-Oriented 736 Information) [50], ISO 23386 (Building Information Modelling and Other Digital Processes Used in Construction Methodology to Describe, Author and Maintain Properties in Interconnected Data Dictionaries) [51], and ISO 23387 (Building Information Modelling (BIM) Data Templates for Construction Objects Used in the Life Cycle of Built Assets: Concepts and Principles) [52]. ISO 12006-3 defines a language-independent information model for the development of dictionaries for object-oriented information exchange in construction. ISO 23386 defines metadata that should be used to describe all concepts in dictionaries so that they are comparable and can be used consistently by software applications. ISO 23387 defines the basic structure for data templates to achieve barrier-free information exchange through standardized structures. Figure 5 summarizes the contribution of standards to the development and use of data dictionaries.

3. Materials and Methods

The bSDD provides its content in a human- and machine-readable form via an Application Programming Interface (API). The API is designed to return single concepts, as well as all concepts of a type. By specifying parameters, the results can be extended with attributes or filtered. Queries can be sent to the data dictionary using HTTP requests. Responses are returned as JSON by default, but other formats can be requested via content negotiation. Software plugins [14] can be used to access classes and attributes from BIM authoring software via the API to classify components. The creation of Information Delivery Specifications (IDSs) for the exchange of information requirements is also possible with the bSDD. The bSDD API allows software-independent access to the dictionaries and can therefore be implemented in any software. Our goal, therefore, is to use the bSDD dictionaries in GIS as an example. To achieve this, we first compare the metamodels of the different domains. Then, the different data schemes and sources for classification in GIS must be examined, before we discuss the limitations of GIS software. Differences in data schemes and data origin were found to be relevant factors in GIS. Based on this finding, various approaches to classifying and attributing features were identified.

3.1. Comparison of BIM and GIS Metamodels

Basically, both BIM data dictionaries and GIS feature concept dictionaries have the task of defining concepts and making them publicly available for standardized use. Figure 6 illustrates the similarities in the use of concepts in BIM and GIS that need to be further explored for potential cross-use of technologies and concepts. It shows, in principle, how the concepts in BIM and GIS are used to describe instances of real-world objects. The concepts can be used directly to classify instances or to describe fixed data schemes (IFC schema, application schemes) that are used to structure the information.

Feature concept dictionaries are dictionaries that contain definitions and related descriptive information about concepts that can be specified in detail in a feature catalog [37]. They provide the concepts for features, feature attributes, feature associations, feature operations, and nominal values with definitions without contextualizing them through specific relationships or additional features. This can be performed in the feature catalogs by reusing the concepts and definitions from the feature concept dictionaries. The concepts of the feature concept dictionaries and feature catalogs can be provided as registers, which are also specified in ISO 19126.

A data dictionary is defined as a database that contains metadata [50] or as a centralized repository of data about data or data elements [52]. The ISO 12006-3 standard defines a metamodel that serves as a schema for the consistent description of concepts in different dictionaries and for linking to concepts from other dictionaries. The metamodel was specifically standardized for data exchange in the construction industry and is the most widely used for data dictionaries. Therefore, we take an in-depth look at it.

In both BIM and GIS, there is a standard that provides a metamodel for describing concepts. By comparing these metamodels, the same, or similar, metaconcepts can be identified. Table 1 compares some of these metaconcepts.

In addition to these metaconcepts, each metamodel also provides metaconcepts that have no equivalent in the other metamodel. The inheritance and relationships between the metaconcepts are also similar: The concepts CD_FeatureConcept and CD_FeatureAttribute-Concept inherit from CD_Concept, and the concepts XtdSubject and XtdProperty inherit from XtdConcept. Drawing relationships between instances of the same metaconcept is possible with both metamodels. The CD_FeatureAttributeConcept can be associated with a single CD_NominalValueConcept or a list as a value. An XtdProperty can also be indirectly linked to XtdValue values via its own metaconcept for lists. The investigation shows that the selected metamodels for dictionaries in BIM and GIS are sufficiently similar to the extent that dictionaries implementing these metamodels can be used in the other domain. It is therefore possible that feature catalogs access the concepts of a BIM data dictionary and specify them for use in application schemes. Alternatively, data dictionaries could provide the classes for GIS classification. However, these possibilities for conceptually linking metamodels will not be explored here.

3.2. GIS Data Schemes and Data Sources

Metamodels are used as a basis to describe the structure of data in a data schema. Some formats in GIS are only intended for data exchange, not for data manipulation. These formats are semantically richer but not always fully interpretable by software. This applies, for example, to all formats based on XML schemes. Software like QGIS 3.40 and ArcGIS Pro 3.3 can read these schemes but cannot change their structure. The GML standard states that GML, expressed as an XML schema, is used to describe application schemes and to transport and store geospatial information [51]. In GIS software, GML files are split into several layers depending on their content, and the hierarchically organized information is compressed into simple attributes in a table. The structures of the GML schema and the specific information of the application schema are partially lost in the process. Although QGIS can use these schemes to import geospatial data, it cannot add new information according to the schema. When QGIS imports special GML application schemes, it can only export them as simplified, general GML. Exporting special schemes is not natively implemented in QGIS. It is not possible to export directly as CityGML, for example, because QGIS does not recognize this specific application schema, nor could it interpret and apply it correctly during an export. The main reason for this difficulty is the complexity of XML schemes, which leave a lot of room for interpretation. Each application schema would require its own export. As a workaround, plugins can use external tools, such as 3DCityDB or the Feature Manipulation Engine (FME), to create CityGML files. Similar limitations apply to other formats, such as DXF. CSV data is also not editable, as QGIS interprets it as read-only, since CSV is not a geospatial data format. However, the fact that QGIS only allows read-only access to these formats is not a major problem, as the layers of these formats can be exported to other geospatial data formats in QGIS. For example, it is always possible to export a GeoPackage in which the data and its schemes can be edited. However, any hierarchical structure of the data source is lost as the attribute table created in QGIS is exported to the GeoPackage. With Web Feature Services (WFSs), it is only possible to modify the data if it is a transactional WFS (WFS-T). WFS-T allows one to insert, update, replace, and delete objects [53]. It is not possible to change the schema and thus add new attributes via WFS-T.

3.3. Limitations of GIS Software

Geospatial data is typically collected in separate datasets, meaning that only similar data—such as roads or buildings—are stored in a single repository. To create a map, these datasets need to be combined. This is carried out in GIS editing software, such as QGIS and ArcGIS, by layers. This layer concept adds another level of complexity to the semantic BIM and GIS integration. Within the GIS domain the object-oriented (model driven) metaconcept from the exchange standards and the software-internal, layer-oriented metaconcept must be clearly distinguished. Each layer typically has an attribute table in which each feature has an entry (row). Multiple attribute tables compromise data integrity and layer manageability. If users were to edit only one attribute table in the layer, this could lead to inconsistencies or redundancies with other attribute tables which, in the worst case, could compromise the referential integrity of the tables.

Object-oriented data formats, such as all XML-based formats, can be mapped in GIS despite the table structure because their complexity is reduced and the data is converted [54,55]. When the GIS software converts this hierarchically structured data into a single attribute table, complex hierarchical structures are sometimes compressed into two-dimensional lists, and information is lost. Another drawback is that for most formats, these steps cannot be undone when the layer is exported again. In addition, some file formats do not allow for subsequent editing because they are intended for data exchange only. On the other hand, communication between GIS software and data dictionaries is unproblematic because GIS often uses HTTP requests to retrieve information, and data dictionaries have an API that can be used to retrieve concepts via HTTP requests.

These special aspects must be taken into account in the following approaches.

3.4. Developed Approaches

The following sections present three approaches we have developed to classify and attribute GIS features using data dictionaries. First, the following approaches will be explained in detail before being implemented and validated in the sections "Editing the Attribute Table", "Extending the GeoPackage", and "Extending the GML Schema".

3.4.1. Editing the Attribute Table (Approach 1)

The first approach uses the ability to edit the attribute table of a layer in a GIS. This approach is only suitable for data sources that allow one to edit the attributes. The attribute tables are structured in such a way that each attribute has its own column, and each feature has a row in which the attribute values are stored. For classification and attribution from dictionaries, additional columns can be added to the table where the dictionary, class, and other attributes with values can be stored (Table 2). However, this approach causes some problems (see below).

• Attributes that may only be used by one class/feature receive their own column. This results in many empty table cells, and the table becomes very large if there are many different attributes. This also violates the normal forms of relational databases since relationships (1:n and m:n) cannot be represented by a single attribute table and tables could be extended with equivalent attributes. From a practical point of view, layers must be thematically restricted in such a way that all attributes can be assigned an attribute value.
• It carries the risk that users will enter attribute values in rows where the attribute does not belong.
• Multiple classification of features is not possible because only one value is allowed in each cell. This problem can be solved by including the dictionary and class names in the column names for customization. Table 3 shows an example. However, this expands the table with extra columns and “null” values.
• Attribute groups cannot be mapped in GIS, whereas property sets are used extensively in BIM.
• Data integrity is not guaranteed. Having one attribute table per layer leads to high redundancy and often meaningless connections between attributes and features.

3.4.2. Extending the GeoPackage (Approach 2)

The second approach applies only to relational data schemes that allow for multiple and connected tables. In the presented study, this approach was developed specifically for GeoPackage, but it can also be generalized to, for example, a PostGIS database. For the BIM data dictionary integration, the database is accessed directly to manipulate it. The GeoPackage can store tables with and without geometry. This approach eliminates the problems of the first approach by using multiple tables to store the added information. The GeoPackage is an SQLite database that must have a specific table schema. However, it can be extended with additional tables and extensions to create an extended GeoPackage. The GeoPackage Related Table Extension [56], defined by OGC as a standard, can be used to map one-to-many or many-to-many relationships between tables. The GeoPackage is therefore suitable for testing whether classification and attribution can be added to the features by creating and linking attribute-only tables. The extension can be used to add the following table schema in Figure 7. The diagram shows how to add classification and attribution to a table of features. First, the extension must be added with an entry in the “gpkg_extensions” table. The mapping tables are also added here. The relationships are defined in “gpkgext_relations”. All classes used can be entered in the table “classification” and all attributes and their values added by the classification can be entered in the table “classification_attributes”. The mapping tables define the relationships between the feature and the class or attribute. To eliminate further redundancy, a separate table is also created for the dictionaries, with identical functionality. This approach is easy to use, as the data loaded as layers can usually be converted into GeoPackages in GIS software. However, the problem remains that complex data schemes become simplified when imported into an attribute table.

3.4.3. Extending the GML Schema (Approach 3)

As a third approach, a “Classification” schema extension (Figure 8) was developed, which allows one to add classification and attribution to features in the GML schema. With the schema, any number of classification instances can be added to each element via “classifications”. Each classification also has a dictionary assigned. Attributes can also be added using “classification_attributes”. The schema extension therefore makes it possible to modify GML files without changing the XML schemes used. It can be added like an extra layer. In GIS software, the concepts of the extension are simplified to simple attribute-value pairs in the attribute table, just like the other schemes.

This approach has the advantage that XML is a widely used language outside the GIS domain and can therefore be read by other software.

While the first approach to classification is implemented in the attribute tables of the layers in GIS software, the other two approaches involve manipulating the files themselves. This can be facilitated by the use of GIS software or with editing software appropriate for the file format (e.g., 3DCityDB, FME, text editors).

4. Validation and Results

The validation of the results for the classification of geospatial data according to the BIM methodology is carried out by practical application on datasets in different schemes. The open-source software QGIS was used for the validation tests. For classification, a Python plugin was developed. This plugin allows the user to enrich the features of a layer with classifications and attributes from the bSDD (Figure 9). The plugin provides the user with the potential BIM vocabularies available in the bSDD, allowing them to select one for the actual classification and attribution. The QGIS Python libraries and the sqlite3 library were used for the implementation. The plugin “Add BIM Data Dictionary Semantics” can be downloaded from the QGIS plugin manager, and the source code is available on GitHub [57]. Figure 10 summarizes the interactions when using the plugin.

The plugin connects via the Uniform Resource Locator (URL) of the bSDD API and offers the user a selection of all contained dictionaries. The plugin is designed to integrate other data dictionaries or property servers in the future, if they also provide their dictionaries via an API identical to the bSDD API. HTTP requests are used to request a list of dictionaries and then the classes of a dictionary, from which the user selects a dictionary and a class. If the class has attributes, these are also retrieved and displayed in a table. The user can then assign values to the attributes. In addition, he selects the layer to be classified. Here, it is possible to either classify all geometry objects that are located in this layer or to make a selection that is limited to a certain number of objects. This selection can be made from the map view. Two classification approaches have been implemented.

4.1. Editing the Attribute Table

The first approach can be applied to all editable data schemes. In this approach, new columns are added to the attribute table to store the name, Uniform Resource Identifier (URI), and version of the dictionary, as well as the name and URI for each feature. If attributes exist, they are also created as column names with the value as content. Table 4 summarizes the tested data sources.

As stated in Section 3.2, some datasets cannot be edited because QGIS cannot interpret their data schemes and insert new data into them. XML-based formats can only be exported in generic GML, not in specific application schemes.

Figure 11 shows the user interface of the plugin with a dictionary and class already selected. Values have also been added to some attributes. The result of the classification can be seen in Figure 12.

4.2. Extending the GeoPackage

The second implemented approach is specifically for GeoPackages as data sources. In the plugin interface, the user can also check the box “Classify also the original GeoPackage file” (Figure 11). The file can then be selected. When the classification is executed, new tables for classes, attributes, and relationships are created in the SQLite database of the GeoPackage using the Related Tables Extension, and the new information is stored in them. When the classified GeoPackage file is loaded again into QGIS, it consists of not only the geometry layer, but also four additional attribute layers with the classes, attributes, and relationships. The relationships to classes and attributes are displayed in the attribute table of the geometries (Figure 13). ArcGIS Pro cannot display the relationships between geometry and classes or attributes because the Related Tables Extension is not implemented in the current version of ArcGIS Pro 3.3 [58].

4.3. Extending the GML Schema

The third approach involved using the developed application schema to add classification to the GML-based data. This was tested in practice by adding classes and attributes to given CityGML and GML files using a text editor. First, the manipulated files were validated against the XSD schema using XML validators. Then, the extended CityGML and GML files were loaded into QGIS, and the semantic information was examined. Although all of the information is displayed, as shown in Figure 14, the information is no longer unambiguous. For example, the attribute URI of the classification is given without its hierarchy in GML, while the URI of the dictionary is. The hierarchy seems to be added randomly for at least one of the attributes with the same name during the QGIS import. On the other hand, due to the multiple classifications, some attributes may have multiple values, making unique assignment impossible.

4.4. Use Case: Planning Solar Panels Using the ETIM Catalog

The plugin is tested on the use case of solar panel planning on existing buildings. To ensure seamless information flow between the GIS and BIM domains, attributes used in GIS should align with those later employed in BIM, preventing redundant data entry and inconsistent storage. Using shared data dictionaries facilitates this integration.

The solar potential analysis in GIS involves assessing whether the environmental conditions of a building’s roof are suitable for photovoltaic installation. Solar potential analysis uses various geodata sources, including topographic maps, city models, digital elevation models (DEMs), and annual solar position and intensity. City models contain building height, roof geometry, and position information, enabling determination of roof surface slope angles and orientation. The DEM, combined with solar position data, primarily supports shadow analysis by representing the earth’s surface, including all structures and vegetation. The data used is made available as open source by the Saxony Energy Portal of the Saxony Energy Agency (SAENA GmbH) as Shapefiles. The analysis results are described in the following section. They include geometries and attributes for each solar potential surface describing expected energy yields, possible number of modules, and CO₂ savings.

Solar potential surfaces serve as the foundation in GIS for determining optimal photovoltaic module placement (Figure 15a). Module positions are created as geometries and classified and attributed using data dictionaries accessible through the plugin. The ETIM (Electronic Technical Information Model) catalog, an international standard for technical product classification, provides suitable classifications and is available over the bSDD. The photovoltaic module class contains numerous product-descriptive attributes. Several attributes can be populated directly in GIS by the planner using values from solar potential analysis and GIS planning, including assumed dimensions, nominal power, and efficiency. These values can serve as requirements for product selection. The classified geometries should then be exported in a BIM software-readable format. In this example, the attribute table was edited (approach 1), and an extended GeoPackage was created (approach 2) to store semantic information. Figure 15a shows the the ETIM attributes with the property group as prefix in the attribute table for one feature. However, as BIM software cannot yet read geometries with semantic annotation in geo formats, the values had to be transferred manually into the BIM software after the geometries were imported as DXF files.

BIM planners import the geometries into their BIM software and integrate them with the building model. The attributes can be used to select a suitable product without having to perform a new analysis, saving time and effort. Once displayed on the roof, planners can position photovoltaic modules directly using the geometry and attributes. Subsequently, photovoltaic module objects are classified and attributed using the same plugin and class (Figure 15b). Existing attribute values are transferred, and missing values are added by the BIM planner through selection of products meeting the requirements. Figure 15b shows some ETIM property groups and attributes with added values. The completed BIM model can then be exported as an IFC file with all information for subsequent processes.

This integrated workflow demonstrates how standardized data dictionaries enable efficient information transfer between GIS and BIM domains, reducing redundancy and ensuring consistency throughout the solar panel planning process for existing buildings.

4.5. Results

Implementing the classification in QGIS using a plugin demonstrates that it is possible to semantically enrich geospatial data with additional classes and attributes in GIS. In addition to GIS dictionaries, dictionaries from the construction industry, such as the bSDD, can be used. Classes and attributes from different dictionaries can also be easily queried by GIS software via the API. The graphical interface with a map allows the user to intuitively select the objects to be classified.

The first approach—the extension of the layer attribute tables in QGIS—is based on the layer principle of the software, and therefore, theoretically allows for application to all data formats supported by QGIS. However, in practice, some formats (e.g., CityGML, GML, or WFS-T) are not editable, and therefore, only limited implementation of classification is possible in QGIS. For shapefiles, the length of attribute names is limited to 10 characters, which means that most information cannot be displayed without additional simplification. The practical implementations have shown that adding a new class and new attributes causes the attribute table to grow continuously, creating many empty cells in the table and making it difficult to read. This approach is best suited for features in data schemes that are already stored as tables.

The second approach, developed specifically for use on GeoPackages, is much more performant and allows for a more semantically structured representation of the classification. This example shows how classification can be implemented in a schema-compliant manner using an extension of relational databases in a tabular structure. The advantage of this approach is that the classification result is software-independent because it is written directly into the GeoPackage file. This avoids software-specific parsers that might not implement the extension correctly. For example, despite the OGC standardized Related Tables Extension, the GeoPackage with classification cannot be imported correctly into ArcGIS Pro because this extension, unlike others, is not implemented by Esri. In QGIS the GeoPackage will import correctly, but the data will not be editable by QGIS. The additional tables are loaded, and the relationships between features and their classes and attributes work. All in all, using GeoPackage with the Related Tables Extension is a suitable way to semantically enrich geospatial objects and make them available in GIS applications.

The use of a separate application schema to classify GML files in the third approach can be easily added through object orientation, but again, the GIS software is the limiting factor in the presentation of the information. Due to the tabular structure in QGIS, multiple classifications and identical attribute names can no longer be uniquely assigned.

In summary, the implementation in QGIS shows that classification of features using BIM data dictionaries is also possible in GIS applications, but there are some limitations.

5. Discussion and Conclusions

In the final section, we summarize the findings, highlight some limitations, and provide an overview of future work.

5.1. Summary

Unlike other BIM-GIS integration approaches, we do not map information from one schema to another or link information together. Instead, we use the respective options to add external classification. This enables the application of semantics from the BIM domain to geo-objects in GIS. To ensure consistency, the same data dictionary is used as the source for both domains. Our approach does not conflict with others, but rather serves as preparation for the conversion or linking of BIM and GIS information. This is because every type of BIM-GIS integration benefits from uniform semantics. The research questions can be answered as follows:

How do the semantic metamodels differ between the BIM and GIS standards? Which standards and technologies from the GIS domain are comparable with BIM data dictionaries? Investigations have shown that although the metamodels used in dictionaries for the two domains from ISO 19126 and ISO 12006-3 differ, they also have many similarities. The exchange with open data standards relies on geometric–semantic information models in both BIM and GIS. Due to their different requirements and traditions, they use different schemes and metaschemes. However, in BIM, classifications and property sets are also often added as generic attributes to entities, following the vocabulary of data dictionaries. In GIS, classifications are part of a complex static schema, following well-established application schemes.

What are the differences between the system architectures used to publish semantics in the BIM and GIS application domains? Data dictionaries are used in BIM for external classification, while concept feature dictionaries are used for defining concepts in application schemas. Therefore, BIM dictionaries are more technologically advanced, e.g., in terms of interfaces. GIS dictionaries are usually published as documents rather than databases.

How can BIM data dictionaries be practically used for the semantic enrichment of geospatial data? Our research has shown that it is possible to use BIM data dictionaries in GIS. Our comparison has shown that similar approaches are used to define concepts for classification. Although the dictionary applications for publishing concepts use different metamodels as a structure, it is possible to map most of them to each other. With our approaches, we were able to show how BIM data dictionaries can be implemented in a GIS software environment, such as QGIS, to annotate the geospatial data according to the BIM classification methodology. However, the heterogeneity of data exchange formats and the way that GIS software handles them makes it difficult to use. The lack of object orientation in many geospatial schemes is also a challenge that needs to be addressed. Nevertheless, some data models can be used to represent the semantic classification of geospatial data. The amount of lost information depends on the data format, but display problems in the GIS software are the main cause. Object-oriented formats are able to store classification and attribution without any loss.

Can the semantics from data dictionaries (especially multiple classification) be transferred to GIS without loss? In principle, the semantics can be transferred to GIS without loss. Currently, however, technical implementation leads to information loss, depending on the approach, due to internal data storage. Additionally, not all data formats are suitable for exchanging external classifications.

The development of the plugin for QGIS has shown how cross-domain use of semantic annotation concepts can be implemented through the use of open, standardized interfaces. Plugins and APIs such as those presented here (“Add BIM Data Dictionary Semantics” QGIS Plugin, bSDD API) can help the BIM and GIS domains to grow closer together in the future. In our view, better integration of BIM and geospatial data can only be achieved by using dictionaries of jointly defined concepts. Almost complete interoperability and semantic integration is only possible if semantics are used across domains.

5.2. Limitations on Integration

The research revealed a number of limitations that need to be considered when using BIM data dictionaries for classification in GIS. In practice, there is a lack of conceptual and IT standards and guidelines for jointly managing geodata and building models. This scientific article can only offer an example of what a scalable solution might look like. It also shows that there are challenges in transferring the concept of classification from BIM to the GIS domain. BIM and GIS have different goals, which means that the classification methods cannot be transferred to each other, although they use similar concepts to the dictionaries for classification. Classification in GIS, as shown in BIM, is not yet widely used. GIS software tools are not designed to easily integrate the classification with data dictionaries. This is particularly evident in the layer principle, which compresses geospatial data into flat structures and causes information about relationships between classes and their instances to be lost. Furthermore, although the data schemes used, such as GML and CityGML, are object-oriented, their use in GIS is associated with challenges due to the layer principle. Such object-oriented, hierarchically structured data schemes are well suited for classification, but GIS software cannot handle their complexity. Thus, these schemes are simplified into tables by the GIS software. Other data schemes, such as shapefiles, do not lose any information when imported into GIS software, but their flat table structure limits their ability to handle the complexity of classification. It has also been found that some data schemes cannot be edited in GIS software. However, these problems are mainly due to the functionality of the software. Open-source software was used in research because it supports many data formats. Tests with ArcGIS Pro have shown that not as many data schemes can be imported. There are add-ons for importing formats such as GML, but they require an additional license. Proprietary software is therefore even more limited in its functionality. For this reason, the approaches have been implemented and validated only in QGIS.

In general, it has been shown that data schemes in GIS are much more static than in BIM, as evidenced by the limited ability to add semantics. Data schemes such as GeoPackage or GML can be extended to allow the addition of more complex semantic information than simple attribute–value pairs.

Some software limitations can be overcome by using GIS software only as a tool to manipulate files. For example, the developed QGIS plugin shows how features of a GeoPackage file can be enriched with semantic information from a BIM-specific dictionary more effectively than directly in the QGIS attribute table. This can also be applied to XML-based data formats or GeoJSON.

5.3. Outlook

The results of this work show that the use of BIM classification systems in GIS is possible, but they also indicate that there are still some problems to be solved. On one hand, the developed approaches should be implemented and tested in other GIS software. On the other hand, it has been shown that classification works best when GIS software is used only as a tool for manipulating data schemes and geospatial data in files. Therefore, it might make sense to develop a specific desktop software or web tool that is specialized in classification and has multifunctional access to different dictionaries from BIM and GIS. This tool could work independently of the domain, and thus, also classify construction-related data. This could enable a comprehensive, semantic classification of building elements, which is desirable for the cross-domain integration of BIM and GIS.

In general, the reverse case should also be investigated, i.e., feature concept dictionaries from GIS should be integrated into BIM to perform classification in BIM.

Another interesting aspect is the extension of the developed QGIS plugin to make the concept feature dictionaries from GIS usable for the classification approaches in addition to the use of the bSDD as a collection of BIM dictionaries.

To successfully use BIM and GIS in tandem, it is particularly important to be aware of the requirements and technical possibilities in practical engineering. New academic concepts should be presented with the help of examples and demo applications in such a way that the technology can be successfully transferred into practice. Therefore, programmatic implementation is the task of the open-source community or commercial software manufacturers.

Currently, there are no commonly used data dictionaries. Looking ahead, a common data dictionary that combines concepts from BIM and GIS should be developed.