CHAPTER 7

Data Exchanges

7.1 Interoperability

A well-defined data exchange process ensures that data systems have consistent metadata to promote interoperability, minimize data redundancy, and improve the user experience. Data interoperability is the ability of systems, devices, applications, or products that create, exchange, and consume data to have well-defined, shared expectations for the contents, context, and meaning of the data. A common phrase among aviation organizations across the globe is, “doing more with less.” As organizations look at data-intensive environments, such as a virtual campus or a digital twin, a true data governance program with a well-established data interoperability process can help organizations achieve this goal of doing more with less.

A successful data interoperability process should start with a standardized asset data registry, which can define collection criteria, data resolution, and accuracy standards, to facilitate data sharing across disparate data systems. A graphic explanation of these intricacies is shown in Figure 7-1. Data that is standardized, compatible with other data, and can be plugged into the many different systems or platform components that utilize this data is foundational to a successful data interoperability process.

There are several challenges airports deal with when facilitating data interoperability. The first and most prevalent issue is that silos between airport departments often house variations of the same data. These silos must be broken down so data can be shared between departments. These data-rich collection processes provide an opportunity to analyze and assess the needs of each part of an organization—beyond the needs of the funding department. This interoperability analysis should be accounted for and facilitated through a designated authority, such as a data governance council. This commonplace issue (maintaining data sets with common features separately across multiple departments) is a large part of the ROI an organization could achieve with a data governance program.

The second most prevalent issue is data maintenance. Data maintenance cannot be an afterthought—if the data needed by a user is deemed important enough to initially collect, the maintenance of that data should be equally important. An organization that continually maintains its data, rather than relying on one user’s version, will make decisions informed by relevant, comprehensive, and accurate information.

Software

With airports utilizing a multitude of systems, a streamlined process in how to exchange data among different software systems and platforms has never been more important. A small sampling of these systems is shown in Figure 7-2. While some platforms such as Autodesk and Esri have been collaborating to make these data translations easier, there are still many details to

work out even in the simplest of data exchange routines. Additionally, when combining software products that have very specialized use cases (e.g., PAVER for managing pavements, Propworks for managing leased properties, and other specialized BIM and asset management platforms), an informed and deliberate data translation and exchange process is essential.

Table 7-1 shows an example of a data crosswalk table that considers the conversion of data from a CAD drawing file into an Esri GDB, and potentially in reverse as well. Considerations must be given to what CAD drawing file layers are converted to a specific Feature Class in a geodatabase. Textual annotations and data from CAD can also be converted into a feature’s attribute data within the GIS. If data is to be routinely transformed between both CAD and GIS, features for symbology (such as block name, block sizes, and even rotation) should be considered so that features look the same when converting back and forth between different, but compatible, data platforms.

While developing a crosswalk table (like that shown in Table 7-1) is important, powerful tools, such as Global Mapper, Structured Query Language (SQL), and Safe Software’s Feature Manipulation Engine (FME), can help transition this data back and forth. FME can convert, transform, share, integrate, and validate data to specific standards and is widely used across the geospatial industry for performing intensive conversion processes. An example of an FME workbench is shown in Figure 7-3.

Another data exchange standard is the IFC, a global standard used to describe, share, and exchange construction and facilities management information. It was created as a data schema that allows the exchange of modeling data among software platforms. IFC is a standard way of storing model content and exchanging that information among the different software platforms that may be utilized throughout the design process. An IFC file is a snapshot in time of a particular design. For example, an architect could create an IFC file and share it with a mechanical engineer. The mechanical engineer can utilize this file for review, measurement, clash detection, or many other use cases, but the reference IFC file cannot be edited. Any change the mechanical engineer wishes to make must be submitted to and completed by the architect—the originator of the file.

7.2 Exchange of Data with Third Parties

As a part of a data governance program, airports should consider many components of a data exchange process. Often, third-party collaborators are provided limited data that is specific to the collaborator’s project work. This practice could prevent unwanted data changes outside a project’s work limits. When a new design project requires making minor or major changes to the airfield, considerations should be taken to determine how the new data will be incorporated into the legacy data set. Will the design data be incorporated into the legacy data set, or will there be an as-built of the data after it is constructed? Often, features are adjusted in the field, so the former option does not give a true picture of how elements were constructed and field adjusted. While Chapter 6 of this guide provides many BPMN illustrations showing how to update the data, those depictions do not fully explain the process of exchanging data with third parties. Figure 7-4 illustrates the tiered process and how data exchange efforts with third-party collaborators would be completed.

Although Figure 7-4 is a simplified approach, there are many different avenues an organization can take to improve communication and coordination through these exchange processes. For example, a third-party consultant provides data in CAD that will be used to update both CAD and GIS features. The airport can save a significant amount of time by ensuring the consultant provides the object data which aligns with GIS attributes, removing the need to fill in attributes from AutoCAD text features. Many airports have also benefitted from a GIS portal for tracking projects. The data portal can indicate area limits for each project. Assessing project limits within an overall campus map can help staff identify potential overlap among projects and share the status of the updated data set with other airport staff members for better overall project coordination. Several existing, continually updated platforms have been developed to help with these data exchanges: the National Institute of Building Sciences BIM Council (formerly buildingSMART alliance) international Information Delivery Specification (IDS); Revit Cloud Work sharing in Autodesk BIM 360; and—even better—Esri and Autodesk collaboration tools that provide connected workflows and data sharing between the two different geospatial software platforms.