MODELLING BELOW-AND ABOVE-GROUND UTILITY NETWORK FEATURES WITH THE CITYGML UTILITY NETWORK ADE: EXPERIENCES FROM ROTTERDAM

: Precise and comprehensive knowledge about 3D urban space is required for simulation and analysis in the ﬁelds of urban and environmental planning, city administration and disaster management. In order to facilitate these applications, geo-information about functional, semantic, and topographic aspects of urban features, their mutual dependencies and relations is needed. Substantial work has been done in the modelling and representation of above-ground features in the context of 3D city modelling. However, the below-ground part of the real world, of which utility networks form a big part, is often neglected. Existing data models for utility networks are generally very domain-speciﬁc and, therefore, not suitable either. This paper describes a 3D data modelling approach for integrated management of below-ground utility networks and related above-ground city objects. This approach consists of manipulating ﬁrst the structure of existing utility data in the commonly used Feature Manipulation Engine ETL software in order to make the data compliant to the CityGML Utility Network ADE data model. Subsequently, workspaces are created that take care of storing the CityGML data into the free and open-source 3D City Database, which has been extended in order to manage utility network data, too. Moreover, the research shows the suitability of the extended 3DCityDB to perform graph-based topological operations by means of the PostgreSQL pgRouting extension. Lastly, the results are visualized in typical GIS applications, e.g. QGIS and ArcGIS.


INTRODUCTION
In today's technologically advanced society the dependency of every citizen and company on having a working infrastructure is extremely high [Semm et al., 2012].Therefore, precise and comprehensive knowledge about 3D urban space, with above and below-ground features, is required for simulation and analyses.In order to facilitate these applications, geo-information about functional, semantic, and topographic aspects of urban features, their mutual dependencies and relations is needed.
In recent years, substantial work has been done in the modelling and representation of above-ground features in the context of 3D city and building models [Biljecki et al., 2015].One well-known standard for representing semantic 3D city models is the international OGC standard CityGML [Gröger et al., 2012].At the same time, specific data models for utility networks were developed by different industries to provide a means to represent, exchange and store utility networks data [Hijazi et al., 2017].Existing utility network data models can be indeed very rich and detailed, however they are generally defined for application-specific domains and lack the possibility to model different network types coherently.Moreover, the mutual relationships between networks as well as their embedding into 3D urban space are not thoroughly supported, yet.As a matter of fact, existing utility network data models are commonly tailored just to a specific type of commodity, and are generally dedicated to serve only as as-built documentation.Therefore, they are currently not suitable for the integrated modelling and representation of utility networks and city objects in 3D urban space [Becker et al., 2013].To conclude, a comprehensive 3D standard data model, which provides a common basis for the integration of the different utility networks within a 3D city model in order to facilitate analyses, visualization and management tasks, is still missing.A 3D data model for utility networks and related city objects can potentially be used for management purposes and grasp the complexity of existing heterogeneous utility networks.Such a data model would be interesting for utility owners, managers, contractors, surveyors and other stakeholders.The objective of this research is to propose a suitable data modelling approach that will allow for integrated management of underground utility networks and related aboveground city objects.
In this paper, several existing utility network data models are briefly described.The scope of this research is limited to electricity and sewer network data, for now.Nevertheless, many aboveground city objects exist that relate to one or more below-ground utility networks.Examples of such city objects are: street lights, electrical cabinets, manholes or pumping stations.Here, only streetlights and manholes (covers) will be considered.In addition, only actual physical relationships will be considered.Other types of relationships, e.g.spatial relationships like proximity are not part of this work.Moreover, the utility networks and related above-ground city objects will be presented in a low level of detail (LoD) since this research is not focused on how to optimally visualize a real world situation.Furthermore, other types of data, e.g.financial data, will not be considered.The same goes for data that relate to time and planning.
As test case, the electricity and sewer network data of the municipality of Rotterdam, the Netherlands, were used.The findings, in addition to the ones gathered from experts at the municipality of Rotterdam, can be used to test and, if needed, complement the most suitable data model and support in fulfilling the needs of the city.
ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume IV-4/W7, 2018 3rd International Conference on Smart Data and Smart Cities, 4-5 October 2018, Delft, The Netherlands

RELATED WORK
Significant research has been conducted in the field of semantic 3D city modelling over the last decades [Emgard and Zlatanova, 2007].Local governments currently use 3D city models for e.g.urban planning and asset management purposes [Biljecki et al., 2015, Benner et al., 2005].One well-known standard for the representation and exchange of 3D city models is the international OGC standard CityGML [Gröger et al., 2012, Kolbe, 2009].
Although substantial work has been done in the modelling and representation of city objects above-ground, below-ground features are often neglected both in theory and practice.[Emgard and Zlatanova, 2007] propose a framework for integrated modelling of geographic 3D data, combining below-and above-ground features, using CityGML.The framework is based on the subdivision of features into: earth surface features, above-earth surface features and below-earth surface features.
Figure 1.Subdivision of features with respect to their position above or below ground (according to [Emgard and Zlatanova, 2007]) Utility networks, located below ground, are critical infrastructures and form a significant part of the real world.[Becker et al., 2013, Becker et al., 2011, Hijazi et al., 2017] present the Utility Network ADE, an extension of the CityGML standard for such infrastructures.This data model allows for the integrated modelling and representation of topography, topology, functional properties and dependencies of networks and their components within a 3D city model.Hierarchical representations for both networks and network components are supported as well.
However, when it comes to the current version of the Utility Network ADE (at the time of writing, v. 0.9.2), no thorough study has been conducted on how to integrate existing utility network data into 3D city models.Furthermore, the focus of earlier studies [Becker et al., 2011, Becker et al., 2012a] has been on the modelling of below-ground utility networks and neglected dependencies and relationships between below-above-ground objects.This paper presents an approach for the integrated modelling of utility networks within CityGML, which includes also the linkage of below-and above-ground features.
CityGML datasets may become very large and objects may be arbitrarily nested leading to complex data structures.Therefore, a database with a carefully optimized database schema is needed, to allow for interoperable data access and management [Zlatanova and Stoter, 2006].The free and open-source 3D City Database (3DCityDB) implements the CityGML standard and can be used to store, represent, and manage virtual 3D city models on top of a standard spatial relational database.

BACKGROUND
Different utility network data models have been developed in the past by different industries to provide means to represent, exchange and store utility networks [Hijazi et al., 2017, Kutzner andKolbe, 2016].Most of them have been developed to meet the needs of specific domains.In this study the focus is put on the following criteria with respect to the data model characteristics: the data model should allow for an integrated representation of topography and topology, modelling in a multi-scale way, linking to existing city objects in an integrated way and it should be able to describe dependencies among different networks.Furthermore, it would be beneficial to pick a data model for further experimenting which is based on open standards and is provided with technical documentation.
A brief description of the most common existing utility network data models is listed below.

INSPIRE Utility Networks model
The The model is based on a node-arc-node structure and network concept.In addition to generic network information, each network element can be detailed within its domain specific application schema through various attributes.

IFC Utility model
The IFC Utility model is an ISO standard developed with the intention to model utilities inside a building [ISO 16739, 2016].It provides a 2D and 3D representation of network objects.Relationships between network objects are described using a connectivity concept, which comprises both the physical and logical connectivity.IFC provides a rich semantic categorization of network objects based on their role in the network.

ESRI Utility Network
ArcGIS provides two sets of network data models to manage the logical and physical relations in a network: the ESRI Geometric Network model and the ArcGIS Schematics [ESRI, 2016].Both data models are semantically rich and complex, but only represent the 2D topography of the utility network besides the logical network connectivity information.

PipelineML
PipelineML is a GML-based data standard for the exchange of pipeline data focusing on the oil and gas industry [OGC, 2016].
The standard only focuses on 2D geometric representation of distribution pipes.In addition, the spatial relationships between network features in a network can be modelled.
ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume IV-4/W7, 2018 3rd International Conference on Smart Data and Smart Cities, 4-5 October 2018, Delft, The Netherlands

CIM
The CIM is meant for power systems and has currently two primary uses: to facilitate the exchange of power system network data between companies, and to allow the exchange of data between applications within a company [McMorran, 2007].The CIM comprises two standards; the IEC standard 61970-301 and the IEC 61968-11.The CIM extensively models the relationships and domain specific semantics, but completely neglects the geometry of each component.

IMKL
IMKL is a Dutch standard data model which is particularly meant for exchanging location information of utility network data and to avoid damage to utilities.A distinction is made between the different utility networks: electricity, gas, chemicals, drink water, wastewater, telecommunication and district heating.Every utility network is described by its location and topology of network elements [van den Brink et al., 2016].IMKL has been adapted to be more compliant with international standards, e.g. the OGC CityGML Utility Network ADE.

CityGML Utility Network ADE
The Utility Network ADE extends the CityGML model by integrating utility networks into the 3D urban space and to make their network topology and topography explicit.It intends to provide a common basis for the integration of the diverse models.Furthermore, the Utility Network ADE allows for hierarchical modelling of networks and subnetworks, as well as of components and subcomponents [Becker et al., 2012b].In addition, the data model includes dependencies and relationships among network features, as well as between network features and city objects.To the authors' knowledge, this is not supported by any other standards at the time of writing.Of particular interest is the attribute "connectedCityObject" of class AbstractNetworkFeature.This allows for a direct linking to any city object (e.g. a streetlight).Further classes for specific network features (e.g.cables, pipes, etc.) are derived from the AbstractNetworkFeature class.Just a selection of those relevant for the work presented in this paper is depicted in the figure.
In hindsight of the criteria presented at the beginning of this section, the Utility Network ADE seems to better fit the needs in terms of richness and flexibility of modelling capabilities.Therefore, the data mapping task described in this work has adopted the CityGML Utility Network ADE as destination.

CASE STUDY: ROTTERDAM
As a test case, this work has used two distinct utility networks: the low-voltage electricity and the standard sewer-system networks of the municipality of Rotterdam, the Netherlands.The low-voltage electricity network is the part that relates to most above-ground man-made city objects (e.g.buildings, streetlights etc.).The standard sewer network conveys water using gravity.

Data
In Rotterdam, several datasets are available for experimentation purposes (Figure 3).A dataset representing sewer pipes and electricity cables as well as the related above-ground city objects (streetlights and manholes) were used.Data are provided in ESRI shapefile format.In addition, a 3D city model of Rotterdam in CityGML format was used.The 3D city model includes buildings, trees, ground level, design and building information.

Mapping existing data to the Utility Network ADE
All network datasets were first checked and then transformed from the input format (shapefiles) to the destination format (XML) according to the CityGML Utility Network ADE using Safe Software's Feature Manipulation Engine (FME) 2017.1 software.FME is an ETL (Extract, Transform and Load) software tool that allows to work with several spatial formats.It offers reading and writing support not only for CityGML, but also for any ADE -provided the XSD file of the ADE is available.This functionality "out-of-the-box" was the reason for using this software.FME essentially reads the source data, manipulates the data structure and content with so-called transformers and subsequently writes the data to another data format.The translation for the datasets of the case study uses and integrates more than a hundred FME transformers.In the following, a list of the transformers used in this work is presented: Relationships (associations, aggregations, compositions) between CityGML classes are generally encoded in such a way that the referenced features are encoded as child elements of the referencing features (e.g. with buildings and building parts).When a class is referenced by several other classes, relationships are realized by means of XLinks.Xlinks are used for pointing to remote objects within the same or an external document.Figure 4 shows an example of how a relationship between classes of the Utility Network ADE is encoded by means of an XLink.In FME, relationships need to be provided explicitly for each referenced object in the form of the role names presented in the UML diagram [Kutzner, 2017].For this purpose, the FME AttributeCreator transformer is used to add the 'citygml feature role' attribute to the referenced objects.The attribute value is the role name of the referenced class.For example, for the objects of class Cable and RoundPipe the attribute value 'component' is used (Figure 5).The same procedure, but with different role names, is used to create relationships between other CityGML objects.Besides some differences between object belonging to different classes, e.g.Cable and RoundPipe, the overall transformation process for both utility networks is rather similar.Therefore, no further distinction is made in this paper when discussing the transformation of each utility network to the Utility Network ADE.
When it comes to the test case of Rotterdam, objects belonging to the following classes -either from the CityGML or from the Utility Network ADE data model -are written: • CityGML: -CityFurniture, e.g. for above-ground streetlights, manholes etc. -CityObjectGroup • Utility Network ADE: -Network The topological relationships are determined thanks to the FME TopologyBuilder transformer.The TopologyBuilder is set to 'assume clean data' in order to prevent that lines be splitted in case they intersect in 2D but not in 3D.The topologically significant nodes (point geometries) and edges (curve geometries) are output.These features, together with the point geometries of the source dataset (streetlights or manholes), form the basis for the rest of the transformation.
The output edges are mapped to the following feature types: • Cables or Pipes • InteriorFeatureLinks (belonging to the FeatureGraph of the corresponding Cable or Pipe) The output nodes are mapped to the following feature types: For both utility networks, the relationship between the belowground utility network features and above-ground city objects are created similarly.In case of the electricity network, the Ter-minalElement represents the below-ground utility network feature.In case of the sewer network, the SimpleFunctionalElement (e.g. the below-ground part of the manhole) represents the below-ground utility network feature.In both cases, a URI, as an attribute value of the 'connectedCityObject', is used to make a one-to-one reference to the above-ground city object (Figure 6).In a standard sewer network, each sewer pipe is connected to a manhole at the start and end of the pipe.In case of the electricity network, a connection cable to the streetlight is constructed by using a the NeighborFinder Transformer in FME.
A FME Creator transformer is used to write the Network and the NetworkGraph features, as aggregates of the other objects belonging to each network.After running the FME workspaces, an XML-based CityGML instance document is written, and it can optionally be visualized directly in the FZKViewer or in FME's Data Inspector (Figure 7).

Storing the Utility Network ADE data into the 3DCityDB
CityGML datasets may become very large and objects may be arbitrarily nested leading to complex data structures.Therefore, a database with a carefully optimized database schema is needed which allows for interoperable data access and management [Zlatanova and Stoter, 2006].For this purpose, the 3D City Database (3DCityDB) is used in this work.The free and opensource 3DCityDB implements the CityGML standard and can be used to store, represent, and manage virtual 3D city models on top of a standard spatial relational database.[Yao and Kolbe, 2017] present how the 3DCityDB can be extended in order to allow for handling arbitrary CityGML ADE's, e.g. by automatically mapping Object-Oriented Models (OOM) to Entity Relationship Diagrams (ERD), and successively generating Data Definition Language (DDL) scripts to generate the database schema.
The proposed approach has been tested on a number of different CityGML ADEs, among which, for example, the Utility Network ADE, however a complete implementation is not yet available due to ongoing research and implementation work.
At the same time, and based on the same mapping rules, [Agugiaro, 2017] has made available a manually-derived implementation of the Utility Network ADE for the Postgres/PostGIS version of the 3DCityDB, which is shipped as DLL scripts for tables, updatable views, stored procedures (both for insert and delete) and ADE-metadata management.All resources are freely available online on GitHub [Agugiaro, 2017].The implementation rules follow the same approach adopted for the Energy ADE [Agugiaro and Holcik, 2017], which is also already available on GitHub.
The 3D City Database extension for the CityGML Utility Network ADE is meant to store, represent, and manage all Utility-Network-ADE-related entities and attributes.In the 3DCityDB, one of the most important tables is named CITYOBJECT.The cityobject table is used as a container of all city objects, above and below-ground, and maps the equivalent abstract class CityObject of CityGML.However, several other tables exist that relate to the CITYOBJECT table through foreign keys in order to fully represent an object belonging to a particular class.For example, a building has data stored in the CITYOBJECT table, in the BUILDING table, and in other linked tables.
Due to the complexity of the underlying database structure, writing CityGML data directly to the database is possible, however rather complex.For this reason, the so-called CityGML Importer/Exporter [Chair of Geoinformatics, Technical University of Munich et al., 2017] is already available and allows to automatically populate the database starting from a CityGML instance document.However, at the time of writing (Spring 2018), the Importer/Exporter currently supports only "pure" CityGML data, e.g.no ADE contents.Therefore, the process of importing of Utility Network ADE data into the extended 3DCityDB can be automated by means of FME.FME reads the Utility Network ADE data and, subsequently, populates the tables of the extended 3DCityDB.
Since many tables are linked through foreign keys, the order of inserting the data is an important task that must be handled with care.For example, the CITYOBJECT table has to be populated before populating the UTN9 NETWORK table, as the id of the UTN9 NETWORK table is a foreign key that refers to the id, as primary key, of the CITYOBJECT table.As mentioned before, data of objects belonging to certain classes are written in more than one table.At the same time, certain tables may contain data of objects belonging to different classes.
Table 1 exemplifies it and lists some classes and the corresponding tables they are mapped to, for example for the electricity network data.The order of listing is also the order of inserting used.More details can be found in [den Duijn, 2018], including the process of inserting the sewer network data.
The UTN9 NETWORK FEATURE table contains a cityobject id field which is a foreign key referring to the id of the CITYOBJECT table (e.g.implementing the connectedCityObject attribute as in the UML diagram shown in Figure 2).This allows for linking the The id, start node id and end node id columns are required for querying the database using pgRouting.The start node id column contains the identifier of the first end point vertex of the Figure 9. Network part that transports waste water using gravity.
edge, the so-called source.The end node id column contains the identifier of the second end point vertex of the edge, the target.In addition, a 'cost' column is required by pgRouting, which contains a value representing the weight of an edge.By default this column is not part of the UTN9 LINK table and can, therefore, either be added or defined "on the fly" at query execution time.
In this study, for testing purposes, each edge is given the same cost value of 1.As an example, the SQL query in Figure 8 uses pgRouting in order to check whether a path exists between two nodes (start: 1647 and end: 1648).The WHERE clause in the subquery tells the algorithm it is not possible to use the broken link, which in this case has id 2440.
In addition, a directed parameter in the route query can be set to true in case the graph network is considered directed.In this research, the direction of flow in a standard sewer system, in which water flows from higher lower elevations, is calculated using the z-coordinates of the start and end vertices of the 3D line geometries representing the network elements (pipes).In [den Duijn, 2018], a test is conducted that confirms the relevance of implementing the flow direction in a network for routing functions.It is checked which route is taken to convey wastewater.After querying the 3DCityDB, the results are visualized in a GIS application (Figure 9).

CONCLUSIONS
The objective of this study was to test the maturity and potentiality of the CityGML Utility Network ADE as a suitable data model for below-ground utility network features and related above-ground city objects.Additionally, it was investigated how to currently store and use Utility Network data in a database, and how to exploit the data in the database to perform some routing analyses.
Based on a comparison between several existing utility network data models, the CityGML Utility Network ADE turned out to be the most promising data model.In contrast with other data models, it is capable of modelling and linking heterogeneous utility network features, as well as utility network features and aboveground 3D city objects -which was a key requirement in this research.The data model allows both for a topographical and a topological representation of a network.The former is generally used for "typical" GIS-based applications, the latter is required for graph-based analyses, typical of network-specific applications.
The suitability of the CityGML Utility Network ADE is proven in this work when it comes to the existing utility network data used in the test case of Rotterdam with regard to the low-voltage electricity and standard sewer networks.However, several other different types of utility networks exist and therefore further research is needed.The Utility Network ADE is an extension to the the CityGML standard and therefore profits from the already available semantic and coherent modelling of several urban objects in a 3D city model.Besides the above-mentioned integrated dual representation (topography and topology), one of the major advantages of the Utility Network ADE consists of the explicit relationships between below-ground network features and aboveground city objects.
With regard to the specific test case in Rotterdam, implementation of the relationships between 1) the below-ground electricity network and above-ground streetlights and 2) between the sewer network and the above-ground manhole covers was carried out successfully.Further investigation is however needed since several other types of relationships exist, but in this work they were not considered, yet.
FME was used for the ETL operations of the existing utility network data.Its graphical programming interface helped in the definition of the process, however the resulting workspaces are still rather complex.Additionally, the success of the ETL process strongly relies on the type and quality of the source data.
Upon conversion of the data to the Utility Network ADE, additional FME workspaces were created to insert the data into the 3DCityDB.The extended 3DCityDB has proven to be suitable for storage and management of the network data.
To facilitate asset management, utility services operation and maintenance, as well as emergency management and disaster response are of great importance for a municipality.The extended 3DCityDB, in combination with the pgRouting library, permits to perform several types of (network) operations that can support these activities.For example, broken or malfunctioning city objects can easily be found in case of a utility strike.Also, the flow of water in a standard sewer system can be simulated.A prerequisite for executing such graph-based analyses is to have modelled the topological relationships between network elements.More other types of relationships would require new queries, and vice versa.
The approach proposed in this paper paves the way for future research on the use and implementation of the CityGML Utility Network ADE as standard data model.

FUTURE WORK
In the following, some ideas are presented that might enhance the proposed approach.First of all, it might be useful to model the network features in a higher geometrical level of detail (LoD).In the current approach above and below-ground network features are represented in a rather low LoD.Secondly, the CityGML Utility Network ADE needs further detailing (e.g. in terms of attributes) with respect to its classes and use.Thirdly, further testing on utility networks and city objects will come along with challenges that will enhance the proposed approach.Lastly, further investigation regarding more types of analyses, modelling different types of relationships, and additional data visualizations tools and strategies is part of the future research.
INSPIRE Utility Networks is part of the "Utility and governmental services" theme within the INSPIRE Directive.The model includes application schemas for electricity, oil, gas, sewer, telecommunication, and water networks [INSPIRE Thematic Working Group Utility and Governmental Services, 2013].

Figure 2
Figure 2 depicts a simplified excerpt of the Utility Network data model, represented in UML.The Network and the AbstractNet-workFeature classes are derived directly from the CityGML class CityObject.They allow for the topographical representation of a network, while the FeatureGraph and NetworkGraph classes (and their components classes) take care of the topological one.Of particular interest is the attribute "connectedCityObject" of class AbstractNetworkFeature.This allows for a direct linking to any city object (e.g. a streetlight).Further classes for specific network features (e.g.cables, pipes, etc.) are derived from the AbstractNetworkFeature class.Just a selection of those relevant for the work presented in this paper is depicted in the figure.

Figure 2 .
Figure 2. A simplified excerpt of the Utility Network UML diagram.The Network and the AbstractNetworkFeature allow for the topographical representation of a network, while the FeatureGraph and NetworkGraph classes (and their components classes) take care of the topological one.Further classes for specific network features (e.g.cables, pipes, etc.) are derived from the AbstractNetworkFeature class.Only a selection is depicted here.

Figure 3 .
Figure 3. Representation of a the input datasets used in this work.Electrical network (in red) and sewer-system network (in purple) of the city of Rotterdam.<Network i d =" NetworkID 47589"> <component> <RoundPipe i d =" R o u n d P i p e I D 1 2 3 e . . ." > <d e s c r i p t i o n >500−PE−Water </ d e s c r i p t i o n > <s t a t u s >inUse </ s t a t u s > <h a s M a t e r i a l x l i n k : h r e f ="# M a t e r i a l I D 1 2 3 e . . ." / > <l o d 1 G e o m e t r y> <L i n e S t r i n g > <p o s L i s t >30 10 0 10 30 1</ p o s L i s t > </ L i n e S t r i n g > </ l o d 1 G e o m e t r y> <i n t e r i o r D i a m e t e r >500</ i n t e r i o r D i a m e t e r > </ RoundPipe> </ component> </ Network>

Figure 5 .
Figure 5. Example of assignment of the role name (e.g.component) using the FME AttributeCreator

•
CityFurniture • Nodes (belonging to the FeatureGraph of the corresponding Cable or Pipe) • Nodes (belonging to the FeatureGraph of the corresponding TerminalElement or SimpleFunctionalElement) • InterFeatureLinks between the exterior nodes belonging to the different FeatureGraphs of Cables or Pipes between the exterior node belonging to the Feature-Graph of a TerminalElement or SimpleFunctionalElement and the exterior node belonging to the Feature-Graph of a Cable or Pipe Figure 6.Example of a link in the Utility Network ADE between a TerminalElement object and a street lamp by means of the conntectedCityObject attribute (inherited from the AbstractNetworkFeature class).The attribute contains the ID of the street lamp, modelled as CityFurniture object in CityGML.

Figure 7 .
Figure 7. 3D view of utility networks (sewer and electricity) connected to above-ground city objects and visualized in the FZKViewer.
Figure 8. Example of a SQL statement to check the connectivity between two nodes (id=1647 and id=1648) with restricted access to the broken link (id=2440).

Table 1 .
CityGML classes and corresponding table names in the 3DCityDB used for the electricity network in the case study.