Semantic 3D Modeling of Multi-Utility Networks in Cities for Analysis and 3D Visualization

Abstract

Precise and comprehensive knowledge about 3D urban space, critical infrastructures, and belowground features is required for simulation and analysis in the fields of urban and environmental planning, city administration, and disaster management. In order to facilitate these applications, geoinformation about functional, semantic, and topographic aspects of urban features, their mutual dependencies and their interrelations are needed. Substantial work has been done in the modeling and representation of aboveground features in the context of 3D city and building models. However, standardized models such as CityGML and IFC lack a rich information model for multiple and different underground structures. In contrast, existing utility network models are commonly tailored to a specific type of commodity, dedicated to serve as as-built documentation and thus are not suitable for the integrated representation of multiple and different utility infrastructures. Moreover, the mutual relations between networks as well as embedding into 3D urban space are not supported. The Utility Network ADE of CityGML as proposed in 2011 provides the required concepts and classes for the integration of multi-utility networks into the 3D urban environment. While the core model covers only the topological and topographic representation of network entities, the functional and semantic classification of network objects is now introduced in this paper. This paper will show how concepts and classes can be defined to fulfill the requirements of complex analyses and simulation, and how properties of specific networks can be defined with respect to 3D topography but also network connectivity and functional aspects.

1 Introduction and Motivation

The range of applications of city models reaches far beyond pure visualization today. Applications such as energy consumption analysis, carbon balancing, risk and disaster management as well as future applications like city life cycle management require an extensive “inventory list” of urban space. Nowadays city models are used to give the administration, disaster managers, and companies access to the city’s inventory. The inventory comprises buildings, streets, vegetation objects, plants, classified land uses, and elevation models. Typically, real world objects above ground can be modeled using existing standards for 3D city modeling such as CityGML or the forthcoming INSPIRE data specifications in the future (Gröger et al. 2008). Assuming that a city can be understood as a system in terms of an organized structure regarded as a whole and consisting of interrelated and interdependent elements (components, entities, factors, members, parts, etc.), thus, a city model can be seen as an abstract representation of such a real existing system (ISO19109 2005). CityGML and IFC represent such an abstraction of a system. Whereas CityGML can represent many elements of the city system (respectively a part of a system), IFC represents a system within a system. Nevertheless, the overall concept of having objects representing physical (building) and conceptual entities (city), giving them contextual information by setting them into relationships and assigning characteristic properties is valid for both models. The IFC model includes object connectivity, processes, etc. that is still an ongoing task within the city wide model—CityGML. The Utility Network ADE of CityGML represents a first approach to extend the abstract model of a city by integrating utility infrastructures into the urban space and to make their network topology and topography explicit.

The core model (Becker et al. 2011a, b) of this application domain extension establishes the relation, or—to be more precise—the connection between aboveground and belowground urban inventory with respect to utilities. The core of this ADE defines the modeling environment by making relevant features and their mutual relations explicit and allowing the 3D topographical modeling of entire networks, sub-networks and network features as well as their graph representations. The consequent treatment of network features as abstraction of real world objects (topographic point of view) as well as a graph object, represented by its own network graph, makes the model more flexible as the models realized in existing GIS utility systems. The module Networkcomponent of the Utility Network ADE will extend the core concept by classes that will describe the entities of any utility network in a semantical-functional way.

Already existing utility network models represent utilities in a semantically rich way, but their components do not interact with or have explicit relations with urban features. Those networks are very detailed and rich of semantics; some of them dedicated for daily use in utility companies, some used as data exchange models and others just represent utility networks within parts of urban space (buildings). Each of them is an abstraction and reduction of a system (model) in itself but they do not provide links to the higher context and thus are not feasible for analysis or simulation purposes in terms of urban energy consumption analysis, carbon balancing, risk- and disaster management, and city life cycle management. A model feasible for those purposes has to meet the following requirements and should represent an eligible generalization and subset of reality:

• The elements of such a model must have functional as well as structural relationships between each other.

• The model must represent independent but interrelated elements in order to enable simulation and complex analysis.

• The model must be valid for different, heterogeneous types of utility networks.

• The model must reduce the complexity on the one hand but preserve the required information for usage in simulations, analysis, calculations, and cartographic visualization in disaster case.

Some popular data models for representing, exchanging, and storing utility networks are introduced and discussed briefly in Sect. 2. The ArcGIS utility models stands proxy for popular GIS-based utility solutions, the IFC model as proxy for building wide supply system, and the INSPIRE network model as proxy for a city or country wide supply system. In Sect. 3, a short overview about the core model of the Utility Network ADE is given, laying out the basis for the introduction of the specific extensions of the Utility Network ADE—the NetworkComponents (Sect. 4) and the NetworkProperties (Sect. 5). Section 6 sketches the implementation of the model in ArcGIS. Finally, we draw conclusions and point to future work (Sect. 7).

2 Analysis of Existing Geospatial Utility Network Models

2.1 INSPIRE Network Model

The “Network” package of the INSPIRE data specifications (INSPIRE 2010a) defines the basic application schema for networks which is extended by additional, domain specific spatial data schemas (INSPIRE 2010b, c). The central class is NetworkElement, which may be any entity that is relevant for a network. The network package consists of further classes that are required for modeling networks, such as Network, Link, and Node.

A Network is a collection of NetworkElements that is the superclass for elements like Area, Node, and some special classes such as GeneralisedLink, LinkSet and GradeSeparatedCrossing (see Fig. 1).

Fig. 1

Network application schema of INSPIRE (adapted from (INSPIRE 2010a))

Thus, a simple network may only consist of Nodes and Links, where a Link must be bounded by exactly two nodes. The clear distinction of NetworkElements into point-like (Node) and line-like (Link) objects and the lack of a feature aggregation schema does not allow for hierarchical decompositions of network components within the core model. For example, a point-like object cannot consist of other point-like or line-like objects. The hierarchical modeling of a line-like object is supported by the class LinkSet. A hierarchical modeling of a network and the modeling of interdependencies is possible by using the class NetworkConnection. NetworkConnections are also NetworkElements relating two or more arbitrary NetworkElements facilitating the modeling of hierarchical networks (see (INSPIRE 2010a, p. 93).

The INSPIRE application schema “Utility Networks” including the sub schemas for Electricity, Oil and Gas, Sewer, Telecommunications, and Water Networks extends the Generic Network Model (GNM, see Fig. 2) besides transportation networks now also by utility networks (INSPIRE 2010a, b, c, 2011). The utility networks application schema extends the classes provided by the GNM by utility specific abstract classes such as UtilityLinkSet, UtilityLinkSequence, UtilityLink, UtilityNode, UtilityNodeContainer and UtilityNetworkElement. For further information, reference is made at this point to INSPIRE (2011) consolidated UML Model.

Fig. 2

Principle structure of modeling networks using the INSPIRE specification. The dependencies are established by creating subclasses from referred packages

In addition to this, the model provides common features (called CommonTypes) to the subsequent application schemas for electricity, water, and so on. Those CommonTypes are types such as pipe, duct, manhole, pole, and diverse enumerations that describe material, exterior shape, and type of features that occur in other utility networks as well. They serve as container features for entities of other utility networks. The further semantic specialization of needed utility entities is then done within the respective application domain schema. Since the core model only provides a 2D representation of network elements, the theme “Utility and Governmental Services” allows for the modeling of an ElevationLine or ElevationPoint to make the relative height of a network component with respect to the terrain explicit. However, the model lacks of an explicit 3D topographic representation of network objects useful for collision detection, simulation of impacts of blast, and 3D visualization.

Basically, only a specialization of the distribution entities such as pipes and cables, devices (called appurtenance) and of the respective network is done. There is no further domain specific classification into other pipes, devices, or other domain specific entities as shown in Fig. 3. Type attributes being available for both distribution elements and appurtenance entities take over the further specialization of those main elements of networks. However, the functionality of those network entities cannot be derived directly or is not obvious. The named use cases for the representation of utility networks in INSPIRE are mapping and documentation, e.g. to facilitate information portals which make information about cables and lines available for contractors that are planning excavation works. Thus, the focus of the model is on describing the topography of distribution elements and appurtenances and not on modeling their functionality and interdependencies.

Fig. 3

Specialization within the domain specific extensions of the INSPIRE UtilityNetwork model (excerpt)

In summary, the structure of the INSPIRE modeling approach for utility networks can be partitioned into three parts. The first part is the Generic Network Model dedicated to the modeling of topological relationships between any network entities. The second part defines utility network specific entities such as UtilityLinks and UtilityNodes and provides more entity specific attributes as well as common types for use in domain specific application schemas. Those schemas form the third part of utility network modeling and specify the domain specific entities and attributes for the respective domain (cf. Fig. 3).

2.2 IFC Utility Model

The most important standard for data exchange of buildings in the field of architecture and civil engineering are the Industry Foundation Classes (Liebich 2009). The IFC represent logical building structures, accompanying properties (attributes) with 2D and 3D geometry as well as utilities. As Liebich et al. (2007), Liebich (2009), Becker et al. (2011a, b), and Hijazi et al. (2011) point out, IFC offers two different ways of connectivity in order to build up a network that may be a physical or logical connection between building service elements. In general, a logical connection realizes the linkage of two components via so-called Ports, whereas a physical connection is established by a realizing element such as IfcFlowFitting. The connectivity concept of IFC comprises both the physical connection between elements (IfcRelConnectsElements) and the logical connection of building service items on the level of their ports (IfcRelConnectsPorts).

Besides the connectivity concept that realizes the topological relations between elements the IFC even provide a model for the topographic and semantic representation of building service elements. The superclass of all building service elements respective of all included distribution systems is represented by the class IfcDistributionElement. Those elements are further specialized (see Fig. 4) into flow elements (IfcDistributionFlowElement) and controller objects (IfcDistributionControlElement) which in turn have further subtypes but do not elaborate further attributes. Those subtypes serve solely for semantically and logically structuring of the model.

Fig. 4

Principle structure of IFC building service elements (excerpt)

IFC distinguishes flow objects into IfcFlowFitting, IfcFlowSegment, Ifc-Flow-Controller, IfcFlowTerminal, IfcFlowMovingDevice, IfcEnergyConversionDevice, IfcFlowStorageDevice, IfcFlowTreatmentDevice, and IfcDistributionChamber-Element. The IfcDistributionControlElement comprises all elements which are necessary to define elements of a building automation control system that are used to impart control over elements of a distribution system (Liebich et al. 2007). Thus, it is possible to control valves, dampers, etc. through explicit actuation (Ifc-Actuator). IFC allows both 2D and 3D geometries to represent the real-world shape and extent of network entities. The geometry is given in a local engineering reference frame which is valid for a single building but which lacks the possibility to evaluate the building utilities in an urban or regional context. To summarize this (see Fig. 4) the layer SharedBLDGServiceElements forms an intermediate layer that classifies the objects and elements of a buildings service system according to their functionality within the building system. Thus, every building system may consist of objects that move (IfcFlowMovingDevice), store (IfcFlowStorageDevice), distribute (IfcFlowSegment), etc. the carried medium. A more precise classification respectively definition of building service system elements is being done within the domain layers IfcHvacDomain, IfcPlumbingFireProtectionDomain, Ifc-ElectricalDomain and IfcBuildingControlsDomain. The IFC utility model intentionally is tailored to the modeling of utility structures within buildings. The integration into citywide utility networks on a larger scale is not supported. Visualizations and analyses are hence restricted to the building scale.

2.3 ArcGIS Network Model

In ArcGIS different types of utility networks are defined based on a core concept called Geometric Networks. This core technology represents the basic structure for all kind of utility networks. A network is constructed from edges and junctions as 2D line and 2D point features. Each real world utility object can be represented as one feature in the network whereas same kinds of features can be represented by a feature class (ESRI 2003, 2007; Grise et al. 2001; Meehan 2007). The geometric part of a utility network (see Fig. 5) is a single graph structure consisting of edge and junction elements with an embedding into 2D space. The graph is composed of features from one or more feature classes in a feature data set (ESRI 2003). It binds together feature classes that form a network and contains all attributes, relationships, and validation rules. The logical network (see Fig. 5) is a special data structure to store the connectivity between features of the network and is implemented by a set of tables.

Fig. 5

Example of a feature dataset containing a geometric and logical network

An ArcGIS utility network may consist of four network feature types: simple edge, simple junction, complex edge, and complex junction and thus provides a more flexible way to create network topology as pure edge-node topology. Whereas a simple edge has a one-to-one relation between the feature and the edge element and connects always two junctions, a complex edge may have more than two connected junctions on their length and may represent a sequence of edge elements divided by junctions. Therefore, those complex edges realize a logically connected sequence of edges, but geometrically they represent a single feature and in this respect, it is a kind of feature hierarchy. Similarly, to the edge concept, a simple junction is a one-to-one relation between a feature and its corresponding junction element and is represented by one point in the network. A complex junction, however, is represented by one object within the geometric network and multiple objects including junctions and edges within the logical network. This is illustrated in Fig. 5 where the pump from the upper part of the picture is represented as a graph like structure in the lower part.

Based on ESRI’s geometric network the data models for electrical power distribution, gas distribution, and water distribution were developed. All data models are especially designed for the daily work in utility companies and thus they represent features and relations for as-built documentation in distribution systems. These models include essential sets of object classes for water, gas, or electricity supply networks and properties as well as rules and relationships that define object behavior and provide “…an implementation that focuses on operations and maintenance portions of the facility life cycle” (ESRI 2007, p. 3 Sect. 1). These models extend or address the ArcGIS Geometric Network Model and distinguish between objects that are building the network topology and those which are used for documentation or controlling purposes. Network-forming elements are specializations of SimpleJunctionFeature/ComplexJunctionFeature or Simple-Edge-Feature/ComplexEdgeFeature. Elements which do not participate in network-forming process are handled as “simple” Point, Polyline, or Polygon features. Since they do not participate as network features, they are not part of the network topology and thus cannot be traced or analyzed by any kind of ArcGIS network tools.

All investigated ESRI utility data models can be structured into 2–3 stages. In a first step a superclass for entities with similar semantics is built and is then associated according to its semantics and geometry as a subclass of either SimpleJunctionFeature, ComplexJunctionFeature, SimpleEdgeFeature, ComplexEdgeFeature (see Fig. 6, ElectricComplexEdge). All of these superclasses are container classes, which inherit relevant attributes to subclasses which are further specializations of these superclasses (ElectricLineSegment, BusBar). The last step is a further specialization from the second stage classes in order to further distinguish the entities of the upper class. In case of electricity, the line segments are further specialized into Overhead (OH) and Underground structures (UG) as well as Primary (Pri) and Secondary (Sec) lines.

Fig. 6

Example of stepwise refinement of the ArcGIS utility data model shown on ESRI’S electricity data model (excerpt)

The ArcGIS utility model serves for documentation and planning support in utility companies and city administrations. The models are semantically rich and complex, but do only represent the 2D topography of the network besides the logical network connectivity information. A 3D geometry representation could be associated by using multipath features but these would be uncoupled from the network modeling; just pure 3D visualization. Each of the domain data models is representing a commodity-specific 2D GIS-based abstraction of the respective utility network in the real-world. It cannot easily be used for a different type of utility network, and thus no common model/database integrating different utility models is being provided. The only ArcGIS component that is shared by all of these data models is the Geometric Network Model that forms the common denominator of all ArcGIS utility networks. Nevertheless, the GNM allows for network tracing and other types of network analysis.

3 Short Introduction to the Utility Network Core Model for CityGML: Utility Network ADE

The UtilityNetworkCore as proposed by Becker et al. (2011a, b) is a CityGML application domain extension (ADE) offering the possibility to integrate network structures into the urban environment. In general, it provides classes and concepts to model multiple different infrastructure networks, to embedded the 3D multi-utility networks into the 3D virtual urban environment and to relate them to each other. The base class of the NetworkCore model is the abstract class _NetworkFeature (see Fig. 7). It is a subclass of the CityGML class _CityObject and establishes the link between aboveground city objects and network structures located above and below ground. _NetworkFeature is the conceptual head for the further semantic and thematic classification and description of network entities. Collections of _NetworkFeature instances of one transported medium/commodity can be grouped to Networks, which themselves might be structured into subNetworks, expressed by a self-association of Network. Thus, network hierarchies as they exist in power or gas networks can easily be represented. A similar concept is used to represent component hierarchies. Each _NetworkFeature might contain other _NetworkFeatures, expressed by a self-association named consistOf and, thus, enabling on the one hand a very flexible and on the other hand a very detailed way to model the hierarchies and affiliation of features, between features, and inside of network features.

Fig. 7

UML class diagram of the UtilityNeworkADE core model

Network and _NetworkFeature are used for the topographic representation of utility networks. The representation of network topology and connectivity is achieved within the network core model by providing a dual concept for the representation of features where each network component can be represented both by its topography and by means of a complementary graph structure.

The FeatureGraph is representing a separate graph structure for each utility element reflecting the functional, structural as well as the topological aspects of each element. Following the general principles of graph theory the FeatureGraph may consist of Nodes and InteriorFeatureEdges (cf. Diestel 2010). Thereby a differentiation into interior and exterior nodes is done. Interior nodes represent structural, functional, logical, or physical internal aspects within a network feature. Exterior nodes are used to establish the connectivity to other NetworkFeatures. Different NetworkFeatures can be linked by connecting the exterior nodes via the InterFeatureLink forming a complete NetworkGraph, which itself is the dual representation of the collection of NetworkFeatures—the Network. In order to make mutual relations between networks or network elements explicit, the edge subclass NetworkLink can be used. Hence, besides the feature aggregation, network aggregation, internal, and external connectivity of features it is possible to make dependencies between networks of different commodity types explicit. Networks sharing the same urban space can therefore be modeled as inter modal networks by having explicitly modeled relations. More details on the NetworkCore model are given in Becker et al. (2011a, b).

4 Integration of Network Components

Based on the abstract NetworkCore model described in the previous section, now the concrete representation of the entities within utility networks will be defined. Since we are interested in the representation of diverse types of utility networks for different commodities, we first identify the common elements and functionalities over the different types of utility networks. These entities are then further specialized to represent the distinct properties and characteristics of the components of the different utility network types. The representation of the commodities and the general network properties are modeled independently from the network components, because each utility network can transport different commodities. The commodities and network types are defined in Sect. 5.

Please note that the aim of the data model is not to replace the other models or systems discussed in Sect. 2, but to provide a common basis for the integration of the diverse models in order to facilitate joint analyses and visualization tasks.

The represented degree of detail, i.e. object classifications and their attributes, was determined mostly by the use case of the simulation of the propagation of failures of critical infrastructures across different utility networks in the context of disaster management. However, first investigations show that the model is also suitable for supporting strategic energy planning. Although utility networks differ substantially with regard to transported goods/commodities, they have the following elements in common (see Fig. 8): DistributionElements are used to transport the commodity from producer to consumer or to connect different network users. FunctionalElements are elements which play a role in the operation or maintenance of the network, but which themselves are not elements of the network. For example, manholes are required to access components of a utility network but are not elements of the related network graph. Devices represent network elements playing an active role in the operation of networks like controlling, measuring, storing, transforming, or amplifying. Terminal-Elements mark end points of the network where the goods/commodities “leave” or “enter” the modeled network, e.g. a hydrant or house service connection. ProtectiveElements represent shielding cases or beddings of network elements.

Fig. 8

Network components are modeled as specializations of NetworkFeature into 6 main subclasses. For further details see (NetworkComponents Model 2012)

The concrete realization of DistributionElements is highly dependent on the transported material (gas, liquid, electricity, light, solid medium) and thus is done by cables, pipes, or canals. Pipes and canals can be further specialized according to the shape of the cross section or construction type respectively. Cables do not have to be specialized any further; they are just characterized by diameter/cross section, material type, and transmission type. Therefore, the modeling of utility network entities must take into consideration the functional level of network features as well as the transported commodity type of those features.

Existing infrastructure assets dedicated for the distribution of commodity can be differentiated into RoundPipe, used to transport liquids like water, wastewater, domestic hot water, and RectangularPipes used to transport medium such as air for cooling systems, exhaust systems, and so on (see the two pictures on the left in Fig. 9). According to this distinction useful attributes can easily be defined which further specify the shape or general state of those pipes, such as interiorDiameter and exteriorDiameter for RoundPipes and exteriorHeight, exteriorWidth, interior-Height, and interiorWidth for RectangularPipes (cf. Fig. 10).

Fig. 9

Some examples of DistributionElements (pipes, closed and semi-open canals)

Fig. 10

Modeling approach for DistributionElements. Further details are given in (NetworkComponents Model 2012)

Canals are typically used to transport storm and wastewater and can be built as walkable, open top, closed, or as multi-utility system depending on mounting type, model, and size (see the two pictures on the right in Fig. 9). Therefore, canals are specialized into ClosedCanal and Semi-OpenCanal (cf. Fig. 10). Using additional attributes such as height, width, and cross section shape further specifies the interior profile. Semi open structures (SemiOpenCanal) can be used to represent Storm water systems that exist in urban space as U-shaped features, often along streets or walkways.

Cables are used for energy supply or signal transmission which determines the composition and material type of the cable, but does not affect the exterior appearance (shape) of those. This eliminates the need for further specialization of the class Cable. The proposed data model for DistributionElements and their specific subclasses as explained above are depicted in Fig. 10.

Besides the DistributionElements a utility network consists of elements of feeding, elements of abstraction, and elements of control in order to build a working infrastructure. Sewage treatment plants, water treatment plants, and relay stations are feeding elements. Pressure increase stations, pressure decrease stations, and transformer stations are likewise essential components of those networks that do not feed into the network but alter the transported commodity by suitable devices. While such devices obviously are components of the logical network, the entire treatment plant or transformer station is to be seen as an entity which contains these devices. Since entire stations also need to be represented explicitly by a specific entity, the class FunctionalElement is introduced (see Fig. 8). FunctionalElements are further differentiated in order to fulfill the requirement to represent the main elements of utility networks. ComplexFunctional-Elements aggregate _Network-Features which build a functional unit such as a water treatment plant. Thus, they include further network entities such as pumps, valves, switches, and generators. SimpleFunctionalElements must not contain other network entities since they represent objects useful for maintenance and inspection of the transported commodity. Manholes or inspection chambers are examples for SimpleFunctionalElements.

The next major subclass of _NetworkFeatures is Device. The amount of devices within gas, power, water, and wastewater networks is huge and the definition of super classes (generalization classes) is difficult due to the fact that the specialization within existing utility networks, GIS based as-built documentations is very fine granular. However, the classification of those devices according to their main functionalities provides a feasible approach for a distinction into subsets. Each utility network contains—according to their functionality—StorageDevices, ControllerDevices, MeasurementDevices, TechDevices, and AnyDevices (the latter representing features with unspecific functionality such as a blind flange).

A StorageDevice can be a battery, reservoir, underground storage, or any other device that is used to buffer or put aside the commodity for future use. ControllerDevices are devices such as valves, switches, gate valves, etc. that are used to control, limit or influence the flow of commodity. MeasurementDevices serve as entities for the quantification of commodity flow, commodity quality, or distribution, e.g. pressure sensor, meter, volumetric flow rate sensor, etc. TechDevices might have the same functionality as controller devices and measurement devices but have a clear dependency on power supply, such as cathodic corrosion protection, electrical driven valves, gauges, and slider. Thus, an additional classification of relevant network features is made and is depicted in Fig. 11.

Fig. 11

Inclusion of network entities suitable for measuring, controlling, storing and manipulating the transported material. Further details are given in (NetworkComponents Model 2012)

Finally, two more feature classes have to be taken into account. Entities like water-tap, street light, gas lamp, hydrant, anything being or situated at an end of a line can be seen as a sink and, thus, be represented by using the class Terminal-Element (see Fig. 12). TerminalElements represent interfaces between the utility network model and the environment, where goods/commodities “enter” or “leave” the network.

Fig. 12

Integration of TerminalElement and ProtectiveElement into the model

The final subclass of _NetworkFeature is ProtectiveElement (see Fig. 12). All types of elements intended or used to provide protection of some kind, such as duct work, cable lines, cable protection packages, or cladding tube are covered by this class. ProtectiveElements are further differentiated into _ProtectionShell and Bedding, the latter representing cable lines or tracks that build the near surrounding of a utility line. According to the profile shape _ProtectionShell is further distinguished into RoundShell, RectangularShell, and OtherShell. Since the ProtectiveElement requires objects to be protected, it can contain any other _Network-Feature including more _ProtectiveElements. As already mentioned in Sect. 3 the network core model supports a very flexible modeling of network features, especially the aggregation of network objects using the consistOf composition. ProtectiveElements, however, might be an aggregate of different protection entities and thus each network entity might exist without the parent elements, i.e. a power cable can exist without the parent protection element surrounding it. A switch in a switchgear cabinet, however, cannot exist without the surrounding cabinet. Using both association types allows for simple (cladding tube) and complex (cable protection package) feature modeling as illustrated in Fig. 13.

Fig. 13

Typical ProtectiveElements from left to right; cable line, cladding, cable protection package, cladding tube (i.e. district heating), cable protection package (i.e. power supply)

5 Modeling Network Properties and Commodities

As already mentioned in the previous section the classification of network objects is not only done with respect to the functionality of elements in the network, but also to the transported material. Elements as cable, pipe, and so forth are used for water, gas, and electricity supply as well as in the field of industrial manufacturing of goods of any type. They are even used in production facilities and buildings. Hence, a simple characterization of network elements into water, gas, or electricity related objects is not appropriate and a more specific way to describe the network properties has to be found in order to differentiate all elements in a thematic and semantic manner that will cover all application fields of utility networks.

The abstract class _CommodityType serves as a container for the chemical and hazard classification of the transported material as well as the material classification of the transported commodity and, thus, for the description of its material properties in particular. As mentioned in Sect. 3 and further described in Becker et al. (2011a, b) a collection of _NetworkFeatures transporting the same commodity are assigned to one network, which itself might consist of sub networks (network hierarchy) which all transport the same commodity. The commodity type therefore is related to the Network and not to the individual network features.

Utility networks transport all types of material in every type of physical condition such as gas, electricity, light, and water. According to this a classification into liquid (LiquidMedium), gaseous (GasMedium), and solid (SolidMedium) material is required (see Fig. 14). Each physical condition, respectively each commodity type possesses its own property set which is needed to describe the transported material adequately. Important properties are for example whether a transported material isExplosive or flammable. Also the electricConductivity besides the Flow-Rate, Temperature, concentration, and pHValue of a commodity can be specified and are needed to inform users of a system or city model about the transported material.

Fig. 14

Classifications of transported medium according to physical condition. Further details are given in (NetworkProperties Model 2012)

As depicted in Fig. 14 a network might also be used to transport goods that cannot be described by a physical aggregate state. In fact, another commodity type is needed that allows for representing electrical energy or signal transmission. As Fig. 14 indicates a differentiation between electrical and optical transmission was made due to the fact that the transmission is different and, thus, the needed properties. Whereas the general principle of optical signal transmission is based on total reflection and the needed properties are core, cladding cross section, and mode type, the electrical energy or signal transmission is based on the movement of electrons and the relevant properties are frequency bandwidth, voltageRange, and amperageRange. Thus, every commodity type can be expressed by its respective physical condition or transmission type.

Further classification of commodity types can be done using well-defined and standardized _CommodityClassifiers. These are explained in detail in (NetworkProperties Model 2012).

6 Implementation and Realization of the Model

The developed data models were brought into practice first within the project SIMKAS-3D (www.simkas-3d.de). The aim of that project was to develop methods for the identification and analysis of the mutual interdependencies of critical infrastructures including the simulation of cascading effects in the failure of supply infrastructures (see Becker et al. (2011a, b) for more details on the background).

In order to achieve the project goals a data model and geodatabase for the homogeneous representation of different utility networks such as water, gas, long-distance heating, and power supply had to be developed. The integrated database should facilitate the common operational picture (COP) for disaster management as well as for the simulation of cascading effects in case of network failures.

The NetworkCore model, the NetworkComponents model, and the NetworkProperties model have been mapped to a relational database schema and are stored using the ESRI File-Geodatabase format. According to the developed three data models the database schema is partitioned into three major parts (see Fig. 15) as well. One is representing the geometry of the network components in 2D (poly-line, point) and 3D (multipath), one is representing the logical model—the core model, in tables and the last one is representing the network properties (commodity types) as a relation to the networks. The utility networks of the supplier companies were converted into the created geodatabase by customized FME workbench processes. The proprietary GIS systems were the data source for the process and the created geodatabase has defined the destination writer type and schema.

Fig. 15

Implementation of the CityGML Utility Network ADE as a geodatabase model for ESRI ArcGIS

The interdependencies between networks, network objects, as well as city objects were identified and added. Figure 16 shows 3D visualizations of the available data and its embedding into the urban space. Each building of the dataset is logically connected to the available network. Thus, the possibility is given to perform complex analysis and simulations from producer (treatment plant) to the utility client (building) with respect to cascading effects, network tracing, and more.

Fig. 16

Embedded multi-utilities into 3D urban space in a perspective view (top = above ground; bottom = view from below ground)

7 Conclusions and Outlook

In this paper a new geospatial information model for multi-utility networks was proposed. It specializes the UtilityNetworkADE core model for CityGML as previously presented in Becker et al. (2011a, b) by concrete classes and relationships for the representation of the network entities used in the different types of utility networks and commodities. The semantic classification of network components into the essential entity types was based on empirical studies carried out at different utility providers. A comparison with already existing models and approaches was given in the paper. The integration with the CityGML standard facilitates the integration of multi-utility networks into the urban space respectively into 3D city models for joint visualization and analysis tasks. Furthermore, interoperable exchange of and access to 3D multi-utility networks is enabled.

The data model represents 3D topography, 3D topology, and functional properties and interdependencies of the networks and their components. Hierarchical representations for both networks and components are supported as well. These characteristics allow to perform geospatial analyses in order to determine the implicit interdependencies between network components within the same or different infrastructures or between network features and other city objects based on spatial relations like proximity. For example, collision detection would prevent many pipeline ruptures caused by excavation works. The logical representation of networks and their interdependencies support complex analyses and simulations as needed in the fields of disaster management, critical infrastructure analysis, strategic energy planning, and simulation of power grids.

Concerning the previously existing utility network models, the suggested model can be considered a superset with regard to model expressivity. This will improve the possibilities to exchange or link data between different systems (INSPIRE, ESRI Utility Networks, IFC ⇔ CityGML). However, it will be a task of future work to show that datasets represented according to these frameworks can be cast into the proposed model without information loss. For this purpose we intend to follow the line of Hijazi et al. (2011) where the lossless mapping of IFC utility networks onto CityGML utility networks and vice versa was shown.

In the current version the model does not distinguish different levels-of-detail (LoD). Also the 3D geometry model is limited to the usage of Multisurfaces, Solids, and graph structures with a 3D embedding. The investigation of multiple LoDs and alternative geometry representations like sweep geometries is subject of ongoing work. Of course, the data model can also be extended to create a more fine-grained and semantically further enriched model, e.g. for the representation of material properties of network components and cross sections of pipes and canals.

Further research is currently being undertaken on the cartographic visualization of multi-utility networks and their operating status meeting the requirements of disaster management and stressful situations. The cartographic representation will focus on the functional aspects of network entities and a geometric simplification will be done in order to provide a common operational picture (COP) of the critical infrastructures within a city.