buildings

: CityGML (City Geography Markup Language) is the most investigated standard in the integration of building information modeling (BIM) and the geographic information system (GIS), and it is essential for digital twin and smart city applications. The new CityGML 3.0 has been released for a while, but it is still not clear whether its new features bring new challenges or opportunities to this research topic. Therefore, the aim of this study is to understand the state of the art of CityGML in BIM/GIS integration and to investigate the potential inﬂuence of CityGML3.0 on BIM/GIS integration. To achieve this aim, this study used a systematic literature review approach. In total, 136 papers from Web of Science (WoS) and Scopus were collected, reviewed, and analyzed. The main ﬁndings of this review are as follows: (1) There are several challenging problems in the IFC-to-CityGML conversion, including LoD (Level of Detail) mapping, solid-to-surface conversion, and semantic mapping. (2) The ‘space’ concept and the new LoD concept in CityGML 3.0 can bring new opportunities to LoD mapping and solid-to-surface conversion. (3) The Versioning module and the Dynamizer module can add dynamic semantics to the CityGML. (4) Graph techniques and scan-to-BIM offer new perspectives for facilitating the use of CityGML in BIM/GIS integration. These ﬁndings can further facilitate theoretical studies on BIM/GIS integration.


are shown in Fi The first step w
s to determine the research objectives.Before exploring the s the art of CityGML in BIM/GIS integration, it is necessary to understand the pro The first step was to determine the research objectives.Before exploring the state of the art of CityGML in BIM/GIS integration, it is necessary to understand the process of BIM/GIS integration.IFC and CityGML are two international standards in their respective domains, and BIM-to-GIS is a mainstream integration pattern.Therefore, we choose IFC-to-CityGML conversion as an example to illustrate the process of BIM/GIS integration, with a focus on the data perspective.In this study, CityGML serves as the destination of the information flow in BIM/GIS integration.Furthermore, considering that the OGC recently updated the version of CityGML, it is important to analyze the changes between the old and new versions and their impact on BIM/GIS integration.Additionally, the emergence o other technological approaches has also influenced the role of CityGML in BIM/GIS integration, making them relevant to our research object.

The second step was to retrieve relevant papers.The search engines, e.g., Web of Science (WoS) and Scopus, were used for collecting the literature.As BIM/GIS integration is a relatively new res

rc
field, a time limit was not considered.The keywords used for collecting the literature included "BIM"

"
uilding information model" or "building information modeling" a

"
IS" or "geographic information system".Accordingly, a

otal of 260
rticles were identified from Web of Science (WoS), and 797 articles were identified from Scopus using the article title, abstract, and keywords as the search criteria.As the focus of this study is on IFC-to-CityGML conversion, the keywords "IFC" or "industry foundation class" and "CityGML" were used to acquire additional literature, and 45 articles were identified from WoS, and 153 articles were identified from Scopus.

The third step was to screen the retrieved papers.In total, 1255 articles were collected, and the paper screening process included (1) removing duplicate articles and (2) checking the titles, abstracts, and keywords of the remaining articles to filter out irrelevant articles, i.e., those that do not focus on the research topic, such as studies on BIM/GIS integration at the process level or application level.

Eventually, 110 articles were retai ed for close examination.Of these, there were 81 journal papers, 19 conference papers, and 10 book chapters.Based on the statistical analysis conducted in this study, a list of representative publication sources is presented.Among the journal papers, the journal Automation in Construction had the highest number of articles with 14 papers.The next highest was the ISPRS International Journal of Geo-Information with 11 papers, followed by International Journal of Geographical Information Science with 5 papers, and Computers, Environment and Urban Systems with 4 papers.Among the conference papers, ISPRS Annals of Ph

ogrammetry, Remote Sensing and Spatial Inform
tion Sciences had 5 papers.In the book chapters 3D Geoinformation Science and Advances in 3D Geo-Information Sciences, each had three papers.The subsequent research will be based on these 110 articles for further discussion.


CityGML and Its Influence on BIM/GIS Integration


CityGML Overview

CityGML is an open model based on XML (Extensible Markup Language), which is an international standard for storing and exchanging virtual 3D city models.CityGML was developed to define a virtual 3D city od l that enables information sharing and exchange among different application domains, facilitates

su
lization, and supports complex spatial analysis.In 2002, the Sp

ia
Interest Group 3D (SIG 3D) started working on the de

lopment of C
tyGML.In 2008, CityGML 1.0 became an OGC standard and has since been adopted by many cities worldwide.CityGML also played a significant role in the establishment of 3D geoinformation standards and infrastructure [33].In 2012, CityGML 2.0 was adopted as an OGC (Open Geospatial Consortium) standard [34] and introduced two new theme modules, i.e., the Bridges and Tunnels module.In 2020, OGC released the CityGML 3.0 Conceptual Model Standard [35], but the CityGML 3.0 Encoding Standard has not yet been released.

As most previous studies focused on CityGML 2.0, the research on CityGML 3.0 is limited.Additionally, some of the key concepts in CityGML remain unchanged.This section describes the features and applications of CityGML 2.0, while the differences between CityGML 3.0 and 2.0 will be highlighted in Section 6.


General Characteristics of CityGML

The key characteristics are as follows:

(1) The CityGML data model is divided into a core module and a theme extension module according to theme (see Section 3.1.2for details).

(2) The CityGML model supports different levels of detail (LoD), allowing an object to be represented in different LoDs suitable for analysis and visualization purposes (see Section 3.1.3for details).

(3) The model consists of two hierarchies: the semantic layer and the geometric layer, and corre ponding objects are connected by relationships to ensure consistency between semantics and geometry (see Section 3.1.4for details).(4) Objects that are not modeled as closed entities (e.g., tunnels, pedestrian underpasses, and underground parking) can be virtually sealed by using a ClosureSurface to calculate their volume, which is beneficial for flood simulation.(5) The concept of TerrainIntersectionCurve has been introduced to place 3D objects at the correct position in the digital terrain model, thus preventing buildings from floating or sinking into the terrain [36].(6) ExternalReference is used to reference external datasets.(7) The Cityobjectgroup module in CityGML allows users to aggregate city objects based on their own criteria and to represent and transfer these aggregated objects as part of a city model.(8) CityGML supports the representation of a pearance features of city models, such as materials and textures, making 3D city models more realistic.(9) For spatial objects with the same shape, such as trees and other vegetation objects, traffic lights and signs, and city furniture, a prototype is modeled, and then matrix transformations (scaling, rotation, and translation) are applied to enable these objects to be reused at different locations in the cit model.(10) The Generics module and Application Domain Extension (ADE) can be used to extend CityGML with objects and object attributes that are not defined in the standard (see Sections 3.1.5and 5.2.1 for details).


Modularization

The 3D city model contains all relevant entities of the city, and CityGML is divided into a core module and 13 thematic extension modules.The core module is a generic module that defines the basic concepts and components of the CityGML model and can be referenced by all theme extension modules.Thematic extension modules are divided according to the specific information required by many different application areas and are independent of each other.

The main purpose of modularization is to represent only the relevant thematic modules in specific applications.Thus, the core module can be combined with related thematic extension modules to avoid running a redundant CityGML model that includes al

rts the represent
tion of features with different levels of detail (LoDs), providing users with more choices.The same object can be represented with different LoDs simultaneously, making it possible to analyze and visualize the same object at different resolutions.However, representing objects in the same LoD is beneficial for integration and interoperability.

The explanation of LoD is as follows (see Figure 2): • LoD0 is a 2.5D digital terrain model onto which aerial images or maps can be draped [37].Buildings in LoD0 can be represented by 2.5D polygons of footprint height or roof height [20].


•

Buildings in LoD1 are represented by block models, including prismatic buildings with flat roofs.• LoD0 is a 2.5D digital terrain model onto which aerial images or maps can be draped [37].Buildings in LoD0 can be represented by 2.5D polygons of footprint height or roof height [20].


•

Buildings in LoD1 are represented by block models, including prismatic buildings with lat roofs.


•

Buildings in LoD2 can be represented with different roof structures and boundary surfaces of different themes.In fact, LoD2 is the most commonly used level of detail in cities and city areas.LoD2 can represent the general shape of objects with low complexity, so it is widely used in energy ana

sis.Some examples of its use includ
in heating demand simulation [38], sola potential estimation [39], 3D noise mapping [40], photovoltaic potentiality analysis [41], and urban planning [42].


•

LoD3 is the most detailed level of detail to represent exterior features.Doors and windows can be represented by "openings" and buildings have detailed wall and roof structures such as skylights and chimneys.


•

LoD4 is nearly identical to LoD3 in exterior features and adds interior features to the buildings, such as rooms, indoor doors, stairs, and furniture.Thus, LoD4 models are typically used for indoor navigation [43].

The 3D city model of CityGML contains multiple modules such as buildings, water bodies, vegetation, transportation, etc., resulting in a large amount of data storage.CityGML defines different levels of detail to reduce software and hardware difficulties in displaying large amounts of city data [44].By adjusting the parameters and by using different levels of detail, the complexity of representing the geometry of objects can be reduced [45].Users can also choose different levels of detail to reduce the rendering power [46].


Coherent Semantical-Geometrical Modeling

Geometric information represents the shape, size, and position of physical objects, which is one of the basic elements for visualization [47].Semantic information represents the material, function, and other attributes of physical objects, which can be used not only for visualization but also for complex spatial analysis [15].CityGML is the first GIS model that supports rich semantic information [20], which distinguishes it from 3D graphic and virtual reality models and may allow it to achieve better benefits [26].

The CityGML model consists of a geometric layer and a semantic layer.If a specific object ex

ts in both hier
rchies, it is connected through relationships to form geometricsemantic consistency.For example, if a wall of a building has two windows and a door at the semantic level, the geometric representation of the wall must also contain the geometry of the windows and the door.The advantage of this approach is that it allows arbitrary navigation in both hierarchies as well as between them, supporting data integration as well as spatial semantic query and an lysis [48].


ADE (Application Domain Extension)

CityGML supports the Application Domain Extension (ADE) extension mechanism to define new object types to existing CityGML models or to introduce new attributes to existing CityGML object types.The advantage of thi

approach is that the e
tension is formally specified.The extended CityGML instance document can be validated against CityGML and the corresponding ADE schema.Multiple ADEs can be used in the same dataset, and an ADE can extend multiple modules simultaneously.


IFC-to-CityGML Conversion

The integration of BIM and the GIS can be divided into three levels: data level, process level, and application evel [12,49].The integration between the two systems largely depends on data integration [47].The main task of BIM-to-GIS is geometric conversion and semantic mapping.IFC and CityGML are the international standards in the architecture, engineering, and construction (AEC) industry and the geospatial industry, respectively.IFC is an open-data model proposed by BuildingSMART to facilitate information sharing in the architecture, engineering, and construction (AEC) industry.IFC-to-CityGML conversion is the most common method of data integration [18], and the process is shown in Figure 3.

sharing in the architecture, engineering, and construction (AEC) industry.IFC-to-CityGML conversion is the most common method of data integration [18], and the process is shown in Figure 3.

First, the text-based IFC file is parsed into an object model.Then, the semantic and geometric information in the IFC object model is processed separately and converted to the CityGML model.This process is called geometric conversion and semantic mapping.Finally, the IFC object model is successfully converted to the CityGML model.

Current research on IFC-to-CityGML conversion focuses on realizing automatic conversion, saving time, reducing errors caused by manual conversion, and realizing lossless semantic mapping.Details will be elaborated in a later section.


Task of Geometric Conversion

The challenges in geometric conversion arise from the differences in data models, coordinate systems, geometric representations, and level of detail between IFC and City ML.The processing of geometric conversion includes representation conversion, coordinate transformation, geo-referencing, representation transformation (solid to surface), and LoD mapping.

Representation conversion refers to the conversion of implicit models into explicit models.Swept solid and constructive solid geometry (CSG) belong to implicit models, which are models created by parameterized modeling methods, with only the parameters of the model being stored.Boundary representation (B-Rep) belongs to the explicit model,

ich is represented by visible points [50]
From the BIM side, both the implicit models First, the text-based IFC file is parsed into an object model.Then, the semantic and geometric information in the IFC object model is processed separately and converted to the CityGML model.This process is called geometric conversion and semantic mapping.Finally, the IFC object model is successfully converted to the CityGML model.

Current research on IFC-to-CityGML conversion focuses on realizing automatic conversion, saving time, reducing errors caused by manual conversion and realizing lossless semantic mapping.Details will be elaborated in a later section.


Task of Geometric Conversion

The challenges in geometric conversion arise from the differences in data models, coordinate systems, geometric representations, and level of detail between IFC and CityGML.The processing of geometric conversion includes representation conversion, coordinate transformation, geo-referencing, representation transformation (solid to surface), and LoD mapping.

Representation conversion refers to the conversion of implicit models into explicit models.Swept sol

and constructive solid geometry (C
G) belong to implicit models, which are models created by parameterized modeling methods, with only the parameters of the model being stored.Boundary representation (B-Rep) belongs to the explicit model, which is represented by visible points [50].From the BIM side, both the implicit models and the explicit model can be modeled in IFC.The GIS has limited support for parametric models [51], so explicit models are used for visualization in CityGML.

Coordinate system transform

ion is the transformation
f the local coordinate system to the global coordinate system.IFC adopts the local coordinate system [52], i.e., the local coordinate system of an object refers to the local coordinate system of the relative object.In contrast, CityGML uses the global coordinate system to represent the position and orientation of objects relative to the Earth's surface or to other global reference systems.

Geo-referencing is the process of converting the global coordinate system to the geodetic coordinate system.Through coordinate system transformation, the local coordinate system in IFC is transformed into the global coordinate system.However, IFC uses a 3D Cartesian coordinate system [53], which represents coordin tes in the form of X, Y, and Z. CityGML uses the geodetic coordinate system, which represents coordinates in the form of latitude, longitude, and altitude.To associate building models with th ir surrounding geospatial environment, geo-referencing transforms the 3D Cartesian coordinate system to the geodetic coordinate system.

Representation transformation (solid to surface) refers to the conversion of solid models into surface models.IFC is a solid model, and its geometric representation usually uses boundary representation (B-Rep) [54] and swept-solid [55] and constructive-solid geometry (CSG) [56], which can be used separately or in any combination for geometric representation.B-Rep represents an IFC entity as an enclosed bounding box.Swept solid defi

s an IFC entity by a 2D profi
e and a sweeping path.Constructive-solid geometry generates an IFC entity by Boolean operations on primitive geometric entities.CityGML is a surface model that only expresses the surface of an object, and its geometric representation is B-Rep.There is a difference in the geometric representation between B-Rep in CityGML and B-Rep in IFC.In IFC, a wall is rep esented as an enclosed bounding box by six wall surfaces.In contrast, in CityGML, a wall is represented only by the visible wall surfaces, such as InteriorWallSurface and ExteriorWallSurface.

LoD mapping is used to map the IFC model to the CityGML model in different LoDs.Although IFC also defines five levels of development (LODs), they do not match the levels of detail (LoDs) defined in CityGML.Moreover, there is no complete transformation framework between LoDs in CityGML.Therefore, LoD mapping is necessary to convert IFC models to different CityGML LoDs.


Task of Semantic Mapping

Semantic mapping is the mapping of element types, relationships, and attributes from the IFC object model to the CityGML model.IFC uses classes to manage all things.It defines t e objects associated with construction activities, the attributes of these objects, and the relationships between the classes.Similarly, CityGML defines the basic entities, attributes, and relations in the 3D city model.

IFC is based

the EXPRESS data modeling la
guage, while CityGML is based on XML.In order to perform semantic mapping between these two standards, they need to be parsed using respective parsers that can understand their respective syntax and semantics.The IFC parser will parse IFC files, extracting the object types, relationships, and attributes defined in the EXPRESS schema.Similarly, the CityGML pa ser will parse CityGML files, understanding the XML structure and extracting the relevant information from the tags and attributes defined in the CityGML schema.

Semantic mapping can be divided into class mapping, attributes mapping, and relationship mapping [18].

There are about 800 classes in IFC4, but only 60-70 of them are related to geospatial information, and de Laat and van Berlo [57] have identified only 17 classes that can be mapped to CityGML.Class mapping adopts three mapping methods [58].One-to-one mapping refers to the direct mapping from IFC to CityGML; for example, IfcD or can be directly mapped to Door in CityGML, and IfcWindow can be directly mapped to Window in CityGML.One-to-many mapping (or many-to-one mapping) means that an IFC class can be mapped to multiple CityGML classes, according to the surface normal direction of the IFC entity.For example, IfcSlab can be mapped to OuterFloorSurface when the surface normal is up, to WallSurface when the surface normal is horizontal, and to OuterCeilingSurface when th surface normal is down.Alternatively, multiple IFC classes can be mapped to a single CityGML class, such as IfcColumn, IfcBeam, and IfcStair, which are all mapped to BuildingInstallation or IntBuildingInstallation in CityGML.Indirect mapping refers to situations where the IFC class cannot be directly mapped to CityGML and that require geometric operations based on the results of one-to-one and one-to-many mappings.

During the process of semantic mapping, it is necessary not only to map IFC classes to CityGML entities but also to map the properties and relationships of the classes.Taking the mapping of IfcWindow to the Window entity in Ci yGML as an example, the properties of IfcWindow (such as thickness, material, etc.) need to be mapped to the corresponding properties of the Window entity in CityGML.This ensures that the converted CityGML model can retain and represent the relevant attributes of Window.Additionally, it is important to map the relationships between IfcWindow and other classes (such as Ifcwalls and IfcOpeningElement) [59] to the Window entity in CityGML.This ensures that the converted CityGML model accurately represents the associations between Window, Walls, and Opening.If the corresponding semantic information for the IFC model is not available in CityGML, the Generics module and the ADE extension mechanism can be applied.


The Current State of Geometric Conversion


The Progress in Geometry Conversion

Several commercial tools are available that can handle geometric conversion to some extent, such as BIMServer [60] and IfcExplorer [61], which can perform geometric conversions but lack semantic mapping capabilities, and FME [62 (Feature Manipulation Engine), which supports both geometric conversion and semantic mapping.However, it should be noted that these tools may not achieve complete IFC-to-CityGML conversion in practical applications.

Overall, progress has been made in geometric conversion, with a variety of tools and techniques available to handle representation conversion and coordinate

ystem transformation.Cust
mized algorithms [6] or existing software packages [63] can be utilized for representation conversion.Customized algorithms offer flexibility but tend to have lower efficiency, higher error rates, and increased cost.Existing software packages, on the other hand, offer higher efficiency and robustness but may lack the ability to be adjusted according to specific requirements [18].Coordinate system tr nsformation involves the conversion of the local coordinate system to a global coordinate system by obtaining a transformation matrix based on IfcLocalPlacement [64].

However, geo-referencing still requires further improvement.On the BIM side, BIM models allow for the input of geo-referencing information, [65][66][67][68], but in practical use, this is often overlooked [50].The existing geo-referencing algorithms mainly include affine transformation [69][70][71], similarity transformation [72] (which is a type of affine parametric transformation), and projective t ansformation [46,73].The manual methods are timeconsuming and labor-intensive, while the automatic geo- eferencing accuracy of BIM on the GIS maps has reached between centimeters to sub-meters [74].


LoD Conversion 4.2.1. The Solid-to-Surface Conversion

In the process of geometric conversion, the solid-to-surface conversion is a crucial task that involves extracting the exterior surfaces of objects.Various algorithms have been proposed to achieve this conversion, but they are prone to errors.Researchers are continually exploring and improving the efficiency and accuracy of algorithms for solid-tosurface conversion.

Fan et al. [75] proposed an algorithm that automatically extracts the exterior surfaces of a building by calculating the distance from the surface to the center of the building.However, this method is not suitable for buildings with non-convex envelopes.Deng et al. [46] proposed an algorithm that can automatically extract the exterior surfaces of buildings with complex envelope structures.However, it suffers from low productivity.Kang and Hong [64] proposed a Screen-Buffer scanning-based Multiprocessing (SB-MP) LoD generation algorithm, which significantly improves the computation efficiency in extracting the exterior surfaces.To address errors in the IFC model, such as chi neys penetrating the exterior of buildings and small gaps between roof slabs and walls, Donkers et al. [50] proposed an algorithm for extracting the outer surface of buildings, effectively repairing these issues.Zhou et al. [76] presented an outline detection algorithm, OutDet, to extract the exterior surfaces of a building information model.


LoD Mapping

LoD mapping involves two processes: defining mapping rules and generating models.

Firstly, defining mapping rules refers to determining which objects should appear in specific LoDs.Taking buildings as an example [77], initial ideas have been defined for generating different CityGML LoDs from IFC models, aiming to use IFC models to automatically generate buildings in CityGML.For example, by referencing IfcWall and IfcSlab, a CityGML LoD1 building model can be generated by obtaining the footprint area and roof height [78].A CityGML LoD2 building model can be generated on the basis of

point cloud of the building roof th
ough an unmanned aerial vehicle (UAV) [79].In subsequent research [46,69], semantic mapping rules have been defined in advance.

The next step is to generate different CityGML LoD objects from IFC objects.There are two patterns for this.One is to generate a LoD1-4 model separate to the IFC model [50], which provides greater flexibility and customization, as each LoD can be generated according to specific requirements and limitations.This metho also makes it easier to manage and update the model, as each LoD can be independently generated and maintained.The other involves generating a LoD4 model from the IFC model, and then generating LoD3, LoD2, and LoD1 models in turns [46,80].This method can be more efficient in terms of processing time and storage space, as higher LoDs can serve as the basis for generating lower LODs.


The Current State in Semantics Transfer


Semantics Transfer in IFC-to-CityGML: Class Mapping

Semantic mapping requires the construction of mapping rules for classes and their relationships and properties.There may be differences in data models and semantics across different domains and standards.Building mapping rules require a deep understanding and familiarity wit the data models, specifications, and standards of both domains.It involves comparing and analyzing the differences and similarities between IFC and CityGML to determine the corresponding classes, relationships, and properties.The knowledge and expertise of experts in both domains play a crucial role in identifying and establishing relationships between classes.The process of semantic mapping is a time-consuming, labor-intensive, and knowledge-intensive task.

Therefore, some semi-automatic methods are proposed to improve the mapping efficiency.Cheng et al. [81] proposed the RSSMM (stop-word removal

ased semantic mapping method), w
ich uses linguistic and text-mining techniques to compare entity similarity, generate mapping candidates, and then manually map based on instances.The WHSMM (word-hashing-based semantic mapping method) has a higher accuracy in generating mapping candidates [82].However, these methods, which are based on linguistic and text-mining techniques, may ignore the matching bet een classes with dissimilar names, such as "Space" in IFC and "Room" in CityGML.In addition to improving work efficiency, the completeness of semantic mapping is another concern.By combination with the ADE method, Stouffs et al. [83] proposed the Triple Graph Grammar method to achieve complete and nearly lossless mapping.


The Current State


The Progress in Class Mapping

The IFC model provides a detailed definition of the buildings, while CityGML is a lightweight city model, and building is just one of its themes.Therefore, the CityGML data model cannot support storing all the semantic information from the IFC data model but only that of a few IFC classes, which means that a large amount of information in the IFC model will be lost during the mapping process.Furthermore, if all IFC classes are converted to CityGML, this would result in a large and complex data model.

CityGML defines the Generics and ADE mechanisms for extending the existing CityGML model to support various applications such as noise mapping [21], u

an supply an
lysis [84], immovable property taxation [85], indoor navigation [43], and cultural heritage management [86][87][88], and as the national 3D standard [89][90][91][92].According to the current research, ADE [93] is the preferred method to extend the CityGML model.ADE can be extended through an XML Schema Definition (XSD) file.Please note that UML (Unified Modeling Language) provides a standard way to visualize the design of a data model.The ADE mechanism mainly extends the semantic information of the CityGML model by adding new objects or adding new properties to existing objects in the existing standard.For example, in the Noise ADE, new objects such as buildingReflectionCorrection, buildingHabitants, and NoiseCityFurnitureSegment are added for noise pollution analysis.In the Indoor Routing and Positioning ADE, new properties are added to the existing BuildingFurniture, where obstacleType indicates whether an obstacle exists and Removable indicates whether it is movable, which is used for indoor navigation analysis [43].The Energy ADE adds a definition of building cooling system properties to CityGML [94].

A single ADE can simultaneously extend multiple CityGML themes, and the Virtual Singapore project achieved IFC-to-CityGML mapping by developing a universal ADE [91].Additionally, multiple ADEs can be used in the same dataset simultaneously.Prieto et al. [95] designed and developed three ADEs, namely the Cultural Heritage ADE, Energy Efficiency ADE, and Intervention ADE, to extend the prop

al heritage management.Egusquiza et al. [96] develop
d four specific extensions in the EFFESUS project (Energy Efficiency for EU Historic Districts' Sustainability): the Cultural Heritage ADE, Energy Performance ADE, Indicators ADE, and Dynamic ADE.

Some widely used ADEs may be adopted by the OGC as part of the CityGML standard.For example, the Tunnel ADE and Bridge ADE were adopted in CityGML 2.0.CityGML 3.0 adopted the Dynamizer ADE [97] and LoD ADE [98].However, the method of extending the CityGML through ADEs has increased the complexity of the CityGML data model [99], and cannot completely replace IFC model.


International Standards to Facilitate Class Mapping

New international standards are being developed to address the semantics mapping problem in an attempt to improve the sem ntic interoperability between BIM and the GIS [100].So far, two international standards have been developed and published by the ISO (International Organization for Standardization), including the ISO/TS 19166 [101] and the ISO/TR 23262 [102].ISO/TS 19166 was developed to address the BIM-to-GIS conceptual mapping (B2GM) problem by defining the mapping requirement, mapping framework and component, and mapping for export from one schema into another.Meanwhile, ISO/TR 23262 was designed to improve GIS/BIM interoperability by aligning the BIM standards developed by ISO/TC 59/SC 13 and the GIS standards developed by ISO/TC 211.Despite the early efforts in these international standards, their effectiveness in facilitating BIM/GIS integration is still to be validated and confirmed.Despite the early efforts in these international standards, their effectiveness in facilitating BIM/GIS integ

validated and confirmed.


Cit
GML3.0 and BIM/GIS Integration

The OGC CityGML Standard Working Group (SWG) and the Special Interest Group    CityGML 3.0 is an evolution of CityGML 1.0 and CityGML 2.0.In addition to being represented by their semantics, 3D geometry, 3D topology, and all objects now have the added feature of representing changes over time.Different spatial representations can be provided for each object (interior and exterior) in four predefined levels of detail (LoD0-3).However, upgrading to CityGML 3.0 does not impl abandoning the datasets in CityGML 1.0 and CityGML 2.0.It provides a certain degree of backward compatibility with existing CityGML implementations.The following sections focus on the new features of CityGML 3.0, including the new space concept, LoD, and dynamic data model.


Space Concept

In the CityGML 3.0 conceptual model, spatial properties have been introduced to provide semantic differentiation.All CityGML feature types are mapped onto semantic concepts of space and space boundary.The specific classification of space concept is shown in Figure 5.

The space concept can facilitate the conversion from IFC to CityGML [103].For example, a wall is represented as a volumetric object in IFC, while in CityGML 2.0, it is represented as InteriorWallSurface and ExteriorWallSurcface. To convert IFC to CityGML, these surfaces need to be identified and extracted first.In CityGML 3.0, according to the space concept, the semantics of the wall is a physical occupied space, which is represented by an object with a volumetric extent.Therefore, it allows for the direct mapping of IFC volumetric objects to CityGML volumetric objects.Similarly, IfcWall, IfcRoof, IfcBeam, and IfcSlab can also be mapped directly to spatial objects with a volumetric extent in CityGML.To some extent, the spac concept can maintain the semantic integrity of the data and ensure that the converted CityGML model accurately represents the original IFC model.

The space concept can broaden the range of applications.In the transportation field, for instance, TrafficSpace is used to represent driving lanes, cycle lanes, and sidewalks, while AuxiliaryTrafficSpace is used to represent middle lanes, green areas, and curbstones.ClearanceSpace can be defined for each traffic space; for example, in Germany, the height of the free space above roads is typically 4.5 m, and the height of the free space above sidewalks is 2.5 m.The definition of ClearanceSpace can be applied to driving dynamic simulati ns [104].Each traffic space is connected to the adjacent traffic spaces, and this information can be used for navigation systems and traffic simulations [105].In the field of indoor navigation, the space concept supports the representation of clear topological, geometric, and thematic relationships between spaces and space boundaries, and defines occupied and unoccupied s

ce.For example, a room is considered unoccupied spac
, while furniture and equipment inside a room are considered occupied space.Algorithms for analyzing the navigable space can be defined at the core module.In the land administration field, there are no cadastral data models that can simultaneously maintain 3D legal objects and physical objects [106].Currently, physical space can represent physical objects and the concept of logical space can represent legal objects in cadastral data models.This will help integrate legal and physical objects in cadastral data models.In addition, space concepts are also used for modeling underground spaces [107], such as using space to represent underground hollow spaces and geological rock layers, and using space boundaries to represent the separation surfaces between underground layers.

Buildings 2023, 13, x FOR PEER REVIEW 13 of 23


Space Concept

In the CityGML 3.0 conceptual model, spatial properties have been introduced to provide semantic differentiation.All CityGML feature types are mapped onto semantic concepts of space and space boundary.The specific classifi

tion of space concept is shown in F
gure 5.The space concept can facilitate the conversion from IFC to CityGML [103].For example, a wall is represented as a volumetric object in IFC, while in CityGML 2.0, it is represented as InteriorWallSurface and ExteriorWallSurcface. To convert IFC to CityGML, these surfaces need to be identified and extracted irst.In CityGML 3.0, according to the space concept, the semantics of the wall is a physical occupied space, which is represented by an object with a volumetric extent.Therefore, it allows for the direct mapping of IFC volumetric objects to CityGML volumetric objects.Similarly, IfcWall, IfcRoof, IfcBeam, and IfcSlab can also be mapped directly to spatial objects with a volumetric extent in CityGML.To some extent, the space concept can maintain the semantic integrity of the data and ensure that the converted CityGML model accurately represents the original IFC model.

The space concept can broaden the range of applications.In the transportation field, for instance, TrafficSpace is used to represent driving lanes, cycle lanes, and sidewalks, while AuxiliaryTrafficSpace is used to represent middle lanes, green areas, and curbstones.ClearanceSpace can be defined for each traffic space; for example, in Germany, the height of the free space above roads is typically 4.5 m, and the height of the free space above sidewalks is 2.5 m.The definition of ClearanceSpace can be applied to driving dynamic simulations [104].Each traffic space is connected to the adjacent t

ffic spaces, a
d this information can be used for navigation systems and traffic simulations [105].In the field of indoor navigation, the space concept supports the representation of clear


LoD

The LoD concept in CityGML 2.0 has limitations in practice.For example, interior features of buildings can only be represented in LoD4 [108][109][110][111]; the floor information is not supported [112,113], and the representation of doors and windows is limited to LoD3 and LoD4 [114,115].A series of modifications or extensions to the LoD concept have been proposed [98,116,117].Considering these limitations, the CityGML 3.0 concept model has revised the LoD concept.The new LoD definition is presented in Figure 6.

Buildings 2023, 13, x FOR PEER REVIEW 14 of 23 topological, geometric, and thematic relationships between spaces and space boundaries, and defines occupied and unoccupied space.For example, a room is considered unoccupied space, while furniture and equipment inside a room are considered occupied space.Algorithms for analyzing the navigable space can be defined at the core module.In the land administration field, there are no cadastral data models that c n simultaneously maintain 3D legal objects and physical objects [106].Currently, physical space can represent physical objects and the concept of logical space can represent legal objects in cadastral data models.This will help integrate legal and physical objects in cadastral data models.In addition, space concepts are also used for modeling underground spaces [107], such as using space to represent underground hollow spaces and geological rock layers, and using space boundaries to represent the separation surfaces between underground layers.


LoD

The LoD concept in CityGML 2.0 has limitations in practice.For example, interior features of buildings can only be represented in LoD4 [108][109][110][111]; the floor information is not supported [112,113], and the representation of doors and windows is limited to LoD3 and LoD4 [114,115].A series of modifications or extensions to the LoD concept have been proposed [98,116,117].Considering these limitations, the CityGML 3.0 concept model has revised the LoD concept.The new LoD definition is presented in Figure 6.LoD4 is removed from the original concept of LoD, and LoD0-LoD3 can represent all the features of the interior and exterior spaces.Considering the floor information, LoD0 represents both the interior and exterior features of a building in the form of floor plans [119].LoD1 represents both the interior and exterior features of a building in block form [120]. LoD2 represents both the interior and exterior features of a building in a general LoD4 is removed from the original concept of LoD, and LoD0-LoD3 can represent all the features of the interior and exterior spaces.Considering the floor information, LoD0 represents both the interior and exterior features of a building in the fo m of floor plans [119].LoD1 represents both the

nterior and ex
erior features of a building in block form [120]. LoD2 represents both the interior and exterior features of a building in a general shape.LoD3 has the highest level of detail, which represents both the interior and exterior features of a building in a detailed shape.It is even possible to model the exterior features of a building in LoD1 while representing the interior features in LoD2 or LoD3.The fact that all LoDs can represent both interior and exterior features implies that there is no need to pre-define semantic mapping rules before LoD mapping and simplifying 3D city models.The limitation of only being able to represent the interior features of buildings in LoD4 is resolved, making it more convenient for applications such as indoor navigation and facility management.These applications require detailed interior features and rough exterior features of buildings.Higher-level LoDs with detailed exterior features bring higher acquisition, modeling, and computational costs [98,121].The benefits of representing floor information are undeniable.For example, in fire-fighting simulations [122], the position of the hydrant cabinet in the floo can be accurately located.Also, floor information is a key influencing factor in real estate valuation [123].

In CityGML 2.0, thematic surfaces were only allowed from LoD2, and openings such as doors and windows were only allowed from LoD3.However, most open-data models are LoD2 data models [19,38,112], and the representation of openings and thematic surfaces is crucial to building energy efficiency [124][125][126].The CityGML 3.0 conceptual model breaks this limitation, and the level of detail is no longer associated with the degree of semantic decomposition of city objects but only applies to spatial representation.This means that, for example, buildings can have thematic surfaces (such as walls and floors) in both LoD0 and LoD1, and doors and windows can be represented in all LoDs

rom
oD0 to LoD3.


Dynamic Data Model

In the CityGML city model, the geometric, topological, semantic, and appearance attributes of city objects change over time.For example, buildings go through creation, destruction, reconstruction, division (splitting into several parts), merging, and modification during their entire life cycle, and some building owners may change as well [127].The planning and design of infrastructure in the city are also highly dynamic [128].The CityGML 2.0 data model is a static data model, with only the CreationDate and Termina-tionDate attributes being related to time.Increasingly, more applications require a dynamic data model with time-varying data.Therefore, according to the frequency of changes, the CityGML 3.0 introduces the Versioning module and Dynamizer module.


Versioning Module

Essentially, the Versioning module in CityGML represents slow changes in city models, including the creation and termination of objects, structural changes to objects, and changes in object states.This module enables the management of multiple versions of the city model, tracks the geometric shapes and thematic properties of single city objects over time, and can represent the history or evolution of the city model.To achieve these functions, CityGML has made some changes.

First, the concept of bitemporal timestamps is introduced by defining the class Ab-stractFeatureWithLifespan in the core module.This class has four attributes: creationDate and terminatio

ate
re used to query the appearance of the city model at a specific point in time, while validFrom and validTo can be used to query the lifespan of a specific object.

Second, in the Versioning module, two new feature types are defined: Version and Version Transition.Version explicitly defines the state of the 3D city model and represents all versions of objects belonging to this state.On one hand, using the combination of primary ID and secondary ID (or sub-ID) can represent multiple versions of city objects.For example, a specific version of a city object can be represented as Wall2100_Version3, where Wall2100 is the primary ID and Version3 is the secondary ID (or sub-ID).On the other hand, by using XPath or XLink to reference the primary ID of a city object, multiple versions of a city object within the same version can be queried, thus avoiding the troubles brought by the aggregation hierarchy of features [48].Version Transition allows different versions of the 3D city model to be explicitly linked by describing the reasons for the modifications.This method has low requirements for memory and storage and can be likened to a combination of full and incremental backups.It is also capable of streaming dynamic changes.Version Transition can be used to manage the history or evolution of the city model [129], but detection tools [130,131] need to be used to detect actual members of merged versions in order to avoid conflicts.


Dynamizer Module

As the CityGML 2.0 model does not allow time-series data, corresponding generic attributes need to be created to store such changing dynamic values.For instance, to represent the energy demand data (heating, electricity, and warm water demand) of a building in each month of a year, 12 generic attributes were created by [132], and in another case, 24 generic attributes were created to represent the energy consumption readings of a smart meter in each hour of a day [97].Moreover, not only will these continuously changing dynamic values be used, but dynamic values will also be customized for certain time periods; for example, the energy consumption values of a building on each working day in a month.AtomicTimeseries and CompositeTimeseries have been introduced in CityGML to address this issue [133].To develop the new concept of Dynamize, the OGC has completed a series of works.In the OGC Future City Pilot 1 Engineering Report [134], semantic 3D city models can have sensors and time-dependent properties using Dynamizer ADE.

The specific applications of Dynamizer can be illustrat d by Figure 7. Dynamizer is a data structure that can acquire and represent dynamic values.Dynamic data can be obtained from sensor observations, specific databases, and external files, and can be represented using the AtomicTimeseries class, CompositeTimeseries class, and SensorConnection class.In addition, Dynamizer provides a way to enhance static city models by adding dynamic attribute values to them.The advantage of this method is that it only allows selected attributes of the city model to become dynamic.If the application does not support dynamic data, these special types of features will not be allowed in the application.Furthermore, Dynamizer can establish an explicit link between sensor o

ervation data and t
e corresponding attributes of the measured city model objects, and the semantics of the sensor data will be implicitly defined by the city model.CityGML to address this issue [133].To develop the new concept of Dynamize, the OGC has completed a series of works.In the OGC Future City Pilot 1 Engineering Report [134], semantic 3D city models can have sensors and time-dependent properties using Dynamizer ADE.

The specific applications of Dynamizer can be illustrated by Figure 7. Dynamizer is a data structure that can acquire and represent dynamic values.Dynamic data can be obtained from sensor observations, specific databases, and external files, and can be represented using the AtomicTimeseries class, CompositeTimeseries class, and SensorConnection class.In addit

n, Dynamizer provi
es a way to enhance static city models by adding dynamic attribute values to them.The advantage of this method is that it only allows selected attributes of the city model to become dynamic.If the application does not support dynamic data, these special types of features will not be allowed in the application.Furthermore, Dynamizer can establish an explicit link between sensor observation data and the corresponding attributes of the measured city model objects, and the semant cs of the sensor data will be implicitly defined by the city model.


Future Work for Facilitating the Use of CityGML in BIM/GIS Integration

To further facilitate the use CityGML in BIM/GIS integration applications, new methods should be explored to address the semantics transfer and geometric conversion problem.Such methods include graph technology and s an-to-BIM.


Graph for Improving Interoperability

A graph-based database has the potential to address the semantics transfer problem between BIM and the GIS.The semantics transfer problem is rooted in the low data interoperability between BIM and the GIS, including low syntactic interoperability and low semantic interoperability, which result in building information loss during data conversion [18].In addition, the problem of relational databases, which are widely used in GIS systems, in representing relationships leads to further information loss.Graph technologies can be used to address these problems [135].

Graphs can represent interconnected building information [136], and graph-based databases support efficient and effective information retrieval by using graph-traversal based algorithms [137], which can overcome the disadvantages of relational databases and address the syntactic data interoperability by using an API (Application Programming Interface).

Nevertheless, the use of graph technologies, especially labelled property graph (LPG)based graph databases, has not been sufficiently investigated, and there are many problems remaining unsolved, e.g., regarding graph generation and the graphical representation of IFC [138].


Scan-to-BIM for BIM/GIS Integratio

A new modeling p
radigm is emerging in the AEC domain for creating building models, which is referred to as scan-to-BIM.Scan-to-BIM is different from the conventional CAD-to-BIM paradigm that uses modeling tools such as Revit; instead, it uses laserscanning and photogrammetry to collect data (i.e., point clouds and imageries) [139].Due to its high efficiency in data collection, this technique is gaining popularity in the AEC domain and has been used many applications, such as project progress monitoring [140] and structural health monitoring [141].Compared with CAD-to-BIM, the building models from scan-to-BIM can be surface-based, which can facilitate the use of building models in the GIS by avoiding the problematic solid-to-surface conversion task.Scan-to-BIM provides another potential opportunity to integrate building information into the GIS, but it has not been sufficiently investigated as well, with problems in geometric regeneration and semantic enrichment [142][143][144].


Conclusions

This study employs a systematic literature review to describe, classify, and analyze IFC-to-CityGML conversion at the data level and the potential influence of CityGML 3.0 to BIM/GIS integration.The main findings of this study are as follows:

(1) IFC-to-CityGML conversion requires both geometric and semantic conversions.There are many differences between these two standards in terms of geometry.Representation conversion, coordinate system transformation, and geo-referencing can be achieved using existing methods.However, in the aspect of LoD mapping, the accuracy and efficiency of existing algorithms need to be further improved to achieve solid-to-surface transformation.In terms of semantics, although there are semiautomatic mapping methods that improve semantic mapping efficiency, complete semantic mapping cannot be achieved.Even when combined with ADE, the use of ADEs will increase the complexity of CityGML models and cannot fully replace IFC models.

(2) The newly proposed standard, CityGML 3.0, has the potential to impact BIM/GIS integration.In terms of geometry, the LoD concept removes some limitations, with LoD4 being removed and all remaining LoDs able to represent interior and exterior features, including doors and windows across all LoDs.This implies that there is no need to pre-define semantic mapping rules before LoD mapping and simplifies 3D city models.In terms of semantics, the space concept can maintain the semantic integrity during the IFC-to-CityGML conversion.The Versioning module and Dynamizer module add dynamic attributes to the CityGML model.(3) Much effort has been made to improve the interoperability between BIM and the GIS, including in the development of new algorithms and the establishment of new standards.In the future, technologies such as graph techniques and scan-to-BIM offer new perspectives for integrating BIM and the GIS using CityGML.

Figure 1 .
1
Figure 1.The research methodology of this review.


Figure 1 .
1
Figure 1.The research methodology of this review.


Buildings 2023 , 23 Figure 2 .
2023232
Figure 2. Level of detail in CityGML[34].


Figure 2 .
2
Figure 2. Level of detail in CityGML[34].


Figure 3 .
3
Figur

s not yet been published.CityGML comp
ises one core module and different theme-based extension modules, as shown in Figure4.The green core module defines the basic concepts and components of CityGML.The red extension theme modules define specific themes.The blue extension modules define the modeling properties that can be combined with all theme modules.In CityGML 3.0, the core module introduces a new space concept and modifies the definition of LoD.The blue extension modules add Versioning, Dynamizer, and PointCloud modules.The red extension modules add the Construction module and modify the Building odule and Transportation module.


as shown in Figure 4 .
4
The green core module defines the basic concepts and components of CityGML.The red extension theme modules define specific themes.The blue extension modules define the modeling properties that can be combined with all theme modules.In CityGML 3.0, the core module introduces a new space concept nd modifies the definition of LoD.The blue extension modules add Versioning, Dynamizer, and PointCloud modules.The red extension modules add the Construction module and modify the Building module and Transportation module.


Figure 4 .
4
Figure 4. CityGML 3.0 module overview

data from d
fferent sources to specific properties of individual city objects [35].7.Future Work for Facilitating the Use of CityGML in BIM/GIS IntegrationTo further facilitate the use CityGML in BIM/GIS integration applications, new methods should be expl red to address the semantics transfer and geometric conversion problem.Such methods include graph technology and scan-to-BIM.


Figure 7 .
7
Figure 7. Dynamizers link timeseries data from different sources to specific properties of individual city objects [35].

Acknowledgments:The authors would like to thank the anonymous reviewers for their comments and suggestions that helped improve the comprehensiveness and clarity of our paper.Data Availability Statement:No new data were created or analyzed in this study.Data sharing is not applicable to this article.Funding: This research was funded by Shenzhen University 2035 Program for Excellent Research (2022B007).Author Contributions: Conceptualization, Y.T., J.Z. and Y.L.; ethodology, Y.T., J.Z. and Y.L.; formal analysis, Y.L.; data curation, J.Z.; writing-original draft preparation, Y.T., Y.L. and J.Z.; writing-review and editing, Y.T., J.Z. and Y.L.All authors have read and agreed to the published version of the manuscript.Conflicts of Interest:The authors declare no conflict of interest.
Application and extension of the IFC standard in construction cost estimating for tendering in China. Z Ma, Z Wei, W Song, Z Lou, 10.1016/j.autcon.2010.09.017Autom. Constr. 202011

Model-based Scheduling for Construction Plannining. V Hartmann, K E Beucke, K Shapir, M König, Proceedings of the 14th Int

national Conference on Comput
ng in Civil and Building Engineering. the 14th International Conference on Computing in Civil and Bu