Modelling Buildings in CityGML LOD1: Building Parts, Ter- rain Intersection Curve and Address Features

3D city models integrate heterogeneous urban data from multiple sources in a unified geospatial representation, combining both semantics and geometry. Although in the last decades, they are predominantly used for visualization, today they are used in a large range of tasks related to exploration, analysis, and management across multiple domains. The complexity of urban processes and the diversity of urban environment bring challenges to the implementation of 3D city models. To address such challenges, this paper presents the development process of a 3D city model of a single neighborhood in Sofia city based on CityGML 2.0 standard. The model represents the buildings in LOD1 with a focus on CityGML features related to the buildings like building part, terrain intersection curve and address. Similar building models of 18 cities provided as open datasets are explored and compared in order to extract good modeling practices. As a result, workflows for generation of 3D building models in LOD1 are elaborated and improvements in the feature modeling are proposed. Two options of building model are examined: modeling of a building as a single solid and modeling of a building with separate building parts. Finally, the possibilities for visualization of the model in popular platforms such as ArcGIS Pro and Cesium Ion are explored.


Introduction
Many cities create and operate 3D semantic models striving to ensure a comprehensive planning and maintenance processes. A digital 3D representation of a building is the key component of a digital urbanscape. CityGML is an open XML-based standard, proposed by of the Open Geospatial Consortium (OGC). This is an application independent Geospatial Information Model designed for semantic representation of city objects and landscape in three-dimensional space. The CityGML standard is also a reference model in the European INSPIRE initiative [1] (p. xv). The building model is the most developed thematic concept [1]. However, there is a lack of detailed information on how to generate a valid CityGML model with a precise representation of building parts, addresses and terrain intersection curve (TIC) and what challenges can occur while modeling these features.
There is a wide range of possible applications of 3D city models [2]. CityGML plays a key role in development of these models by providing not only a geometry representation, which is needed for various spatial analysis, but a semantic description of city objects with different features. It supports different Levels of Detail (LOD). This paper focuses on LOD1 represented by prismatic buildings with flat top surfaces. This type of LOD can be considered as a starting point when the information about rooftops' geometry is not available. Although LOD1 building models are simple, they are widely used in various applications [3]. Besides GML-based encoding of the standard, there are other encodings such as CityJSON [4] and relational database/SQL encoding [5]. Although a wide adoption of the standard, the practices related to the creation of CityGML models do not assume a uniform approach, especially when a particular feature need to be modeled such as the TIC or the building part.
The existing 3D city models often cannot meet all requirements of different stakeholders: local authorities, urban planners, real estate developers or architects. Julin et al. [6] highlight a gap between 3D city models and the initial expectations of the wide range of possible uses (e.g., visualization or any kind of spatial analysis). The large-sized city models imply challenges regarding their storage and update [7]. To be a useful resource for the public authorities and other stakeholders, the 3D city models need to be constantly updated [8]. Ledoux et al. [4] (p. 2) argue that CityGML-based models are quite difficult to parse and extract information from.
The city of Zurich provides a showcase of different applications of the 3D city model including the planning of high-rise buildings and microclimate studies [9]. It is worth to note that CityGML is used in a limited way, according to the authors. The open data portal gives an access to 3D building datasets in *.gpkg, .*shp, *.dxf and *.gdb formats only [10]. In contrary, the Kalasatama Digital Twins Project shows a wider adoption of CityGML 2.0 standard by developing a city information model, which coexists with the reality mesh model of the territory [11].
Experimental workflows are developed considering the whole process of the 3D city modeling in detail. Dimitrov and Petrova-Antonova [12] propose a workflow starting from the preparation of 2D data to the generation of a CityGML model and finally visualizing it in a web application.
Some of the 3D city models are provided as open data, which can be used by third parties. For example, the 3D model of Prague developed in LOD2 is available, but in a proprietary format [13]. The Novi Sad project provides a highly detailed description of the 3D city model generation, including LIDAR data acquisition, 3D processing and webbased visualization [14].
The splitting a building into its parts and managing this semantic hierarchy is a feature of the CityGML standard. Agugiaro describes an experimental case of enriching an existing CityGML model in LOD2 of the city of Vienna [15]. Semantic data is added and the existing CityGML model is regenerated to contain single-part and multi-part buildings. In addition, the model is extended with building models in LOD0 and LOD1. Biljecki et al. [16] underline that LOD1 models can have differentiated top surfaces without splitting the buildings into their parts. This variation of LOD1 is not restricted by the standard and according to the proposal of the LOD specification it could belong to LOD1.3. A similar case of different roof heights in LOD1 is noticed [1] (p. 67).
It is worth noting that the selection of an appropriate 3D geometry representation for buildings could be a challenging task. Recent research dedicated to the Digital geoTwin of Vienna considers the methods of creation of 2D data from 3D models or generating coarser 3D models from more detailed 3D models [17]. The authors introduce an addition to the improved LOD specification, proposed by Biljecki et al. [16].
Another specific feature of the building model in CityGML standard is the Terrain Intersection Curve (TIC). This feature delineates an intersection between a building and a terrain surface [1] (p. 13). It serves for better positioning of a building on a site. Yan et al. [18] investigate the ways the terrain intersection curve can be generated and propose five cases of the generation of the TIC depending on the initial datasets. The 2D footprints and the digital terrain model (DTM) are the most used datasets for development of building models in LOD1. According to the proposed method, the resulting building model gets a bottom non-planar surface draped onto the ground surface, which is a rare approach.
The 3D geometry is an important base for various types of spatial analysis, e.g., noise propagation, energy modeling or wind simulation. It is assumed that there is no 3D model suitable for all possible applications [19]. A coarse model with correct geometry can be more valuable comparing to the more detailed model with geometrical errors. It is easier to conduct an environmental analysis such as a wind simulation if the 3D model is reasonably simplified. For example, the edges less than 2 meters can be removed [20] with the help of a sweep-plane algorithm proposed by Piepereit et al. [21]. This simplification method works with extruded 3D solids, while it will be more efficient to generalize footprints before the extrusion. The LOD0 footprint could play here an important role as a basis for the extrusion of buildings.
Finally, the possible integration of cadastral data and 3D city models provides interesting prospects, if the cadastral database is continuously used for the model's update. The footprints used for extrusion of buildings in LOD1 often come from the cadastral map. The study of the 3D cadaster in China [22] shows that CityGML is close to another XMLbased format ISO19152 LADM dedicated for land administration. LADM can contain a linkage to 3D models of building structures. In this case LOD1 models could incorporate cadastral footprints as LOD0 features.
This paper aims to tackle the challenges related to development of 3D building models in LOD1 by modeling of a single neighborhood of Sofia city in Bulgaria following the good practices of the existing 3D city models. The proposed 3D building model resolves issues related to representation of building parts, addresses and TIC in CityGML 2.0 standard. Two methods for dealing with buildings having differentiated rooftops are examined: modeling of a building as a single solid and modeling of a building with separate building parts. In addition, a new method of modeling of the TIC is proposed. Finally, an address feature as a point object is implemented.
The remainder of the paper is structured as follows. Section 2 presents a comparison of 18 datasets from various cities worldwide and different modeling methods of the CityGML building in LOD1. Section 3 describes the study area and the corresponding data sources; Section 4 is dedicated to the modeling process of 3D building features implementing improvements in the model structure. Section 5 shows the visualization of the proposed building model and discusses related issues. Sections 6 discusses the obtained results. Section 7 concludes the paper and gives directions for future work.

Overview of 3D City Models: Building Parts, Terrain Intersection Curves, Addresses
This section provides an overview of the open datasets identified by the 3D geoinformation research group (Delft University of technology) [23]. The official CityGML datasets of 18 cities available on geoportals of local authorities are selected for exploration. The building models in LOD1 developed within research projects, such as that of Singapore, are excluded from the study. Building models, which are not based on CityGML standard are also not considered. Table 1 presents a comparison of building models, giving information about the country and city where the model is produced, year of the last update, and a LOD implemented. The columns "Building part" and "TIC" demonstrate the presence of those features. The column "xAl Address + geometry" shows whether an address is represented as an xAl-based feature, plain text or it contains a point geometry as well. Table 1 includes primary LOD1 datasets, except those of Vienna and Linz, which have LOD2. All the datasets are visually explored using FZK Viewer. Regional specifics seem to be quite indicative. Only one US city model (New York) is examined, since it is delivered as publicly available CityGML dataset. It dates from 2016 and future plans for any updates are not affirmed. Other US city models rely mainly on ESRI proprietary formats and less semantically rich 3D formats such as 3DS, OBJ, DAE etc. In contrary, there is a range of cities in Germany (note that North Rhine-Westphalia State consists of 29 cities) where official CityGML datasets are publicly available. Berlin and Potsdam provide datasets dated back to 2014 and 2012 accordingly. Another significant group of cities adopting CityGML standard can be found in Finland and Estonia. Although, a lot of papers on CityGML-related topics are published by researchers from Delft University of Technology in Netherlands, only Rotterdam has an official CityGML model. In the case of Amsterdam, only models based on DAE and DXF formats are available. Worth to note that a large country-wide dataset 3DBAG relies on CityJSON and other 3D formats.
The building part is implemented in 5 from 18 datasets: Linz, Vienna, North Rhine-Westphalia State (NRW), Hamburg and Rotterdam. Vienna and Linz are modeled in LOD2. In the case of Vienna, the building part is purely defined by the change of roof form and elevation. The dataset of Linz demonstrates detailed structures (even steps in stairs) and fails to meet any requirements of SIG3D manual regarding the building parts [24] (pp. [18][19][20]. Sometimes building parts represent tiny elements such as a stair railing, but it doesn't provide any benefits. NRW and Hamburg implement the building part in a similar way: parts depict the main forms of a building as extruded footprints without the evidence of various usages. The last case of Rotterdam follows the same approach as that of NRW and Hamburg, but the buildings are quite detailed since their parts are extruded separately and have different height attributes. The address feature is implemented in 4 different ways: (1) an address feature as a regular xAl feature (7 of 18 datasets); (2) an address feature with xAl structure and point geometry (3 of 18 datasets); (3) an address stored as a plain custom attribute (1 of 18 datasets); (4) a missing address in any form (7 of 18 datasets). The case of Rotterdam shows the address features as geometrical points with limited xAl information. The address point itself is located within the building footprint.
The TIC is implemented only in 2 city models (Hamburg and Espoo). This feature is generated as an intersection line of an extruded building footprint and a terrain surface in both cases. A building itself usually is elevated according to a minimum Z-value of its outline draped onto a terrain surface [21]. This can be considered as purely formal approach, while no underground structures are modeled. Another interesting point in both cases is related to a TIC surrounding each building in a group of buildings. The adjacent buildings are constructed in a row with no gaps and logically there should be no terrain intersection lines located on adjacent wall surfaces.
Taking into account the above considerations, the following approach is chosen for development of the proposed 3D city model. The 3D building model includes building parts, although some issues of representing the hierarchy "building -building part" arise in model visualization in other GIS software. The significant variations of the rooftop levels within a single solid are manually modeled. They are considered in the proposed LOD 1.3 by Biljecky et al. [16] (p. 30). Manual editing is an appropriate method of modeling in case of landmark, in which significant variations of rooftops determine the perception of a building.
The address feature is modeled as a geometrical point or points if there are multiple addresses assigned to a single building. Within case of multiple addresses for a single building, the multiPoint attribute allows precise specification of the building entrances' locations [13]. The point coordinates can be 2D or 3D. This could serve for navigation purposes at any LOD.
The TIC is an optional feature when the underground structures are unknown. It represents an intersection with a ground on a façade surface. The implementation of TIC features without unnecessary lines on the adjacent wall surfaces can lead to a more complicated workflow. In this paper, we propose a new approach for modeling of TIC, where intersection curves surround only external walls of a group of buildings.

Study Area and Data Sources
This section describes the specifics of the study area and data sources used for modeling.

Study Area
Sofia is a capital and the largest city of Bulgaria with a population of nearly 1.27 million. It consists of 24 districts. Given its heterogeneity in geometry, infrastructure and environment, district Lozenets of Sofia is chosen as a case study for the development of a 3D city model. A significant part of the territory of the district is occupied by low-rise residential buildings among trees and shrubs. At the same time, there are regions with intensive construction such as neighborhood Krastova vada, where problems with accessibility and availability of the road infrastructure, public spaces and public services arise. The neighborhood covers an area is of 59 hectares.

Data Sources
The datasets for implementation of the city model are primary cadastral data provided by Sofiaplan -a municipal enterprise responsible for the spatial and strategic planning of Sofia Municipality. The coordinate reference system of source data is BGS2005 / CCS2005 (Bulgaria Geodetic System 2005, EPSG: 7801), which is the one generally used by the city of Sofia. Table 2 provides a description of the input datasets. The building footprints originate from the cadastral map and contain various attributes, including floor count and codes of usage type. However, there is no link between the buildings and their corresponding addresses. Every footprint represents a single building without separate building parts. Adjacent buildings within the same parcel as garages, warehouses etc., are treated in the cadaster as separate property items. Thus, this information can't be used as a basis for the modeling of building parts. Figure 1 shows the garage building as a separate property on the cadastral map and in Google Earth view. To calculate the building heights, the buildings are grouped into three categories according to their usage type: (1) residential buildings, (2) amenities like schools or retail and (3) others.
Several buildings with substantial differences in the heights of their parts are selected to be modeled using the building part feature in CityGML. Google Earth imagery and an orthophoto of the study area are used for the visual inspection and selection of the most suitable buildings. Their footprints are extracted to a separate dataset and manually divided into regions with different heights using QGIS.
Since there is no information about the underground structures, the TIC has to be generated automatically based on the intersection between the buildings and the terrain.
Addresses are represented as points. Since some of them are located outside of the building footprints, additional effort to join the buildings and addresses is needed. Certain buildings have more than one address due to availability of several separate entrances. The parcels do not provide any useful information except for spatial linking of addresses and buildings.
Terrain contours with 1 meter interval are used to form a digital terrain model of the neighborhood. City unit geometry represents administrative boundaries of Krastova vada and clips all the relevant datasets. The satellite imagery has a 0.3-meter resolution and 3 bands containing RGB-values. This dataset is used as a texture for rooftops.

Modeling of Terrain Intersection Curve and Buildings in LOD1
This section describes the modeling process of the buildings, including building parts, addresses and TIC. FME Workbench 2021.1 is used as a tool for data transformation. The overall modeling process is shown in Figure 2. To enrich buildings with address information, the datasets containing building footprints, addresses and parcels are spatially joined. Then the TIN surface based on the terrain contours is generated. The building footprints and address points are elevated. At this step, the workflow is divided into two paths. The first path considers a CityGML building model in LOD1 with building parts. The second one processes buildings with differentiated rooftops as single solids. Both paths provide textures of the building rooftops obtained from an orthophoto imagery.

Integration of Buildings and Addresses
There is no explicit link between the address points and the corresponding buildings. Thus, the following rules are applied to merge them: 1. Link parcels and buildings based on the boundaries of parcels and footprint centroids. 2. Link addresses and footprints if an address point or points are located within a footprint.
3. Link addresses and footprints if an address point or points are located within a 2meter distance from a footprint; 4. Link addresses and footprints if an address point or points share the same parcel with a building. Figure 3 shows the case when the address (a) is quite far from the footprint (b), but both are located in the same parcel. The centroids of the footprints are marked with the red crosses, while the address points are represented with red dots. The addresses and buildings are linked via an attribute "gml_parent_id", which is a unique ID of a building. The processed building footprints and the address points are written into a new dataset.

Modeling of Terrain Intersection Curve
A preliminary 2D version of TICs for every group of adjacent buildings is generated. Figure 4 shows a case when the TIC outlines every building in a group (a) and a case, where the proposed method for removal of the duplicating TIC features is applied (b). All curves related to the same building are grouped by an ID in both cases.  Finally, the TICs are appended to the dataset with building footprints and address points for further processing.
At this step, a triangular irregular network (TIN) of the terrain surface is created based on the contours. Building footprints are draped onto the terrain and form breaklines in it [21]. The resulting building footprints are elevated to the TIN up to a minimum Zvalue of their projections onto the terrain. 2D terrain intersection curves from the previous step are draped onto the terrain as well ( Figure 5). The vertical scale of Figure 5 is exaggerated.

Modeling of Buildings in LOD1
The modeling of the buildings assumes several variations depending on the way how the building part is treated. First, a Z-offset to the enriched building footprints is applied and an extrusion is performed. The heights are calculated according to the usage types of the buildings. The calculation of heights is performed based on these categories, e.g., the height of residential buildings is calculated as follows (1) Initially, all buildings are modeled as single solids without buildings parts or rooftop variations. The address features are written as points by setting "citygml_lodname" to "multiPoint" and "citygml_feature_role" to "address". The address points are stored as geometrical objects, which can be used for navigation purposes as it is shown in Figure 6. The 3D TICs are added to the building features and linked to them based on "gml_id" attribute. The final enriched buildings' dataset is transformed to CityGML format in LOD1. Two methods of modeling the buildings with uneven roof surfaces are proposed: 1) Modeling a solid building with a differentiated rooftop, and 2) Modeling a building as a group of building parts with different heights.

Modeling a Solid Building with a Differentiated Rooftop
This method requires a manual editing of solids without creating of the building parts' features. Two arbitrary buildings with significant variations of the heights are selected and exported as named groups. SketchUp 2018 is used to divide their rooftops into faces with different heights. Figure 7 shows the result of the applied processing in comparison with the Google Earth view. The initial buildings selected for the refinement are substituted with their manually obtained versions. Finally, the CityGML attributes are reassigned, and the new versions of the building are written to a new dataset.
Rooftops are extracted from a satellite imagery using a geometry filter. Every planar face with a positive normal vector is treated as a roof. Walls have their own color for visualization purposes. The same principle of reading the CityGML dataset, enriching and writing building models back to CityGML format is applied. Figure 8 shows the resulted building model in FZKViewer.

Modeling a Building as a Group of Building Parts with Different Heights
This method follows the building part concept proposed in CityGML standard. Every building part becomes a child feature to a parent building. The footprints of five buildings are divided manually into parts with different floor counts and stored as a new vector layer in QGIS.
The initial footprints of these buildings from the cadaster are substituted with the polygons of the building parts. All the polygons are extruded. The parent geometry is removed for the buildings with parts, keeping all the geometry as building parts. To establish the hierarchy between the building and its building parts, the attribute "gml_par-ent_id" of the building part is populated with the value of the corresponding building "gml_id". The attribute "citygml_feature_role" is set to "consistsOfBuildingPart" value. The satellite textures are assigned to the rooftops. A CityGML dataset containing building part features is produced. Figure 9 shows the selected building part feature and its attributes in FZKViewer.

Results and Visualization Issues
In the previous steps FKZViewer was used for visualization purposes. In this section ArcGIS Pro and Cesium Ion are used. ArcGIS Pro is a desktop GIS-application with wide range of possibilities. Cesium Ion is a web platform for storing and visualizing for various kinds of geodata. The CityGML model contains 471 buildings and 198 addresses in both cases of building parts modeling. The dataset obtained in Section 4.3.2 is far more interesting case for visualization tests due to availability of "building-building part" hierarchy.

Visualizing in ArcGIS Pro
The dataset described in Section 4.3.2 is imported in ArcGIS Pro 2.7 with the help of Data Interoperability add-on, which is in fact an instance of FME Workbench. The imported CityGML dataset is shown in Figure 10. ArcGIS Pro divides the features into layers with the same type of geometry during the import. Building and building part features are converted to ESRI multipatch geometry. The TICs are represented by a vector line layer. Addresses are converted to a vector point layer. All geometry types, textures and attributes are preserved. However, buildings with building parts are represented as tabular data without geometry. The hierarchy of a building and building parts can be restored partially within ArcGIS Pro based on related tables even in the case of buildings without geometry. Figure  11 shows the selected hierarchy of "building-building part" in ArcGIS Pro. Figure 11. Building with building parts in ArcGIS Pro. Figure 12 shows the 3D building model with building parts, which is descibed in Section 4.3.2. The model is visualized using Cesium Ion. First, the initial CityGML model is tried to be visualized. Second, transformation into Cesium 3D-Tiles format is performed and the obtained model is also tried to be visualized. When CityGML and 3D-Tiles datasets contain standalone curves or points both visualizations failed. This is caused by inability to store polyline or point geometry in *.gltf format, which lies in the core of 3D-Tiles specification. When a building has building parts and no geometry inside itself only attributes of the main building feature are displayed as it is shown on Figure 13. The principles of generating 3D building models with building parts, addresses and the TIC in LOD1 and the possibility of assigning different attributes and textures are explored through a real use case of Sofia city.

Visualizing in Cesium Ion
The resulting CityGML models, presented in Sections 4.3.1 and 4.3.2, consist of a building model (Buildings, Building Parts) a Core model (CityModel, Address) and an Appearance model. Figure 14 shows an UML diagram of the implemented CityGML objects and features. The main difference between them is related to the way of treating buildings with differentiated roof tops. Section 4.3.1 proposes an approach with variations of rooftops within a single solid, while Section 4.3.2 considers multi-part buildings. TICs are added to 3D geometry of the buildings in both cases. In addition, both cases consider address features and textured rooftops. The situation, where multiple addresses correspond to one building is examined. The visualization compatibility of the obtained datasets is explored using ArcGIS Pro 2.7 and Cesium Ion. Based on the results from the exploration analysis of the existing 3D city models and from the experiments, we can conclude that the building module being the key element of the CityGML standard contains numerous variations even in LOD1. Two modeling methods of building with different rooftop levels are applied: building as a single solid with uneven roof (LOD 1.3 according to Biljecki et al. [16]) and building, consisting of separate building parts. The building part turns out to be a feature generating potential issues during visualization.
The address feature can contain geometrical representation, which is important for a precise navigation. There are web services, which can show mapped building entrances and propose routes to them as in the case of Yandex Maps [25]. A proper reading of the xAl structure can be problematicfor certain software packages. Thus, a custom string attribute for address information can be considered for implementation. In addition, there is no possibility to include the points into Cesium 3D-tiles for the time being.
To the best of our knowledge, the TIC turns out to be formally used feature, when the underground structures are not defined. Also, it hampers the process of importing CityGML model into other platforms like Cesium Ion. When underground structures are present, the TIC becomes a valuable feature, e.g., for energy modeling.

Conclusions and Outlook
The existing research on CityGML 3D modeling is mainly focused on the building representation in LOD1 as a simple solid, while skipping issues related to TIC, building parts, and addresses. This paper explores such issues by creating a 3D building model in LOD1 of Krastova vada neighborhood in Sofia city. The performed overview of the practices of modeling buildings in LOD1 shows that СityGML is applied in different ways and there is no consistent approach. Detailed guidelines for correct application of the standard could help for the wider adoption of the standard.
The building part feature remains an important characteristic of the building in the 3D city model. However, variations of rooftops turn out to be very formal argument for using a building part. From our point of view a separate property item in the cadaster is the main argument for the decision. A method considering a solid building with various rooftop heights obtained manually is proposed. This provides a possibility for modeling prominent landmark buildings more precisely. In addition, a case of a multi-part building is explored and implemented. The TIC and address points need to be justified before to be used in the 3D model as well.
As a future work, a more precise method for calculating building heights without initial elevation data can be implemented, following the approach proposed by Biljecky et al. [3]. If point clouds data or 3D photogrammetric meshes are available, they can be used to obtain next level of precision. The LOD0 footprint of a single building could aggregate geometry of parts as a single contour. Thus, basic types of spatial analysis can be conducted much easier using 2D-contour comparing to 3D-solids. The case when there is a 2D-outline of a building is like the concept of a Simple 3D Building in OpenStreetMap [26], which is adopted among multiple OpenStreetMap contributors. In future work enriched LOD0 footprints with building parts are planned to be used.
The CityGML standard seems to be a sophisticated conceptual model with multiple hierarchies and links, but not yet widely adopted by the software vendors comparing to IFC-format in AEC industry. Nevertheless, the CityGML building model schema natively provides a bridge between the "horizontal" GIS and "vertical" BIM.