Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

BIMs are becoming increasingly popular in the geospatial community, and have allowed for the production of a certain amount of work integrating BIM into GIS (Benner et al. 2005; Clemen and Gründig 2006; Industry Foundation Classes for GIS (IFG) 2009; Isikdag et al. 2008; Isikdag and Zlatanova 2009; Peachavanish et al. 2006; Wu and Hsieh 2007). BIM is seen as an essential data source for creating a more navigable, interactive and visually realistic information for built environments (Peachavanish et al. 2006). Moreover, some building elements, such as interior utility networks, e.g. gas, water, and electricity, are hidden. The geometry of the existing network is not visible and cannot be collected using traditional 3D measurement and re-construction methods (i.e. laser scanning, surveying, photogrammetric techniques). Therefore, there has been an increasing interest in addressing the issues related to interoperability and integration between 3D BIM data and 3D GIS data. Integrating building utilities within their broader context will open the doors to new application thereof for management of urban utilities (e.g. maintenance operation, emergency response, inspection operation). Several real-world cases can highlight some specific issues, which require integration of interior and exterior utilities in a broader context (Hijazi and Ehlers 2009; Hijazi et al. 2009). City authorities perform regular inspections of some buildings in the city (e.g. chemical labs, factories) to ensure that the water discharged from these buildings is not wasting the public water resources. The inspection team needs to find the location of these elements inside these buildings (trace from specific point on exterior network to locate the equipment in building), in order to test whether they are working probably. Other case refers to maintenance operation in large campuses e.g. university, hospital. Facility managers need to perform maintenance operations, which can be either caused by a failure in the network or planned (preventive) operation (due to date of expiration or cleaning). Both cases will cause an outage of service; since replacing of elements is required. Therefore, buildings occupants need to be warned. Integrating interior and exterior utilities will allow performing analysis and defining the equipment that would be out of service to the room level (e.g. labs, offices). Currently, facility management make an assumption and generalize the announcement, and some time been unable to provide information to the concerned persons.

It is widely known that overcoming the problems associated with heterogeneous environments requires interoperable methodologies and tools. Standardization of data models has been suggested and practiced as a major stride towards achieving the goal of interoperability (Akinci et al. 2008; Peachavanish et al. 2006; Shen et al. 2009). Industry Foundation Classes (IFCs) (Liebich et al. 2010) and City Geographic Markup Language (CityGML) (Gröger et al. 2008) are officially recognized as two standards, and have been independently developed; the former by the International Alliance for Interoperability (IAI), which is the standardization body for the AEC/FM community, and the latter by the Open Geospatial Consortium (OGC), which is the standardization body for the geospatial community. As a result, IFCs are not readily usable in GIS and CityGML (Akinci et al. 2008; Isikdag and Zlatanova 2009; Nagel et al. 2009). The main problem in the integration of BIMs with geospatial information occurs at the point of transfer of geometric information (Wu and Hsieh 2007). Building models use representations such as CSG and Sweep Geometry and in local coordinate system, while geospatial models mainly use Boundary Representation (BRep) and in real world coordinate systems.

A utility network can be modeled in CityGML (Gröger et al. 2008) using UtilityNetworkADE (Becker et al. 2010) (First Draft) – a generic utility network model that is under development (ADE 2010). The IFC schema has different entities that can support the GIS utility network application. IFC schema contain entities representing different network objects, and classify them based on semantics, e.g. pipes, lamps, although connectivity concepts are also involved (Liebich et al. 2010). A thorough understanding of semantics is required to achieve integration and schema mapping (converting models, objects, or descriptions from one world into the concepts used in the other world).

In this paper, we investigate the possibility of integrating the 3D BIM utility network data into a GIS. CityGML Utility Network Application domain extension (ADE) has been employed in this study. The development of the mapping follows a pragmatic approach by means of a manual inspection of both schemas to see which entities and attributes correspond. The work includes analyzing the different concepts of building service system presented in IFC, and looking for possibilities to represent these concepts in CityGML/UtilityNetworkADE.

The paper is structured as follows: after the introduction, Sect. 2 provides an overview of related work with respect to BIM-GIS, CityGML and possible transformation between both standards. While Sect. 3 presents the main concepts and modeling paradigms of IFC concerning utilities, Sect. 4 introduces the main concepts of CityGML’s UtilityNetworkADE. In Sect. 5 we present the investigation results concerning the mapping from IFC utility to CityGML utility, it is organized in two subsections: thematic classes and graph structures. In Sect. 6 the research is concluded.

2 Related Work

To date, a certain amount of work has been carried out on the integration of IFC, GIS and CityGML. Two approaches have been employed: either to transfer geo-data from GIS to BIM; or to transform BIM data into GIS. The industrial foundation class for GIS (IFG) (Industry Foundation Classes for GIS 2009) was one of the first efforts for the integration of IFC models with GIS (and geospatial models). Benner et al. (2005) proposed the QUASY object data model, which is a 3D semantic building model for urban development. The authors also developed a tool for automatic generation of semantic building models based on IFC-models. Nagel et al. (2009) demonstrate converting IFC to CityGML, and focus mainly on the CityGML-Building class. He provides a conceptual requirement for the automatic reconstruction of building information models from uninterrupted 3D Models. Their two-step transformation strategy incorporates CityGML as an intermediate layer between 3D graphic models and IFC/BIM models. Wu and Hsieh (2007) presented an algorithm for automatic conversion of IFC to GML. The algorithm works only on the transformation from swept solid models to the B-Rep. Isikdag and Zlatanova (2009) provide preliminary ideas for defining semantic mapping between the IFC data model and CityGML. The purpose of their work was to allow automatic transformation between the two models. In another study, Isikdag et al. (2008) have investigated the possibilities of automatic conversion from IFC to GIS based on two case studies: fire response and site selection. Their research includes a description of a developed tool for automatic conversion from IFC to ESRI shapefile and GeoDatabase. Another effort for integrating BIM in CityGML is GeoBIM ADE. Its purpose is to extend CityGML with the rich semantics of IFC (ADE 2010). In parallel, commercial software for conversion from IFC to CityGML and vice versa is in development [i.e. IFCExplorer (2008), BIMserver (2009), and FME from Safe Software (2008)]. However, the focus of the transformation methods presented in the above studies considers only the building’s architectural elements, such as walls, spaces, doors, also it concentrating on the geometry transformation issues. To our knowledge, there is no systematised study on enabling interoperability between IFC and GIS for utility networks.

3 Interior Building Utility in BIM/IFC

An international standard for data exchange of building information model (BIM) data is the industrial foundation class (IFC). It was developed by the International Alliance of Interoperability (IAI) to facilitate interoperability in the building industry (Liebich et al. 2010). The goal of the IFC is to enable interoperability between building information systems. The latest release is IFC 2x3 TC1. Version 2x3 has introduced the ifcXML specification by using XML schema to define the IFC models in parallel with EXPRESS (Wu and Hsieh 2007). By contrast with the traditional de facto standards of CAD exchange, such as drawing files dxf or dgn, the IFC is strictly model-based. A wall is not a set of lines (polygons), but rather an object with specified attributes and relations (Clemen and Gründig 2006). The key contents of the current IFC 2x3 include (Isikdag et al. 2008; Liebich et al. 2010; Schevers et al. 2007; Shen et al. 2009):

  • IFC enables re-use of building information through the whole building lifecycle

  • IFC is an object-oriented and semantically rich model

  • IFC provides the representation of building models in 3D

  • IFC is a spatially related data model, wherein spatial relationship between building elements are maintained in a hierarchical manner

  • IFC provide a schema for electrical wiring and plumbing details

IFC supports utility networks inside buildings (building service systems); it has a shared building service element layer that defines the basic concepts required for interoperability between building service domain extensions: i.e. the plumbing, Heating Ventilation Air Conditioning (HVAC), Electrical and Control domains. IFC methodology for specializing building service components follows a general approach for a component within a distribution system, no matter what the systems is. Therefore, the same IFC component can be shared and used to represent the different networks (e.g. gas, water and electricity) (see Fig. 1). The IFC concept for utility support has the following major characteristics (Liebich et al. 2010):

Fig. 1
figure 1_6

Informal IFC schema, the highlighted part is representing the hierarchy chart of interior utility – building service elements

Full size image

  • All building service elements are exchanged by a subtype of IfcDistributionElement. The various subtypes inherit attributes and relationships from IfcDistributionElement and do not add any further attribute. These subtypes are introduced for the purpose of semantics and logical structuring of the model. Examples of these subtypes include IfcFlowSegement, which defines the occurrence of a segment of a flow distribution system that is typically straight, contiguous and has two ports (e.g. a section of pipe or duct). IfcFlowController defines the occurrence of elements of a distribution system that are used to regulate flow through a distribution system (e.g. damper, valve, switch, relay). Its type is defined by IfcFlowControllerType or its subtypes.

  • IFC handle connectivity using two methods, logical and physical connectivity. Logical connectivity can be achieved without having a physical element to realize the connectivity. On the other hand, physical connectivity is achieved by enhancing the logical connectivity with a realizing element.

  • IFC represents building objects by considering the real 3D shape; such as CSG, Sweeping, or SolidModel. One object can have several representations. Building service components implement SolidModel representation using specific types, which are: B-Rep, Surface model and Sweep solid. Each of these types can be replaced by Mapped Representations, which allows the reuse of the shape of a particular object. The object can be inserted one or several times by using a block reference, including a transformation matrix.

  • IFC provides the concept of system; a system is defined as an ‘organized combination of related parts within an AEC product, composed for a common purpose or function or to provide a service’.

4 Utilities Within CityGML–UtilityNetworkADE

CityGML is an OGC standard, which provides a specification for the representation of 3D urban objects (Gröger et al. 2008). It is the only 3D information model for the exchange of 3D city models. One of the reasons for creating such a model was to enrich 3D city models with thematic and semantic information. The information model of CityGML is an XML-based format implemented as an application schema of Geography Markup language (GML3). Today, CityGML seems to provide the best framework for semantic-geometric relations of 3D objects above earth surface (Emgard and Zlatanova 2008; Groneman and Zlatanova 2009). It maintains a good taxonomy and aggregations of Digital Terrain Models, sites (including buildings), vegetation, water bodies, transportation facilities, and city furniture. The underlying model differentiates five consecutive levels of detail (LOD), where objects become more detailed with increasing LOD regarding both geometry and thematic differentiation. In LODs 2–4 of CityGML the building facade is defined in the form of boundary surfaces, i.e. WallSurface, Roof Surface, Ground Surface or Closing surface. The LOD4 allows the representation of interior building elements, e.g. rooms, furniture, interior wall surfaces. Nevertheless, the current version of CityGML still lacks the integration of subsurface features, such as geology, utility networks and underground constructions (e.g. tunnels). Recently the modeling group of SIG 3D has been working on some extensions of CityGML; these include extensions to represent bridges (ADE 2010), and utility networks. The latter is the extension to model utility networks in cities (Becker et al. 2010). The intuitive efforts have resulted in the publishing of the first draft version for utilizing the CityGML concept of application domain extension to provide an abstract level data model that provides the main concepts to model utility networks regardless of its type. The ADE forms a new package, providing the possibility to integrate one or more Utility Networks into a city (Fig. 2). The data model has the following features (Becker et al. 2010).

Fig. 2
figure 2_6

UtilityNetworkADE and its relation to CityGML and GML (Becker et al. 2010)

Full size image

  • It provides a graph data structure with simple geometry representations, as well as true geometry representation of utility network objects.

  • The network features, which represent any topographic object in the network (e.g. pipe, tunnel), are inherited from the cityobject class, just as are other classes such as streets or buildings.

  • All the utility network elements are generalized (core model), with no classification of elements based on their specialized functions in the network.

  • The data model allows the aggregation of a utility network element to represent a specific network as well as the aggregation of many features to represent a superior feature

5 Mapping IFC Building Service Systems Data into UtilitiesNetworkADE–CityGML

Based on the previous description of the features of IFC and CityGML standards regarding utility networks, there is a significant overlapping of information content between both standards. This section compares the different UtilityNetworkADE classes and the corresponding information in IFC. We investigate the possibilities for generating the UtilityNetworkADE in CityGML using the IFC utility network classes (see Fig. 3). The mapping described on this paper is grouped into two categories thematic classes and graph structure.

Fig. 3
figure 3_6

UML class diagram for the UtilityNetworkADE the upper part represent the topographic classes and the lower part represent the graph representation (Becker et al. 2010)

Full size image

5.1 Thematic Classes

UtilityNetworkADE of CityGML uses two classes to represent networks; these are _NetworkFeature and Network. The class Network is a central element in the UtilityNetworkADE data model. It is intended to provide a topographic representation of entire networks (e.g. water, gas). It is derived from the GML Feature Collection, and serves therefore as a collection of networks, where each network is a collection of _NetworkFeatures. The class inherits the following attributes: Unique ID, Description and name. It is possible for a network to have a sub network, and so it is possible to aggregate different parts of a network with same commodity to a specific network. However the main role of the Network class in the data model is to allow the aggregation of different network features to form a specific network.

The IfcSystem entity in IFC, which is a subtype of the entity IfcGroup, represents a similar concept to the Network class in CityGML. Its role is to relate and compose a group of network objects that fulfill a common purpose; it acts as a functional related aggregation of objects, e.g. a system that comprises water distribution elements (pipes or ducts or cables and related items). The IfcSystem did not include any rule to sustain connectivity between the different network objects; however, it is expected that the connectivity that is established between the different network elements will be generated in a systematic way – for example, to establish a flow path (Fig. 4).

Fig. 4
figure 4_6

Elements aggregated into a system in IFC (Peachavanish et al. 2006)

Full size image

The attributes of network class, like Unique ID, name and description, can be obtained from the attributes of the IfcSystem entity: Unique ID could be acquired from IfcGloballyUniqueId, name from IfcLable, and Description from IfcText. The complete list of the elements participating in an IFC system can be obtained from the IfcRelAssignsToGroup. Moreover, the IfcRelAssignsToGroup can be used to allow the participation of one element in more than one system. Yet this could be useful for generating the class network link, which allows the creation of the connectivity between different network systems, e.g. a water pump connected to an electricity network. The nesting of a group of network elements to form a sub-network or sub-system can be obtained from the entity IfcRelNests. Figure 5 provides an example of the IfcSystem for a water network; it comprises entities and an alternative representation in UtilityNetworkADE. The parent water system is composed of two sub-networks, hot and cold water; and the network also includes a heating machine which is part of three systems (cold water, hot water, and electricity).

Fig. 5
figure 5_6

IfcSystem in IFC vs. Network class in UtilityNetworkADE. Water heater is the Network link which connects the hot and cold water systems

Full size image

The class _NetworkFeature serves as a root class representing any topographical objects of a utility network (e.g. pipes, manholes). The class is derived from the CityGML super class CityObject. Therefore, it inherits all the characteristics of CityObject class. All thematic network classes can be derived from this class, and these thematic classes can be used to provide hierarchy subclasses for division of network objects based on their semantics – that is, their functional meaning in the networks. The network object in class _NetworkFeature is an abstract Feature class in GML. According to the terms of ISO 19109, a feature can have arbitrary attributes, spatial and non-spatial attributes. The spatial attributes serve, for instance, the mapping of actual 3D object geometries in different levels of detail.

The class _NetworkFeature can be generated using the IfcDistributionFlowElement in IFC (Fig. 6). All building service elements in IFC are exchanged by a subtype of IfcDistributionElement. The various subtypes inherit attributes and relationships from IfcDistributionFlowElement and do not add on any further attributes. These subtypes are introduced solely for the purpose of semantics and logical structuring of the model. IfcDistribuationElement plays a similar role to the _NetworkFeature class. The text below summarizes the subtypes, providing a brief description for their specialized functions. Figure 7 provides an example of these subtypes.

Fig. 6
figure 6_6

Ifc thematic classes (left) and its alternative representation in UtilityNetworkADE by deriving it from _NetworkFeature class (right)

Full size image
Fig. 7
figure 7_6

Examples for different IfcDistributionElement

Full size image

  • IfcFlowSegment: defines the occurrence of a segment of a flow distribution system that is typically straight, contiguous and has two ports (e.g. a section of pipe or duct).

  • IfcFlowFitting: The distribution flow element IfcFlowFitting defines a junction or transition in a flow distribution system (e.g. elbow, tee, etc.). Its type is defined by IfcFlowFittingType or its subtypes.

  • IfcFlowTerminals: defines a permanently attached element that acts as a terminus or beginning of a distribution system (e.g. air outlet, drain, water closet, sink, etc.). A terminal is typically the point at which a system interfaces with an external environment. Its type is defined by IfcFlowTerminalType or its subtypes.

  • IfcFlowController: defines a distribution system that is used to regulate flow through a distribution system (e.g. damper, valve, switch, relay). Its type is defined by IfcFlowControllerType or its subtypes.

  • IfcDistributionChamberElement: defines the place at which distribution systems and their constituent elements may be inspected or through which they may travel.

  • IfcFlowStorageDevice: defines a device that participates in a distribution system and is used for temporary storage of a fluid, such as a liquid or a gas (e.g. tank). Its type is defined by IfcFlowStorageDeviceType or its subtypes.

  • IfcFlowTreatmentDevice: defines a device typically used to remove unwanted matter from a fluid, either liquid or gas, and typically participates in a flow distribution system (e.g. air filter). Its type is defined by IfcFlowTreatmentDeviceType or its subtypes.

  • IfcFlowMovingDevice: defines an apparatus used to distribute, circulate or perform conveyance of fluids, including liquids and gases, and typically participates in a flow distribution system (e.g. pump, fan). Its type is defined by IfcFlowMovingDeviceType or its subtypes.

  • IfcEnergyConversionDevice is a device used to perform energy conversion or heat transfer and typically participates in a flow distribution system. Its type is defined by IfcEnergyConversionDeviceType or its subtypes.

IFC represent Building service components –IfcDistributionFlowElement using SolidModel representation with its specific types: B-Rep, Surface model and Sweep solid. Transforming geometrical information from the IFC model of these elements in case of sweptsolid requires conversion operations.

Special network objects, such as pumps, tanks (IfcFlowMovingDevice IfcFlowStorageDevice), that are composed of several parts can be also represented within _NetworkFeature; this class can consists of one or many network objects. Information about the list of objects that aggregate to form one object can be obtained from the entity IfcRelAggregates. Using _NetworkFeature class, it is possible to aggregate these objects and treat them as though they were a single object.

5.2 Graph Structure

The connectivity between the network objects is given with a graph structure in the UtilityNetworkADE. Each topographic object _NetworkFeature as well as Network class can be associated with graph representation. Similarly, IFC represents the topological relationship between the different network objects, using the concept of connectivity. As mentioned previously, the IFC distinguish two types of connectivity - logical and physical connectivity. In the following text, we will discuss the different classes that comprise the graph in UtilityNetworkADE, and further investigate the related concept in IFC, and the possibilities for transforming it to generate the UtilityNetworkADE graph classes.

The class NetworkGraph in UtilityNetworkADE represents the topological view of the utility networks in CityGML. Each thematic network object _NetworkFeature has graph representation using the class FeatureGraph. The graph representation for one feature can be simple - composed of one node derived directly from node class - or a composite, where a group of nodes and edges is needed to represent one network feature. In the second case the internal node is distinguished by an interior node (Type: interior) from the node class. Additionally, the connecting links between these nodes are further specified using an interior feature link subtype (InteriorFeatureConnection) derived from the edge class. See Fig. 8 for an illustration of these relations.

Fig. 8
figure 8_6

Graph representation in UtilityNetworkADE (composite case), a node type interior is used to connect more than one InteriorFeatureLink (T-fitting) (left) (Becker et al. 2010)

Full size image

If two network objects _NetworkFeature (using Feature graph representation) are connected, then their relations can be represented using the NetworkGraph class (Fig. 8). The connectivity is expressed using the class InterFeatureConnection, which is derived from class edge. This holds two attributes: direction, to specify the flow direction in the edge; and link control, which allows controlling the flow in the network so it is possible to control the commodity on the network. The classes that compose the class Network graph are derived directly from the classes Nodes and Edges, which are directly derived from gml::feature and represent a feature in terms of ISO 19109. Its geometry is realized using simple point gml::point and simple curve gml::_curve.

In IFC, the concept of connectivity is introduced as a method to represent the relationship between the different IfcDistributionFlowElement. The physical Connectivity concept is generally associated with things that are directly or physically connected. However, there are circumstances where it is important to know that there is a connective relationship between two (or more) objects, but where there is no physical connection to identify this fact. In this case, the idea of non-physical connection is termed logical connectivity, in the sense that there is a logical or implied connection between objects. An example for this connectivity can be seen in a light switch, where the lights are turned on and off by that switch (see Fig. 9). Frequently, the cable that connects the switch with the light will not be instantiated in a model, and so the physical connection cannot be achieved. In this case, the cable making the connection has to be considered.

Fig. 9
figure 9_6

The logical connection between light and light switch key, the route of electrical wire is not available

Full size image

The connectivity information in both cases (physical and logical connectivity with ports) is represented using the same entities. The connectivity information can be extracted from the entity IfcRelConnectsPortToElement and IfcRelConnectsPorts, which has optional attributes, implied the cable making the physical connectivity from switch to light fixture. IfcRelConnectsPortToElement defines the relationship that is made between a port and the IfcDistributionFlowElement. Ports contained in different elements are connected to each other using the IfcRelConnectsPorts relationship. Using both relationships, a topological model can be defined and transformed to direction attributes associated with the edge class in UtilityNetworkADE. Figure 10a–c provides examples representing the connectivity information of network objects in IFC, and the possible transformation to represent them using UtilityNetworkADE classes. The geometry of network graphs in UtilityNetworkADE is represented using node and edge classes, which are derived from GML feature class, which in turn can be associated with simple geometry representation. IFC allow multiple geometric representations of its elements. Therefore, in cases where the topology representation is available for any IfcDistributionFlowElement entity, it can be transformed into IFC. It should be noted that the representation of network objects as points and lines need harmonization in order to have the same classification as the node types (interior and exterior) and edge subtype (InterFeatureLink and InteriorFeatureLink) in UtilityNetworkADE. If the graph representation is not available in IFC (simple line and point of network object), it is still possible to generate it and transform it into the class FeatureGraph with respect to its subtypes in UtilityNetworkADE.

Fig. 10
figure 10_6figure 10_6figure 10_6

(a) IfcFlowSegment associated with two ports modeled using Featuregraph class of UtilityNetworkADE. (b) IfcFlowFitting associated with three ports modeled using FeatureGraph, the interior node is not directly represented in IFC and could be generated on the fly in UtilityNetworkADE. (c) Connectivity relation between IfcFlowFitting and IfcFlowsegment and its corresponding representation in UtilityNetworkADE

Full size image

Another approach to extract the connection information in case of physical connectivity would be by using the class IfcRelConnectsElements, where each network object has attributes represented by the IfcDistributionFlowElement that this object is connected to or from.

Logical connectivity can include cases without ports. It can be seen from the situation of a water supply pipe that discharges into a tank (the particular situation in this example being a potable water pipe, which is taken to discharge into a tank containing non-potable water; in which case, a specific distance between the outlet of the potable discharge and the waterline of the non potable water in the tank must be maintained) (Fig. 11). In this case, the connectivity information is achieved in IFC using IfcRelConnectsElements or IfcRelConnectsWithRealizingElement.

Fig. 11
figure 11_6

Logical connectivity in case of water tank (Liebich et al. 2010)

Full size image

Currently, the relation could be modeled in UtilityNetworkADE using the InterFeatureLinks with no geometry representation. However this is not enough and undesirable since it could break the useful concept that unfulfilled port describes an open end in pipe. There is a need for a special class that allows modeling the connectivity and the distance that should be left between the two objects and could represent the air gap.

6 Conclusion

The paper investigates the possibilities for integrating interior utility in 3D city models. Following a background literature review, the paper presents an approach for integration interior building utilities in city models by means of semantics mapping. The approach involves harmonizing the semantics and thus allowing formal mapping between the BIM and real world network in UtilityNetworkADE/CityGML (core model). The information provided in the paper can contribute to the efforts of enriching 3D city models with urban knowledge, so as to extend their functionality and usability.

The investigation has proved that UtiltiyNetworkADE provides the primary classes, which can be easily extended to model the interior building utilities. Most building service concepts in IFC schema can be mapped to UtilityNetworkADE with lossless of data. Specialized classes can be easily derived from the class _NetworkFeature to represent the different thematic concepts in IfcDistributionFlowElememt. Network Class provide similar concept to the IfcSystem in IFC. The nesting of network objects between different networks can be used to extract the connectivity link (Network Link) between the different network systems.

The graph structure in UtilityNetworkADE can be generated using the IFC entities, in case of logical and physical connectivity with ports, connectivity information can be transformed and logical links can be created in UtilityNetworkADE using sub classes of _Edge without having a geometry that represents the physical connectivity. Generating the nodes and edges classes in UtilityNetworkADE with its subtypes in case of physical connectivity requires special consideration; a transformation approach would be needed to tackle problems that can be associated by moving different nodes and edges to the graph classes in UtilityNetworkADE. Some nodes need to be considered as interior nodes and others which represent the ports are considered exterior nodes. It is important to notice that this problem needs harmonizing in all cases of IfcDistributionFlowElememt expect the IfcFlowsegment (e.g. pipes) The IfcFlowsegment is typically represented as a straight element in IFC standard and therefore it represent an Interfeaturelink and the ports represent an exterior nodes.

The logical connectivity without ports (e.g. water tank cases) cannot be represented directly in UtilityNetworkADE. An alternative solution could be using Interfeaturelink or Network Link with no geometry representation. However, the solutions don’t address the problem adequately.

Although there are explicit semantic classifications on IFC schema regarding interior utilities, it is important here to mention that the investigation shows that the current IFC editors (e.g. AutoCAD MEP, Autodesk Revit MEP, or ArchiCAD MEP) implement the standard in different manners and some concept are implemented but cannot be transferred to IFC standard. For example, the concept of logical connectivity with ports are implemented in AutoCADMEP but cannot be directly transformed to be represented using IFC entities.

The ongoing research will focus on formally defining new classes that will help to customize the UtilityNetworkADE to represent the interior Utility, the relation between the UtilityNetworkADE and GeoBIM ADE could be investigated. Moreover, a bidirectional transformation will be considered and investigated, the current work concentrated on unidirectional information transformation (i.e. from a BIM to CityGML models). Such transformation might also be required to support urban upgrading and renovation related tasks where an information model of a building usually does not exit.