A Digital Information Model Framework for UAS-Enabled Bridge Inspection

Abstract

Unmanned aerial systems (UAS) provide two main functions with regards to bridge inspections: (1) high-quality digital imaging to detect element defects; (2) spatial point cloud data for the reconstruction of 3D asset models. With UAS being a relatively new inspection method, there is little in the way of existing framework for storing, processing and managing the resulting inspection data. This study has proposed a novel methodology for a digital information model covering data acquisition through to a 3D GIS visualisation environment, also capable of integrating within a bridge management system (BMS). Previous efforts focusing on visualisation functionality have focused on BIM and GIS as separate entities, which has a number of problems associated with it. This methodology has a core focus on the integration of BIM and GIS, providing an effective and efficient information model, which provides vital visual context to inspectors and users of the BMS. Three-dimensional GIS visualisation allows the user to navigate through a fully interactive environment, where element level inspection information can be obtained through point-and-click operations on the 3D structural model. Two visualisation environments were created: a web-based GIS application and a desktop solution. Both environments develop a fully interactive, user-friendly model which have fulfilled the aims of coordinating and streamlining the BMS process.

1. Introduction

Traditionally, authorities, states and organisations have managed bridge facilities via manual inspection. This involves qualified inspectors visually identifying and capturing element deterioration in the field using digital imaging, where equipment such as mobile inspection units and scaffolding will be used in situations where elevation is required [1]. Any captured images and inspection data can then be relayed and compiled into a bridge management system (BMS), supporting repair, rehabilitation and maintenance decisions [2].

However, there exists a number of problems with the current inspection process and data management policies: (i) the scarcity of qualified inspectors and resources may create a backlog of maintenance activities; (ii) inspectors are exposed to significant safety risks when operating in areas of limited accessibility and any equipment needed may pose a serious disruption to traffic flow; (iii) current BMSs are laborious and inefficient, consuming both time and resources [3]. Many systems provide little to no visualisation tools, which may significantly depreciate temporal context and offer limited interpretability to engineers with no previous knowledge of the specific structure. Traditional methodologies also mean methods of data storage and processing are often disconnected, where complete information about an asset may be stored in a variety of software with little to no integration possible.

To fill the current voids in BMSs, several non-destructive technologies have been implemented across literature to collect and process data [4]. these include infrared thermography, terrestrial laser scanners and unmanned aerial systems (UAS) [5,6,7,8,9,10]. UAS provide a unique solution to a number of problems in data acquisition by allowing the automation of aerial and close-up digital images, thereby isolating inspectors from potential hazards. Second, they naturally enrich an information model by offering the opportunity to easily reconstruct 3D models through collected point cloud data.

However, the in-depth and comprehensive analysis that a drone system can provide only leads to benefits if the information is properly utilised. Mismanagement of drone data has the potential to further confuse inspection engineers, who are now faced with an abundance of digital information [11]. As such, there exists a need to develop a data information model to store, process and manage the bridge inspection data captured through UAS [2,8,12]. To fill this gap, this paper proposed a novel methodology for a digital information model covering data acquisition through to a 3D GIS visualisation environment, also capable of integrating within a bridge management system (BMS). Previous efforts focusing on visualisation functionality have focused on BIM and GIS as separate entities, which has a number of problems associated with it, see, e.g., [13,14]. The proposed methodology has a core focus on the integration of BIM and GIS, providing an effective and efficient information model, which provides vital visual context to inspectors and users of the BMS. Three-dimensional GIS visualisation allows the user to navigate through a fully interactive environment, where element level inspection information can be obtained through point-and-click operations on the 3D structural model. Two visualisation environments were created: a web-based GIS application and a desktop solution. Both environments develop a fully interactive, user-friendly model which has fulfilled the aims of coordinating and streamlining the BMS process

The rest of the paper is organized as follows: Section 2 establishes an understanding of the features of UAS based bridge inspection data to set the requirements of the digital information model. A review of the main data systems capable of handling the UAS data their advantages, disadvantages and integration potential are discussed. Section 3 presents the geographic information systems (GIS) and bridge information modelling (BrIM). Section 4 discussed the integration of BIM and GIS. Section 5 displays the proposed methodology from data acquisition all the way to the 3D GIS visualisation environment, and the proposed new holistic framework integrating GIS and BIM. Section 6 provides concluding remarks and future work suggestions.

2. UAS for Bridge Inspection and Framework for Bridge Management Systems (BMSs)

Bridge records can be categorised as follows: The bridge is discretized into characteristic entities, e.g., load-bearing sub-structure, deck elements, safety elements etc. These are shown in

Table 1. Bridge Entities.

	Entity	Element Examples
1	Deck Element	Primary Deck Element	Secondary Element
2	Load-bearing Substructure	Pier	Column
3	Durability Element	Drainage System	Paint
4	Safety Element	Access Walkway	Handrail
5	Other Element	Machinery	Cable Group
6	Ancillary Element	Approach Rail/Barrier/Wall	Signage

in accordance with guidelines from [15]. Singular elements are then grouped under these entities and individually assessed on a condition rating scale based on the extent and severity of distresses or damage (often a single numerically defined scale such as 1-to-5). Bridge records are then stored in a BMS. Storage of such data allows bridge managers full control over geographically scattered portfolios of assets, provides an individual or aggregated picture of structural vulnerability and facilitates relative or comparative condition assessments.

Framework for Bridge Management Systems (BMSs)

BMSs are constructed to help bridge managers efficiently operate large asset stocks by providing and processing construction, inspection and maintenance data. Many transport departments have committed to the development of systems due to a rising portfolio and growing traffic numbers, with varying degrees of sophistication. National efforts include the PONTIS application built for the Federal Highway Administration in the United States [16]. It includes functions such as recording inventory and inspection data, as well as suggestive maintenance actions and preservation policies. Initially, BMSs were simple data storage tools utilising a database to store standard inventory information such as location, construction date and building materials used. However, various routines have now been added to the standard practice, making them capable of generating a complex management system.

A typical modern BMS framework can be simplified into four modules: data acquisition, data analysis and interpretation, information model and decision support model. Each module is discussed below:

• Data acquisition refers to both the methods and technologies used for capturing digital images. Typically, wireless mobile technologies can be used to transfer real-time media captured during drone flights to an easily accessible cloud-based system. UAS have a high potential to be able to provide complete autonomous navigation in the future, removing the need for any human interaction during the data acquisition process. This will contribute towards alleviating both human and capital resource scarcity;
• Data analysis and interpretation refers to the image processing tools and algorithms recruited to analyse the digital images captured during bridge inspection. The most common interpretation technique employed are crack detection algorithms [17,18]. This involves methods to isolate cracking from the rest of the scene, using grayscale image transformations for easy detection. The end result is a “crack image” which can then be stored in the database.
• The digital information model provides data storage, processing and management capabilities for UAS and bridge data. Producing such a system is the main focus of this paper, and modelling efforts and developments will be discussed in the preceding sections. In this case, the model must be proficient in storing and integrating 3D modelling, digital imaging and asset records;
• The decision support system allows engineers and bridge managers to analyse data contained in the information model from a holistic viewpoint and generate a systematic response to the assets safety condition and any maintenance strategies. An analytics engine may utilise machine learning and computer vision techniques to scrutinize imagery and inspection data, then capable of generating automated recommendations and required actions to end users.

Information is key to effective bridge management; therefore, an essential module of a management system is the information model. Databases are at the heart of the module and ultimately form the basis and quality of all decisions and actions considered by the BMS. Reference [19] noted the addition of visualisation to asset management provides a highly useful cognitive aid for processing overwhelming amounts of information. As such, GIS and BIM have been employed as the two primary databases within BMS and asset management literature. Laser scanning technology has been prevalent in GIS environments for many years now. However, with recent developments in BIM hardware, this system now also facilitates the integration of point cloud data. With both database systems capable of supporting point cloud data and digital images of a bridge asset, the benefits and drawbacks of the systems should be realised before advancing.

3. Geographic Information Systems (GIS) and Bridge Information Modelling (BrIM)

3.1. Geographic Information Systems (GIS)

GIS provides a multimedia platform to collect and store rich semantic information (i.e., attributes) alongside geometric representations of these features through spatial data. Data can be mapped on either local or global coordinate reference systems, providing location-based management. This develops an augmented information model capable of producing smart colour-coded thematic maps of the asset portfolio, as well as navigation through all the data using point and click operations through a digital map. Thus, a GIS is a database system supporting spatially referenced data, as well as a set of operations for analysis of data, all under one medium. Furthermore, GIS data can be managed in a spatially enabled relational database management software (RDBMS), such as the PostGIS extension for PostgreSQL, providing efficient methods of interpreting and scrutinising data through SQL queries. A number of literatures has developed a framework capable of the following: (1) managing currently available bridge condition data; (2) visual applications for appropriate bridge information; (3) support of user-defined query interface for decision making support [20,21,22], along with [23] who produce a web-based GIS system that allows for 3D visualisation along with the management of pertinent bridge maintenance data.

Issues with Current GIS Practices

Although GIS software is capable of modelling the built environment in 3D, geometry is not well represented [24]. For example, extensive, detailed features such as thicknesses and construction materials are neglected and simply remain modelled as a line. As such, GIS’ scope remains a tool for planning and operating infrastructure, as opposed to one capable of the initial 3D design and construction modelling of this infrastructure. Due to this, users of GIS must translate 3D data from Building information modelling (BIM) software, often through manually recreating the geometry. When data is manually converted between different software, data exponentially reduced in quality and value that could affect accuracy, whether it be through human error or misinterpretation. Furthermore, manually recreating the information is time consuming and unnecessary rework. To combat such issues, modern literature has proposed the use BIM itself as an information model. This method therefore integrates the construction and maintenance phases of a bridge lifecycle, eradicating the problem of diminishing returns in data transfer.

BIM appears similar to GIS when their basic features are first considered: (1) both systems provide data management, processing and visualisation tools capable of dealing with spatial and non-spatial data; (2) indoor and outdoor features of the environment can be meaningfully modelled, i.e., separated by entities unlike CAD. However, there exist several key differences which would be important in a bridge inspection context. BIM focuses on the detailed modelling of structural components from an architectural and construction viewpoint. Additionally, it represents a stand-alone model of a singular asset with locally referenced geometry. Conversely, GIS would visualise the same asset with geographical context including referencing with coordinates and map projections.

3.2. Bridge Information Modelling (BrIM)

BIM can be formally introduced as the development and use of a 3D digital model that is proficient in representing the design and operation of an asset. The model is a data rich, object-orientated and intelligent form of computer-aided design. The demand for BIM has rapidly risen in the past ten years or so, but its use is still restricted to certain elements of the industrial lifecycle. BIM is extensively used in initial design and construction phases, however, applications to facilities management are a more complex issue [25]. BrIM is the acronym used when BIM is applied to bridge infrastructure. Currently, its foundations for an information model are based upon a fully comprehensive 3D model that is capable of integrating structural element data obtained from past reports and field data.

DiBernardo [26] was perhaps the first to utilise BrIM, in an attempt to improve data quality standards for the National Bridge Inventory within the US. Field data was collected during manual bridge inspections and included key information such as missing fasteners, cracks and misalignment of structural members. This was then integrated with a parametric model by storing the inspection data in the user-defined attributes (UDA) of the BIM software. UDAs can store digital images, notes and sketches. The customised UDA field essentially creates a database of element-level information, which would usually be stored in an external database. Several improvements and variations have since been made to this framework. Refs [17,27] then transited the 3D BrIM model to a cloud-based data storage system where UDAs can instantly be updated in the field using mobile devices. The BrIM model is first converted to industry foundation classes (IFC) format, a neutral file that facilitates interoperability between software, then uploaded and downloaded using Autodesk BIM 360 Glue. The model and UDA database can then be accessed from any device with internet connection, allowing easy information access for decision makers. Following a survey also conducted by Al-Shalabi, et al. [27], the US have realised the effectiveness of the BrIM approach as a beneficial tool for enhancing the reliability and quality of inspection practises.

3.2.1. Industry Foundation Classes (IFC)

IFCs provide a standardised, digital description of a built asset complying with ISO (international organisation for standardisation) certification. One standard specification for the construction industry facilitates the interoperability and pass-over of information between different software and platforms. IFC presents itself as a schema for the formalised representation of building components or elements. IFC has several different versions and releases, with the most recent being IFC4. However, the most widely used and adaptable schema still remains the IFC2 × 3 (for more information see [28]).

Physical elements, people and geometry are grouped into logical entities (known as IFC class names) and include their attached attributes (such as Global ID, description, relationships and geometry). Entities are the main nodes of the schema and can be thought of as tables in a traditional database. Attributes are therefore the metadata contained in the columns of the table. A hierarchical tree of entities can be split into two: occurrences and types. Occurrences are individual instances of products, e.g., IfcWall. Whereas types refer to the corresponding type of products, e.g., IfcWallType. Throughout the whole hierarchical schema, entities are classified based on a list of pre-defined, approved IFC class names to help with industry standardisation. Within “type” entities, IfcElement represents the building or structural components, e.g., IfcWall, IfcSlab, IfcColumn, etc. The geometries of elements are hidden attributes and represent the coordinates of the corresponding shape. For the purpose of 3D modelling and bridge inspection, IfcElement types are crucial entities. The hierarchical tree of an IFC2 × 3 schema is shown in Figure 1 for visualisation purposes.

3.2.2. Issues with Current BrIM Practices

However, there exists a number of challenges when adopting the conventional BrIM approach for an information model. As aforementioned, a BIM model extends far beyond just a collection of 3D geometry, with the ability to incorporate semantic information as to both the type of element and relationships between them. Furthermore, it acts as a centralised database capable of storing attribute data associated to geometric elements. Yet, BIM models are severely limited when it comes to manipulating and querying data. The problem of accessing BIM data has not gone unrecognised, but still remains unsolved. In the simplest sense, BIM software developers provide standard interfaces for accessing basic data requirements. For any needs more complex than those the standard interface provides, additional access can be provided through application programming interfaces (APIs). APIs are predefined functionalities to retrieve data through scripts. The main problem with using APIs for filtering BrIM models is that they are proprietary in nature. In other words, an application written for one software cannot be transferred over or used in another. In addition, unless the API developed is complex, with both the time and cost of development increasing with complexity, ad hoc queries may be severely restricted. The development of an intuitive query language for BIM models capable of retrieving, updating and deleting geometric and related semantic information is still in its infancy. Open query languages such as BIMQL Mazairac and Beetz [29] have been suggested and partially developed for use on an IFC file format but are yet to be formalised and do not offer spatial query functionality. The filtering of BIM components is therefore restricted to their numeric relationships, rather than through spatial semantics. Moreover, although the lexical components of BIMQL are purposefully designed to mimic existing query languages, it is still a new language by nature, representing additional costs and time of learning for end users. With the absence of an established domain language, users or managers wanting to filter a BrIM model for decision-making purposes are faced with a laborious and cumbersome process which may be time inefficient. Many existing, non-BIM database applications use SQL as the preferred query tool due to its powerful and extensive spatial capabilities when combined with a spatially enabled extension package. Despite this, there currently exists interoperability issues in the exchange between SQL and BIM, a topic which is further discussed later.

The other problem is with regards to the IFC default schema mapping being ill-equipped and inefficient in providing a platform to manage bridge inspection data. With BIM being actively introduced in and natively designed for the construction industry, the default data schema is best applied to buildings. From an extrinsic point of view, a schema could be made from IFC entities that represent building components (e.g., IfcBeam and IfcColumn). However, following this methodology means it becomes impossible to meaningfully represent each bridge component and the semantics of the 3D bridge structure [30]. The BrIM model and converted IFC file then simply become a tool for visual recognition and management of 3D geometric information, as opposed to a complete information model offering control over non-spatial attributes. This is particularly problematic due to Revit’s, and other BIM software, in general, inherent rigidity in overriding default IFC class name mapping. Revit offers two methods for assigning unique classes to structural families: (1) Standard IFC export settings interface; (2) Assigning IFC export parameter to a family, in turn overriding the hierarchy of default IFC settings. Whilst they do allow partial flexibility, i.e., alternative setting for IfcWall is IfcFooting, they do not allow complete rework or mapping outside of Revit’s supported IFC class names which only correspond to the semantics of a standard building.

Lastly, while BIM is relatively rich in storing geometry and semantic information, it does not hold surrounding information or context. Spatial context through topographic information of an area can be highly useful for UAS bridge inspections. For example, it can be used for planning drone flight paths prior to an on-site walk around for routine inspection practices. It may also aid in the planning of transport routes to and from the bridge site with maintenance, repair, and construction materials. Alternatively, it can simply be used to exercise further control over a geographical sparse network of bridge assets, e.g., viewing the location of a specific asset in context of other assets within the management portfolio.

4. Integrating BIM and GIS

With inherent disadvantages present in both GIS and BIM methods for bridge management, there holds significant advantage in integrating the two systems. Existing efforts of integration focus on unidirectional compatibility, with workflow transferred from BIM into GIS. Within this, interoperability between the IFC format and CityGML (format for storage and exchange of 3D city information) is a common theme [31]. Following this, [24] developed a systematic framework for the integration of IFC file format and ESRI Shapefile, allowing a BIM to be viewed in both 2D and 3D ArcGIS map projections; the framework covers initial point cloud stitching all the way through to analysis of 3D structural and temporal data. The SafeSoft FME (Feature Manipulation Engine) programme is used as a midpoint data integration tool for the conversion of file formats to solve issues of interoperability. However, none of these studies are in the context of facilities management, or more specifically bridge inspection. Since an information model is involved in direct exchange of information with a decision-support system (and other modules of a BMS), there are additional issues to consider when comparing to a standard integration case. This relates to the correct tagging of objects in BIM to ensure a homogenous information platform for the modules to interpret information. For example, if the semantics of the bridge are described differently in the information model than in the decision support system, exchanges of information are made difficult.

4.1. Database Management System

When handling large datasets, such as compiled bridge inspection records, the use of a database management system (DBMS) is also recommended. A DBMS preserves the consistency (of the database), isolation (having no side-effects or unforeseen circumstances on other concurrent transactions) and durability (ability to survive after crashing) of data transactions [32]. Where a data transaction is broadly defined as the creation, reading, modification (update) and deletion of data (commonly referred to as CRUD). It also allows multi-user access to the operating system.

Within a DBMS, the relational data model is the most widely used (RDBMS). A relational database is a collection of tabular relations, with each table, or entity, having a set of attributes. For relational databases SQL is used for database interaction. Queries, if correct, will generate execution code that is passed to the database processer capable of manipulating stored data according to the CRUD principles. PostgreSQL is an open-source RDBMS which can be extended to store both 2D and 3D geometries with the PostGIS extension. PostgreSQL and other RDBMS offer direct connectivity options with commercial GIS software packages (such as ArcGIS and QGIS).

4.2. Benefits of Integration

Adopting a similar unidirectional integration framework seen in literature would benefit an information model in the following ways:

• Facilitates efficient information exchange: Automated shuttle of geometric information between IFC and GIS reduces loss of data quality and richness amongst 3D models and eradicates time-consuming manual rework of geometry;
• Provides a query-based platform: Once both geometric and non-spatial attributes have been exchanged to a GIS, they can be queried spatially or through semantic relationships. This is by reason of direct compatibility between a RDBMS and a GIS;
• Enables Conversion of Schema: The IFC schema where geometry is extracted from can be mapped into a format capturing the semantics of a bridge and inspection practices. The schema can be edited through a RDBMS;
• Provides spatial context: IFC geometry is enriched by blending a layer of geospatial context.

4.3. Interoperability

Interoperability refers to the ability of systems or software to exchange and interpret information. Heterogeneity in the context of databases can be defined into the following categories [33] and are the main factors affecting interoperability between BIM and GIS models:

• Semantic heterogeneity: an element, component or object may have more than one description or classification, where systems do not have a pre-defined interface;
• Schematic heterogeneity: an object or entity may have different hierarchies in the databases, e.g., an entity in one database may be an attribute in another;
• Syntactic heterogeneity: each database is implemented with a different paradigm, e.g., relational or object-orientated.

It immediately becomes apparent that a degree of syntactic heterogeneity is present in the interchange. The IFC schema is represented through object–orientation due to the complex hierarchical relationships, specifically relating to inheritance and aggregation structures. Conversely, the geospatial databases are relational by nature. However, schematic and semantic heterogeneity are also of major relevance here.

5. Proposed Network Architecture

Figure 2 displays the proposed overall methodology from data acquisition all the way to the 3D GIS visualisation environment. The proposed new holistic framework integrates GIS and BIM. The overall network architecture of the digital asset information model integrated within bridge management systems and the detailed methodological steps involved is presented. Two visualisation environments were created. First, a desktop solution with common integration to a commercially available GIS software. Second, a web-based solution in an open-source Javascript library to display the geospatial data. The remainder of the section will outline and explain in further detail each step of the methodology.

5.1. Point Cloud to BIM

Figure 3 shows the typical conversion of point cloud data to a Revit BIM model. As aforementioned, point clouds are one the primary outputs from the drone-based topographic surveys of bridges. Typically, LiDAR scanners carry out airborne scanning of the structure and surrounding area, utilising lasers and calculations of time of delay to generate a collection of three-dimensional coordinates. Autodesk ReCap software can be used to transform the data, capable of cleaning up and “stitching” the point clouds together into a file format supported by Revit (.rcp file). Once the point cloud is imported into Revit, it can be used as a guide where the user can trace over the geometry and create IFC elements.

In relation to a network of projects, UASs for inspection practices have been tested. Several scans were taken for each asset, as well as aerial images of structural damage, with a plan to implement the data within this report. Unfortunately, upon inspection of the collected data, there was a number of problems with LiDAR data related to water surface reflection. As such, a test BIM was created. The test bridge was created with a relatively low level of detail (Figure 4), i.e., simple structural design with low number of components and the omittance of small, detailed features. It is geolocated to the position of Stone Bridge in Chelmsford, Essex (easting: 570991.86; northing: 206554.53). Figure 5 then details the standard IFC mapping class names when exported from Revit.

5.2. Preparing the BIM Model

Within an IFC schema and BIM software in general, products and elements are placed on a local coordinate system (LCS). There are at least four hierarchical instances of an LCS within an IFC model, where building elements are attached to a story, a story layers a building, and then a building is part of a site, as illustrated by Figure 6. As such, the geometry within a BIM model must be geolocated and projected to a national-level coordinate system, in this case the British National Grid (BNG). Revit natively offers a “Specify Coordinate at Point” function which can be used to relocate the geometry to BNG. The user can simply identify the corresponding real-life BNG coordinates at a point at the base (zero elevation) of the project by referencing topographic mapping provided by the ordinance survey. It should be made sure the project base point is set to the layer IfcSite, this way all spot coordinates and elevations are displayed relative to the first hierarchical instance (IfcSite). The true orientation of the structure can be achieved by rotating the project true north. Finally, since BNG is projected in meters, project units should be changed from default (mm) to meters to eliminate the natural scaling issues between BIM and GIS.

5.3. Integrating the Data

Step 1: Exporting the IFC: Once the preparation of the BIM model is complete, it should be exported to the IFC file format. Revit’s IFC options can be changed from the default settings, to only export the relevant element instances, ultimately reducing the amount of rework required to the schema. Obsolete objects (in this context) related to IfcElement can also be excluded. For example, hidden lines can be hard coded to “Not Exported”. Unfortunately, entities hierarchically above IfcElement must be exported, with no current option to exclude them. These include entities such as IfcSite, IfcBuilding etc. The export setup should also be changed to a “high” level of detail, to best preserve the complexity of geometry.

Step 2: IFC to RDBMS: The SafeSoft FME suite is next used to convert the BIM geometry into a GIS-suitable format through the direct translation of IFC files into a spatial database. To receive the geometry of an IfcElement, the FME suite extracts two essential attributes from an entity node: these being IfcLocalPlacement and IfcProductDefinitionShape. The placement describes the coordinates of an element relative to its parent LCS. Linking a geographical location to the BIM model means IfcElement eventually reaches a national or global coordinate system. The shape then captures the physical geometry parameters/characteristics necessary for rebuilding a homogenous element in another database. Figure 7 shows the geometry attribute structure for IfcElement.

The FME quick translator software directly imports the IFC file into PostgreSQL. The PostGIS extension should first be installed within the database server to enable spatial storage capabilities. Once the IFC geometry has been extracted, it is translated into a “polyhedral surface” that is stored in a geometry spatial data column. A three-dimensional polyhedral surface consists of a list of vertices, edges and facets. The characteristic attributes of an element are also extracted and stored in the other columns. The resulting data is automatically divided into entities (layers) that correspond to the default IFC Class names, such as IfcColumn and IfcBeam.

Step 3: Restructuring to UML: SQL can then be used to combat the inherent downfalls previously mentioned within the IFC schema, restructuring to a format properly capturing and fulfilling the needs of bridge inspection practices. The newly devised inspection schema is presented in Figure 8 through unified mark-up language (UML). Individual elements have been regrouped into the entities recommended by [15] following the Department of Transport’s guidelines for bridge inspection data systems, for the effective discretization of the structure. Both “bridge” and “image” entities have also been added to the schema in PostgreSQL. The bridge table is a non-spatial entity which captures essential information about the site and asset as a whole, e.g., formal name and build year. The image table then stores digital images taken during the UAS data acquisition process. Original unedited images and crack images are stored as the “bytea” data type, meaning they are represented in binary. Images are also geolocated by storing the feature as a point, corresponding to the real-life coordinates of the photographed element. The geometry was created using the “AddGeometryColumn” command, which also permits the use of z-coordinate, i.e., allowing exact positioning to the relevant element.

5.3.1. Desktop Solutions

The desktop solution involves integrating IFC data with a desktop GIS software; ESRI’s ArcGIS suite in this case. FME Quick Translator is again used to shuttle the geometries and attributes between data storage mediums. The PostGIS database will be translated to vector data stored in a shapefile (.shp). The shapefile is ESRI’s spatial data format for storing non-topological geometry and the resulting attributes for spatial features such as polygons and MultiPatches. A shapefile consists of three main filetypes: main file (.shp), index file (.shx) and dBASE table (.dbf). The main file stores the geometric information for objects, or features as they are known in a GIS. The other two files reference this main file. The index file indexes the features. While not necessary, this supports faster data access. The database table then stores all the descriptive attributes for the features.

Within FME, the shapefile output dimension should be selected to “3D + Measures” and solid storage to “MultiPatch”, thus ensuring the polyhedral surface stored in the geometry column is correctly translated to a 3D spatial feature within the .shp file. MultiPatches are shape types for 3D geometry within a shapefile. They store a collection of “patches” to represent the bounding boxes of the 3D object. The geometric information stored within a patch can be square, triangle or triangle strips. The polyhedral surface and MultiPatch geometry types are depicted in Figure 9 for comparative purposes. The rest of the attributes from the database are extracted and stored in the .dbf file. It is wise to first name both entities and attributes in lower case within PostgreSQL, thus avoiding database reading errors which can occur in ArcGIS when upper case characters are used (first noted in the ESRI International User Conference: ESRI [34]).

5.3.2. Web Solutions

The desktop solution involves integrating IFC data with a desktop GIS software; ESRI’s ArcGIS suite in this case. FME Quick Translator is again used to shuttle the geometries and attributes between data storage mediums. The advancements in technology have brought about an increasing demand for web technologies within asset management. Focusing on web-based GIS could be an indispensable part of user and organisation needs, since it provides an effective, easy usage and fast-sharing platform that is easily accessible to many stakeholders.

Cesium is an open-source Javascript library that can render 3D globes and maps in a web browser. Cesium offers support for vectors, three-dimensional terrain and the modelling of geometrical objects. Traditionally, geometrical objects are streamed in Javascript using GeoJSON. GeoJSON geometry consists of a collection of two-dimensional coordinates in a shape that can be extruded to a fixed height to make 3D shapes that include points, LineStrings and Polygon. PostGIS geometries can be converted to GeoJSON using standard SQL script (ST_AsGeoJSON). However, GeoJSON currently only supports SFS 1.1 geometry types. SFS 1.1 geometry, also known as simple features, is defined by the ISO as basic two-dimensional geometric shapes with no curve, etc. As such, there is no possibility of the translation from polyhedral surface to GeoJSON. Furthermore, if translation was supported, extruding the geometry of each feature can become both complicated and time consuming.

The main reason Cesium was chosen as the web solution for the bridge inspection application is the 3D streaming capabilities for the built environment through the support of the 3D tile geometry type. Three-dimensional tiles offer a direct streaming format capable of being integrated with the polyhedral surfaces stored in the PostGIS dataset. Three-dimensional tiles were developed by the Cesium team, specifically for the purpose of streaming massive heterogeneous datasets that are geometrically rich, as well as allowing the detailed viewing of these features. It also supports individual interactive selection and styling for features. In other words, the tiles can contain and display the inspection metadata from the DBMS, enhancing user interaction and the usefulness of the information model.

The PostGIS entities with the polyhedral surface geometry were tiled using the FME Quick Translator tool, previously used in the information model workflow. Three-dimensional tiles are composed of two files: JSON and b3dm. The main file Tileset file is JSON, and this is the entry point from where Cesium loads the 3D geometry into the scene. JSON files then reference b3dm, where the properties or attributes from the database are contained within the file header. Three-dimensional tiles are internally based on a cartesian coordinate system, operating under the WGS 84 (ESPG:4326) ellipsoid grid. Although the PostGIS geometry is stored under BNG (ESPG:27700), FME will automatically transform the SRID (spatial reference identifier). The two-dimensional geometry of the image points will be converted to the traditional GeoJSON format since it is classified under the simpler SFS 1.1 definition.

5.3.3. Web Architecture

Figure 10 shows the basic web architecture for the online Cesium app created in this paper. GeoServer is an open-source web app server allowing the publishing of spatial data in open geospatial consortium (OSG) standards; it is particularly useful for the handling and transformation of large datasets. GeoServer can accept inputs from a variety of sources and deliver them in standards such as vector, raster and styled map imaging. GeoServer can also natively connect to database sources, helping to inject interoperability into the web architecture; for this reason, it was used to publish the 2D image points to GeoJSON and to host the features themselves. GeoJSON only supports the publishing of features in WGS 84; as such, when publishing the layer in GeoServer, the spatial reference system handling was changed to the option “reproject native to declare”. This converts from the existing BNG to the format readable by Javascript. Unfortunately, GeoServer does not support the storage of or transformation to 3D tiles; this is why FME was used to tile the polyhedral surfaces. As such, the resulting tile files have to be stored locally in the Cesium app runtime environment.

The Cesium frontend Javascript API was downloaded and used in conjunction with Node.JS. Node.JS is a Javascript runtime environment that allows the server-side execution of Javascript code, where scripts run on a web server and respond to requests from the client.

6. Concluding Remarks

This work introduces a critical framework for a digital information model for bridges, providing an efficient platform for storing, processing and managing UAS inspection data. Although the methodology being demonstrated uses test bridge data, the developed architecture of the information model covers from point cloud collection all the way to a 3D GIS visualisation environment for the storage and processing of UAS inspection data.

The findings are as follows:

• The proposed framework provides both desktop and web-based 3D GIS environments, where BMS users can quickly obtain inspection data, thereby providing a tool to help make bridge performance information easily accessible to all bridge stakeholders;
• The study establishes an understanding of the features of UAS based bridge inspection data to set the requirements of the digital information model;
• The main systems capable of handling the UAS data are reviewed, and the pros and cons are discussed;
• A digital asset information framework is developed, which is integrated within bridge management systems;
• The visualisation environment offered by commercial desktop GIS products and open-source web-based GIS are evaluated.

Future work recommendations:

• With restructuring of the bridge inspection schema occurring in the DBMS, there is currently many manual reworks required to achieve a suitable architecture fully addressing the asset management domain. This can be investigated further;
• Developing an IFC extension for the purpose of bridge asset management, or more specifically bridge inspection, should be seen as a crucial development point for future work;
• The main worry with regards to performance and scalability issues with the current methodology is when multiple assets are modelled and when the geometry and detail of the assets are increased. This may be an interesting point for further studies.