IMPACT OF INFORMATION MANAGEMENT DURING DESIGN & CONSTRUCTION ON DOWNSTREAM BIM-GIS INTEROPERABILITY FOR RAIL INFRASTRUCTURE

: The need for efficient and sustainable infrastructure – always critical to a city - is further gaining momentum as urbanisation creates the challenge of sustainably designing, constructing and operating the built environment. The AECOO industry, directly responsible for addressing this challenge, has adopted the use of BIM and GIS to aid in this endeavour. Both BIM and GIS overlap with respect to capturing aspects of the built environment, but are not interoperable by nature. To ensure a consistent and structured way of managing the information produced within these environments, industry standards such as IFC are implemented. Research to date focuses on addressing the integration between BIM and GIS for buildings by delving into the IFC and CityGML interoperability, which has highlighted significant geometric and semantic barriers that in the stage of integration, cannot be easily manoeuvred. The purpose of this paper is to provide an insight regarding the information lifecycle during Design & Construction in the HS2 Rail Infrastructure project and investigate the impact of current information management processes - and in particular Standards such as IFC, - on BIM-GIS interoperability and lifecycle management of an asset. Results demonstrate the levels of mis mapping during the export to IFC which varies depending on the infrastructure asset type. Discussion shows that these can be addressed by the introduction of additional semantic property sets to facilitate downstream BIM-GIS interoperability for O & M, enabling scope for future work.


MOTIVATION
Infrastructure in the built environment has an increasingly important contribution towards the development and efficient function of a modern, sustainable, city as it is directly related with its economic, social, industrial and environmental performance (Strange, 2018). With the transition of the population to urban environments expected to rise up to 70% by 2050, modern cities emphasize on upscaling their transport infrastructure services, such as Rail and Highways (Jouili et al., 2017).
High Speed 2 (HS2) is the UK's new high-speed railway that will link London, Midlands and the North (HS2, 2020), extending over 500 km. Such a high complexity project sets in place onerous requirements to ensure maximised efficiency and timely delivery during Design, Construction, Operation & Maintenance (O&M) and eventually Decommissioning, a set of stages that form the lifecycle of the project (Matějka, 2017). Information that is fit for purposei.e. the right information given to the user in the right format at the right timeis fundamental to achieve the required efficiency and delivery. Two core approaches help to meet these information needs: • Building Information Modelling (BIM) has received a significant adoption within the Architecture-Engineering-Construction-Owner & Operator (AECOO) industry (Guillen et al., 2016) particularly on the construction side.
• The value of geospatial awareness and Geographic Information Science/Systems (GIS) is highlighted within Industry Standards such as PAS 1192:3, especially during the operational phase of the Asset (Boyes et al., 2017).
The lifecycle stages of a project, while they represent the maturity of the project, face significant challenges when it comes to the handover of information (Parlikad and Jafari, 2016).
Firstly, the different scope for every stage: for instance, during the construction phase the relevant stakeholders do not necessarily understand, need or create information to support O&M requirements that capture the performance or maintenance of an asset. The different scope also generates the challenge of setting up a systemic, efficient and consistent handover of information, a lack of which leads to reacquiring information that has been captured in a former stage but has not been handed over or has been discarded; an activity that is associated with great increases in cost. The second challenge relates to the longevity or lifespan of a built asset. For example, data produced by BIM authoring tools during Design, even if it accompanies the project across its full lifecycle, may still become redundant and unreadable by future software tools due to data storage format and software version changes. This problem is exacerbated when the long life of infrastructure assets -which sometimes runs into 100+ yearsis considered. International standardsthe use of internationally defined data models and processes to manage the information generated by a project -aims to address this challenge.
Information that is generated and stored following defined data structures and best practices around data management, enhances its interoperability and exchange during the different stages of a project's lifecycle. In theory, the Industry Foundation Classes (IFC)an open BIM Standard and interoperable exchange format (buildingSMART, 2020) that focuses mainly on the stages of Design & Construction for Buildings (Theiler, 2018), should act as the standard for information handover between the construction and operation phases of a built asset, moving the information to GIS to enable the continued use of location data through the full lifecycle of the asset. This highlights the importance of BIM-GIS interoperability. However, IFC provides limited coverage for Infrastructure which results in geometric and semantic mis-mapping of infrastructure assets (e.g. Bridge, Tunnel, Road) and ultimately loss of information that could be useful for O&M. This in turn places barriers to useful BIM-GIS interoperability at handover.

Purpose & Research Questions
The purpose of this paper is to provide an analysis of the Although focusing on three asset types, this work proposes a method to highlight the semantic and geometric interoperability issues that arise across an entire infrastructure project. It provides an insight in how to utilise industry standards such as IFC and Uniclass2015 (NBS, 2020) to mitigate the impact of inadequate information containers in IFC and the challenges that are generated for BIM-GIS integration. Focus is on the a priori information management process of producing IFCs in order to demonstrate how decisions made at early stages of information creation can have downstream impact in BIM-GIS interoperability.
Overall, the paper will highlight the importance of an early adoption of full lifecycle data quality management if successful BIM/GIS integration is to be achieved throughout the project. This in turn is fundamental to enable information-driven Asset Management and achieve best return on the initial cost of data capture.  (Gelder, 2015). Uniclass2015 is applicable in numerous activities during Design & Construction such as Estimating, CAD Drawing & Layer specification as well as the production of in-house information containers and provides combined information for buildings, infrastructure and landscaping (Gelder, 2015). In this work, Uniclass2015 is introduced during the 3D Modelling process to enhance the semantic information of the Models and is part of the custom property set that is exported to the IFC.

IFC and IFC for Infrastructure:
As noted above, IFC is a data model and exchange format specification for BIM (buildingSMART 2020). The standard initially focused on modelling objects and features required when constructing buildings. The more recent development of IFC for Infrastructure is led by buildingSMART Infrastructure Room (buildingSMART Infrastructure Room, 2020). In order for an IFC Extension to be released within the official IFC Schema, there are several deployment phases that needs to be endured, starting with collecting the requirements of the asset type that is within the scope of this extension, followed by defining the conceptual schema and finally proceeding to testing, validation and implementation (Borrman et al., 2019).

IFC for Infrastructure Extensions Status:
IFC Alignment, applicable in linear infrastructure (i.e. Tunnels, Road, Bridges) has been introduced in IFC 4.1 (buildingSMART Infrastructure Room, 2020) aiming to provide information regarding horizontal and vertical alignment of infrastructure data models. IFC Bridge is in the approval phase by bSI, with deployment to follow (buildingSMART Infrastructure Room, 2020). buildingSMART Infrastructure Room is also steering the activities for developing IFC Road, IFC Tunnel and IFC Ports and Gateways. IFC Rail has reached "Candidate Standard" and is focusing on the development of an extension related to management of Railway Assets, such as Track and Signalling (IFC Rail Project, 2019). The IFC Tunnel project is finalising the global process map (buildingSMART completion of requirements reports. IFC Tunnel is at Phase 1 (Collection of Requirements), prior to proceeding to technical implementation.

CityGML:
CityGML is an XML based format for storing, managing and exchanging virtual 3D City Models and an international Open Geospatial Consortium (OGC) Standard (Open Geospatial Consortium, 2012). The current version is CityGML 2.0, however CityGML 3.0 is set to be released within 2020 (Kutzner et al., 2020). CityGML 3.0 has been revised to facilitate the interoperability with other major standards, including IFC, by introducing a new "Construction" module and revising the modules of "Buildings" and "Transportation". This paper investigates CityGML 3.0 due to its imminent release and relevance to Construction and Infrastructure.

BIM-GIS Integration within AECOO
BIM-GIS Integration is an emerging topic within a variety of application fields in 3D Cadastre, Urban & Environmental Application as well as Indoor & Outdoor Navigation, performed on different levels: data, process and application (Liu et al., 2017). The value of BIM-GIS within the AECOO industry is highlighted via its implementation on practical case studies (Irizarry and Karan, 2012;Sebastian et al., 2013) during Design and Construction, but also in Asset and Facilities Management with initiatives such as the GeoBIM Project (Ellul et al., 2018), as both the Geospatial and BIM communities realise the benefits of interoperable data formats (Noardo et al., 2019 (a)). Within this context, Boyes (2017) investigates the integration of GIS-BIM for asset management in the Crossrail infrastructure project in UK, summarizing the key findings into: (i) geometric differentiations between BIM and GIS and (ii) decision making process during asset tagging. With regards to Facility Management, Kang and Hong (2015) propose a BIM-GIS solution for facility management in order to address the interoperability challenges of the supported data formats, by utilizing the Extract-Transform-Load (ETL) to perform a unidirectional conversion from BIM (IFC) to 3DGIS (CityGML).

Challenges of BIM-GIS Integration:
However, BIM-GIS interoperability until today is far from straight-forward. The "GeoBIM Benchmark 2019" initiative (Noardo et al., 2019 (b)) is a collaborative effort to document and analyse the capabilities of existing software tools to facilitate the integration between BIM and GIS and particularly the two dominant Standards in the BIM and GIS world respectively: IFC and CityGML. Preliminary results indicate the lack of customising the export phase from the native format to IFC, relying completely on the setup of the software regarding the mapping process. Furthermore, known issues are missing or misshaped geometries (curves) as well as errors in calculating geometric characteristics such as volumes and heights. CityGML 3.0 is introducing upon release new feature types (i.e AbstractConstructiveElement) to facilitate the mapping with IFC classes, such as IfcWall, IfcSlab and IfcRoof among others (Kutzner et al., 2020), presuming that the aforementioned classes exist in the IFC schema. While this might be the case for buildings, the new feature types are also directed to infrastructure objects such as Bridges and Tunnels, for which the IFC may not provide sufficient coverage. Therefore, how can BIM-GIS integration be enabled, if the open data format (IFC) does not contain IfcSlab, IfcWall, IfcRoof or IfcPile in the first place? Furthermore, rail infrastructure includes objects that are not directly covered within the CityGML Standard, such as types of Civil Works (Embankment, Cutting, Rail Portal) and Vent Shafts.

Gap Analysis
The focus of this paper emphasises on analysing the use of IFC in Infrastructure and particularly three infrastructure objects (Tunnel, Vent Shaft and Civil Works), for which an official IFC extension has not yet been deployed (it is at preliminary stages of development). The majority of ongoing research work is focused on the stage of integration between BIM and GIS and results indicate that the structure of IFC is essential to a successful conversion. However, when an IFC is exported, as an exchange format, there is little to no room for manoeuvring, and in addition there are very few studies that follow the information lifecycle from the information schemas used for creation of BIM in native format (to support construction), through IFC (for exchange at handover) and into GIS (for O&M).

Data Provider
The data in this work is provided by the BIM Team within the Skanska-Costain-STRABAG Joint Venture (SCS JV) working on behalf of HS2. SCS JV as the main contractor works together with "Design House" (DH), a Typsa-Arup-STRABAG Joint Venture, to produce the BIM Models for the Scheme and Detailed Design Stage for HS2 Rail Project.

Infrastructure Elements Selection
For the purposes of this paper, three infrastructure elements are selected: Tunnel: Defined as a tunnel, circular in form, mined using mechanical means from within a shield. A segmental lining is then assembled within the shield to form either a temporary or permanent lining.
Vent Shaft: Is a vertical or inclined structure designed and constructed to provide, where applicable, pressure relief, ventilation and/or access/egress from the ground surface to the underground HS2 running tunnels and associated underground structures and facilities.
Civil Works and particularly Embankments: Earthworks where that the vertical alignment of the (upline inner rail, or whichever is the reference rail) is equal to or above 1m of original ground level.
These objects were selected based on the following criteria: To maintain consistency, all IFC Models are produced at the same information exchange stage as explained in subsection 2.1.2 and particularly during the stage of Scheme Design. They consist of Graphical Information (GI) and Non-Graphical Information (NGI).

Graphical Information, Modelling Process & LoGD
The Graphical Information examined in this paper are three (3) IFC 2X3 (as per the BIM Execution Plan) models of the infrastructure elements as explained in section 3.2 and illustrated in Fig. 1. The BIM Authoring software for the generation and export of these models is Bentley AECOsim Building Designer CONNECT edition. The models have been created within SCS JV in collaboration with DH, as per the Modelling Guidelines that have been specified within the HS2 BIM Execution Plan. The guidelines explain the detailed specifications set in place to ensure consistency regarding model appearance, format and geospatial location. For the creation of GI, a centralised Content Library is created within AECOsim, containing all the Types to be used within SCS. An example is presented in table 1. In this context, the Type describes an element (Slab, Pile) that forms the Asset (Vent Shaft). It is important to note that a Type does not have a 1:1 correspondence with an object modelled in the IFC schema (for instance, IfcBeam stores In Situ Beam, Capping Beam, or Steel Beam among others), thus there is information created at this stage in the process that will be lost during export to IFC from AECOsim.

Non-Graphical Information (NGI) & LoMI
The generated Models include NGI as specified within the BIM Execution Plan under the group "SCJ Definitions". The SCJ Definitions are a custom set of information that is essential to produce and maintain during Design & Construction.
Consistency is maintained across all elements, by using centralised data libraries within AECOsim. These SCJ Definitions aim to address the semantic gaps when generating the standard models (which in turn correspond to gaps in the exported IFC). Two particular NGI Fields are examined in this work: (i) Type: describes the Type of the element (In Situ Wall, Precast Wall, Concrete Pile) and Uniclass2015 as explained in subsection 2.2.1. Fig. 2 shows the data flow from the model creation up to the IFC Export.

Phase 1: Extract IFC Classes
The IFC Model is created and exported from AECOsim and then imported in Safe Software Feature Manipulation Engine (FME) as single feature types, extracting the solid geometry and the Property Sets (SCJ Definitions) as additional feature sets, since they are not natively supported in the official IFC schema. Table  2 summarises the extraction of IFC classes for the Vent Shaft: The IfcPropertySet SCJ Definitions, which stores the NGI as described in section 3.4 are mapped within FME using the "ifc_unique_id" parent-child relationship, linking the attributes "Type" and "Uniclass" to every element. "Type" provides additional information regarding the nature of the object (i.e. In Situ Slab), while "Uniclass" returns the Uniclass value for this particular element.

Phase 2: Transform & Map IFC
The extracted IFC consists of geometric elements (IfcSlab, IfcWall), the enumeration types (ET) of these elements (Concrete Wall) and the property sets (SCJ Definitions). For every geometric element, the attributes "Type" and "Uniclass" are extracted in order to create a table that maintains only the unique values for every infrastructure object. The next step of the transformation process is the percentage (%) calculation as described in equation (1)  (1) where X = % of participation Y = number of the Type (a) or IFC Class (b) Z = total number of all Types (a) or all IFC classes (b) The above values are calculated to understand the participation of each element within its relevant class, not from structural importance, but from a quantifiable point of view, in order to provide a primary index in terms of highlighting the contribution of the specific type of information that is mis-mapped during the export to IFC. Once the property sets from section 4.1 are linked with every element, the mean for both the Type and IFC class values is calculated and stored as an attribute within FME as shown in Figure 4: Figure 4: Snapshot of the FME Process for IfcBuildingElementProxy

Phase 3: Data Visualisation
The output of the workflow originally is a format-agnostic tabular visualisation which contains the following columns: (i) Asset Type, (ii) IFC class, (iii) Type and (iv) Uniclass, (v) % of Type within IFC class and (vi) % of IFC class within infrastructure object. For the purposes of this work and to facilitate the interpretation of the results, a Unified Modelling Language (UML) visualisation is selected with the following structure as demonstrated in Figure 5. "Asset Type" refers to Tunnel, Vent Shaft and Embankment. "IFC Class" refers to the IFC Classes that form the "Asset Type" (i.e IfcSlab, IfcWall). Each "IFC Class" contains "Types" (i.e. Composite Slab), the "Uniclass" that matches each "Type" and the calculated percentage (%) from Phase 2.

Phase 4: Mapping to 3DGIS Standards
The final step of the method is to semantically map the IFC Models to 3DGIS Standards. In this work, CityGML (LoD 4) is selected due to its dominant position as a 3DGIS Standard and an additional column to the output of Phase 3 is introduced: "CityGML Feature Type". As CityGML 3.0 is yet to be released, the mapping is taking place at a conceptual level based on "AbstractConstructionSurface" (ACS), "AbstractInstallation" and "AbstractPhysicalSpace" (APS) feature types, including a recommendation on how the IFC Classes relate to specific CityGML Surfaces, Spaces and Installations.

RESULTS
Fig . 6 presents the percentage (%) calculation of a specific IFC Class against the rest of the IFC Classes within the corresponding IFC Model. The Vent Shaft consists of 12 IFC Classes, the Embankment consists of 4 IFC Classes, while for the Tunnel all elements are stored within the IFC BuildingElementProxy Class. Essentially, Figure 6 shows that there are IFC Models which may consist entirely of IfcBuildingElementProxy, increasing the risk of mis-mapping during conversion to 3DGIS. Vent Shaft is covered sufficiently by IFC compared to the Tunnels and Embankments, as its nature mimics the structure of Buildings.  3). The UML representation captures the hierarchy levels among the elements, starting from the Asset Type (i.e. Tunnel), followed by the IFC class, which further consists of the Type, Uniclass, % of Type within the IFC Class and CityGML Feature Type. The IFC Classes included in Fig. 7   With regards to the interpretation of Spaces; in BIM, during Scheme Design, the modelling process introduces "Space Reservation" to highlight an area which will be geometrically filled during Detailed Design, as the LoMI matures which is the reason of selecting the "AbstractInstallation" feature type. A method has been proposed to examine the IFC Standard regarding its capabilities to sufficiently address Infrastructure assets, whilst also discussing a comparison with the CityGML 3.0. The method is applicable to IFC Models that incorporate a set schema of properties. However, it is heavily dependent on the input data as each Contractor implements custom Modelling Guidelines that affect the generation of the IFC Models. The semantic enhancement is essential to facilitate the extension of the IFC schema and the BIM-GIS interoperability, yet the different sources of IFC datasets production would require partial alterations of the technical workflow. Additionally, the method should involve professionals from both worlds (BIM and GEO) as the mapping between the Standards can be interpreted differently, leading to loss of essential information for implementation within AECOO.
The main question addressed in this work is: "Within infrastructure projects, to what extent does decision-making when creating information for Design and Construction impact downstream interoperability of the data in later stages of the asset lifecycle?". As shown in Figures 6 and 7, current standards result in generic mapping at different levels (asset type, element) when construction BIM is converted to IFC for handover to 3DGIS at O&M. Two sub-questions explore the above in detail: "What infrastructure elements and properties are mis-mapped during an export to IFC, and at what stage of the information creation/migration process does this mis-mapping take place?" The semantic mis-mapping is performed at different hierarchical levels within IFC. Firstly, every infrastructure Asset (Tunnel, Vent Shaft, Embankment) is stored under the IfcBuilding, due to lack of infrastructure IFC classes. Secondly, the IfcBuildingElementProxy generic class stores a variety of information, which in the case of Tunnels constitutes 100% of the IFC Classes within the model. Therefore, unless the IFC model's elements are accompanied by additional semantic information that provide an insight with regards to their nature, such as Type or Uniclass, it is challenging to identify what these elements represent by deciding upon their geometric representation.
With regards to the stage of the process where this mis-mapping takes place, the export of IFC is performed during the Design stage (Scheme & Detailed). However, the LOD of the models has been decided during the commencement of Works, which precedes the stage of Design. LoMI is typically enriched as design matures and tailored according to the specific needs of the project, raising another important challenge towards standardisation.

"How does the IFC classification affect integration with GIS standards for O & M?"
This work has highlighted the misplacement of elements within IFC due to its limited coverage for infrastructure and consequently, the semantic interoperability challenges during the integration to 3DGIS. Identifying the Level of Detail; both graphical and non-graphical, which should be integrated to 3DGIS (i.e. is drainage required within 3DGIS?) is key, however the different interpretation of the LoD concept within BIM and GIS is a significant barrier to this endeavour.
The mis-mapping taking place during Design & Construction has a direct impact during the decision-making during O & M, should an integrated GeoBIM environment be the desirable solution to monitor asset lifecycle. Specifically, the integrated model would provide incorrect results in queries such as: "how much budget do we need to allocate to maintenance of noise limitation surfaces?", forcing the Project Manager to re-capture the information which consequently results in significant cost increases. Furthermore, an IFC Model does not necessarily incorporate semantic additions to infrastructure elements, which further highlights the fact that the current schema, which the Asset Managers would interrogate, leads to loss of information.

CONCLUSIONS & FUTURE RESEARCH WORK
The information produced in infrastructure mega-projects such as HS2 needs to be stored, managed and exchanged efficiently and in alignment with information needs at the different phases of the project lifecycle. This requirement of "delivering the right piece of information to the right person at the right time" is associated with significant costs in terms of data acquisition and storage. BIM and GIS approaches can help to streamline this process and the various standards, in theory, help to link the information lifecycle (capture/use/edit/delete) to the lifecycle within AECOO. However, current standards have limitations in addressing the infrastructure of the built environment. These limitations, do not only complicate further the BIM-GIS interoperability, but more importantly could lead to poor decision-making during O & M.
Therefore, this paper makes the following recommendations: • Enhance the IFC schema either with custom semantic property sets or by embedding industry standards such as Uniclass. However, this will partially address the IFC limitations; property sets can be used very differently by different people and in effect creating a different, nonstandard, sub-schema within the standardised data. Create a mapping of information lifecycle and built asset lifecycle to better identify the value of information at all stages. This will assist on where to focus the information management efforts and which elements of information are of most value for construction, O&M and both.
Regarding future work, it is essential to understand the level of information that is produced during the BIM process, which needs to feed into GIS and the role of 3DGIS Standards in lifecycle Information Management. While the suggestion of generalising information is not new, the investigation of LOD (LoGD & LoMI) in BIM and how this relates to the LoD in GIS needs to be further looked at. On top of that, this work shows that a relationship between IFC and Uniclass2015 can be established, however further research is required to understand how the semantic mapping can work, particularly when CityGML is introduced in the mix. Furthermore, the proposed method needs to be tested in additional infrastructure IFC Models, produced with different guidelines. Lastly, further investigation is required to determine whether information requirements from Design & Construction is fit for O&M, in order to identify the scope for BIM-GIS interoperability throughout asset lifecycle.