IFC-CityGML Data Integration for 3D Property Valuation

Abstract

The accurate assessment of proper value in complex and increasingly high-rise urban environments is a significant challenge. Previous research has identified property value as a composite of indoor elements, such as volume and height, and 3D simulations of the outdoor environment, including variables such as view, noise, and pollution. These simulations have been preliminary performed in taxation context; however, there has been no work addressing the simulation of property valuation. In this paper, we propose an IFC-CityGML data integration approach for property valuation and develop a workflow based on IFC-CityGML 3.0 to simulate and model 3D property variables at the Level of Information Need. We evaluate this approach by testing it for two indoor variables, indoor daylight and property unit cost. Our proposed approach aims to improve the accuracy of property valuation by integrating data from indoor and outdoor environments and providing a standardized and efficient workflow for property valuation modeling using IFC and CityGML. Our approach represents a solid base for future works toward a 3D property valuation extension.

1. Introduction

Given the rapid urbanization and population growth, residential properties tend to be more densified and vertically developed. That has led to more complex urban areas that require more efficient and sustainable city management. 3D urban models and City Digital Twins (CDTs) are increasingly developed to deal with the new requirements of the city such as sustainability [1,2,3], efficiency, and well-being [4,5]. Real estate valuation, recognized as a main issue in city management, should benefit from the advancements in 3D building/city modeling to allow precise and reliable valuation of properties. Indeed, the presence of high-rising residential buildings and the complexity of the surrounding urban environments add significant challenges for real estate stakeholders (investors, taxation administration, valuer, etc.) to assess the property value accurately.

Traditionally, the property value is the process of estimating the amount of which the property will be exchanged in the market [6]. However, property value is defined, following the work of El Yamani et al. [7], as the association of indoor elements related to the property as 3D objects (e.g., volume, height) and 3D simulations from the property’s outdoor environment (e.g., view, noise, pollution). Therefore, taking into account both indoor and outdoor variables in an urban context, characterized by high-rising residential buildings and complex surrounding urban environments, requires efficient methods for modeling and simulating the property value.

Recent works have identified relevant 3D variables (indoors, outdoors) for property valuation [7,8,9,10]. El Yamani et al. [7] have proposed a classification of 3D variables in terms of spatial granularity, covering several scales: from building elements of a building part (e.g., construction materials, openings,) to the large neighborhood level (e.g., building envelope, surrounding amenities, atmospheric conditions). Thus, a property value simulation should be performed at the building scale (indoor variables), at the neighborhood or the city scale (outdoor variables), or by considering the two scales when it comes to interactive variables implying the interaction between indoor and outdoor variables. Therefore, to accurately determine the value of property, it is necessary to determine the spatial and non-spatial elements required to assess the 3D variables’ value and to identify where and how to obtain them.

Such 3D variables can be acquired from Building Information Models (BIM) and/or City Information Models (CIM). BIM and CIM allow rich geometric and semantic modeling related to the building or the whole city, respectively [11,12,13]. Specifically, in the scope of our research, BIM offers rich information required for property valuation both for spatial and non-spatial elements at the building level, while CIM allows simulating outdoor variables requirements at the neighborhood or the city scale.

The Industry Foundation Classes (IFC) and CityGML are among the most advanced data models for indoor (building elements) and outdoor (building’s built environment), respectively. While IFC and CityGML offer distinct geometry, topology, and semantics, their integration poses significant challenges due to discrepancies in geometric and semantic coherence during the conversion process, as observed in prior studies [14,15,16,17].

In recent years, several research studies have been conducted to bridge the gap between these two standards and make it possible to integrate them for indoor and outdoor modeling and simulations, under many use cases, frameworks, and concepts [18,19,20]. Specifically, developments have been made to address the semantic mismatches and the geometry conversion problems between IFC and CityGML [21,22].

Various studies have explored the integration of IFC and CityGML, which can be classified into two approaches: generic integration based on IFC-CityGML, and specific integration based on IFC-CityGML use cases, such as energy or indoor navigation [22]. For example, Noardo et al. [23] developed an IFC-CityGML schema model for permit checking, while Ohori et al. [14] created workflows for bi-directional conversion between IFC and CityGML. Berlo and Laat proposed a meta-model to preserve IFC semantics and properties in CityGML without a specific use case. Although some studies have proposed IFC-CityGML integration for different use cases, including energy, urban planning, and indoor navigation, there is still a lack of generic use cases, such as real estate valuation [22].

From the perspective of property valuation, prior approaches have primarily centered on fulfilling 3D cadastral taxation criteria by adopting LADM (Land Administration Domain Model) as the standard model [9]. To this end, Çaǧdaş et al. [24] developed an extension for taxation valuation, known as “ADE Taxation,” using CityGML. Other authors have focused on extracting variable requirements from IFC in the indoor context, such as valuation units for apartment legal boundaries based on Ifcspace [10,25,26], indoor daylight obtained from BIM simulations [27], or specific outdoor requirements like view quality by determining viewshed requirements based on GIS analysis (distance to view, etc.) [9].

While the literature has acknowledged the importance of indoor elements and 3D simulations of the outdoor environment for property valuation, work remains to be conducted to simulate integrate data sources needed for assessing property valuation variables. The use of for the two prominent standards, IFC (Industry Foundation Classes) and CityGML, is inevitably chosen for the property valuation model. Developing a standardized and efficient workflow based on IFC-CityGML 3.0 should improve the accuracy of property valuation by integrating data from indoor and outdoor environments. The evaluation of indoor variables, such as indoor daylight and property unit cost, serves as an initial demonstration of the effectiveness of this approach and provides a solid foundation for future extensions in 3D property valuation.

Therefore, there is a need to address integration of IFC and CityGML for property valuation purposes. Therefore, this paper aims to propose a data integration approach based on BIM (IFC) and CIM (citygml) for a 3D property valuation model. The main contributions of our research are the following:

• Analyzing the property variables specifications and requirements within an integration approach for property value simulation;
• Proposing and implementing a workflow based on IFC and CityGML for simulating property 3D variables (cost and daylight);
• Analyzing and discussing the study case outputs toward a future data valuation model extension.

The paper is structured as follows: Section 2 reviews prior research on data integration methods based on IFC-CityGML, highlighting the challenges they encounter. Section 3 proposes an integration approach. Section 4 presents a case study in which we propose and evaluate the integration workflow, focusing on two indoor variables: indoor property daylight and property cost. Lastly, Section 5 discusses the strengths and limitations of our approach and provides recommendations for developing a 3D property valuation model.

2. Related Works

Several authors have proposed workflows to integrate IFC and CityGML for specific use cases. Isikdag et al. [28] converted IFC to CityGML for indoor navigation. For 3D cadaster, Kalogianni et al. [29] and Kara et al. [9] extracted legal boundaries from IFC before integrating the property building in its surrounding 3D urban environment to assess outdoor urban regulations and extract 3D overlooking and visibility. The literature suggests that the schema-based approach is one of the most commonly used integration methods [30]. Other integration approaches include the system-based and ontology-based approaches [20,21,31,32,33]. These approaches can be used separately or in combination to integrate data from IFC to CityGML for specific use cases.

In order to determine the appropriate integration approach and the necessary level of information for a given use case, it is crucial to consider the specific requirements and applications. In this section, we will first examine the previous research regarding 3D property valuation and then second investigate the various data integration approaches and identify their associated challenges. Additionally, we will discuss the concept of “Level of Information Need” and its significance in the context of property valuation.

2.1. 3D Property Valuation Background

In the context of property valuation, the previous research has predominantly centered on fulfilling the 3D cadastral taxation criteria, often adopting the Land Administration Domain Model (LADM) as the foundational reference [6]. To elaborate, researchers such as Çaǧdaş et al. [21] have extended this model to accommodate the intricacies of taxation valuation, introducing the concept of “ADE Taxation” and employing the CityGML framework. Similarly, other scholars have been focused on extracting relevant specifications of variables from the Indoor Facility Concept (Ifcspace) component within the Industry Foundation Classes (IFC) framework for applications that center on indoor considerations [7,22,23]. Moreover, investigations have delved into parameters like indoor daylight, employing simulations based on Building Information Modeling (BIM) data [24]. Further studies have ventured into aspects beyond the building’s physical attributes, such as evaluating view quality through comprehensive geographic information system (GIS) analyses [6].

Notwithstanding these existing explorations, there exists an unmet need in the realm of property valuation—the integration of the Industry Foundation Classes (IFC) and CityGML standards, specifically aimed at enhancing property valuation procedures. Consequently, the primary objective of this research paper is to introduce and establish a novel data integration approach. This approach is founded on the principles of Building Information Modeling (BIM) and City Information Modeling (CIM), with the overarching goal of enabling the comprehensive 3D valuation of properties.

2.2. IFC-CityGML Integration Approaches

• System-based approach: it consists in a web system-based approach, where building information is not stored but is directly integrated into an information system for visualization purposes. This approach provides the possibility to extract a part of IFC semantics and performs full geometry conversion into an intermediate format (e.g., WebGL, B3M (batched 3D model)) or into a 3D city models’ standards (e.g., CityGML, CityJSON)) before their integration into a web-visualization platform. The geometry and semantics are stored in separate databases (IFC/BIM, CityGML/GIS). As an example, Xu et al. [34] integrated directly IFC data into a WebGIS system and visualized the results with Cesium. Emamgholian et al. [35] used this approach in the context of 3D urban regulations.

This approach is mainly used for specific use cases. However, it is challenging at the level of storing information. Moreover, it requires open data to be visualized in a web platform, which can be problematic when it comes to sensitive or personal data (e.g., property value, private property, etc.).

• Ontology-based approach: it consists of translating IFC and CityGML semantic class entities into a new UML (Unified Modeling Language) ontological model based on RDF (Resource De-scription Framework) and OWL (Ontology Web Language). The integration of IFC and CityGML can be achieved in two ways: (1) recognizing similar concepts/entities and merging them, or (2) connecting all the classes from IFC and CityGML into a unified model thanks to an ontology tool (OWL). Information can be extracted from RDF triples based on an ontology query language (e.g., SPARQL etc.).

We also refer to this approach in the literature as semantics-web-based or linked-data-based approach. Under this approach, we can cite the work of El-Mekawy et al. [36] who proposed a UBM (Unified Building Model) as an intermediate data model to combine IFC and CityGML classes and terminologies. In the same trend, Tauscher [37] introduced the Triple Grammar Graph (TGG) as an automated ontology tool for IFC2CityGML mapping rules. However, such an approach is mainly based on full semantics mapping and does not make it possible to extract the specific information needed from IFC to CityGML that can be required for a specific use-case application.

• Schema-based approach: it consists of mapping between schemas or data; the process is referred to as “schema matching” and “data matching”, respectively [38].

Schema mapping techniques are divided in two approaches: (1) developing a specific conversion workflows based-ETL (Extract Transform and Load) tools or (2) extending CityGML or CityJSON schema, respectively, based on ADE and extensions. The latter approach provides the capability to extract the needed semantic and geometric information from IFC and map it to the corresponding CityGML/CityJSON classes and semantics. This approach is, however, not fully automated since it requires a one-to-one mapping process for every specific use case. Under this approach, Krijnen [19] developed an application to address the automation process of IFC-CityGML (precisely CityJSON), referred to as “GEOBIM” application, which is a recent implementation of [39] work. They developed an open source application for an automatic transformation for building geometric elements from IFC to CityJSON, which is a not applied yet to a specific application requirements.

Table 1. IFC2CityGML data integration approaches: capabilities and challenges.

Approach	Capabilities	Challenges
System-based approach	- 3D Data visualization. - Direct use of BIM in GIS.	- Only web-based GIS systems and platforms (e.g., Cesium). - Limited implementation possibilities (Databases). - Semantic selection is challenging.
Ontology-based approach	- Automatic integration approach. - Semantics mapping. - Generic data integration approach.	- Complex process of semantic mapping. - Extracting specific information is not possible. - Limited at the geometric conversion.
Schema model-based approach	- Possibility to extract requirements for a specific use case. - Non-looseness of information. - Possibility to extend schemas. - Schema mapping based on semantics. - Geometrical errors detection. - New flexible data model for geometry encoding (CityJSON).	- Complex information extraction from BIM (mainly IFC schema). - Limited control during the conversion process: limitation due to the opaque ETL interfaces. - Mature-less city models at the level of implementation and software support (CityGML 3.0). - Geometric and semantic mismatches not all solved. - Limited usability and implementation of ADEs.

shows that the three data integration approaches have their own advantages and limitations. The selection of the most appropriate approach depends on the specific application context, which determines the integration purpose and the necessity of preserving or not the source schemas. Moreover, the integration process can either focus on enriching the semantic content of IFC data in CityGML (Ontology approach) or on extracting geometric features [40,41], or on converting IFC data into CityGML to add generic features and entities both geometrically and semantically [42], depending on the application context.

2.3. LoIN (Level of Information Need)

In the field of property valuation, the acquisition of specific information at the elemental level, such as cost data, holds critical significance. However, conventional integration workflows often overlook such detailed data. Moreover, the challenge of uncertainty in property valuation remains a prominent concern, prompting researchers globally to explore various avenues for resolution. One such avenue involves the integration of disparate data sources. Another approach involves the fusion of distinct valuation techniques through hybridization as a potential solution for automatic valuation models [43].

Addressing these complexities requires a suitable data integration paradigm that can be performed at different information levels, from various data sources, and enriched with external data related to building elements or environmental data. Noardo [44] emphasized that the user requirements should be clearly defined to ensure a successful integration process that is suitable for multiple use cases, which can be challenging given the specificity of each application.

Although IFC and CityGML provide rich semantics information at the building and city scales, not all of this information is necessary for specific use cases. Both data models provide information based on the concept of level of Detail (LoD), which represents the level of granularity of geometric and semantic information of objects. CityGML proposes a classification of LoDs that has recently been updated in version 3.0 to address various applications [45,46]. In the BIM context, several concepts such as Level of Development, Level of Accuracy, and Level of Information have been proposed to extend the concept to the model as a whole [18], but these concepts are sometimes confusing and lack standardization, leading to different interpretations of the requirements of each level of granularity.

To address this issue, a new concept called the Level of Information Need (LoIN) has been introduced by BuildingSmart as a new standard EN 17412-1 [47]. The LoIN concept suggests that the granularity of information should be tailored to meet the specific needs of information exchange based on the context of use. This is especially crucial in property valuation, where building elements information must align with technical requirements for each variable at both geometric and semantic levels. While this concept has been introduced in dictionary descriptions, there is currently no technical implementation developed at the BIM&CIM level.

3. Method

In this section, we describe the methodology used to simulate and model 3D property variables using an integrated BIM and CIM approach. Figure 1 illustrates the meta-workflow, which is broken down into steps that we analyze in the following subsections.

As discussed in the related work section, the schema model method is the most appropriate approach for our work. It requires operating at the schema level in order to extract information based on the level of granularity required for each indoor and outdoor property variable.

Additionally, to enable further analysis at the neighborhood or city levels, the BIM and CIM should be maintained as reference models. IFC and CityGML are the most suitable data models for the proof of concept of our approach.

The recent version of CityGML 3.0 offers some improvements and new concepts related to modeling of constructions such as Buildings that are divided into Constructive Elements. Buildings as well as BuildingParts and ConstructiveElement classes allow mapping constructive elements from BIM data sets given in the IFC standard (e.g., the IFC classes IfcWall, IfcRoof, IfcBeam, IfcSlab, etc.) onto CityGML [46]. These improvements are relevant to integrate variables requirements, mainly the cost and materials for property valuation purposes. However, the task is not trivial until we have to deal with some mismatching issues that are analyzed and discussed in our case study.

We adopt a recent method proposed by Kutzner and Kolbe to convert IFC to CityGML3.0 in our conversion workflow. Their approach utilizes a data integration-based schema mapping, and the conversion is conducted with an ifc-to-citygml3 conversion tool available on GitHub. However, their method has certain limitations: (1) it employs a generic mapping for IFC/CityGML 3.0 classes without considering specific application requirements, and (2) it uses different data formats as inputs, such as IFC and Revit format.

Using separate readers for IFC and Revit in an IFC to CityGML 3.0 conversion can create problems due to compatibility issues, increased complexity in the workflow, possible data loss, and increased risk of errors. This may result in incomplete or inaccurate conversions. Therefore, we propose an adjusted workflow tailored for property valuation purposes.

The proposed workflow is divided into three stages, as illustrated in Figure 1:

(1)

Variables specifications—This stage aims to identify, classify, and select the relevant data specifications needed for 3D property valuation.

(2)

Variables retrieval levels—The suitable data sources are defined (building models and city models), and the process needed to retrieve each specific requirement based on spatial and non-spatial elements from the selected 3D models or other external data sources is defined.

(3)

Variables Assessment—The final stage involves assessing the variable values required for property valuation.

3.1. Variables Specifications Definition

Accurate simulation of 3D property value requires the identification of relevant variables for property evaluation and the selection of appropriate data sources to simulate them. El Yamani et al. [7] proposed a comprehensive analysis of such variables.

The identification process involves defining the property valuation requirements for each variable and specifying the required level of information, including the granularity of the geometric and semantic data, for variable estimation.

3.1.1. Variables Requirements

Through a deep literature review, a set of relevant 3D variables for property valuation were identified. Technical requirements for these variables were analyzed and classified based on building and city scale elements. The identification process was based on the analysis of 3D variables with high relevance to property valuation determination, with some variables being proposed due to their potential impact on the valuation process.

The identified variables were then summarized and classified according to indoor, outdoor, and interactive categories. (Figure 2).

The interactive variables can be used to predict changes in the value of residential properties in relation to the surrounding neighborhood (e.g., indoor daylight, air flow, sunlight exposure, and air quality).

The influence of the surrounding built environment on the building property can affect the interactive variables, such as indoor daylight, which is typically simulated at the scale of the building model. The obstruction of sunlight by surrounding buildings can significantly impact the accuracy of indoor daylight simulations, underscoring the need to consider neighborhood characteristics in 3D property valuation.

3.1.2. Level of Information Need

As stated before, 3D variables (as shown in Figure 3) can be obtained from BIM, CIM, or other data external sources. For each data source, integration workflows should be developed to retrieve the precise information. For each scale of the analysis (building or city or both), the degree of granularity should consider the smallest part/element of the model that holds significant information for simulating the property value [8]. For example, indoor sunlight requires attributes at the level of IFC (ifcspace) and the value is stored in a CityGML class (Room).

In the following, we propose two information specification levels for property valuation, named LoIN-1 and LoIN-2, for property valuation, which are described below.

• LoIN-1:

The specifications at this stage focus on the fundamental and generic entities and attributes that are necessary in any initial step for property valuation simulation and modeling. One such example is the Property Unit, which has boundaries that are required for defining other variables. The Property Unit can be defined as a boundary of space, volume, or building elements, and it can be obtained from either the IFC building elements or the IfcSpace (check Supplementary Materials Tables).

• LoIN-2:

At the second level of the approach, detailed information is obtained for each variable by analyzing the input/output specifications of entities, attributes/Pset_properties, or relationships. The IFC/CityGML schema is used to select relevant classes or subclasses to retrieve the required variables.

The Pset_properties, which are attributes generated during the building modeling process according to IFC schema specifications, are used to provide more comprehensive information for each variable. For instance, indoor daylight is modeled as a Pset_properties, which is created during the BIM modeling stage and is not exported as IFC parameters by default. This approach allows for a more granular and accurate simulation of 3D property valuation variables (check Supplementary Materials Tables).

3.2. Retrieval Levels

Recent research has identified different approaches for retrieving variables based on data integration from 3D building and city models. However, to our knowledge, none of them have been studied for property valuation. As presented in Figure 4, retrieval levels for variables requirements provided from 3D data models (city and building levels) can be classified into two major classes:

(1)

Direct retrieval: in this level, variable requirements can be directly mapped from building or city models based on an integration and conversion workflow. For example, the conversion process allows mapping features from IFC to CityGML, or it can be created as a feature CityGML ADE.

(2)

Indirect retrieval: this level requires further processing for data integration workflow to extract variables values or requirements either from IFC or CityGML. It can be performed through two main stages. The first step is to transform variables requirements from IFC to CityGML in order to provide their composite elements; the second step is to extract their final value (example attribute) from the CityGML classes.

Another level of extraction concerns retrieving information from external sources (climate databases, real estate transactions, standards cost elements, etc.). Within the scope of this paper, cost elements have been integrated into BIM as external data to each building element (wall, column, slab, and roof). Moreover, further data need to be retrieved from external data sources, such as climate dataset, for modeling indoor daylight.

3.3. Variables Assessment

The final stage of our workflow consists of assessing the variable values required for property valuation. Regarding the requirements retrieval levels, this subsection considers analyzing the variables assessment in terms of data structure, standardization, and storage possibilities for property valuation (Figure 5).

Therefore, we mainly classify the process of variables assessment in terms of the following:

(1)

Indoor variables: refer to variables simulated/extracted from BIM/IFC entities and stored as attributes extending the IFC property sets. These variable simulations can be conducted in two ways: (a) directly simulated in BIM and then extracted to IFC as an input to the integration workflow, or (b) assessed from IFC elements during the transformation and the mapping process from BIM to CIM.

(2)

Outdoor variables: outdoors variables are simulated after the retrieval step and when the transformation workflow from BIM to CIM is achieved. This process is required if further geospatial queries are needed to assess the final variable value at the level of information need. This can be achieved through storing the retrieved information into a 3D database and then executing queries for information extraction or through further processing by using for example 3D geospatial analysis.

(3)

Interactive variables: these variables simulation can be sourced from indoor quality variables, such as the indoor daylight, indoor air quality and indoor noise and impacted by the outdoor built environment, such as the surrounding building amenities (building elevation, etc.). For example, indoor daylight is determined based on building requirements such as room physical boundaries, building thermal properties, and the simulation of the amount daylight assessed from windows and the sun position.

4. Study Case

The study case aims to demonstrate the feasibility of our proposed workflow for simulating 3D property variables. We tested and validated how to simulate and model two property valuation variables: indoor spatial daylight and property unit cost. We chose a residential building composed of multi-property units for which a BIM model has been created.

Beyond the technical aspect of data integration, we attempt to prove the feasibility of using IFC and CityGML to extract the level of information needed to assess property valuation variables. Figure 6 summarizes the study case framework.

Numerous studies have underscored the pivotal role of property unit cost and indoor daylight as influential factors in property valuation. For instance, research has delved into the impact of property unit cost, demonstrating that the choice of building construction materials significantly affects property value. Buildings constructed with superior materials not only tend to incur lower maintenance costs but also boast reduced energy consumption, leading to potential savings [48].

Similarly, indoor variables, particularly indoor daylight within residential buildings, have emerged as noteworthy determinants of property valuation. Researchers such as Li and Chen [49] have stressed the importance of properties that are naturally illuminated. Such features contribute to reduced energy consumption and lower operational costs. Recent investigations have gone further to explore the profound influence of energy performance on the quality of life for occupants. While these studies did not rely on 3D simulations but rather conducted interviews with residents across various property story levels, the findings elucidate a clear trend: properties with ample natural daylight tend to be preferred over their counterparts within the same building [50].

Another energy-related variable of significance is a building’s solar potential. As illustrated in the work of Helbich et Jochem [51], varying levels of sunlight exposure impact individual property units. Their research established a positive correlation between solar radiation and residential property value, as higher solar potential translates into reduced energy consumption and heightened property value. Properties equipped with abundant roof solar potential, in particular, command higher market values.

Furthermore, it is crucial to acknowledge that indoor living quality exhibits considerable disparities across different apartment units within buildings. For instance, findings presented by Turan [48] suggest that floors characterized by abundant daylight illumination can increase property values by a notable 5% to 6%.

These insights collectively underscore the paramount importance of considering property unit cost and indoor daylight as pivotal variables with substantial impact on property valuation.

4.1. Variables Specifications

In the previous sections, we classified the property valuation requirements according to the LoIN specifications and determined how each requirement can be extracted, either from an IFC entity, attribute, or an additional “Property Set,” or enriched from IFC to CityGML, or mapped to a CityGML class or class’s attributes. These choices are elaborated upon in greater detail in the following section.

This subsection discusses the LoIN specifications for each variable, which include both geometric and semantic requirements as well as the data models used to source the specifications (IFC LoIN, CityGML 3.0 classes, and external data formats).

Table 2. Variables specifications levels for property unit cost, indoor daylight variables and property unit.

Variable Specifications Levels	Input Property Valuation Requirements		Data Models Integration Specifications
	Geometric Specifications	Semantic Specifications	IFC LoIN	Citygml 3.0/ Classes	External Data Format
Property unit (PU)	- sweep volume: for property unit boundaries - solid: for building elements composing the property unit	- PU Area; Volume - PU Name; Number - PU materials and building elements type and installations	From class: IfcSpace IfcBuildingStorey IfcSlab, IfcColumn IfcMember IfcWall Attributes: Area, volume, number, Item Cost Property sets Pset_Materials Quantities PSet_Cost InstallationsType	To class: building unit constructive element Attributes +Area; +Volume, +PropertyUnitName; +PropertyUnitNumber +PropertyUnitelementstype	- 2D conceptual plans
Property unit cost	- Materials quantities (thickness, width, height) (solid in IFC) B-Rep: for building elements converted to CityGML	- Building cost at the level of apartment (mapping)	From class: IfcSlab, IfcColumn IfcMember IfcWall IfcbuildingStorey (composition Type: Partial) Attributes: IfcMaterial Property sets PSet_Cost	To class building Parts/building unit Attributes +Property Unit Cost	- Cost items and material types - Construction materials categories and families
	- Property unit boundaries (B-rep)	Materials type
Indoor Daylight	- Room’s physical space 3D (B-rep) - Openings size - Openings location	- Thermal properties (from BIM) Spatial Daylight	From IfcSpace or IfcZone Attributes IfcThermalTransmittance	To Bldg.: room Bldg: Building parts +Attributes - Indoor daylight value - Indoor Daylight quality	Climate data
	- Property unit physical boundaries (B-rep)	autonomy (attribute) (extraction)			Building thermal properties

summarizes the specifications required for determining the generic feature of a property unit (LoIN-1) and assessing two specific variables (property unit cost and indoor daylight) (LoIN-2).

4.2. Retrievals Levels and Assessement

An algorithm was developed to convert the chosen variables (property unit cost and indoor daylight) from IFC to CityGML by retrieving the necessary information from the former and performing geometrical and semantic mapping.

All data transformations and algorithms in this study case were performed using the software “Feature Manipulation Engine” (FME version 2022.2). Property valuation requirements from different formats was imported into FME using “Readers” and the relevant attributes and entities were selected and extracted, mainly form IFC format in our approach, and then transformed using “Transformers”. After the translation, the newly generated output was exported to CityGML 3.0.

Since FME cannot recognize the last version of CityGML 3.0, we had to add the CityGML required classes by importing the “GML” schema of the Building core classes to FME, specifically “Building”, “BuildingConstructiveElements”, “Room”, “BuildingParts”, and “BuildingUnit’’.

It is also essential to mention that the IFC file needed to be georeferenced before it was imported to FME. Storing the georeferencing properly is a compulsory step, without which it is impossible to proceed to the integration with the city context for simulating outdoors variables. Therefore, the IFC file was georeferenced according to the approximate address specifications. Otherwise, in the best scenario, the coordinate system should be specified during the building modeling [19].

During the data integration process, we needed to check and visualize the mapping results by using “FME inspector “and the “FZK viewer”. In the next subsections, we describe the integration process we performed to retrieve variables either indirectly (property unit cost) or directly (the indoor daylight).

4.2.1. Property Unit Cost

In order to retrieve property unit cost specifications, a two-step conversion process was employed during the IFC-CityGML integration: BIM2IFC and IFC2CityGML.

• BIM2IFC: the necessary features and attributes were extracted at the building model level and exported to IFC. These extracted requirements for cost can be classified as entities/classes (such as IfcBuildingStorey, IfcWall, IfcSlab, IfcColumn, and IfcMember), attributes (including material quantities, thickness and type), and Property Sets (defined as newly assessed attributes, in this case the calculated cost of building elements as shown in Figure 7).

• IFC2CityGML: the first approach of this conversion process involves retrieving the property unit cost requirements by mapping them to CityGML classes through a transformation algorithm. The property cost variable comprises spatial and non-spatial elements, which can be obtained from the IFC file’s four main separate classes composing the building elements. To determine the cost estimation of the property unit, input information is required at the level of small building parts elements, such as materials quantities and cost, which can be extracted from IFC entities such as ifcBeam, ifcwall, ifcmember, and IfcSlab. However, to extract the spatial extent of the property physical boundaries and determine the building cost at the level of CityGML BuildingConstructiveElement and the whole Building cost, the data from wall, slab column elements, etc., need to be merged geometrically and semantically to the level of the building parts extent.

The second approach involves structuring the building floor to model building property units based on the building constructive elements boundaries for each floor, which enables the extraction of building elements, materials quantities, and cost at the level of the property unit boundaries. The IFC schema allows spatially grouping building elements within the same floor into one group of building units, making it possible to extract the necessary information.

To store the property cost in CityGML classes, it is first stored in the BuildingConstructiveElement class and then stored in the BuildingUnit class by hierarchy as an attribute. The geometry conversion is conducted using a customized ConvertGeometry tool that converts the hierarchical solid geometries present in the IFC file to composite surfaces of CityGML. The semantics conversion is carried out using an Attribute Manager tool that matches the attribute from IFC to the CityGML corresponding class and attribute, deletes the unrequired attribute for the ifcbuilding elements, and defines their type, such as cost estimation (valuetype: integer).

The conversion process faces two main limitations: (1) the need for a suitable method to extract the cost from the different IFC classes, and (2) the inadequacies of the IFC and CityGML classes for storing data at the building unit level. These limitations justify the need to create a new element in the CityGML schema called the Property Unit class.

4.2.2. Indoor Daylight

In this section, we aim to transform indoor daylight information from IFC spaces to CityGML3.0 building units. To achieve this, we first simulated indoor daylight using the Insights plugin in Revit and BIM software. We used various input data, including climate data, building location, glazing materials, and thermal properties to assess the value of the variable.

Indoor daylight specifications are retrieved directly during the conversion stage from ifc2citygml 3.0 (Figure 8) through a simulation in BIM software and then retrieved from IFC to CityGML ADE.

We chose Spatial Daylight Autonomy (SDA) as the primary factor to evaluate indoor daylight. SDA measures the percentage of the floor area of a property unit that receives sufficient natural light, and the values are represented as a rate from 0% to 100%. The SDA value of 75% is the preferable natural sunlight by property occupants, while a value between 55% to 75% means that the indoor space daylight is “acceptable.” However, when the value is under 55%, artificial lighting is necessary.

The variable attribute “IndoorDaylightQuality” was assessed based on the spatial distribution of illuminance levels in each floor area. The researchers used the SDA value for each building floor level to determine the existing definition-based energy performance. The results were spatially visualized in BIM software and stored as an attribute [7].

To map the indoor daylight from “Ifcspace” to CityGML “Building::Room,” the Room class needed to be extended with the indoor daylight attribute (Figure 8). We used FME transformers to store the variables, which consisted of three steps: “Expose Attribute,” “Convert geometry,” and “Attribute manager” [42]. These transformers were used to extract hidden IFC features and property sets, convert geometry, and create the correct CityGML hierarchy. Finally, we used the “AttributeManager” to create a new attribute in the BuildingRoom class named “IndoorDaylight” and its value type (see Figure 9).

5. Discussion

In this paper, we proposed a data integration approach based on BIM and CIM for a property valuation purpose. A deep analysis of variables requirements in terms of Level of Information Need was supported by a case study addressing the simulation case of two variables (cost and indoor day light).

The proposed workflow addressed the potential problems and errors that can arise during the transformation process between IFC and CityGML.

Based on the results, we recommend some guidelines and recommendations to be considered when dealing with IFC-CityGML conversion in the context of property valuation to allow accurate simulations.

The section also highlights the need for a validator tool to test the transformation process and validate the resulting data and suggests expanding the methodology to incorporate outdoor and interactive variables for a more comprehensive property valuation.

5.1. Validator Tool Recommendation

The process of transforming indoor daylight information from IFC spaces to CityGML Building units can lead to a number of geometric and semantic errors. These errors can result in data loss or incorrect data during the transformation process. To minimize these errors, it is recommended to carefully validate the original IFC model and ensure that it adheres to the requirements of the CityGML standard. In addition, future works should develop a check validator tool for Propertyvaluation LoIN through the proposed workflow approach. This tool will help to thoroughly test the transformation process and validate the resulting data to ensure that it is accurate and complete. Such a tool is necessary to ensure the reliability of the data integration process and to avoid errors that may impact the accuracy of property valuation results.

5.2. Software’s and Technologies’ Limitations

Using the latest version of CityGML 3.0 raises some limitations, such as SQL encoding and a lack of software support for CityGML ADEs, since it is still under development. However, our approach has the advantage of being generic and able to define the necessary information for each valuation variable specification, regardless of the standard version or technology used. Future investigations could be carried out on the CityJSON data model, which is aligned with the CityGML 3.0 schema, but it should be noted that it is not yet compliant with FME software.

5.3. BIM Modeling Requirements

We recommend guidelines to follow during the modeling stage to overcome the difficulty of obtaining specific requirements for valuation purposes at the BIM stage. One guideline is to group all building floor units into specific groups for practical export of property unit building elements for each apartment to the IFC file. This can help avoid a time-consuming extraction process. Another guideline is to specify thermal zones for simulating indoor daylight variables so they can be exported to the IfcZone for the simulation space of the property unit. Lastly, the cost for each building element entity needs to be integrated and delivered by the construction stakeholders to allow an accurate simulation of the whole building cost.

5.4. Method Generalization

In a boarder perspective, to incorporate outdoor and interactive variables into our proposed approach, additional specifications and data sources need to be identified and integrated into the workflow. For outdoor variables like view quality and noise level, the specifications and data sources can be identified. Some required data need to be retrieved from external data sources, such as digital elevation models or noise maps.

The incorporation of outdoor and interactive variables into the workflow would require additional data sources, specifications, and assessment methods, but it could result in a more comprehensive and accurate assessment of the property unit’s value. Developing a specific simulation model for interactive variables such as indoor daylight and outdoor sunlight exposure would be necessary, which could consider the building’s geometry and materials, as well as the surrounding outdoor environment. BIM and city models, as well as external data sources such as weather data and solar radiation models, could be used as data sources.

The results of the study demonstrate that the proposed workflow is both feasible and reliable. The study’s focus is specifically on two variables: property unit cost and indoor daylight. It demonstrates how these variables can be simulated using a schema mapping process between IFC and CityGML. The process involves defining the specifications for the variables from both IFC and CityGML in terms of LoIN and using an effective conversion process to extract the specifications from both IFC and CityGML.

This methodology can be applied to other variables beyond property unit cost and indoor daylight, as demonstrated by the study’s findings.

6. Conclusions

In this paper, we have proposed a generic workflow for supporting data integration in property valuation based on IFC and CityGML 3.0. We presented a coherent approach for data integration, which involved identifying specific requirements for valuation variables based on the LoIN. We mapped these requirements for both IFC and CityGML and proposed a structured approach for specifying the needed features, attributes, and property sets. We also proposed simulation approaches for all variables during the retrieval process.

Our proposed workflow was applied to a case study, where we successfully assessed two variables: indoor daylight and property unit cost. We defined and tested the specification levels for these variables and structured them as follows: Property Unit as a new feature class, and Indoor Daylight and Property Unit Cost as property unit attributes. We discussed the potential of our method and the results of the case study and highlighted some technical limitations.

It is important to acknowledge that our study case focuses on a subset of required in property valuation process. However, our proposed approach, when implemented as outlined, has the potential to mitigate valuation uncertainty by systematically integrating these data aspects. It is important to recognize that property valuation is complex process influenced by a multitude of factors (environmental, urbanistic, financial, social, and legal). While our approach focuses on 3D data to enhances accuracy and comprehensiveness through structured data integration, it is essential to remember that the estimated property value is inherently shaped by property markets.

In the IFC-CityGML data integration process, we found that a one-to-one mapping from IFC to CityGML classes/attributes was possible, allowing us to extract requirements and structure them hierarchically in the two models. However, this is not an automatic process, as some features require manual acquisition or substantial processing. Recent work has investigated the automatic extraction of building features from IFC models using IfcOpenShell, such as the detection of apartments [52], which may address some of the complexity and issues with the IFC model.

To enhance our approach, we plan to test our workflow with further outdoor variables to improve the specification levels for outdoor requirements and prove the feasibility of our approach. We also aim to propose a 3D property valuation extension and its implementation as a CityGML ADE, while addressing the limitations of SQL encoding in CityGML 3.0. Then, we plan to investigate the adaptability of our generic model to other data models such as CityJSON.

Finally, our proposed workflow offers a valuable contribution to property valuation by providing a structured approach for data integration that enhances accuracy and comprehensiveness. Our findings suggest that additional work is required to integrate other variables’ data requirements into the proposed workflow.