Requirements, Development, and Evaluation of A National Building Standard—A Swedish Case Study

Abstract

The aim of this paper is to present a proposal for a national building standard in Sweden. We define requirements for the proposed standard, e.g., it should support development of 3D city models, connect to building information models (BIM) and national registers and be based on a national classification system for the urban environment. Based on these requirements we develop an Application Domain Extension (ADE) of the building model in the proposed CityGML 3.0 standard denoted CityGML Sve-Test. CityGML 3.0 includes several new features of interest, e.g., the space concept, enhanced possibilities to convert data, and to link to other standards. In our study we create test data according to CityGML Sve-Test and evaluate it against the requirements. It is shown that BIM models (in Industry Foundation Classes, IFC, format) can be converted to CityGML Sve-Test and that a classification system facilitates this conversion. The CityGML Sve-Test dataset can be used to increase the automation level in building permissions checking and a related study shows that CityGML 3.0 has capabilities to link to legal information and be a base for 3D cadastral index maps. Based on our experience, we suggest that the national building standard should conform to international standards and, if possible, include a classification system. The exchange format (GML, JSON etc.) might change, but to be based on a standardized data model ensures harmonized structures and concepts.

1. Introduction

Building information has been collected and maintained on regional and national level for centuries. During the last decades 3D representations of buildings have become increasingly common, especially in larger cities, as parts of 3D city models. Already in 2012 there were more than a thousand city models worldwide [1] and the number is growing [2,3]. Reasons for creating 3D city models vary, earlier the models were mainly used for visualization, but now they are used for other purposes as well, such as urban planning, decision making, analyses, and also to replace the 2D base maps in urban areas, which requires that the city models have connections to e.g., cadastral registers. To support these new requirements on the 3D city models, there is a need for new national standards to obtain a more uniform management of the building information. Some countries have recognized this need and have created national 3D building or city model standards, for example the Netherlands [4] and Germany [5].

3D representations of buildings are also common in architecture, engineering, and construction (AEC) companies where 3D computer aided design (CAD) models are now often replaced by more advanced building information models (BIM). Earlier 3D building representations were mainly used for presentation, but there is an increasing interest in using BIM for analyses and integration with geodata in 3D city models. Such 3D city models play an important role in the digital transformation of the built environment process and requires, among others, that there is a linkage between city models and BIM. This sets new demands on the models, but it also allows for new categories of people and applications to use them. Depending on the purpose of a 3D city model and expertise, the models are developed on different platforms using different techniques, e.g. using 3D GIS, BIM, or computer graphics [2,3,6].

One obstacle with linking building information between BIM and 3D city models is that 3D city models generally have a hierarchically strict structure as opposed to BIM where the same information can be described and associated in many ways [7,8,9]. One possible way to overcome such interoperable issues is to use a classification system. National classification systems have been used for a long time in the AEC industry, but their linkage to 3D city model applications have not been well studied. Other advantages of using a classification system in the BIM to 3D city model transformation is that the classification will enable common definition of terms, it can specify which elements to be included in BIM, and it will facilitate an automated conversion [10,11].

There is a need to complement a building or 3D city model standard with measuring guidelines to ensure that city objects are created in a uniform way, regardless of whether the geometric part of the building information is created from laser scanned or photogrammetric data, which is still most common, or from BIM. Examples of issues that can affect the resulting model are, among others, the minimum sizes of objects to include, how objects are measured (e.g., using mean roof height for roof measurements) [12], and the way the building objects are described (e.g., restricting which geometry types that are allowed) [13].

There are several aspects to consider in creating a national building standard. First the application requirements should be specified. Second, an international standard to conform to should, if possible, be chosen. The reason for this is that an international standard is often well established and is likely to be implemented by more software tools. Third, a classification system should, if such a system exists, be included in the standard to improve definition of terms and facilitate interoperability with several urban processes. Finally, the standard should be complemented with measuring guidelines to ensure a more uniform creation of the building objects.

The aim of this paper is to present a proposal for a national building standard in Sweden. In the study we (1) specify requirements for building objects, (2) develop a standard based on the requirements, (3) create test data according to the standard and perform some case studies, and (4) evaluate the proposed standard. It should be noted that the situation in Sweden resembles many other countries which make the results of the study general.

The paper is organized as follows. Section 2 gives an overview of applications for building information in 3D city models and BIM. Section 3 provides an overview of standards for the built environment, with the intention to both describe the standard to which the proposed Swedish standard should conform, and to other standards to which it could relate. Section 4 describes related work in this field. Section 5 describes requirements on building information at a national context. In Section 6 the development of a Swedish building standard is described and Section 7 evaluates the standard and describes test cases against the requirements. In Section 8 the findings are discussed and finally Section 9 concludes the paper.

2. Applications of 3D City Models and BIM

There are several applications for 3D city models, in [2] the authors identified 29 different types of use cases, for example energy demand estimation, building type classification, propagation of noise, 3D cadaster, urban planning, emergency response, and facility management. The diversity of use cases shows that 3D city models can be used for many purposes and this should be considered when planning for the implementation of a new 3D city model.

The integration of BIM and 3D city models can increase the use of the 3D information. The authors of [6] describe applications where combined BIM and 3D geodata city models are used, for example: 3D cadaster, where BIM contributes with more detailed geometry information and geodata with information about ownership and transaction history; navigation, where BIM provides indoor and geodata outdoor information; and urban environment analysis, where analyses of e.g., indoor climate, sunlight visualization, and energy consumption require both BIM and geodata.

In [3] the authors analyzed the functionality and usability of 19 3D city models in six Finnish cities. The following criteria were used: platform used; data accessibility, regional data coverage, and the use of as-planned information (e.g., BIM). 3D modelling experts were interviewed and the possibility to find real-time information, to interact, and better include stakeholders in the decision-making processes were described as important benefits. 3D city models should also include lifecycle management to support different decision-making processes in the municipalities. Most of the studied 3D city models included a small geographic area and had limited functionalities, but this was not what the cities had expected. In [3] the authors grouped the studied projects into three 3D city model categories: 3D GIS, BIM, and computer graphics. The categories overlap, but no project belonged to all categories. To capture all characteristics, a 3D city model should include all three perspectives and to accomplish this, a concept for harmonizing 3D city modelling is proposed (Figure 1).

Figure 1. A concept for harmonizing 3D city modelling from [3].

A drawback with a comprehensive 3D city model is that it includes many different user perspectives which can result in a very complex model. For many use cases a simple model will suffice, and a complex model with unnecessary information could cause problems. The research presented in [14] is critical to 3D city models that are too comprehensive for their purpose. To overcome this Kang describes five BIM-GIS integration levels (BG-IL) where the simplest integration is a coordinate reference system integration (BG-IL1), followed by geometry model integration (BG-IL2), element data integration (BG-IL3), relationship integration (BG-IL4), and finally the most advanced integration, semantic information integration (BG-IL5). Use cases can be mapped to the integration levels, for example visualization would require BG-IL2, facility management BG-IL3, navigation services BG-IL4, and semantic information queries BG-IL5.

3. Standards for the Built Environment

3.1. CityGML

The most comprehensive standard today for the exchange of 3D city models is the CityGML standard by the Open Geospatial Consortium [6,15]. The main focus of CityGML is to represent the geometric and semantic aspects of features in a city. To support this, CityGML contains an information model, divided into several sub-models of buildings, tunnels and bridges, city furniture, vegetation, etc. Furthermore, CityGML supports multiresolution modelling by including different levels of detail (LOD) where the geometry, topology, and semantics are described with varying complexity. The current version, CityGML 2.0 [15] defines five LODs (Figure 2a), from a digital elevation model (LOD0) to a detailed representation of both the interior and exterior of a building (LOD4). The main motives for having these levels are that applications need different representations of the buildings.

Figure 2. Examples of levels of detail (LOD) (a) in CityGML 2.0 from [16] and (b) in CityGML 3.0 from [17].

CityGML is currently being revised both to increase the usage of the standard in different areas and to improve the interoperability with relevant standards such as Industry Foundation Classes (IFC) [18], Land Administration Domain Model (LADM) [19], and IndoorGML [20,21]. In the new version, CityGML 3.0 [22], the core model has been restructured and extended and is now based on two abstract classes, Space and SpaceBoundary, to which all the geometric representations are associated. These classes are further divided into subclasses, LogicalSpace and PhysicalSpace. The LOD concept is also slightly modified. LOD4 is removed and instead both interior and exterior representations are allowed for all LODs, LOD0 to LOD3 (examples in Figure 2b). In addition, a new versioning module is developed having bitemporal timestamps for all objects (i.e., creationDate, terminationDate, and validTo, validFrom) and the possibility to have multiple versions of city models. It is also possible to describe time varying data for city objects and to integrate sensor data with 3D city models in the new dynamizer module.

Even though CityGML is a comprehensive standard, it can still not fulfil all requirements, for example in a national context or within a specific field. To overcome this, both CityGML version 2.0 and 3.0 allow for schema extensions to include additional information, either by using generic city objects and attributes, or by creating an Application Domain Extension (ADE). The use of an ADE seems to be the most commonly used technique for extending CityGML and have been used in many different areas [4,23,24,25,26]. An ADE is created as a new schema with its own namespace and the relevant CityGML classes are imported. The extensions can be created by creating new classes that inherits from CityGML classes; or by adding attributes to existing CityGML classes, but where the new attributes belong to the ADE namespace, described as “hook elements” in the XML schema definition file [15]. In [26] the authors performed a literature review of CityGML ADEs and found 44 publications describing ADE developments. Out of these, 18 were classified as general extensions, and the remaining ADEs were developed to meet more specific requirements within a certain field.

3.2. CityJSON

CityJSON is a JSON implementation of a large subset of CityGML 2.0 [27]; it is relatively new and is not an official OGC standard. The data structure of JSON is used in many programming languages and it is one of the preferred formats for data exchange on the web. It includes three simple datatypes (strings, numbers, booleans) and two data structures: arrays (an ordered list of elements) and objects (consisting of key/value pairs). In CityJSON, the CityGML 2.0 data model is flattened out and all hierarchies removed [28]. Figure 3 shows an example of how a building with two building parts can be represented. The geometries in CityJSON are described using the same 3D geometric primitives as in CityGML, but with some restrictions that for example only allow for one way of representing semantics and geometries of a feature.

Figure 3. Examples a CityJSON implementation of a building with two parts, from [28].

The CityJSON data model is documented as JSON schemas that also can be used to validate CityJSON files. The schemas are openly available at https://cityjson.org/schemas/. CityJSON can be extended, allowed extensions are add new complex attributes to an existing object; create or extend an object; and add new properties at the root. The extension is stored in a separate JSON file.

3.3. INSPIRE Building

The INSPIRE data specification for buildings [29] is one of the 34 spatial data themes in the INSPIRE directive issued by the European Union [30]. It is strongly influenced by CityGML 2.0 but also by other standards (e.g., ISO 6707 Building and Civil Engineering, DGIWG Feature Data Dictionary, and ISO 19152 Land Administration Domain Model), by use cases (e.g., for safety, environment, urban expansion, and infrastructures) [19,31,32] and by current national databases. The building theme includes buildings and other constructions that are important for environmental applications, e.g., elevated constructions and environmental barriers.

3.4. Industry Foundation Classes—IFC

IFC is an open ISO standard [18] that specifies a conceptual data schema and an exchange file format for BIM data and is developed and maintained by buildingSMART International. It is a comprehensive and well-established standard that is implemented by a large number of software. The aim of IFC is to advance information exchange between different actors and programs without information loss. IFC describes the building information from the design, construction, and management phases. It includes for example building objects, such as walls, ceilings, doors for the architectural design; and pipes, air outlets, heaters, and valves for technical building equipment. IFC uses space elements (IfcSpace) to describe certain functions for areas and volumes within a building.

Requirements on the IFC model can be defined using the ISO standard Information Delivery Manual (IDM) [33]. The intention with this is to facilitate the interoperability between software applications used during the whole lifecycle of a construction. The IDM can be translated into Model View Definitions (MVDs) to create a subset of the IFC schema. This is done to delimit the IFC model for a certain purpose, e.g., to be used in a specific software or analysis. MVDs can be encoded in a neutral and machine-readable format called mvdXML and gives implementation-specific guidance of the structure and format, for example which objects to be included together with their required attributes and possible values.

3.5. Land Administration Domain Model—LADM

The LADM standard [19] describes the part of the land registration that concerns the rights, responsibilities, and restrictions that affect land or water, and the geometrical representation of those objects. The standard supports 3D representation and is divided into four packages: Party (persons and organizations involved in the rights transaction), Administrative (rights, restrictions, responsibilities, and administrative units), Spatial unit (textual, point, area or volume representation of legal spaces for buildings, and utility networks) and Surveying and representation (surveying spatial sources and representing geometries and topology). In LADM, the base class of the Spatial unit package is LA_SpatialUnit with LA_LegalSpaceBuildingUnit as a subclass that can represent the geometry of a LA_BAUnit (Basic Administrative Unit, e.g., an apartment or a garage). A legal space does not have to correspond to a physical space [34].

3.6. LandInfra and InfraGML

LandInfra is a relatively new OGC standard for land and civil engineering infrastructure facilities [35]. It includes features such as roads, railways, land features, land division, survey, facilities, projects, and alignment. Wet infrastructure, such as water distribution systems, storm drainage and waste water will be included in a later version of the standard. LandInfra describes the division of land based on administrative (jurisdictions and districts) and on interests in land (land parcels, easements, and condominiums). InfraGML is an OGC encoding standard that defines the GML encoding for LandInfra. It is published as eight parts: Core, LandFeature, Facility and Projects, Alignment, Road, Railway, Survey, and LandDivision.

3.7. Swedish National Standards

Svensk Geoprocess Byggnad 3.0 [36] is a specification for 2D and 3D buildings in Sweden. It is mainly based on CityGML and the INSPIRE data specification for buildings together with specific national building information (e.g., attributes for house on someone else’s land and unidentified area); furthermore, the geometry are only modelled on building parts (cf. [37]). The SGP Building specification does not comply to the CityGML or INSPIRE extension rules.

CoClass is a new Swedish digital construction classification system for the built environment, with classes ranging from residential areas down to the smallest screw [38]. It is adapted to BIM, and contains descriptions of objects, properties, and activities throughout the lifecycle for both buildings and facilities. By using CoClass, all parties will have access to a common language with the same concepts and terminologies. CoClass will also create a stricter IFC structure. The theoretical ground of CoClass is ISO 12006-2:2015 (Building construction—Organization of information about construction works—Part 2: Framework for classification) [39] and the principle of reference designation is based entirely on SS-EN 81346-1 (Industrial systems, installations and equipment and industrial products—Structuring principles and reference designations—Part 1: Basic rules) [40].

4. Related Work

4.1. Development of National 3D Building and 3D City Model Standards

The implementation of building and 3D city model standards is a complex process. To ensure that all city models within a country are consistent, many aspects and requirements should be considered during the implementation. For this, national guidelines need to complement the standard. The pilot implementation of the national 3D standard in the Netherlands (as a CityGML ADE extension, IMGeo-CityGML) is an example of this [4]. Around 600 people from 100 organizations were involved and a national 3D interest group was formed to coordinate the implementation. A result from the pilot was a toolkit for data producers wanting to convert their 2D IMGeo data into IMGeo-CityGML, including implementation specifications, example data, a 3D validator, technical specifications, and a web site for show cases. The IMGeo-CityGML extension contains all additional definitions from the 2D IMGeo, including a link to the 2D geometry which makes it possible to store 2D and 3D data in the same model [25]. To aid data providers and to get a more uniform implementation of 3D city models, national implementation guidelines were created. The technical specifications include guidelines for both the collection and modelling of objects for the IMGeo-CityGML [41]. It describes how the existing 2D IMGeo data can be used as the basis to automatically generate 3D topography for LOD0 to LOD2.

Germany has also developed a national 3D standard for buildings. New requirements on 3D building information (e.g., for urban planning and noise and energy simulations) and the fact that many German cities created their own city models (that often lacked updating possibilities and quality information) resulted in a decision to create a national dataset for 3D buildings [5]. The standard is created as a CityGML 1.0 ADE, AvD-CityGM, that both limits and extends CityGML. Only the modules Building, Generics, and Appearance and the LODs LOD1 and LOD2 are allowed, but additional attributes for quality information is added in the ADE [42]. The nationwide dataset for LOD1 buildings is completed and the dataset for LOD2 buildings is on its way. The AdV-CityGML datasets are centrally stored in a 3D City Database (3DCityDB), an open source solution that includes a spatial relational database schema for all thematic modules from CityGML. Various export formats from 3DCityDB are available, e.g., KML, Collada, dxf, and 3D shape.

In a Turkish study, the authors of [43] examined if CityGML ADE extensions can be used to create 3D city models from the Turkish TRKBIS standard for large-scale topographic features. A comparison between CityGML buildings and TRKBIS buildings was performed and a CityGML ADE that includes all additional classes, attributes, and code lists from TRKBIS was developed in UML. A CityGML ADE for the transport data theme was also created in UML using the same method. Future work in this research is to generate GML schemas from the UML models and to test it with real data.

4.2. Harmonization and Validation of 3D Buildings/City Models

Harmonized information is a vital part when trying to achieve a digital and more process-oriented information flow for example in a smart city or between phases in the planning and building process. However, definition of concepts in a specification can be ambiguous and allow for many variants. The definitions are also often described as recommendations, not as requirements. This can result in concepts that are described slightly different in different datasets which can hamper information exchange between these datasets. This becomes even more prominent when information is exchanged between two standards that have many concepts in common, but where the concepts are defined in slightly different ways [37]. One way to overcome this is to create modelling guidelines with recommendations on how to model 3D building objects in a correct way for the intended purpose. An example of this is the guidelines by the SIG3D Quality Working Group [13] which states for example how the LODs should be defined, which geometry types to use, and valid and invalid ways to divide a building into building parts. To ensure that data is collected or converted in a uniform manner, surveying guidelines should also be used. The Swedish surveying guidelines for Geometric representation on exchange [44], is an example of this. The guidelines define requirements for data collection and data exchange for information that conform to the Swedish specification for buildings [36] and four other spatial themes. According to the guidelines, buildings can be represented in 2D or 3D and in different LODs. Different LODs have different requirements both concerning surveying methods, tolerances, and how the geometry should be represented.

A dataset does not fully conform to a standard if it does not pass the validation rules given in the standard. OGC, the Sig3D quality group, and EuroSDR performed a quality interoperability experiment to give a better understanding of the requirements in CityGML and how these requirements can be validated [45]. Geometric and semantic validations were performed, and conformance requirements were tested in a formal and automatic way. Results show that to be able to validate geometries, the number of possible geometry types must be restricted, tolerance requirements for the geometries must be added and semantics and geometry must cohere.

4.3. Integration of 3D City Models and BIM

It is becoming increasingly common to store information about a building in both geodata and BIM formats and using this information for different purposes during the lifetime of a building. Examples of this are to accomplish a digital information flow of 3D building information in the AEC industry, for digital representations of the planning, design, and construction of buildings, but also for cities where officials need the information for e.g., building permits and 3D real property formation. This leads to an increasing demand for exchanging and reusing information within and between the standards that describe 3D building information. There are many challenges to overcome to be able to exchange 3D building information between BIM and geodata formats. Often a BIM model is transformed to a geodata model and the software and format in which the BIM model was created, and to which geodata format it should be transformed, have a substantial influence on the complexity of the transformation. Several standards also share many concepts, but these concepts are defined in similar, but not identical ways. One example of this is the geometry representation, IFC uses many different types of geometries e.g., Swept Solid, Constructive Solid Geometry, and BRep, while CityGML only uses BRep, which can result in complex geometric transformations [6,7]. Another example is the LOD concept, in IFC LOD stands for Level of Development and in CityGML for Level of Detail, and the two LODs do not match.

One way of connecting geodata and BIM models is to convert BIM models to create or update 3D geodata city models. The authors of [6] classified the integration of BIM and geodata into three categories: data level, process level, and application level. A comparison of the effectiveness, extensibility, effort, and flexibility shows that the methods are suitable for different purposes. An integration at the data level with a semi-automatic conversion and translation together with extensions of existing standards could, according to the authors, be a good compromise. An important aspect here is that buildings in a city model should be similar irrespective of if they are derived from BIM-data or from laser scanning/photogrammetry data. This could be achieved by creating measuring guidelines and routines based on these guidelines for both BIM data conversion and lasers scanning/photogrammetry data. By this, the two data sources could be used interchangeably, i.e., provide similar building objects. This is described in a case study by [12] where they show that the differences between building models from the two sources are only on a decimeter level.

All kinds of integration between city models and BIM, including data conversion, set requirements on the city model standard. A recent study of how to extend CityGML with an ADE to obtain good conversion was performed by [46]. They adopted a triple graph grammar technique to formally relate IFC and the CityGML ADE, both semantically and geometrically. Data conversion from, and integration with, IFC has also been considered in the development of CityGML 3.0 and a new feature class, BuildingConstructiveElement, has been introduced to facilitate the linkage to IFC [21].

The interoperability between BIM and 3D city models can also be enhanced if a common classification system is used. A prerequisite for this is that all objects in the models are classified, i.e., all objects have an attribute for the classification code. The classification of the models must be standardized and readable regardless of who created it or in which tool it was created. One example of where a common classification system can be used is in an automated check of building permit applications. The information needed in the building permit process is identified and the corresponding building objects are classified. This will facilitate the automated checking of the model against regulations in the detailed development plan as the classification will give a more precise definition of the object to be checked [47].

To go even further in the interoperability, one could introduce common object identifiers for features in the BIM and 3D city model. This is a prerequisite to facilitate versioning and lifecycle data management. Common identifiers are not dealt with in this study.

4.4. Connection to 2D Models and Registers

Today, many registers have linkages to and need to be synchronized with 2D maps. If a 3D city model should replace the current 2D base map it must connect to the 2D information, either by including this information in the 3D models or by links to the 2D models. Links to other types of registers, e.g., cadaster registers should also be facilitated. In the Netherlands, this was solved in a CityGML ADE (IMGeo-CityGML) that includes links from all CityGML objects to a 2D geometry, which makes it possible to store both 2D and 3D data in the same model [25].

Another way of handling the connections is by linkage between the BIM and the CityGML models. It can for example be used if additional information from BIM is required to be easily available. This can be achieved by using external referencing from CityGML objects to corresponding objects in external BIM databases [15,48], i.e., without any transformation of data between the models. The external referencing of CityGML objects, via a Uniform Resource Identifier (URI), to objects in external databases can also be used to link to e.g., LADM data and other information sources that are required to complete the 3D model (Figure 4).

Figure 4. External references in CityGML from the CityGML 2.0 standard [15].

4.5. 3D Cadaster

The density of many cities is high and has led to a need for a more detailed way of dividing the use of spaces within buildings. This in turn has led to an increasing number of 3D property registrations. In many cases, the 3D properties are currently not registered as volumes (in a digital 3D model). For example, in Sweden there is a 2D representation of the 3D property in the 2D digital index map, and a textual description of the 3D parts in the land register [49]. To better manage and search for cadasters, there is a growing demand for linking 3D cadaster to digital 3D models. From a technical perspective BIM can be used for defining the boundaries of 3D cadaster. However, in many countries this is not possible from a legal perspective (see e.g., [50], for a discussion on rules for drawing cadastral boundaries within a building in Sweden). A BIM could be used for visualization of the extent of the 3D property units, but to get an overview of the 3D property units in larger areas, a city model is required. For example, in [51] the authors visualized legal spaces in a LoD1 city model based on a CityGML 2.0 ADE. City models also facilitate analysis of the cadaster information since the city models can be linked to other types of register and geospatial information.

The new proposed version 3.0 of CityGML has taken 3D cadaster into account by providing a stronger connection to the LADM standard [19]. Among others, the enhanced core module makes it possible to distinguish between physical and logical spaces, where the logical spaces e.g., could represent the legal spaces of the 3D cadaster. If city models are used for visualization and analyses of 3D cadaster it is preferable that data describing both the physical buildings and the 3D property units can be derived from a BIM-model; a methodology to perform this is proposed by [52].

4.6. Building Permit Process

There is a growing interest to automate the building permit process, as the current process often prolongs the construction time. Information, such as detailed development plans and building permit regulations, are still often handled in paper format or as pdf files [53,54,55]. This can make the process ineffective, both concerning time and cost. Therefore, the process needs to be more standardized and strive towards having a process-oriented approach where all actors can share information. A proposal for such an approach has been developed within the EuroSDR GeoBIM project [56] where the current building permit process was studied in the participating countries. Based on that study and future visions, the project defined a workflow for information exchange in the building permit process where 3D building information play a prominent role; it is e.g., used to improve the rule checking of the building permit application. To enable parts of this rule checking, the BIM-model of the proposed building can be converted to geodata and integrated in a 3D city model. The updated city model is then utilized both for visual inspection as well as in automated routines where the properties of the building and the surrounding environment are tested against rules in a digital detail development plan [55].

4.7. CityGML ADEs

To fulfil specific requirements that occurs within different areas, CityGML has been extended to suite various applications. In [57] the authors created an ADE extension that includes information needed to store and manage data required for calculation of building energy flows. The authors of [58] identified a need to be able to better compare the results from different noise studies. This could be facilitated by having more standardized input and output data for noise simulations. To achieve this, the existing Noise ADE was extended, that is, also an ADE can be extended. In [23] the authors created an ADE extension with features that are needed for geotechnical work at construction sites. The authors of [24] created a CityGML ADE extension that includes detailed description of ownership of condominiums. It is called CityGML-LADM ADM and has links to the LADM standard [19] to facilitate the cadastral management. Another ADE that has links to a standard is the CityGML Infra ADE [59]. It includes additional information from the OGC standard LandInfra [35] that is not included in CityGML. LandInfra includes valuable information, but the standard is rather new, is rarely used, and has no software support. The ADE and a software transform tool between the CityGML Infra ADE and InfraGML (the GML implementation of LandInfra) are expected to increase the use of LandInfra.

5. Requirements for the National Building Standard

National standards for 3D buildings and city models demand a requirement analysis [3,14]. Will the 3D building data only be used for visualization or should it also be used for analyses? Both cases can affect the complexity of the model, but in different ways. For cartographic visualization, the building information may need to be generalized to improve performance. In the latter case, the analyses to be supported could affect the complexity of the model. That is, what additional textual, semantic, and geometric information should be included in the standard to fulfil all the specified requirements. One way to assure that the potential usage of the building information is reached is to create implementation requirements that, as far as possible, are measurable (see [4]). This can be used to verify to what extent the requirements are fulfilled once the standard has been implemented.

There is currently no well adopted national standard for 3D buildings in Sweden. The Swedish 2D and 3D building specification [36] was finalized in 2018, but it has not been implemented in production, and new requirements have emerged, such as better support for the planning and building process. To investigate the requirements as well as test and evaluate the standard a national project was launched. The project was coordinated by Lantmäteriet (the Swedish mapping, cadastral, and land registration authority); the project also included experts from academia, some larger cities and technical consultants (see [47]). The results from the project are reported to Geodatarådet, a board that governs the development and use of new geodata standards in Sweden. The proposed national building standard has the working name CityGML Sve-Test.

The standard does not need to support other domain-specific applications, such as noise or energy flow modelling. However, it should be possible to extend the building standard to support these applications. Furthermore, it should be possible to complement the building standard with information or standards of other themes to create a comprehensive national 3D city model standard.

Based on the description above, the requirements used in the development of a proposal for the new Swedish national building standard, CityGML Sve-Test, are:

• The national building standard should support the representation of both 2D and 3D buildings.
• In order to be interoperable with city models, to be able to view the building information in software and use common tools for data conversion from e.g., BIM (IFC), the national building standard should comply to an official international standard that is well established and implemented by other countries or cities.
• The national building standard should be supplemented with surveying and modelling guidelines to ensure a uniform implementation (e.g., similar to [44] and [13]).
• The national building standard should include all attribute information from the Swedish specification for 2D and 3D buildings [36].
• The Swedish construction classification system CoClass [38] should be used in the national building standard. CoClass is also recommended to be used in BIM-models and using CoClass in both BIM and geodata models will facilitate integration and conversion between these data domains.
• All references from the national building standard to registers, 2D models etc., should be performed using external referencing.
• From a cadaster perspective the national building standard should support:
  • visualization of a simplified 3D cadaster;
  • link to the BIM where the borders of the 3D cadaster are defined using external referencing;
  • link to 2D cadaster, 3D cadaster, and other relevant cadastral information using external referencing.
• The national building standard should support the building permit process with:
  • additional information and links to other registers that is required for the building permit process using external referencing;
  • conversion of a (standardized) BIM model to enable visual as well as quantitative rule checking of building permit rules (in e.g., a digital detail development plan).

6. Development of a National Building Standard—CityGML Sve-Test

6.1. Selection of International 3D City Model Standard

CityGML is the most comprehensive standard today for the exchange of 3D city models [6]. It includes a well-established building model that can be implemented as is or together with additional information in an ADE (e.g., [4,5,23,24,43,59]). Therefore, it was decided that the proposed national Swedish building standard should use CityGML and that an ADE should be developed as CityGML does not include all the information that the national standard requires.

There are currently two versions of CityGML: the official version 2.0 and the proposed version 3.0. Even though CityGML 2.0 is a well-established and working implementation of the standard, CityGML 3.0 (Figure 5) was chosen for the development of the building standard as it includes new modules that are of significance from a Swedish perspective. The core model, where the basic concepts and components of CityGML are defined, has been restructured and extended. It is now based on spaces, AbstractSpace and AbstractSpaceBoundary, to which all the geometric representations are associated. The space classes are further divided into two subclasses, AbstractPhysicalSpace and AbstractLogicalSpace. Physical features, such as Building, BuildingPart, BuildingInstallation, and Room are all associated with the physical space. This is also the case for BuildingConstructiveElement, a new feature type that was included to allow direct mapping of constructive elements from IFC (e.g., IfcRoof, IfcSlab, and IfcWall) to CityGML. Logical features on the other hand, such as Storey and BuildingUnit, are associated with the logical space and were included to improve the interoperability with legal spaces in the LADM standard.

Figure 5. Extract from CityGML 3.0. Yellow objects belong to the Building module, red objects to the Construction module, blue objects to the Core module, and the green objects represent the geometry.

Another new module of interest in CityGML 3.0 is the model for versioning and lifecycle management. It includes bitemporal timestamps which allow objects to have one timestamp that refers to the real-world object and one for the database version of the object. It is also possible to create multiple versions of the 3D city model and to define links between different versions.

One requirement of the building standard is that it should be possible to complement it with information or standards for other themes, e.g., roads, to make a comprehensive national standard for 3D city models. The road information can for example be stored in the LandInfra standard. There is a recent study of creating a CityGML Infra ADE that allows storage of LandInfra features in CityGML 2.0 ([59]; see Section 4.7 above). Based on this we foresee that the choice of CityGML for the building theme could support later work in including more themes into a national 3D city model standard, but this is not further studied in this paper.

The release date for CityGML 3.0 is not decided at the time of writing, but both a sneak preview [21], conceptual models, and encodings (https://github.com/opengeospatial/CityGML-3.0) of CityGML 3.0 are available.

6.2. Methodology to Create CityGML Sve-Test

The building standard CityGML Sve-Test is based on the building model in CityGML 3.0 and is developed as an ADE that includes all additional information from the Swedish building specification [36], together with information from new requirements that have emerged. The standard has been developed by the following steps:

1)

Compare the CityGML 3.0 and the SGP Building application schemas to determine which object types, attributes, and relations that exist only in SGP Building.

2)

Evaluate the requirements from the building permit process and 3D cadaster to identify demands of new object types, attributes, and relations.

3)

Create a UML application schema that extends the CityGML 3.0 standard with all additional information from the first two steps.

4)

Transform the UML application schema to an XSD schema file.

To technically verify the standard, we developed some test data; these data are mapped to the XSD file, transformed to GML files and, finally, validated. This is further described in Section 7.

6.2.1. Comparison of the CityGML 3.0 and the SGP Building Application Schemas

The first step was to compare the SGP Building and CityGML 3.0 UML models to determine which classes, attributes, relations, and code lists that only exist in SGP Building. With this as a basis it was decided which properties and subclasses from SGP Building should be added to CityGML Sve-Test.

The results of the comparison suggested that one new object type (physical building, BY_FysiskByggnad) should be created and seven CityGML object types (Building, BuildingPart, BuildingUnit, BuildingInstallation, BuildingConstructiveElement, Door, and Window) should be extended with additional attributes together with new data types and code lists.

6.2.2. Evaluation of New Requirements from 3D Cadaster and the Building Permit Process

Specific building information requirements that are needed within the building permit process have been captured within the national project. These requirements were compared with information that is currently available in the Swedish building specification and in CityGML 3.0. The result of this suggested that three additional attributes should be included on building parts: roof angle, attic, and basement.

6.2.3. Create a UML Model for CityGML Sve-Test

The CityGML Sve-Test was created following the ADE description in the CityGML 2.0 standard [15]. A new UML project with its own namespace was created in the Enterprise Architect software and the draft CityGML 3.0 consolidated model [22] was imported into the project. The red objects in Figure 6 describe existing CityGML objects that are extended with new attributes (stereotype <<ADEElement>>) and a new object that is created (stereotype <<FeatureType>>). Corresponding datatypes and code lists were also created. Grey objects are CityGML objects that are used in CityGML Sve-Test, but not modified.

Figure 6. Selected parts of CityGML 3.0 and created Application Domain Extension (ADE) objects (in red).

6.2.4. Transform the UML Model to an XSD Schema File

To transform the UML model to an XSD schema file, the open-source Java tool ShapeChange was used [60]. ShapeChange requires certain tag values to be added in EA and configuration files to be modified to conform to the test environment, for example the tags targetNamespace, version, and xmlns must have values at the application schema level. The CityGML 3.0 XSD files are not yet available via URLs and were therefore downloaded to a local computer. The files were modified for the links (imports) between the files to work, and element references were modified to make the links from the CityGML Sve-Test XSD file to the CityGML 3.0 XSD files work.

7. Evaluation of CityGML Sve-Test

7.1. Evaluation Methodology

The evaluation consists of two parts. The first part, Section 7.2, is an evaluation of the conformance to the national implementation requirements described in Section 5; in the second part hands-on tests are performed. Section 7.3 describes the creation of test data and in Section 7.4, Section 7.5, Section 7.6 and Section 7.7 four test cases are described and evaluated. The test data as well as some of the scripts used are available on GitHub (https://github.com/LeveransspecifikationerGeodataBIM/).

7.2. Conformance to the National Implementation Requirements

The first implementation requirement states that an official international standard should be used. CityGML Sve-Test is a CityGML 3.0 ADE, and even though this is a proposed new version of the standard, it can be assumed that this version will be as well established as CityGML 2.0 in the future. The national 3D city model standard should be supplemented by surveying and measuring guidelines, and if CityGML Sve-Test becomes the official building standard in Sweden, corresponding guidelines should be created.

Further, the requirements state that all national specific information from the current building specification should be included in CityGML Sve-Test together with the CoClass code from the Swedish construction classification system and the possibility to have external referencing to registers. These requirements are fulfilled as the corresponding attributes were added to CityGML Sve-Test. This is also the case with the additional information needed in the building permit process.

7.3. Creation of Test Data

The study area was around the construction project of a kindergarten in the city of Karlstad in Sweden, called Lotsen. Three datasets were used:

• a BIM model in IFC format, hereafter called LotsenIFC;
• 3D geodata buildings surrounding the building Lotsen in DWG format, hereafter called ExistingBuDWG;
• the detailed development plan of the area in GML format, hereafter called DetailedDevPlan

Besides data for the study area around Lotsen we also used a BIM-model from Falun, Sweden, denoted Myran. This BIM model describes a vehicle inspection building.

LotsenIFC is an IFC architecture model exported from Autodesk Revit 2018 in IFC 2x3 format (as the model could not be correctly exported to IFC 4 due to problems with curved walls, Figure 7). The BIM model, LotsenIFC, was transformed from a local coordinate system relative to the building model, to a correctly georeferenced model using the project base point in Sweref 99 13 30 (EPSG:3008) which is the official municipality system. All the building objects in the BIM model that have linkage to CityGML Sve-Test were classified with CoClass in Revit before exporting it as an IFC file.

Figure 7. Kindergarten Lotsen, Revit model.

The 3D DWG (Autodesk AutoCAD), ExistingBuDWG, was provided from the city of Karlstad to represent the existing buildings in the area (see Figure 8). The buildings did not have any building id, which was solved by dissolving the 3D building geometries into a surface footprint for each building and then a spatial join between the original 3D geometries and the 2D surface footprint was performed to set an id on every building. Some of the building faces were wrongly oriented but were not fixed in the project (cf. Figure 8).

Figure 8. Existing buildings and a footprint of Lotsen on top of 3D contour lines.

The detailed development plan, DetailedDevPlan, conforms to the Swedish standard for computer readable plans [61] and was obtained from the city of Karlstad (with support from the National Board of Housing, Building and Planning) as a GML file. No modifications were made on this dataset.

7.4. Conversion of BIM to CityGML Sve-Test

Both LotsenIFC and ExistingBuDWG were converted to CityGML Sve-Test format. LotsenIFC was converted to both LOD1 and LOD2 models while ExistingBuDWG was only converted to LOD1. The conversion was performed with the extract, transform and load (ETL) tool Feature Manipulation Engine (FME) from SAFE Software (https://www.safe.com/) and the results of the conversation can be seen in Figure 9.

Figure 9. (a) LOD1, (b) LOD2 conversion, and (c) the original model.

To create an LOD1 model is relatively simple, a building footprint is created and set to the lowest point of the building and extruded to the highest point of the building to create a valid building solid. The creation of a LOD2 model is more complicated as it is based on that the roof is kept intact and that new walls are created and extruded downwards. The solids created are dissolved into one (or few) main solid that represents the entire building. In this building, the walls were outside the roof, so the conversion had to use both the roof and the top of the walls to create a building solid. Difficulties in dissolving the wall and roof geometry resulted in some unremoved inner walls (Figure 10).

Figure 10. (a) Lotsen, a complicated building model and (b) Myran, a simpler example with correct solid translation.

The CoClass classification was useful in the translation of IFC building objects to CityGML Sve-Test. It simplified the selection of correct building objects and geometries. The selection was used to create the relevant CityGML Sve-Test attributes such as bounded by, areas, and building UUID. The hierarchical structure of CityGML Sve-Test consisting of city model, building, building part, roof surface, and wall surface was then created. Cross validation between IFC attributes and CoClass classification was used in the project. For instance, controlling if both CoClass and IFC attributes include information regarding if a wall is external or not will make it safer compared to using only one source.

The GML-geometries for LotsenIFC and ExistingBuDWG files were created using FMEs built-in transformers and finally, the attributes of CityGML Sve-Test were added and GML files were written with a text writer in FME since no native CityGML 3.0 writer exists. The files were later used in the test for building permit applications.

7.5. Using CityGML Sve-Test for Building Permit Applications

A test case was performed to study if CityGML Sve-Test can facilitate automated checks of building permit applications, more specifically if the standard supports automated checks of requirements in a detailed development plan (Figure 11).

Figure 11. Workflow for the test case to study an automated check of regulations in a detailed development plan.

First the detailed development plan, DetailedDevPlan, was imported into FME with a script that was previously created within the project Får Jag Lov? coordinated by Boverket (the National Board of Housing, Building and Planning) (see [55]; FME script available on GitHub: github.com/TestbedLU). The dataset LotsenLOD1GML was imported into FME (Figure 12a) using a general XML-reader. The geometry was extracted with a GeometryExtractor transformer and the area where the building will be located according to the building permit application was identified (Figure 12b). The existing regulations in the area were obtained from the detailed development plan (Figure 13). In this case study, one regulation was related to function of the building and two regulations were related to the properties of the building (number of storys and level of densification—defined as the building area divided with the area of a specific region). These regulations were categorized into two lists: one for regulations related to function (upper) and one for regulations related to building property (lower) in Figure 13.

Figure 12. (a) LOD 1 CityGML 3.0 ADE model and (b) the building (brown) located in the area in the development plan where it will be placed according to the building permit application.

Figure 13. The existing regulations in the area where the building will be located according to the building permit application.

The test of the regulations was performed in a Python-script embedded in FME that also generates a report in Excel. In Sweden the around 270 regulations that can be included in a detailed development plan are listed as codes in a criteria list. Around 85% of these can be automatically checked [55]. As an example, the code DP_KM_S_For (upper regulation in Figure 14) states that the function of a building must be kindergarten (swe: Förskola). The Python script loops over the lists of regulations and checks all existing regulations against the code attribute in the LotsenLOD1GML building.

Figure 14. Visualisation in S-Visualizer: (a) the Lotsen building, LotsenLOD1GML, (b) the surrounding existing buildings, ExistingBuGML, (c) the corresponding CityGML Sve-Test attributes of building (a).

The test case shows that it is possible to use an automated method to check if a building in CityGML Sve-Test format conforms to the regulations in a detailed development plan. The test case only included three regulations, but it still shows potential advantages of the extending CityGML with an ADE. The attribute byggnadArea (building area) that was used to calculate the level of densification is part of the created ADE. Other CityGML attributes such as function, for checking the function of the building, and storeysAboveGround for checking the maximum number of building storys were also used.

The attribute coClass that is part of the created ADE includes a CoClass classification value and this can facilitate automated checks of building permits. It can be a support when checking the function of a building; and since this code is present in both the IFC and geodata models it can also facilitate the linkage between the models within the building permit process.

The building in this test has a flat roof but other roof types, such as gable roof, and regulations related to roof angle are common in detailed development plans. Even though the roof angle can be calculated from a LOD2 (and higher LOD) building model it is an advantage to check the roof angle based on attribute instead of involving calculations based on geometries. This will be possible using CityGML Sve-Test as it includes the attribute roof angle.

7.6. Importing CityGML Sve-Test to Software Tools

Another test case was to import test data in CityGML Sve-Test format into two commercial software tools, for visualization of geometry as well as attributes. The two software were S-Visualizer from Complete3D and Revit from Autodesk.

The 3D visualization tool S-Visualizer can import e.g., raster, vector, 3D surfaces (mesh), point clouds, and supports analyses, such as modelling of solar radiation and water levels. Within this study, an import function for the CityGML3 Sve-Test format was developed. Figure 14 shows that both geometry and attribute data from the datasets LotsenLOD1GML and ExistingBuGML can be displayed with S-Visualizer.

The test in Revit was performed by Symetri, a reseller of Autodesk Revit who also develop Swedish adaptations for Revit. As part of this study, Symetri developed procedures for importing CityGML3 Sve-Test into Revit. The dataset ExistingBuGML was successfully imported and the result is shown in Figure 15. Some experiences from the work is that coordinates must be transformed to a local coordinate system upon import; the best geometric conformity is achieved with Direct Shapes (a format that does not allow further editing); adding the required attribute Properties is straight forward, and the values of those attributes can be modified; Revit does not have built-in support for code list management, this would require an extension; finally how the object hierarchy from CityGML should be recreated in Revit requires further investigation.

Figure 15. The dataset ExistingBuGML in CityGML Sve-Test format is imported and visualized in Revit.

7.7. 3D Cadaster

A study by [52] established technical and legal solutions for the AEC companies, the cadastral surveying units, and city-surveying units to share information for handling 3D cadaster information. Their method was based on the open standards LADM, IFC, and CityGML 3.0. The cadaster attribute information was stored in LADM, while the physical extent of the cadaster units (as well as the easements) was stored in IFC. The IFC data (both building and cadaster borders) were converted to CtiyGML3 and integrated to an existing city model (Figure 16). This approach enabled visualization of the cadaster information on a city scale (corresponding to a 3D cadaster index map), as well as macro analysis of cadaster information, by linking the CityGML 3.0 data to LADM. In the study it was shown that by utilizing the AbstractSpace in CityGML 3.0 it was possible to perform this linkage without extending CityGML with an ADE (cf. work by [24], who created an ADE for CityGML 2.0 for a similar purpose).

Figure 16. A simplified 3D cadastral index map based on integration of CityGML 3.0 and Land Administration Domain Model (LADM). Two 3D cadaster units are shown, one in green color and one in yellow [52].

The study by [52] was based on CityGML 3.0 (without any ADE), and not CityGML Sve-Test. Nevertheless, the study shows the capability of CityGML 3.0 for linking physical and legal information, and that CityGML 3.0 can be used as a base for a 3D cadastral index map. Since CityGML Sve-Test is a superset of CityGML 3.0 this capability is guaranteed also in this model.

8. Discussion

8.1. Choice of Standard

From our perspective a national building standard should be based on CityGML as this is an open and comprehensive standard that is well established [6,15]. However, the selection of the current official version 2.0 or the new proposed version 3.0 is an open question. Version 2.0 is more mature and it is supported by a number of software while version 3.0 includes many new and promising features. This is shown in the example where the logical space concept is utilized for 3D cadaster applications. The new feature BuildingConstructiveElement is also interesting as it allows for direct mapping of constructive elements from IFC (e.g., IfcRoof, IfcSlab, and IfcWall). This together with the use of the CoClass classification can enhance the transformation from IFC models. CoClass might also be interesting from an international perspective as up to this date, five countries have signed a letter of intention to explore possibilities to develop a common environment classification system with CoClass in their countries.

However, there are also disadvantages to using CityGML 3.0 and the new features that come with it. Already, CityGML 2.0 is often regarded as a complex and too broad standard and therefore it has not been implemented—in its entirety—by many GIS software vendors. The new extended version 3.0 will likely increase the complexity in implementing and validating CityGML files. Irrespective of the CityGML version, the next question is whether the model should be extended with additional information using an ADE, or not. According to [26] an advantage with ADEs is that it makes it possible to add more application specific information while disadvantages are that it adds complexity to the model and that there is few software that can entirely interpret ADEs.

Another option for a national 3D city model standard is CityJSON, a JSON implementation of a subset of the CityGML 2.0 data model. According to [62], disadvantages with CityGML are the complex and verbose GML encoding that both make it difficult to parse files and for developers to implement. In CityJSON, all hierarchies are removed, and the geometries are simplified. JSON is favored by many developers as its data structure is used in many programming languages. JSON is also one of the preferred formats for data exchange on the web. CityJSON is relatively new and is not an official OGC standard, but it can be seen as an exchange format for CityGML.

8.2. Information Architecture

Sweden plans to take a two-layer approach in the development of standards for 3D geodata. The first layer contains a conceptual model that includes “all” information needed for the built environment, but with no mention of any international standards or formats. The second layer represents the data exchange with a distinction between bidirectional data exchange between two predefined parties where update is allowed; and the provision of data to different actors. The CityGML Sve-Test is proposed to be part of this layer and it should be possible to add additional data formats both for data provision and for data exchange. Examples of such formats are JSON and possibly also linked data in the future. Furthermore, the current plan is not to include any specific layer for restricting the data content, but the need to have surveying and modelling guidelines is clearly stated.

The Swedish two-layer approach could be compared to the ongoing standardization work of 3D geodata in the Netherlands. The authors of [63] want to simplify this standardization by proposing a three-layer approach. Here, the first layer is a conceptual model that to a large extent conforms to standards, e.g., CityGML and national standards. The second layer includes modelling constraints on the conceptual model to limit it for a specific purpose, e.g., to restrict the geometry types or limit the use of certain objects. Finally, the third layer defines the encoding formats for data exchange, e.g., XML/GML, CityJSON, or JSON-LD (to allow linked data properties in JSON). The authors of [63] anticipate that such 3D standardization framework is more flexible and will thereby simplify the implementation of 3D city models.

Neither of the above-mentioned examples provide a presentation layer, i.e., a layer including details of the cartographic solution. This layer is in many practical applications important and could act as a fourth layer.

8.3. Purposes of 3D City Models

Many of the choices described above boil down to what the building information should be used for. In [3] the authors analyzed the functionality and usability of 19 Finnish 3D city models and conclude that many models do not live up to the expectations, especially not to the expectation of being a multipurpose digital platform that can serve various and differentiated needs for city officials, citizens, and organizations. To overcome this, Julin et al. suggest a concept for harmonizing 3D city modelling that includes and combines three different techniques for 3D city modelling: 3D GIS, BIM, and computer graphics. The authors of [14], on the other hand, suggest that a 3D city model should not include more than what is needed for its intended purpose and propose five BIM-GIS integration levels of the models depending on what the application should be used for.

In Sweden there is now a strong focus on the digitalization of the planning and building process, among others to automate the building permit process. Here, the building theme plays an important role and the Swedish building specification needs to be revised to include the new requirements. The main focus of CityGML Sve-Test is applications for the planning and building process, but it should also be possible to extend the model with information for additional applications, e.g., noise and energy analysis or navigation. This can be done either by extending an existing theme with additional information, or by extending the model with additional themes (e.g., city furniture, tunnels, and bridges). Such extensions will be facilitated and also more harmonized if a comprehensive standard like CityGML is used.

Both having a very comprehensive 3D city model and a more minimalistic one has advantages and disadvantages. In a comprehensive model “everything” needed can be included, e.g., CityGML includes modules for buildings, tunnels, bridges, city furniture, and vegetation. It is therefore relatively simple to add new applications. Disadvantages with such model is that it can be difficult to implement and to use. A more minimalistic model is easier to implement and to use. Disadvantages here are that it can be difficult to foresee all possible usages and to fit in new applications without changing the model.

8.4. Versioning of 3D City Models

The lifecycle perspective is another important aspect for buildings and 3D city models that are used in urban planning. For example, objects in a city (e.g., buildings, tunnels, and bridges) are planned, constructed, renovated, and demolished; in the planning process it could be desirable to visualize different alternative versions of buildings when planning a new construction; when BIM data is used as the source for a 3D city model, one needs to know when these models were synchronized. That is, there are many different lifecycle aspects and they need to be considered when implementing a 3D city model. Some examples in the literature where this is described are in CityGML 3.0 where a new versioning module is added [64], and a new approach for versioning of 3D city models in CityJSON is proposed by [65]. To use the Product Lifecycle Support standard [66] is another approach described by [67]. Lifecycle management is not included in this study but needs to be tested and evaluated in future studies.

9. Conclusions

In this study we developed a proposal for a Swedish building standard, CityGML Sve-Test. It was developed as an ADE of CityGML and we chose to use the new proposed version 3.0 of CityGML as this version includes many new features that are of interest from a Swedish perspective. For example, the new space concept distinguishes between physical and logical spaces, where the logical spaces could represent the legal spaces of the 3D cadaster; and the enhanced possibilities to more easily convert data and to link to other standards such as IFC and LADM. CityGML Sve-Test also includes the Swedish classification system CoClass [38] both to improve the definition of terms and to facilitate interoperability with other urban processes. To overcome the difficulties of using a comprehensive standard, it is important to develop and use detailed guidelines that describe how objects in the city model should be added and updated, as well as what to include from the model when providing the information to various actors.

The test cases performed in the study show that it is possible to convert an IFC model to a CityGML Sve-Test dataset and that the use of CoClass can facilitate this conversion. It was shown that a CityGML Sve-Test dataset can be used to automatically check if a building conforms to the regulations in a detailed development plan. It was also possible to import and visualize CityGML Sve-Test datasets in the commercial software S-Visualizer and Revit. Finally, the authors of [52] showed that CityGML 3.0 has the capability to link to legal information in the LADM standard, that cadastral information can be visualized using CityGML 3.0, and that it can be used as a base for a 3D cadastral index map.

There are various options for 3D city models, all having advantages and disadvantages. We assume that the need for national coordination of 3D city models will increase with the number of complex models within a country. We believe that to have a successful national implementation of building and 3D city model standards, it is important to specify what the models should support, that is what should they be used for, and how complex should they be. The implementation should then settle on a reasonable level. We also suggest that the building and 3D city models, or at least their data models, should conform to an international standard, e.g., CityGML. The exchange format (XML/GML, JSON etc.) might change in the future but to build on a well-established and standardized data model will ensure that the models both have a harmonized structure and harmonized concepts. If a classification system exists, it should be included in the standard to improve definition of terms and to facilitate the interoperability with BIM data. The standard should also be complemented with measuring guidelines to ensure a more conforming creation of the objects included in the standard.