CityGML Application Domain Extension (ADE): overview of developments

Abstract

The Application Domain Extension (ADE) is a built-in mechanism of CityGML to augment its data model with additional concepts required by particular use cases. The goal of this paper is to provide an overview of the ADE mechanism and a literature review of developments since its introduction a decade ago. The discovery of publications found that currently there are 44 ADEs supporting a wide range of applications, but also application-agnostic purposes such as harmonisation with national geographic information standards. We hope this paper to double as a reference material for the developers of new ADEs.

Introduction

The CityGML standard [1] of the Open Geospatial Consortium (OGC) is the staple open data model and format for the storage and exchange of semantic 3D city models. It is used in several countries around the world for a wide spectrum of application domains [2].

While CityGML is intended to be a universal and application-independent geographic information model, the advent of dozens of applications and burgeoning use in different geographic contexts and software [3, 4] requires some additional information that is not readily available in the CityGML data model [5]. An example of such a case is the application of 3D city models in the energy domain: a method employed to estimate the energy demand of a building may necessitate specific and less common information such as building occupancy [6], an attribute that CityGML does not envisage by default. The developers of CityGML have foreseen situations such as this one, and thus for this purpose two ways to support augmenting the CityGML data model beyond its initial scope are offered: through (i) generic objects and attributes, and (ii) using the Application Domain Extension (ADE) mechanism. The former method has been used in practice but it has certain disadvantages (discussed later), thus the latter method is preferred by developers and it is consequently the topic of this paper.

ADE is a mechanism for enriching the data model with new feature classes and attributes, while preserving the semantic structure of CityGML, and it is an important component of the standard since its early versions. Its main purpose is supporting additional requirements by certain use cases, which is accomplished by specifying extensions to the data model.

As this paper will show, ADE is employed for a few dozen different purposes, and in spite of being around for a decade there has not been any general publication so far focused solely on this integral and important concept of CityGML. This paper is intended to bridge that gap by giving an overview of the ADE mechanism, its developments, and discussing the current landscape of available implementations. Section CityGML ADE gives a general review of the ADE concept—mostly by condensing the relevant parts of the current version (2.0) of the CityGML standard [1], while Section Modelling a CityGML ADE briefly presents different approaches to model an ADE. Section ADE literature review provides a literature review of publicly available ADEs, while Section Discussion discusses the main findings and observations. Another aspiration of the paper is to serve as a reference for the developers of new ADEs.

CityGML ADE

Overview and history

The ADE concept has been introduced in CityGML in its early days (in version 0.4 released in May 2007). Its two main purposes are:

• Addition of new properties to existing standard CityGML classes. For example, adding the information on the gas consumption of a building.

• Addition of new object types. For example, adding a new module for city walls and monuments.

An ADE may be specified either with an XML schema definition file (XSD) or with Unified Modeling Language (UML). However, the CityGML documentation describes only the former approach. Afterwards, a document explaining the development of an ADE through a UML was released: the OGC best practice ‘Modeling an application domain extension of CityGML in UML’ [7], which is also published as a conference paper [8].

The concept has remained unchanged in the version 2.0 of the standard, with an addition of a new example in the Annex of the standard (covered later in this paper). However, some of the ADEs developed alongside version 1.0 have been integrated as standard modules in CityGML 2.0 (i.e. Tunnel ADE and Bridge ADE). These cases demonstrate that well documented and widely useful ADEs may have the prospect of being adopted by OGC and make their way into the standard.

In a nutshell, some other relevant aspects regarding ADE to note are:

• An ADE has to be defined with its own namespace in order to prevent conflicts with CityGML modules.

• An ADE may extend multiple CityGML (thematic) modules at once.

• Multiple ADEs can be used in the same dataset simultaneously.

• ADEs do not necessarily need to be approved by a standardisation body nor by OGC, as anyone can develop an ADE and produce datasets conforming to it. Therefore generally speaking there is no such thing as an ‘official ADE’ in the context of OGC and CityGML. However, besides the ADEs developed by an organisation with an authority (e.g. a national standardisation body establishing a national 3D spatial data infrastructure), some ADEs can be considered ‘de facto official’. These ADEs may be the ones that are widely supported by the OGC community (e.g. developed by multiple research groups participating in the CityGML Standards Working Group). Such efforts have a prospect of being integrated in future version of CityGML.

• An ADE can have its own code lists.

• An ADE can be used to introduce new spatial representations for existing CityGML features [9].

It should be noted that the need for extending the CityGML model does not imply that it has shortcomings by design. CityGML is designed in such a way to keep a minimum number of common features using a slim core data model with the option to be extended for specific applications. Such a philosophy avoids having a large and complicated data model with an extensive number of classes.

Examples¹

The CityGML 2.0 standard [1] provides two examples of ADEs: an ADE for noise immission simulation (Noise ADE; Annex H) and an ADE for ubiquitous network robots services (Robotics ADE; Annex I).

Here the first ADE is briefly described as an example of the implementation, with extracts taken from the standard [1]. This ADE is intended to provide support for generating noise pollution maps with simulations based on 3D city models. Such a spatial analysis requires certain information not provided by the CityGML data model. For example, these are the noise reflection properties of buildings and their number of inhabitants (to estimate the population affected by noise). In the ADE they are added as elements buildingReflectionCorrection and buildingHabitants, and are being modelled as child elements of CityGML building features (Fig. 1):

Fig. 1

Excerpt of the UML diagram of the Noise ADE, depicting the augmentation of CityGML Building with noise related attributes not standardly available in CityGML. The prefix noise indicates attributes and objects that are associated with the Noise ADE. Source: OGC CityGML 2.0 standard [1]

An example of a resulting ADE-compliant CityGML dataset follows:

The documentation of this ADE also contains an example of adding a new feature type (Fig. 2). In this particular instance the noise barriers are modelled (represented as NoiseCityFurnitureSegment, as child elements of CityGML city furniture objects), which is not possible explicitly with the CityGML data model:

Fig. 2

Excerpt of the UML diagram of the Noise ADE, depicting the augmentation of CityGML CityFurniture with a new feature type NoiseCityFurnitureSegment with gml:Curve geometry. The prefix noise indicates attributes and objects associated with the Noise ADE. Source: OGC CityGML 2.0 standard [1]

Note that it is also possible to define the geometry of the noise city furniture objects NoiseCityFurnitureSegment in the Noise ADE. For example, the outline of a noise barrier can be represented by a curve gml:Curve. An example of a Noise ADE-compliant CityGML dataset demonstrating this case is given in the continuation:

Modelling a CityGML ADE

ADEs can be modelled directly in the XML schema or can be generated by extending the UML model of CityGML with application specific information and later deriving the XML schema from it. The CityGML 2.0 standard [1] specifies rules and guidelines for modelling ADEs in the XML schemas. Van den Brink et al. [8] describe six different ways to create a CityGML ADE using UML. In this section, we give a brief overview of the most preferred ways of modelling an ADE in XSD and UML.

Using ‘hooks’: Every CityGML feature class has a GML ‘hook’ of the form ‘_GenericApplicationPropertyOf<Featuretypename>’ in its XML schema definition which allows to attach additional attributes to it by ADEs [1]. For example, bldg:_GenericApplicationPropertyOfBuilding can be used to attach new attributes (e.g. numberOfInhabitants) to the existing Building class:

Using sub-classes: Another favoured approach for modelling an ADE is by extending the CityGML model with new classes for new feature types as subclasses of the existing CityGML classes. In this case, the hook mechanism is not used because a new class is added and not only properties to an existing CityGML class. The subclasses are also marked using the same stereotype («featureType») as the CityGML classes and are not suppressed in the XML Schema.

As an example, Fig. 3 depicts the extension of CityGML Building class with a new feature type Garage as a subclass with «featureType» stereotype. The new class Garage also has a new attribute numberOfCarsParked. The XML schema for the ADE can be generated from the UML model using the ShapeChange² tool. ShapeChange is a JAVA based tool which implements UML to GML encoding rules described in ISO 19136 [10], ISO 19118 [11], and ISO 19109 [7, 12]. The XML schema is generated only for the ADE classes and attributes and not for the entire CityGML data model because it is already publicly available. The generated CityGML ADE schema only needs to correctly import the CityGML schema.

Fig. 3

Example UML model depicting the extension of CityGML Building class with a new feature type Garage as a subclass with «featureType» stereotype. The new class Garage also has a new attribute numberOfCarsParked

This approach has been accepted as the best practice by the OGC [13]. Another factor supporting this approach is that the concept of sub-classes and inheritance is easy to understand with basic knowledge of UML.

ADE literature review

Method

The concept of ADE has been featured in many research papers, from brief mentions to comprehensive descriptions of implementations. More than a hundred of research papers in the 3D GIS field containing ‘Application Domain Extension’ or ‘CityGML ADE’ have been screened in order to identify those that present the development of an ADE or are in any other way considered relevant for this paper. However, most of the discovered papers were not particularly relevant in the context of this paper, as in many instances the ADE concept was merely mentioned as a functionality of CityGML when describing the standard or in the discussion about future work.

We have identified 44 ADEs in the relevant subset of the screened publications. In this section their overview is given: each of the ADEs is described, while their list with general properties is given in Table 1. The table contains various information such as whether there is a dedicated website where it is possible to download the schema or follow developments.

Table 1 List of identified ADEs

The discovered ADEs are delineated in two categories: (i) those that are developed for supporting specific applications (Section Supporting applications), and (ii) generic ADEs that supplement CityGML without a specific intended application, e.g. for adapting CityGML to a national context or to preserve rich information when converting other 3D formats to CityGML (Section Generic). As it is usually the case with taxonomies such as this one, some subjective choices have been made, as the labelling of some of the identified ADEs might be subject to different interpretations. For example, an ADE might be considered generic because its functionality provides information useful for a variety of applications (e.g. extending the data model with additional classes related to transportation), but in practice it serves a single specific use case.

Finally, software support for ADE has been overviewed as well (Section Overview of software support for ADE).

Overview of the identified ADEs

Supporting applications

The primary aim of the ADE concept is to enrich the data model of CityGML supporting specific applications, thus it is not surprising that in practice most of the developed ADEs belong to this category.

One of the most mature efforts in this arena is the Energy ADE [14–16], jointly developed by several European organisations, mostly universities. This ADE has been incepted with the intention of bridging the gap of an open model standard in the urban energy modelling domain, supporting interoperability between different tools and stakeholders. It extends CityGML by enriching the data model with information required for energy simulations, such as the used energy system, building occupancy, and its physical properties (e.g. material). The model is flexible, taking into account different levels of detail (LODs), and it is modular foreseeing the potential coupling of Energy ADE with other ADEs. The Energy ADE is supported by several implementations and studies [15, 17–19], and it is established both in an XSD schema and UML class diagram (Fig. 4).

Fig. 4

Excerpt of the UML diagram of the Energy ADE, depicting the augmentation of CityGML Building with features not standardly available in CityGML. Source: Energy ADE v. 1.0 documentation (http://www. citygmlwiki.org/index.php/CityGML_Energy_ADE)

A related effort is the 2011 work of Dalla Costa [20], documenting an early proposal for an Energy Efficiency ADE. This ADE enriches CityGML by defining thermal zones for buildings and other information crucial for managing energy efficiency. However, the work appears to remain in its prototype phase, as no subsequent publications could be discovered.

An ADE of the same name was introduced in [21] (and subsequently it was a subject of the publications [22, 23]), enabling the modelling of physical properties of materials such as reflectivity and transmittance.

The Noise ADE, the exemplary ADE included in CityGML 2.0 [1], has been described in Section Examples hence it will not be described extensively in this section. Other relevant aspects of the Noise ADE to note are that it allows segmenting roads according to noise requirements and modelling train characteristics to understand railway noise [24]. It is available in both XSD and UML form.

The Noise ADE is also an interesting case to demonstrate the flexibility of the ADE concept. Its schema has been extended by subsequent work of independent researchers [25], indicating that extensions are customisable and extensible per se (since ADEs are extensions, this technically means extending an extension). The researchers identify limitations of the existing ADE for the practices and legislation of noise pollution modelling in the Netherlands, e.g. lack of support for industrial noise and for distinguishing different speeds of vehicles. The work enriches the Noise ADE with new classes and attributes resulting in the Extended Noise ADE, adapting the existing ADE to particular requirements suiting a national context and local legislation.

Another interesting example in the noise field is that the same application domain may occasionally be covered by different ADEs (as it is the case in the aforementioned energy application), allowing narrowing down the focus of each. For example, Konde [26] developed an independent ADE tailored for road traffic noise and concentrated on a particular noise propagation model, without much relation to the Noise ADE. This ADE extends the Building module by including attributes such as reflection correction factors for walls and roofs, which are required by the noise propagation method used.

Besides the Noise ADE, the second exemplary ADE included in the CityGML 2.0 standard [1] is the ADE for Ubiquitous Network Robots Services. This ADE augments CityGML with features necessary for robot navigation, such as floor material and additional information on openings [27]. It extends the bldg:Room feature, which is available only in LOD4, doubling as an example of an ADE that is dependent on the LOD.

UtilityNetworkADE [28–30] enables modelling utility networks in CityGML. It tailors the data model including the utilities (e.g. freshwater and electricity) with information on usage, materials, operating parameters, and population depending on the network. It has been used for various purposes, e.g. simulating the cascading impact on population in the event of a failure of the infrastructure [31], facility management and vulnerability assessment [32]. This ADE is relevant in the context of Building Information Modelling (BIM) since it is possible to transform Industry Foundation Classes (IFC) data containing utilities to this ADE [33]. At the time of the submission of this paper, this ADE is a proposed integration to CityGML 3.0.

Computer Aided Facility Management (CAFM) ADE [34] is an instance adapted for facility management. It enriches LOD4 models with additional features about rooms, e.g. ceiling height and window size, which are suited for managing various tasks such as cleaning and costs [35].

Çağdaş [36] proposed an ADE adapted for immovable property taxation, taking into account the legal and administrative aspects which are not covered by CityGML. The Immovable Property Taxation ADE is developed fulfilling the requirements of the Turkish law. It integrates modelling the property units (e.g. parcel) with their components, and legal and economic attributes (e.g. rights), which are required for property taxation and management. The ADE defines several new classes and attributes, e.g. the apartments are modelled as BuildingUsePart. Similarly as the mentioned lack of legal building units, an interesting addition to note is that because parcels do not have a dedicated CityGML representation, a new feature class CadastralParcel has been created within the CityGML LandUse module.

Another work related to this application is the one of Dsilva [37] who developed an ADE for property administration in the Netherlands. The work enhances the building module of CityGML by including apartments and their properties relevant for cadastre (e.g. ownership rights and number of rooms).

A few researchers [38–40] suggest an extension of CityGML with legal concepts found in the Land Administration Domain Model (LADM) [41]. For example, Li et al. [39] propose an ADE giving consideration to the internal ownership structure of condominium units. The paper includes two examples of datasets from China.

Cultural heritage has also been subject of CityGML extensions. The Cultural Heritage ADE is defined both by an UML and XSD, and it has been described in multiple publications [21–23, 42]. Cultural heritage has been a subject of other unrelated ADEs defined by Costamagna and Spanò [43], Noardo [44], and the BCH (Built Cultural Heritage) Management ADE developed by Zalamea et al. [45], indicating particular interest in this application of 3D city models. These ADEs extend the Building module with a class intended for cultural features, allowing modelling monuments including their history, protection status, and condition.

Similarly, but focused to a national context, Mohd et al. [46] developed an ADE for Malaysian heritage houses. Their ADE augments CityGML to support the documentation of heritage houses for their preservation and monitoring of damages.

In the frame of the above described project of Prieto et al. [21], a companion ADE to the Cultural Heritage ADE was designed: Intervention ADE includes information on the actors involved in the processes for the maintenance and the rehabilitation of the cultural heritage.

Although CityGML’s focus in practice is not so much on the interior of buildings, a fair share of ADEs has been developed supporting indoor applications since the LOD4 as defined by the standard falls short with certain applications. Dutta et al. [47] developed an ADE for indoor routing and positioning. It adds attributes of indoor features that are of relevance for this application domain. For example, the feature FloorSurface is extended to include routing and positioning attributes. BuildingInstallation is enriched supporting modelling connectors between storeys, such as staircases and elevators. Thanks to this ADE, WiFi routers can be modelled as well, supporting the positioning aspect of this application.

Another work focusing on enhancing CityGML for interior features is the Indoor ADE developed in Korea [48–50]. This ADE provides two feature models extending the Building module: Indoor Space Feature Model and Indoor Facility Feature Model. The former includes space features such as meeting rooms, while the latter is geared towards facilities such as fire hydrants. One of the key features of this ADE is the extension of CityGML supporting storeys, which was discussed by other researchers as well but implemented in different ways [51, 52]. This ADE is dependent on the LOD of the data, as it is builds on top of standard features available only in LOD4 of CityGML (e.g. Room).

Prandi et al. [53] developed an ADE supporting multiple services related to smart cities: solar energy, improving mobility of citizens (routing), and noise mapping. This ADE was deployed within the i-SCOPE project (interoperable Smart City services through an Open Platform for urban Ecosystems), with an interesting distinctiveness that it is developed with multiple applications in mind. Examples of features enriched by this ADE are information whether a traffic light is capable of giving audio signals, height of doorsteps, and width of elevator doors.

In the water domain, HydroADE [54] was developed for exchanging dynamic 3D flood information. The ADE is supported by a web visualisation and examples.

Zamyadi et al. [55] created an ADE for augmented reality (AR). One of the interesting aspects of their work is the extension of the Appearance module to suit augmented reality applications (e.g. denoting the render priority), which is not a common occurrence (the only other related work we identified is an ADE focused on bridging CityGML and a computer graphics format for improving gaming experience [56]). In the related domain, a study by Hasse and Koch [57] involved extending CityGML with the thematic model of ENC (Electronic Nautical Charts), which they later used with an AR engine to visualise the 3D representation of ENC objects and the corresponding electrical information.

Air Quality ADE was developed by Arco et al. [58] to characterize the existing city objects with air quality values around them so as to identify the main sources of air pollution and the affected areas.

Generic

Many ADEs have been developed also as a general extension of CityGML without a specific application in focus. For example, some of these ADEs have been implemented for adapting CityGML supporting a national standard or enabling interoperability between a national standard and CityGML. Furthermore, it is relevant to note that national 3D geographic information models can be developed entirely as a CityGML ADE [7, 59, 60].

The Netherlands has a national 3D standard (Information Model Geography — IMGeo) that is established as a CityGML ADE [13, 61, 62]. The IMGeo ADE is designed as an extension of the existing 2D standard, utilising concepts from CityGML. It is expressed as UML, describing adaptations that give means to fitting the Dutch context and enabling extensions to the previously established 2D standard. A relevant detail to note about the work behind IMGeo is that it is one of the earliest ADEs defined with an UML model, and a byproduct of the project are the publicly available guidelines on modelling ADEs using UML [63].

Similarly, an extension of CityGML according to the requirements of the Turkish Urban Information System (TRKBIS) has been developed [60, 64]. The ADE has been established in UML, with currently available documentation focusing on enhancing the building and trasportation modules. For example, the attribute describing roof material of a building and the maintenance authority of a transportation entity have been enabled in the ADE. Classes have been extended as well, e.g. the class OtherConstruction³ not available in CityGML but a part of the TRKBIS is available owing to the ADE.

The European INSPIRE Building specification is partially based on CityGML, hence an ADE was developed fostering interoperability between the two standards [65, 66]. The ADE focuses on the 3D portion of the INSPIRE Data Specification on Buildings, and it extends CityGML with building attributes that are not available in the data model, e.g. number of dwellings, building nature, and metadata on data quality such as the accuracy of the height. The specification is available as XSD and UML, and work in practice is mostly focused on implementations in Germany [67].

Adapting the CityGML data model to a local context is not exclusive to national standards and efforts of government agencies. For example, Li et al. [68] extend CityGML for modelling ancient Chinese-style architecture. Specifically, the RoofSurface feature of Building has been extended in the ACRoofADE entertaining Chinese-style roofs, e.g. include information about dynasty and type of ridge. It is also interesting to note that this comprehensive work focusing on a particular component (roofs) of a particular architecture (ancient Chinese) doubles as a data modelling guideline as it provides instructions on data acquisition in different LODs.

ADE has been employed also in enhancing thematic modules without a national context in mind. The work of Kumar et al. [9, 69] presents a solution for enhancing the efficiency of storing terrain in CityGML. CityGML iTINs ADE introduces new geometry types in the GML schema which are extended to existing CityGML features for compact representation of massive terrains, resulting in a compression factor of 20.

Guerrero Iñiguez [70] suggested an ADE for the inclusion of geometric and semantic properties of tree roots in solitary vegetation objects at different LODs.

A new concept ‘dynamizer’ has been proposed by Chaturvedi and Kolbe [71] for enabling the representation of dynamic information in semantic 3D city models for different purposes. Examples of such dynamic properties are real-time information on electricity consumption from smart meters. Dynamizers are currently realised in CityGML with an ADE. However, the integration of this concept in the next version of CityGML 3.0 is being currently discussed in the CityGML Standards Working Group (SWG). The evolvement of a concept implemented as an ADE into a native component of CityGML is not uncommon (i.e. see Tunnel ADE), as discussed earlier. For another related ADE, the reader is referred to the Dynamic ADE [22, 23].

Kaden et al. [72] developed Geodata Join ADE to enrich the CityGML data model with additional information about the relationship between the adjacent city objects (e.g. a building and a road) in order to remove geometric inconsistencies.

TopoADE was developed by Li et al. [73] to enrich the CityGML data model with topological relationships, i.e. relationships between geometric primitives and between semantic features.

Tamminga et al. [74] study the establishment of a standard for exchanging traffic and transportation models as a CityGML ADE. In this work in progress, researchers point out that CityGML provides a geographical context, which many existing traffic and transportation models currently lack. Examples of attributes that are added to the CityGML thematic module representing roads are maximum speed of a road segment, gradient, and capacity. With that, this ADE opens the door for different uses of CityGML in transportation applications.

Varela-González et al. [75] proposed the Traffic Sign ADE for modelling traffic signs with specific feature types, attributes, and their relationship with road network models defined in the Transportation module.

On the subsurface, Tegtmeier et al. [76] developed the 3D Geotechnical Extension Model (3D-GEM), an ADE for handling information on subsurface geological and geotechnical features.

ADE has also been used to extend CityGML with a custom LOD specification and richer semantic structure (e.g. allowing balconies to be denoted) [77].

Besides the harmonisation of national standards, a subcategory that may be identified in this group are ADEs developed in the frame of the conversion from IFC to CityGML. Because CityGML and IFC are inherently different formats conceived for different purposes and scale, there is large disparity between them in terms of object types, geometry, attributes, and relationships [78]. Therefore, ADEs have been developed supporting their interoperability.

Deng et al. [79] introduce the Semantic City Model ADE for capturing the semantic information from IFC that would normally not be possible to store in CityGML. The ADE allows storing the structural properties and component relationships in CityGML. An interesting aspect to note is the support of multiple LODs, as the conversion results in multiple instances differentiated by their spatio-semantic grade.

Perhaps the most prominent ADE in the context of IFC ⇔ CityGML interoperability, is the one introduced in 2011 by De Laat and Van Berlo [80]. The extension GeoBIM is developed for integrating IFC semantics and properties in CityGML. It works in the way that existing CityGML features such as Room are extended with rich information from IFC. Their work identifies a subset of IFC classes that are of relevance for IFC (less than 10% of the total number), and focuses on mapping them onto CityGML. For example, the IFC class ifcDoor is mapped onto the CityGML Door extending the attributes OverallWidth and OverallHeight, originally not available in CityGML.

Another identified work utilising ADE in the domain of BIM–GIS integration is the PANTURA ADE [81]. This ADE partially captures IFC data types and hierarchy. It has been tested on an IFC model of a bridge, and the resulting model is tested in a use case for analysing the disturbance induced by bridge construction.

Finally, the 3D Metadata ADE was recently developed focusing on adding metadata related to 3D city models in CityGML standard [URL-10]. It incorporates ISO 19115 [82] metadata elements and several other elements related to 3D city models such as LODs, feature count, and metadata related to CityGML thematic models, e.g. the total number of building parts and installations in Buildings. It also defines attributes to store information about any other ADE(s) already present in a dataset, which is an interesting functionality in the context of this paper. The 3D Metadata ADE has a modular structure and can be extended by other ADEs to incorporate their metadata. Figure 5 illustrates such an example. A new class MDnoiseBuilding is created by extending the Metadata ADE MDBuilding class. MDnoiseBuilding has a new attribute to store information such as the number of buildings enriched with Noise ADE attributes (numberOfNoiseBuildings). Similarly, MDnoiseRoads is a subclass of MDRoads with a new attribute to store the number of noise road segments present in the data (numberOfNoiseSegments).

Fig. 5

Excerpt of the UML diagram of the 3D Metadata ADE, depicting how to extend it to incorporate the metadata related to other ADEs (such as Noise ADE) i.e. an ADE of an ADE for an ADE. Source: 3D Metadata ADE (https://github.com/tudelft3d/3D_Metadata_ADE)

Overview of software support for ADE

Nowadays a number of software packages support CityGML, from data generators to visualisers. In this section they are overviewed considering their ADE support.

The most current list of maintained software with CityGML support is the one available at the official CityGML website⁴, and hence it is taken here as the authoritative list for this analysis. A quick inspection of the software revealed that support for ADEs is limited. Introducing a new ADE entails modifying an existing software package or developing a new one. Most software packages have no support for ADEs whatsoever, hence the continuation of this section focuses on the software that at least partially has a support for ADEs.

The free CityGML geodatabase solution 3DCityDB currently does not offer full support for ADEs. However, there is work in progress in extending 3DCityDB supporting CityGML ADEs [83, 84]. Furthermore, there are some independent implementations demonstrating support for ADEs in 3DCityDB, e.g. EnergyADE, Dynamizer ADE, and UtilityNetworkADE.

FZK Viewer, a free Windows-only visualiser supports visualisation of ADE data. It is a schema-aware software and thus supports any ADE as any other GML application schema. It requires the ADE XML schema to process the new objects and attributes defined in the ADE.

citygml4j, the open source Java API for CityGML, provides full support for handling ADEs. It is capable of reading ADE-enriched CityGML datasets and writing the ADE classes/attributes back to disk without loss of information.

azul, a free macOS visualiser supports the IMGeo (reviewed in Section ADE literature review), which is an ADE. Other than this ADE, the software may visualise geometries that are inside any ADE extension. However, thematic extensions concerning features (e.g. new attributes) that are not predefined in the code are not shown. The software is open-source, hence support for other ADEs is a viable option.

3dfier⁵, an open-source software to automatically construct 3D city models in OBJ and CityGML formats, also implements the IMGeo ADE 2.1.1.

FME, the commercial extract, transform, load (ETL) software, can manipulate ADE-enabled CityGML datasets as long as the XSD schema is provided. Figure 6 shows an example of a dataset with Noise ADE attributes being visualised in the FME Data Inspector.

Fig. 6

Example of the FME data inspector showing a dataset with attributes extended by the Noise ADE. Source of the dataset: OGC [1]

On a related note, the ADE mechanism is currently being implemented in CityJSON, a JSON-based implementation of CityGML.

Discussion

Principal observations from the literature review

With 44 identified ADEs developed for a variety of purposes, the ADE landscape is quite diverse. They have been developed for a range of applications from land administration to energy analyses, and generic purposes such as harmonisation of national data standards. Thanks to enriching the CityGML data model with new features, the ADEs enable new applications of CityGML data and enhance existing ones. While the ADE mechanism has been introduced to support applications, an interesting observation is that more than a third of instances identified in our review is generic, without a specific application in focus.

Some of the ADEs are merely described in a subsection of a short paper without any published XSD/UML and are confined to being prototypes and early-stage proposals, while others are well documented and mantained, and some have even been adopted as national standards and are supported by software implementations. This results in a large difference between the maturity and adoption of ADEs, as it appears that several of them are very specialised and designed as pilot projects.

The Energy ADE and UtilityNetwork ADE particularly differentiate themselves here, being developed by international consortia involving different types of stakeholders, and continuously being featured in publications (examples of papers are given in the previous section). Among a few others, these ADE can be considered as exemplary developments.

ADEs in general focus on one thematic module (and that is mostly Building), which can be explained by the fact that most applications consider only that thematic aspect of 3D city models [3]. For example, indoor navigation usually does not require any other thematic class beyond buildings.

At the side of levels of detail, the situation is mixed. Some ADEs do not account for LODs, while others are restricted to a particular LOD, especially those involving indoor data, which is relevant for the discussions about the conversion from IFC to CityGML and for indoor applications such as navigation.

A shortcoming that we have noticed is the limited reach of ADE when it comes to open data. ADE-enriched CityGML datasets are seldom available, indicating that while the development of the specification may be lively, their implementation and utilisation lag behind.

Finally, an interesting differentiation is noticed when it comes to diversifying or focusing the scope of ADEs. For example, the Energy ADE [16] is developed with multiple use cases in mind. However, Prieto et al. [21] and Egusquiza et al. [22] resort to another philosophy, developing multiple ‘mini-ADEs’ within the same project, each with a specialised purpose, separate and complementing each other. In relation to such an approach, it is interesting to point out that certain ADEs have been created by extending existing ADEs, i.e. it is possible to create an ‘ADE of an ADE’. For example, Kumar et al. [25] show the possibility of extending the existing Noise ADE with new elements and attributes, instead of creating a new extension from scratch. Such a notion of customising and/or extending an existing ADE allows designing a ‘core’ ADE that can serve as a base for multiple, more specialised ADEs, diminishing their overlap.

Interestingly, we have also noticed a significant overlap of some ADEs. For example, there are three similar ADEs independently developed that even bear the same name (Cultural Heritage ADE).

Disadvantages of ADE and open questions

Because they solve the shortcomings of the default CityGML data model by enhancing it for certain purposes, ADEs entail an added layer of complexity in the data model [85].

Virtually always, developing an ADE by default means that it cannot be entirely interpreted by existing software, which is evident from the brief review of software (Section Overview of software support for ADE). A custom schema entails development of customised software solutions for modelling, exchange, visualisation, and utilisation of ADE-enabled CityGML datasets. It appears that it is uncommon to have the ADEs supported by software as authors often stop at the development of a schema [79]. Furthermore, ADEs rarely seem employed in other research. Their development usually ceases soon after publication, and in many cases work does not go beyond a research paper.

While our review has shown that there is a relatively large number of ADEs, it is not common to find publicly available datasets that contain an ADE, and their validation has not been subject of research [2, 86].

Even though ADEs are intended to supplement CityGML, it is important to note that the geometries must be compatible with the Geography Markup Language (GML). This might be a disadvantage for purposes such as the conversion from IFC because it involves additional forms of geometry such as constructive solid geometry (CSG) [87].

The current ADE documentation leaves some open question, e.g. one of these relates to the level of detail: how would it be possible to denote the LOD of a spatial property introduced by an ADE? In CityGML, the LOD is only implicitly given by the name of the spatial property which starts with lodX (e.g. bldg:lod2MultiSurface). However, the CityGML specification does not elaborate how this should be achieved in an ADE. Therefore, when writing ADE-enabled software such as a viewer, it is not clear how it is possible to specify which ADE features are available in which LOD.

Finally, it appears that, besides the CityGML standard, there is no authoritative publication focused on the ADE concept nor a ‘101 guide’ (which we try to at least partially solve with this paper).

Key literature

Among the identified literature, some documents differentiate themselves as key literature, being relevant for developers venturing into developing an ADE. The starting document is the CityGML 2.0 standard [1], that not only defines the ADE concept but also contains some guidelines and the two examples shown in Section ADE literature review. Given that CityGML 3.0 will probably not introduce changes to the ADE mechanism and it is yet to be published, it is to be expected that—when it comes to the ADE mechanism—the CityGML 2.0 standard will still be relevant for some time.

The guides prepared by Van den Brink et al. [63] focus on the development of an ADE as UML. The authors offer six alternative approaches to do so, hence it is an essential read for developing an ADE as UML.

Finally, it is also relevant to highlight the paper of Yao and Kolbe [83] focusing on implementing ADEs in a database.

Generics: the alternative to ADEs

As mentioned in the introduction of this paper, the other official way of supporting the extension of the data model is through generic attributes (_genericAttribute) and generic objects (GenericCityObject). While this approach is not in focus of this paper, it is discussed here briefly for the sake of completeness and overview. The advantage of using generics is that it does not change the CityGML XML schema.

An example from practice is the 3D city model of the Hague in the Netherlands⁶. Each building contains the attribute of the height of its eaves, expressed as a generic attribute, for example:

The CityGML 2.0 Generics also has a GenericAttributeSet element which supports grouping of related generic attributes (_genericAttribute) under a common name [5]. This is akin to the concept of "PropertySets" (IfcPropertySets) in IFC to dynamically add properties to the objects (IfcObject). A GenericAttributeSet can contain any number of arbitrary generic attributes (_genericAttribute) and its name serves as an identifier for the entire set. It also has an optional codeSpace attribute to specify the authority, e.g. the organisation or community that defined a generic attribute set and its contained attributes.

However, most of other aspects go in favour of ADEs. One of the key differences of ADE over Generics is that the former must be defined in an additional XML schema with a dedicated namespace. The CityGML standard denotes that this is an advantage for ADE because the extension is formally specified, and realisations can be validated against the schemas, which is not possible with generic objects and attributes. Further advantages of ADE over Generics is that the chance of naming conflicts is diminished, multiple ADEs can be used in the same dataset, and the fact that Generics might not be suitable for all situations given that there is a limited number of predefined data types that can be used [37].

Conclusion

The CityGML ADE is a powerful mechanism to suit different application needs by extending CityGML through new features. An ADE is specified by an application schema in a different namespace, and it provides hooks to allow integration into existing CityGML types [5, 36]. It has been an integral part of CityGML for more than a decade, and it is one of its most featured functionalities considering that it has been subject of a large number of research papers in the 3D GIS community (as evident from the review in Section ADE literature review). The development of most ADEs has been fueled by the needs of specific applications that require additional information originally not provided by CityGML. Different communities from academia, industry, and government sector have developed different ADEs for adapting CityGML to their requirements. At the same time, thanks to the ADE concept, CityGML remained relatively light and simple describing only common information.

The conducted literature review reveals that there are currently 44 instances of ADEs. ADEs have also been developed for application-independent tasks such as harmonisation of CityGML with national standards, having an outreach beyond their initial aim of supporting applications such as energy modelling and analysing noise pollution. These are primarily customisations of the CityGML data model for fitting the local context, e.g. development of national standards in the Netherlands and Turkey. Their adoption by government agencies may give credibility and motivation for the development of an ADE in future similar projects or adoption of existing ADEs.

The review also found that the state of development is mixed: while some ADEs are strongly underpinned (published schema and research papers and a maintaned website), most of ADEs are however not well documented nor they are supported by software. Energy applications are the predominant driving force behind the development of ADEs, which is not surprising given that many applications of semantic 3D city models revolve around energy [3]. It is to be expected that some of these, such as the dynamizers, will become an integral component of the future version of CityGML [71], as it was the case with implementations such as the Tunnel ADE becoming part of CityGML 2.0.

Finally, it is important to note that this paper was written before the adoption of CityGML 3.0. While some developments related to CityGML 3.0 are already publicly available [52, 88] and while the authors of this paper are involved in the CityGML SWG, at the moment it is not possible to discuss with absolute certainty the final version of CityGML 3.0 and its impact on the ADE mechanism. Even though at the moment it seems unlikely that CityGML 3.0 will include changes to the ADE concept, changes to other fundamental concepts of CityGML such as the LOD [52] may render some of the previous ADEs incompatible [16].