Open-Source Tool for Transforming CityGML Levels of Detail

: Urban Building Energy Modelling (UBEM) requires adequate geometrical information to represent buildings in a 3D digital form. However, open data models usually lack essential information, such as building geometries, due to a lower granularity in available data. For heating demand simulations, this scarcity impacts the energy predictions and, thereby, questioning existing simulation workﬂows. In this paper, the authors present an open-source CityGML LoD Transformation (CityLDT) tool for upscaling or downscaling geometries of 3D spatial CityGML building models. With the current support of LoD0–2, this paper presents the adapted methodology and developed algorithms for transformations. Using the presented tool, the authors transform open CityGML datasets and conduct heating demand simulations in Modelica to validate the geometric processing of transformed building models.


Introduction
In 2018, about 55% of the world's population resided in urban areas. This number is projected to increase up to 68% by 2050 [1]. According to the United Nations, an increase in urbanisation will also increase energy demands in different parts of the world [2]. As urbanisation is closely related to the economic, social and environmental aspects of sustainable development, it is necessary to develop strategies addressing climate change and ever rising energy demands [3,4]. Although there are wide debates about whether cities amplify or reduce the anthropogenic impact on the environment, understanding the energy trends of urban areas is of strategic importance for transforming towards a sustainable and low carbon future [5,6]. Urban energy analysis, a technique to quantify energy demands, is often used in the design, operations and commissioning phases of an urban area. At times costly and labour intensive, the technique allows urban planners and simulation scientists to efficiently predict energy trends across large areas by incorporating varied principles and methods of information sciences [7]. Over the past decades, many urban energy simulation models and programs have been developed, enhanced and are in use throughout the scientific community [8]. Using different modelling techniques, the data models used for simulations often vary in their respective geometric and semantic definitions. For energy analysis, these models predominantly require additional energy-specific data in the form of enrichment as it lacks essential information required for energy predictions. Moreover, due to multiple inconsistencies and limited availability of these models, data interoperability is a critical issue in all stages of a simulation process [9]. Data models such as CityGML are sometimes openly available for a few cities and municipalities [10]. However, if openly available, these models are generally less detailed and, in many instances, cannot be directly used for simulations. As large amounts of open data lack higher geometrical granularities within data models, facilitating the geometric transformations, from lower to higher granularity or vice versa, is a must for efficient usage of open data. In this paper, the authors present the CityGML LoD Transformation (CityLDT) tool for transforming CityGML datasets from lower to higher and higher to lower geometric granularities.
The remainder of this paper is structured as follows: The "Literature Review" chapter highlights different energy modelling techniques, an enrichment approach, factors influencing energy model predictions and, the considered data model CityGML with respect to its corresponding Levels of Detail, Application Domain Extension and availability. The review presented in Section 2 forms the basis of developing CityLDT; the "Aims of Research" chapter describes the challenges of using CityGML models and further introduces the CityLDT tool; the "Methodology and Implementation" chapter highlights the methods adapted to transform CityGML LoDs; the "Tool Validation" chapter gives an overview of three use cases demonstrating the applicability of the tool; the "Discussion" chapter highlights the significance of CityLDT in UBEM-based studies and further discusses the availability of the tool. This is followed by the "Conclusion" chapter.

Literature Review
This chapter provides an introduction to UBEM and BEM, their usage and individual modelling techniques, an archetype-based enrichment approach, the state-of-the-art highlighting some factors influencing energy simulations and, further details over the OGC open-standard CityGML. For developing and validating the CityLDT tool, this literature review served as a basis.

UBEM and BEM
Urban Building Energy Modelling (UBEM), an analytical method to model buildings on city-levels, is often considered as a comprehensive and advantageous strategy to understand the overall energetic behaviour of urban areas. Using UBEM-based approaches, a prognosis of energy demands, retrofitting requirements and energy saving potentials can be made. UBEM inherits many methodologies and principles from Building Energy Modelling (BEM) but is usually used at a larger scale. For energy analysis, UBEM requires input data such as building geometrical detailing, construction data, 3D models, building physics data, Heating, Ventilation and Air Conditioning (HVAC), occupancy profiles, and system descriptions [11][12][13][14]. Generally, building models in UBEM are less detailed than in BEM [15,16].
In BEM, the modelling techniques mainly comprise of black-box models (empirical or statistical-based), and grey-box models (both physics and statistical-based) and white-box models (forward modelling or physics-based) [17][18][19]. For UBEM, two more categories are defined, namely, top-down and bottom-up [9,14,19]. The top-down approach includes econometric and technological models [20] by employing the statistical information and macroeconomic variables for determining energy demand projections [19]. It is suitable for an aggregated and broad level large-scale analysis as it couples variables such as gross domestic product, fuel costs, and income to the energy sector [20,21]. A top-down approach also subdivides the measured energy use at an urban level using statistical relationships established between individual building properties (such as age and area), occupancy patterns, and population [22]. The top-down approaches often lack details relating to the current and future technologies that could influence the energy demand of a building [23]. Apart from the top-down approach, a bottom-up approach is also commonly used in UBEM. The bottom-up approach requires an extensive amount of detailed information about each buildings along with substantial computational resources [22]. Developed using a bottom-up approach, the models consider and articulate building clusters with similar characteristics (geometric and non-geometric parameters) at different modelling levels [17]. In bottom-up models, the description of the individual building is based on the type of input data, i.e., dwelling properties, building physics and energy use [24,25]. On regional and national levels, the bottom-up approach extrapolates the estimated energy consumption of a representative set of individual houses and the approach consists of two distinct methodologies: a statistical method and an engineering-based method [23]. Using a bottom-up approach, some approaches also allow modelling of large groups of residential buildings and uses the information from public building registers, weather measurements, and hourly smart-meter consumption data [26]. According to Costanzo et al. [20], the advantage of bottom-up over top-down approaches is their ability to analyse energy demand by endusers and provide detailed technological interventions to improve the energy efficiency of buildings. Bottom-up models are also generally referred to as "urban building energy models" in some of the existing literature [27][28][29][30][31][32][33].

Archetype-Based Approach
In many of the bottom-up UBEM-based physical approaches, enrichment of pure geometrical models is considered an important step [12,19]. For an efficient simulation workflow, parameters such as heating and cooling schedules, and material properties, etc., are enriched directly in the input data model. Approaches made by previous studies [21,29,[34][35][36][37][38][39] relate to pre-defined archetypes for enrichment. An archetype is defined by selecting a sample building with measured data or by using statistical building-related data [40]. Previously, Reinhart and Davila [28] describe the available building archetypes in different countries and further explain the process of enriching building models with archetype information. A recent article by Hao and Hong [41] also states that a detailed building characterisation, including physical properties, geometry information, and energy use data should be used as input for UBEM by establishing building archetypes. Using an archetype-based approach, the geometrical models are enriched with specific attributes based on their years of construction and building usages. Some databases and sources [42][43][44][45][46][47] require years of construction and building usages for assigning digital models with energy specific building information for an archetype-based enrichment. The information about the years of construction and building usages is, therefore, a requirement for an archetype-based enrichment and should be included directly in the input data models. The usability of an archetype-based enrichment also increases the dependence on precise building-related information. However, an inclusion of specific information into the data models results in a more complex and lengthy process for the urban energy community.

State-of-the-Art
A basic UBEM approach applies virtual 3D models of heat and mass flows to predict energy demand along with assessing the indoor and outdoor environmental conditions at an urban scale [28]. Energy model predictions are largely influenced by factors such as input data models [48,49], building geometries [50][51][52], construction properties [36,53], occupancy [54][55][56], urban form [57][58][59], densification [60,61], and micro-climate [31,62], etc. Although different factors contribute to developing UBEM workflows, virtual 3D models are mostly considered as a starting point for simulations. Virtual 3D city models are currently being used in many different applications and have become general-purpose tools for storing, exchanging and distributing geo-spatial information [63]. For computing the energy performance of the buildings, 3D geometrical data models are generally used as an input for building geometries, years of construction, building usages, roof types, etc. One such virtual 3D city model, particularly the Open Geospatial Consortium (OGC) standardised and open data format of City Geographical Markup Language (CityGML) [16,64], has provided a significant boost in the development and visualisation of urban energy data [65].

CityGML
CityGML, an open XML-based data format, is used to represent cities and urban areas for storage and exchange of geometrical data for individual buildings. CityGML facilitates the representation of semantic and topological information at a city level and is commonly used in energy-related applications [66]. With the CityGML Core Module concept exists a number of thematic modules for representing buildings with their interior and exterior structures. For energy simulations, generally, the CityGML Building Module is considered. CityGML also uses surface geometry representation for depicting different building elements. The data models defined in CityGML use uniform spatial reference system definitions. They contain information related to building footprints, geometries, numbers of floors above/below ground, years of construction, and roof types, etc. Figure 1 gives an overview of the basic structure of a building represented in CityGML format. Each building is modelled with an outer shell and interior rooms. The outer shell consists of individual outer wall surfaces and the building roof surfaces. The interior rooms include the geometric definition of the interior wall surfaces along with ceiling and floor surfaces.

CityGML-Levels of Detail
For representing real objects with geometric and semantic detailing, CityGML models support the concept of Levels of Detail (LoD) [66]. Depending upon the amount of information present in the models, datasets in CityGML can be represented in five LoDs. Starting from LoD0, building models are represented by a regional and landscape scale representation with the lowest accuracy [9]. The LoD0 models consist of semantic information, the footprint and height of a building and representations of the roof; however, it does not include any information on building installations and city furniture (city furniture objects are immovable objects such as traffic lights and signs, advertising columns, lanterns, benches or delimitation stakes [66]). LoD1, generally an extrusion of the LoD0 model, represents the buildings in a single geometry block with a flat roof surface. For LoD1, the volume of a building is estimated using the building height and flat roof area. Upscaling from LoD1 by including more information, the LoD2 building models represent detailed roof information. For energy simulations, the information of roof surfaces is important to calculate the actual volume of a building. Cities and urban areas, often represented as LoD2 models, are also prominently used in energy-related analysis. Compared to LoD2, the LoD3 models are much more detailed. The LoD3 models are used to represent buildings with an exterior architecture and landscape scale. These models include information about windows, openings and exterior installations for different buildings. For a detailed interior architectural representation, it is common to use the LoD4 models. The LoD4 models are quite detailed; however, these are generally not used for simulations. Recently, the LoD4 is also excluded from CityGML 3.0 due to its lower usability and excessively complex geometry processing [68]. Figure 2 gives an overview of the five LoDs in CityGML.

CityGML-Application Domain Extensions
Virtual 3D CityGML models are used for many different applications ranging from traffic noise simulations [69], flood analysis [70], Building Energy Performance Simulation (BEPS) [71], and many others. Depending upon the desired application, CityGML geometric models are extended using the Application Domain Extension (ADE) mechanisms. This extension facilitates the extensive usage of the geometrical model by many use cases and simulations. Though there exist many different types of ADEs [66,72,73], for energy simulations, the energy ADE [74] and the utility network ADE [75] are generally used.

CityGML-Usage and Availability
In recent years, published articles such as [76][77][78][79][80][81][82][83][84][85][86][87] have made use of CityGML models for energy performance simulations. Some studies facilitate energy demand calculation simulation environments such as Modelica [88][89][90][91] and EnergyPlus [80,92,93]. Although widely used for energy simulations, the availability of these geometric data models is always in question. In a taxonomic review, Malhotra et al. [9] recently concluded that CityGML along with EnergyPlus is most prominently used in UBEM-based studies. Their article also emphasises that the usage, enrichment and further storage of enriched open datasets in the form of CityGML Energy ADE and gbXML will help simulation scientists in efficiently developing, validating and maintaining energy simulation workflows and tools. Moreover, due to a lack of availability and simplified geometrical approaches, Carnieletto et al. [94] recently highlighted the difficulties in calibrating and validating UBEM-based approaches using models developed in CityGML, GeoJSON, CityJSON. Rosser et al. [95] also mention that it is challenging to develop urban housing stock models for energy simulation as it requires a range of information for accurately representing the characteristics of each building. Their article further mentions that the development of nation-wide data is planned for the future [96,97]; however, it is not available for countries such as the United Kingdom. Braun et al. [98] describe the challenges, such as missing information, geometric inconsistencies and inaccuracies, faced when creating energy models from a CityGML model for the city of Stuttgart, Germany. Chen et al. [13] evaluate the availability of public datasets in San Francisco and recognise a lack of common parameters while mapping data into CityGML. Although there exists many difficulties in developing and accessing open-CityGML datasets, some countries, municipalities and governmental organisations do provide open access to the data in LoD1 and LoD2 [10]. Table 1 gives an overview of the availability of open-source 3D CityGML data in different LoDs.  [99][100][101][102][103][104][105][106]. "&" denotes the availability of the different LoDs. In some datasets, the number of LoD1 models is higher than the LoD2. This is denoted as "1 > 2".

Aim of Research
As shown in Table 1, the datasets representing cities are most commonly available in LoD1 and 2. Although some countries also provide access to LoD3, these are not included in the scope of this paper and are mostly restricted in access. Instead, the LoD0 models alongside LoD1 and 2 are used in the rest of the paper. As previously mentioned, the LoD0 CityGML models are a two and a half dimensional Digital Terrain Model and can be used to visualise building footprints and/or the geographical occurrence of a building. The applications of LoD0 might be limited but is generally used for digital cartography [108], floor plan generation [109] and others. In LoD1, the buildings are represented as block models with prismatic buildings and flat roofs [110]. The LoD1 models differ from LoD2 as it does not include differentiated roof structures and thematically differentiated surfaces. Due to simplified geometrical definitions, easier imports into different tools, and feasible transformations from other data models, the LoD1 is also commonly used despite its mentioned shortcomings [111][112][113]. Previous studies from Malhotra et al. [49], De Jaeger et al. [48,50,51], Faure et al. [27], Geiger et al. [114] and Monien et al. [52] demonstrate the impact and deviations of building geometries and CityGML LoDs for UBEM use cases. The deviations, in simulation results, between LoD1 and LoD2 can sometimes also occur due to varying wall/roof ratios. Due to varied applications and a generalised availability of open CityGML datasets in LoD1 and LoD2 [10], it is necessary to enable the transformation of CityGML models from one LoD model to another.
Previously, an article by Fan and Meng [115] presented an approach for deriving 3D building models in different CityGML LoDs. Implemented using Matlab, their approach primarily focused on downscaling higher LoD models into lower LoD models. The presented approach in their article did not include any information over upscaling CityGML LoDs. Another method by Deng and Cheng [116] also presented an automatic transformation of different CityGML LoDs. In their workflow, a new exterior shell extraction algorithm is developed using a ray tracing-based algorithm. They classify building surfaces as interior or exterior and also include an additional LoD called LoD3.5. Other techniques proposed by Li et al. [117] and Sun et al. [118] also allow the transformation of different LoDs, but these are generally limited to downscaling higher LoDs to lower ones. Moreover, most of the previously mentioned techniques are not available as open source nor updated in recent years. Therefore, in this paper, the authors introduce an open-source CityGML LoD Transformation (CityLDT) tool.
CityLDT allows the input of CityGML LoD0, 1 and 2 models. Depending on the input data, a transformation to the desired LoD can be achieved using the tool. CityLDT enhances the interoperability of CityGML LoDs, thereby, increasing its usability in a number of use cases. Due to a modular structure, CityLDT can be incorporated into different workflows and tool chains. Detailed explanations of the developed algorithms along with the tool's functionalities, accessibility, structure and limitations are given in the next sections. Furthermore, three use cases are described highlighting the usability of the tool. In this paper, a bottom-up UBEM-based archetype approach is also used to simulate CityGML building models for heating demand computations.

Methodology and Implementation
An analysis using an advanced search on the academic platform "Web of Science" [119] shows an increasing trend in UBEM-based published articles from 2010 to 2021. Using keywords "UBEM", "GIS", "heating demand simulation", "CityGML", "LoD", a further analysis depicted in Figure 3 over the usage of openly available data shows that more than 96% of the studies, i.e., 7803, do not use open data. Between 2010 and 2021, only 572 articles make use of open-access data for UBEM. This fact can be caused by less or no availability of open data models, supporting workflows, or even due to a lack in interoperability within the data models itself. If a software or workflow limits the usage of detailed input data, a workflow to transform the model's LoD should be openly available. This paper, therefore, focuses on these transformations using only CityGML building models. Figure 3 gives an overview of the number of publications from 2010 to 2021 with or without using open-source input data. As the analysis was made in mid-2021, the number of publications for 2021 is comparatively lower than the one in 2020. With lower or higher detailing, virtual 3D data models can also be generated using different techniques and methodologies [120]. As simulation scientists focus on the interoperability of different data models, many recent studies increasingly focus on transforming Building Information Modelling (BIM)-based Industry Foundation Classes (IFC) models into Geographical Information System (GIS)-based CityGML models. Biljecki et al. [121] recently suggested an extension, in the form of CityGML ADE, to prevent loss of information while converting IFC to CityGML. Zadeh et al. [122] also suggest an integration of BIM and GIS data for practical applications such as operation and maintenance on an urban scale and for designing district energy centres. Studies such as Jusuf et al. [123], Colucci et al. [124], Tauscher et al. [125], Adouane et al. [126], Zhu et al. [127], Donkers [128] also explain the requirements, processes and implementations of combining the domains of Building Information Modelling and Geographical Information System together. Although previous studies focus on transforming from one domain to another, not many highlight the importance of interoperable data processing within the considered data model itself. If thoroughly explained, data models in different granularities can be used over a wide range of applications. Therefore, this paper presents algorithms and use cases for transforming CityGML models between LoD0, 1 and 2.
The transformation from one LoD to another can be achieved using the presented CityGML LoD Transformation (CityLDT) tool, which provides a user-friendly and selfexplanatory Graphical User Interface (GUI) enabling users from all domains and expertise. With an objective of simplified transformation of CityGML data models between different LoDs, users may consider LoD0, 1 and 2 as input for the tool. A support for LoD3 and 4 is foreseen by the authors as future work. CityLDT is being developed and tested using Python programming and supports version 3.5 and higher. Using CityLDT, data models are transformed by either (i) upscaling from lower to higher LoD or (ii) downscaling from higher to lower LoD. Within both approaches, the output data models are exported in the identical CityGML version as the input model. As demonstration objects, the FZK House [129] in LoD0-2 is further used in Sections 4.2 and 4.3. A representation of the FZK House in different LoDs is also previously shown in Figure 2 (Section 1). In this paper, the visualisation of CityGML models is made using the FZK Viewer [130]. The algorithms used for transforming CityGML models comply with the SIG3D "Modelling Guide for 3D Objects" [131]. Section 4.1 gives an overview of the import options of CityLDT. Sections 4.2 and 4.3 explain the two approaches used to transform the LoDs. Section 4.4 highlights the optional user inputs to edit the input model. Furthermore, Section 4.5 describes the export options for the transformed CityGML models.

Import
As input, CityLDT facilitates the selection of a single CityGML dataset or a number of datasets by selecting a single folder. It also allows users to select individual building models along with the option of selecting all the models present in the dataset. The import of the CityGML dataset also highlights the model's LoD. This is displayed to the user for a simplified selection. Currently, both building and building parts (a building part is a subdivision of a building that is homogeneous related to its physical, functional or temporal aspects and may be considered as a building [131].) are considered as a single building and a building part cannot be transformed individually. Figure 4 gives an overview of the CityLDT's input window.

Upscaling from Lower to Higher LoD
In CityLDT, upscaling the CityGML models from lower to higher granularity requires an extraction of parameters from the input model and, sometimes, user-based parametric inputs. Some attributes, such as the bldg:GroundSurface (the "bldg" namespace refers to the definition of class Building in CityGML; it includes different sub-classes for defining the geometrical definitions of individual buildings with various granularities [131]) are considered from the input model; however, parameters such as bldg:measuredHeight (the building height is similar to the "measured height" as defined in the modelling Guide for 3D Objects [131].), if not present, are either calculated using other geometrical parameters (only for LoD1) or must be provided by the user. Sections 4.2.1 and 4.2.2 explain the approaches used for upscaling the LoD of the models.

Upscaling LoD0 Models
The CityGML modelling guide [131] states that buildings in LoD0 are represented by the footprint or roof outline using a horizontal polygon with a well defined absolute and constant height. The LoD0 models sometimes might not contain the required information for representing a building with higher detailing [131]. For upscaling the LoD0 into LoD1 and LoD2, initially the groundSurface coordinates are extracted from the bldg:lod0FootPrint element of the LoD0 model. As there are no designated groundSurface elements in the LoD1 model, this information is added to a bldg:lod1Solid element. Whereas, for LoD2, this information is added to the bldg:boundedBy/bldg:GroundSurface element.
After defining the base of the building, the 3D structure requires the building height. The bldg:measuredHeight element, which defines the height of a building, is used from the input model. If not present, it must be provided by the user. The extracted or user-defined height of the building is then added to the bldg:measuredHeight element of LoD1 and LoD2 models. If desired by the user, it is also possible to change/overwrite an existing bldg:measuredHeight element.
For the 3D structure of LoD1 building models, the geometric parameters are modelled as an extrusion of the ground surface using the bldg:measuredHeight. The coordinates defining the extruded geometry of the building (including wall surfaces and flat roof) are added to the bldg:lod1Solid element. Contrary to LoD1, the modelling of LoD2 representation requires the definition of a roof type for the building. This is extracted from bldg:roofType element of the LoD0 model. If not available in LoD0, it can be provided by the user. In case no roof type information is present in the input model nor defined by the user, a building with a flat roof is created. Certain roof types such as dual-pent, gabled, etc., also require the information about roof height (defined as a bldg:roofHeight element in CityGML) from the user. The roof height refers to the minimum eaves height, which is the point where the external walls, if projected upwards, meet the lowest point of the upper surface of the roof [132,133]. If a user-provided roof type consists of a tilt, the orientation of the roof is also required. The roof orientation refers to the heading of the longer side of the roof surface with respect to the building. Currently, the generation of six different types of roofs, namely, monopitch, dual-pent, gabled, hipped, pavilion and flat, is supported in CityLDT. An integration of other roof types is also foreseen in the future. All information about the building geometry is stored within the LoD2 model using the bldg:lod2Solid and bldg:boundedBy elements. Figure 5 gives an overview of upscaling a LoD0 model.

Upscaling LoD1 Models
Similar to upscaling LoD0, the ground surface coordinates of LoD1 models are extracted for upscaling into LoD2. Since there are no specific groundSurface elements in LoD1, the coordinates having the minimum elevation are considered as the ground surface polygon. The height is either taken from the bldg:measuredHeight element or is calculated (if not present) using the building geometry. Furthermore, if the information about the type and height of roof is missing, it must be provided by the user. Otherwise, the building is created with a flat roof. In the case of upscaling from LoD1, the information about the intersection of the building/building part with the terrain (if available) is also included in the desired LoD2 model. Building elements such as bldg:lod2Solid and bldg:boundedBy are used to store most of the geometrical definitions of the building. Figure 6 gives an overview of upscaling an LoD1 model.

Downscaling from Higher to Lower LoD
Downscaling the models of higher LoD is less complex compared to upscaling. Although there exist some similarities in downscaling, the individual transformations from higher to lower detailing are highlighted in Sections 4.3.1 and 4.3.2.

Downscaling LoD2 Models
Transformation of a LoD2 model to a LoD1 and LoD0 requires the information of ground surface coordinates from the building's bldg:boundedBy/bldg:GroundSurface element. This ground surface is necessary to define the geographical location of the building. For LoD0, the extracted ground surface coordinates (from the LoD2 model) are added to the bldg:lod0FootPrint element. Whereas for LoD1, these coordinates are added to the bldg:lod1Solid.
As CityGML datasets generally include the bldg:measuredHeight element, if present, it is also preserved in the LoD0 model. In case the height is not included in the original dataset, it is calculated using the building geometry and individual wall surface coordinates. For this, the distance between the lowest and highest vertices (with respect to sea level) is calculated and added to the desired model as a bldg:measuredHeight element. If the height of storeysbelowGround is present in the original LoD2 model, the calculation of measuredHeight does not include the total height of below ground storeys but only the combined height for storeysaboveground is considered. Similarly, if the number of storeysbelowGround is present, the height of individual storeys below ground is calculated using the distance between the lowest and highest vertices and is excluded from total height of the building.
While transforming into LoD1 and LoD0, the geometrical definitions of the LoD2 model are not included. These definitions consist of all surfaces defined in an LoD2 model as bldg:lod2Solid and bldg:boundedBy elements. Moreover, the terrainIntersection element, an important parameter of a building or building part, is mostly present in LoD2 models. For transforming the LoD2 models in LoD0, this attribute is not included; however, for LoD1, it transforms into the LoD1 terrainIntersection element. Figure 7 provides an overview of downscaling the LoD2 model to LoD1 and LoD0.

Downscaling LoD1 Models
For downscaling from LoD1 to LoD0, the ground surface coordinates of the considered building are searched for within the bldg:lod1Solid element. Since there is no designated groundSurface within the LoD1 model, the one with the lowest average elevation is considered. The coordinates are further added to the bldg:lod0FootPrint element. Similar to the downscaling of LoD2 models, the height of the building is either extracted from the bldg:measuredHeight element or is calculated using the building geometry. The terrainIntersection (if available) is not considered in the LoD0 model. Figure 8 gives an overview of downscaling the LoD1 model to LoD0. For lowering the granularity of data models, no user-based geometric or parametric inputs are required and it can be performed for one or more than one building consecutively. The next section highlights some of the optional user-inputs to enhance the building models.

Optional Inputs
Along with the granularity transformation, CityLDT also supports some optional userinputs. This allows users to export data models as per their requirements and applications. The users can export the transformed models by either using attributes of the initially selected input model or by modifying the existing attributes. The following inputs can be provided by the users: • Building Function: The building function, referring to the actual usage of the building, plays a significant role in analysing the energetic performance of a building. In a bottom-up archetype-based approach, the building function is important to precisely enrich the building models with statistical data. Based on the usage of the building, the occupancy, heating/cooling schedules, etc., are used for simulations. In CityGML, the building function is stored in the bldg:function element and is generally defined with the help of external definable dictionaries known as code lists [66]. In CityLDT, users can input the building function based on the CityGML standard definitions. • Year of Construction: The bldg:yearOfConstruction element includes the first year of a buildings' construction. Previously CityGML models representing cities included the years of construction within the open datasets; however, this is now changed as per the analysis made by the authors. This parameter is also important for an archetype-based enrichment. Some cities and municipalities also provide the years of construction of different buildings in separate databases [134]. If available, these could be added to the data models using CityLDT. • Storeys above/below ground: The storeys above ground refer to the number of above ground floors of a building, whereas the storeys below ground refer to the floors below the ground surface. In CityGML, both of these parameters are stored as individual elements. The storeys above/below ground are important for simulating apartment buildings, multi-family houses and/or terraced houses as they generally consist of more than one floor. This parameter can be added/modified using CityLDT.
The next section highlights the export options within CityLDT.

Export
CityLDT supports the CityGML versions 1.0 and 2.0 for generating the transformed data models. The 2.0 version of CityGML is an application schema of OGC's Geographical Markup Language (GML) version 3.1.1 [135]. For storing the transformed building parameters, users can define the desired output directory. If not defined, the path of the selected input directory is considered and a new folder is created and added. In total, there are three export options available to store the transformed models.

•
Only transformed building models: While exporting the transformed building models, the non-transformed buildings are not included in the output. The transformed models are, however, combined and stored as a single dataset for output. • Transformed and non-transformed models: For exporting both transformed and nontransformed, new datasets can be generated comprising all building models from the input dataset. This might be important for datasets containing both LoD1 and LoD2 together. If required for simulations, the building models in LoD1 can be transformed and combined with the LoD2 models. • Transformed building into individual CityGML datasets: This option enables the users to store the transformed building models as individual datasets containing one model per dataset.
The next chapter highlights three use cases to demonstrate the implementation and application of CityLDT.

Tool Validation
The CityGML LoDs are intended to differentiate multi-scale representations of semantic 3D city models [136]. An increase or decrease in the geometric detailing within a model often impacts its required storage space, complexity and usage. For energy performance simulations, models with more geometric detailing, i.e., higher LoDs, are generally considered. As the availability of detailed models is limited, integrating workflows to transform from lower to higher LoD is necessary. Based on the individual applications, the flexibility to transform the LoDs is also important for standardising approaches, workflows and data usage in the field of UBEM. Therefore, to increase the acceptance of CityGML in geo-spatial applications, CityLDT allows users to transform CityGML LoDs in a user-friendly manner. For demonstrating the applicability of the tool, this section highlights three use cases. Section 5.1: Considering an open CityGML dataset for the city of Vienna, Austria. As the open dataset consists of building models in LoD2, the models are transformed to LoD1 and LoD0 and are further compared. Section 5.2: A sample building model, FZK House [129], from the CityGML Wiki [99] is transformed from LoD0 to LoD2. The building model is further simulated using a Modelica-based approach. Section 5.3: A cluster of 500 building models in LoD1 for Hamburg, Germany, is transformed to LoD2 and is simulated using a Modelica-based approach. For both Sections 5.2 and 5.3, the heating demand simulation is performed using an archetype-based bottom-up UBEM approach, and the results are compared to the simulation results of the (originally available) open data model in a similar granularity/LoD.

Open Data Vienna
With a population of nearly 1.8 million inhabitants, Vienna is the capital and largest city of Austria. It is composed of 23 districts [137]. For different districts of Vienna, open CityGML LoD2 building models are available under the Open data Initiative of the Austrian government [138]. Most of the available data are geo-referenced according to the MGI/Austria GK East projection (EPSG code: 31256) [137]. For the CityLDT use case, a small district within the city is considered. As open data mainly consists of LoD2 building models, these are transformed into LoD1 and LoD0, respectively. Figure 9 gives an overview of the district in different LoDs used for the CityLDT transformation. The district, considered for transformations, consists of 307 building models and 1205 building parts with different roof surfaces such as flat, gabled, and mono-pitch, etc. Some buildings consist of dome-shaped roofs. For such buildings, a flat roof is created instead, as currently, there exists a limitation of modelling buildings with pre-defined roof types in CityLDT. In the future, the algorithms to model other roof types are foreseen. Both the original and transformed models consist of a similar number of buildings and building parts. The transformation of LoD2 models into LoD1 is achieved in 2.97 s and from LoD2 into LoD0 in 2.56 s. The transformations also change the required storage-spaces of the datasets in different LoDs. Initially, the considered LoD2 model has a required storage size of 37 MB. If transformed to LoD1, this decreases to 13 MB and for LoD0 it further decreases to 2 MB. This reduction in the required storage-space can be quite significant while transforming datasets of a complete city for further processing.

FZK House
For testing the geometrical upscaling within CityLDT, the (previously mentioned) FZK House [129] available in LoD0-4 on the official CityGMLWiki [99], is considered for transformation. In order to validate the geometrical transformations, the open and developed models are simulated to deduce the current heating demand. The LoD0 model of the FZK House is upscaled to a higher granularity of LoD1 and LoD2. To upscale LoD0 into LoD1 (further referred to as B1), the measured height is added to the model. For upscaling to LoD2 (further referred to as B2), parameters such as roof type, roof height and roof heading are added to the input model. Figure 10 gives an overview of the LoD0 model transformed to LoD2 (B2) along with the user-defined inputs. Using a bottom-up archetype-based approach, the openly available LoD1 (further referred as A1), LoD2 (further referred as A2) and the transformed (B1 and B2) models are enriched with energy specific parameters. For such an archetype-based approach, the authors consider the TABULA Episcope project [140] for European buildings. With archetypes for buildings in 21 countries, a standard parametric definition is made for the residential buildings stock based on the years of construction and building usages. In case of the FZK House, the year of construction is pre-defined as 2015 and the building function refers to a residential building. Building specific information for year 2015 using a Single Family House (SFH) archetype is enriched within the geometric model. The enrichment of the building model is performed using the open source tool TEASER (version 0.6.9) [35]. Using Modelica [141] libraries such as AixLib [90], Buildings [142], BuildingSystems [143] and IDEAS [91], the TEASER tool allows generation of ready-to-simulate Modelica simulation models of a single building or an urban scale. For simulating both the derived and open-access versions of the FZK House, the AixLib (version 0.7.3) and Dymola (version 2018) [144,145] are used for Modelica model generation and simulation, respectively. Hourly weather data for the year 2015 are considered using the Test Reference Year (TRY) for Hamburg [146]. Once simulated, the LoD1 (A1 and B1) and LoD2 (A2 and B2) models show similar heating demand profiles. Although slightly higher in case of B2, the simulation values differ from A2 due to an addition of the roof height as user-based input. The additional roof height increases the building volume. This change in the building volume thereby increases the heating demand requirement of the simulated building. The simulation of all the four building models, on a standard laptop, is achieved in a total of approximately 30 min. Figure 11 provides an overview of the simulation results for the open and transformed models. Since the deviation between the open and upscaled LoD1 models is quite small (<0.02%), it is not represented in Figure 11.

Open Data Hamburg
A 3D representation of the buildings for Hamburg, Germany, is available as opensource in LoD1 and LoD2 [147]. First published in 2013 and often updated on a yearly basis, the data are made available by the Hamburg State Office for Geoinformation and Surveying [147]. The open 3D models, representing individual buildings, are widely used for urban and spatial planning, architecture and property marketing. Recent studies [77,[148][149][150][151] use CityGML LoD1 and LoD2 datasets for urban energy analysis. In this paper, the authors consider a district from the geographical location of Hamburg Hamm. The representation of buildings within the selected district is openly available as LoD1 (further referred as OD1) and LoD2 (further referred as OD2) models. Using CityLDT, the OD1 dataset is upscaled into LoD2 (further referred as TD2) for heating energy demand simulation. The transformation of all LoD1 models into LoD2 is performed in 3.45 s. Figures 12 and 13a,b demonstrate the selected district using Google maps, the open 3D LoD1 models and the upscaled LoD2 models, respectively. The LoD1 (OD1) and LoD2 (OD2 and TD2) datasets individually consist of 544 building models, categorised as residential buildings. In the open datasets (OD1 and OD2), the buildings are modelled with different roof types; however, while transforming to TD2, only flat roofs are considered in the new model. OD1, OD2 and TD2 further categorise the 544 building with 183 building parts. Both buildings and building parts are considered as individual buildings for simulations. Using TEASER [35] and the Modelica Library AixLib [90], OD1, OD2 and TD2 are transformed into ready-to-simulate Modelica models. The authors use these models to compute the heating demands over a period of one year using the Modelica environment Dymola [144]. In the open datasets, sometimes the orientation of the buildings are modelled incorrectly. For such inconsistencies, workflows including 3Dis CityEditor [152], CityDoctor [153], Galdos CityGML INspector [154] can be used to inspect and correct the building geometries. In this paper, however, such buildings are not considered for computations. Moreover, for some buildings, the polygon normal of the individual surfaces are modelled in the opposite direction whereas, for some, the polygons do not have closed surfaces and correct linear rings. Therefore, for each granularity, the simulations of 491 buildings are carried out amounting to a total of 1473 simulations. On a standard laptop, the generation of Modelica models, enrichment of energy specific data and heating demand simulation of all 1473 buildings is completed in a combined real time of approximately 21 h. For simulations, hourly weather data are considered using the Test Reference Year (TRY) for Hamburg and year 2015 [146]. Figure 14 provides an overview of the dynamic simulation results for OD1, OD2 and TD2.   The simulation results of open LoD1 models (OD1) are comparatively much higher than the open LoD2 (OD2) and the transformed LoD2 models (TD2). As mentioned previously, some deviations between the LoD 1 and 2 occur due to varying wall/roof ratios. Further information over the factors influencing these deviations is highlighted comprehensively in previous literature [27,[48][49][50][51][52]114,155] and is, therefore, deemed outside the scope of this paper. Although there exist slight discrepancies in the computations of LoD2 open and transformed data (both in Sections 5.2 and 5.3), these could be minimised by a detailed one-to-one parameter mapping for the individual buildings. If modelled similarly, the simulation results, as per the authors would perfectly coincide with each other as the (transformed) buildings would be modelled with similar roof types and building volumes.

Discussion
Suitable for representing individual buildings or urban areas, data models such as CityGML can be used in multiple UBEM-related workflows and tool chains [9]. As mentioned previously, a CityGML LoD2 model is commonly considered for urban heating demand simulations, resulting from sufficient detailing and lower complexity in pre-and post-processing of building geometries. Using extensions such as the Energy ADE [74] and Utility Network ADE [75], the CityGML LoD2 models are used for building/district energy as well as network simulations. Different workflows, such as CityATB [156], GML Toolbox [157], CityDoctor [153], or Feature Manipulation Engine (FME) [158] and simulation environments, such as EnergyPlus [92], Modelica [141] with supporting libraries, facilitate the import of CityGML LoD2 models. Whilst gaining popularity in UBEM, the availability of open CityGML data is comparatively low [10,159,160]. If available, CityGML building models often do not contain adequate detailing for heating demand simulations, thereby, restricting its usage. Simulating models with lower geometric detailing impacts the overall computational analysis resulting in imprecise energy demand predictions. As previously highlighted in Sections 5.2 and 5.3, the data models with less detail cannot be used appropriately for energy performance simulations. When comparing LoD1 and LoD2 models, high deviations are recognised in heating demands. These deviations impact the standardi-sation of UBEM-based approaches alongside questioning the reliability of developments made within the urban energy community. For a city-wide simulation, deviations within energy predictions might even increase exponentially for a higher number of buildings. Therefore, algorithms facilitating the upscaling or downscaling of the geometric definitions are of high importance and should be available as open-source.
In this paper, the authors highlight the technical implementation and usability of the CityGML LoD Transformation tool. The tool facilitates the transformation of geometric granularities within CityGML datasets. Available in varied LoDs, this transformation, i.e., upscaling or downscaling the granularity, of CityGML data models is crucial. The open-source CityLDT tool currently supports an import and export of LoD0-2. It allows users to upscale 3D CityGML models where less/no detailed data exist and can also be used to downscale models for applications such as flood simulations, geographical mapping or for storage and exchange in databases. The CityLDT is developed using Python programming (version 3.5+), and its interface enables users to import, select, edit and export data models in LoD0-2. The algorithms developed in CityLDT use mathematical equations and geometrical theorems to process the building geometries. With a modular architecture and simplified development tracking, the tool can be integrated and extended for other simulation workflows and tool chains. Due to its open-source nature, published under the MIT license, it is transparent, flexible and versatile. The source-code is available here: https: //gitlab.e3d.rwth-aachen.de/e3d-software-tools/cityldt (accessed on 4 December 2021).
The methods and algorithms developed within CityLDT are extensive and rely on multiple mathematical computations. Although the development process is endeavoured to be kept open-source, the authors acknowledge that the tool is being developed primarily using the Python environments "PyCharm 2020.1.1" [161] and "Visual Studio Code" with some extensions [162]. The users, in seldom cases, might encounter minor compilation errors within other environments as different environments use varied internal libraries and solvers. Moreover, the current implementation of CityLDT majorly requires manual inputs from the users of the tool. The high dependency on user-inputs, in some cases, might lead to inappropriate model transformations. In future, the authors would like to further automate the transformation process by incorporating external databases and libraries. For manual inputs, an inclusion of pre-defined checking algorithms to eliminate any unintentional human errors is also foreseen by the authors.
In many UBEM-based studies, the possibility to replicate simulation results and workflows is comparatively low. This is often due to granularities and detailing of the considered input data model. Using CityLDT, the reproducibility of studies can be increased as the tool allows users to develop suitable data models, in its required LoD, for usage into multiple use cases.

Conclusions and Future Work
Urban planning and resource management generally require a transformation of the built environment into 3D spatial representations. This transformation facilitates systematic analysis of urban areas for their energetic behaviours [163]. Often clustered together, the 3D representation of individual buildings is commonly developed in the form of data models that differ based on their purposes, stakeholders and application requirements. Requiring a broad availability of data, geometrical data models along with precise energy specific information benefit urban planners, researchers and scientists to simulate and predict energy demands in cities and city-quarters. For urban energy analysis, however, open data models do not generally include the geometric detailing required to represent individual buildings in their respective geographical contexts. As previously mentioned in Section 3, studies such as [115][116][117][118], do allow transforming CityGML building models; however, these are primarily limited to downscaling higher LoD models to lower ones. Moreover, the algorithms are mostly available with a restricted access. Therefore, this paper introduces the open-source CityGML LoD Transformation tool for transforming CityGML data models in LoD0-2. With a user-friendly GUI, CityLDT allows users to transform and edit individual buildings as well as large urban areas. In this paper, the authors downscale LoD2 to LoD1 or LoD 0 and upscale LoD0 or LoD 1 to LoD2. The tool currently supports CityGML version 1.0 and 2.0 in LoD0-2. Furthermore, development of algorithms to process and transform LoD3 and 4 along with the inclusion of CityGML3.0 is foreseen by the authors. Using Modelica, the authors simulate downscaled and upscaled models in order to validate geometries of the transformed models. Once simulated and compared to a model in a similar granularity, the results (largely) coincide for the transformed and openly available data. Although the authors do acknowledge slight deviation in the simulation results, these could be minimised by a one-to-one mapping for building parameters. Moreover, the usage of other simulation workflows and an integration of processing more complex surface geometries is foreseen as future work. With some refinements in the simulation workflow, adjusted net volume calculations, consideration of other roof types and more precise archetype assignment through geometrical analysis of the CityGML building models, neighbouring buildings and net leased area, the authors envision further improvements in the simulation results. In the future, the authors would also like to make use of the tool in different research projects and further investigate the deviation in simulation results as well as individual building geometries. Currently, CityLDT supports the import of existing CityGML datasets; however, in the future, the flexibility to develop new building models in varied LoDs is also planned. Furthermore, the usage of external databases and pre-defined archetypes to generate CityGML models is envisioned by the authors.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: