Guidelines for Collecting, Applying, and Maintaining Pavement Condition Data at Airports (2019)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

63 Data Storage, Maintenance, and Access The nature of airport pavement condition data is evolving from hard copy reports, data tables, and printed graphics to data that are both generated and accessed via digital means. In the era of hard copy reports, the biggest challenge might have been locating a report on a bookshelf or in an organization’s archives. Increasingly, the challenges are identifying efficient ways to store, access, and logically integrate large volumes of condition (and other related) data that are routinely generated. Today the quantity of pavement condition data generated, stored, and used has grown sig- nificantly, and the space required to store that data has also grown. As more and more data are collected over time, and the ability to generate and access more data becomes available, this trend will continue. This chapter explores types of pavement condition data storage, main- taining data integrity, providing data access, and data governance standards. It builds on the premise that all pavement-related data must be properly stored and maintained so that they can be accessed by stakeholders when needed. At the same time, it is acknowledged that data storage and access must fit the needs of each agency, and there is no singular solution that will work for all agencies. Data Storage Airport pavement data come from multiple sources: some data are generated internally, some are generated by consultants, and some may be provided by contractors as part of construction projects. These data are generated in a variety of different formats, and there is no universal protocol for referencing locations associated with the data. Pavement data files may be quite large, presenting challenges for both storing and sharing such data. Historically, each data type might have been isolated in its own “silo.” That is, pavement condition data, records of pave- ment maintenance, friction data, geotechnical data, and other data types were generated in a variety of formats and managed who generated the data or who was the primary user, including planning, maintenance, operations, or engineering. Project-level condition data, which may be similar to network-level data but are generated for different purposes, would rarely be linked to network-level datasets and might be stored by an engineering department or offsite with the airport’s consultant. With data being generated and used by different parts of an airport’s organization, it can be challenging for agencies to store all condition data in one location, or to provide access to the range of stakeholders who might want to use it. Options for pavement condition data storage include internal, external, and cloud-based. The applicability of each method depends on the type of data stored, the quantity of data, and the number of stakeholders who need to access the data. Additionally, Table 15 summarizes the C H A P T E R 6

64 Guidelines for Collecting, Applying, and Maintaining Pavement Condition Data at Airports information detailed below, including various considerations that airports can take into account when deciding how and where to store pavement data. Regardless of the method of storage, it is important to remember that technology can be quickly outdated. For example, while a few years ago the vast majority of computers used CDs and had CD drives, today most computers do not, and USB drives and external hard drives are much more common. This may not always be the case. Airports should keep paper copies of reports, when possible, and keep electronic versions of data in common formats, such as PDF, plain text files, and so on. Even these formats are not future proof: some documents from the 1990s cannot always be opened today and may require help from IT staff in order to convert to a modern format. Internal Data Storage Internal data storage describes datasets that are stored by the airport, whether they are gen- erated by the agency or developed by a contractor and delivered to the agency. These datasets could be specific files or both the data and specialized software used to store and access the data. If data are developed by a consultant and provided to the agency, the agency must load it onto local computers or a network. For data generated by an external source, the agency should specify the desired data format in contract documents. That format should be com- patible with the agency’s software so that it can be read and widely used internally if needed. If proprietary software is required to view or edit the data, that need should be identified and addressed in project deliverables. It should be emphasized that data submitted in a format only suitable for viewing (such as a PDF) may impede further work; if there is an option to receive data in the native format, that should be spelled out. Internal data storage is best suited for organizations with well-defined roles and responsibili- ties, substantial technical capabilities to handle datasets, effective communication practices, and management support. If these characteristics are not in place, the ability to manage and apply pavement data is undermined. With internal datasets, one issue to address is the technical component of data storage. Data- sets may be stored on local computers (e.g., a facility engineer’s) or on an agency’s network for access by multiple individuals. The capabilities of the network and computers must be main- tained so that stakeholders can access the data. Table 15 identifies typical file sizes for different File Type Description Typical File Size PAVER Pavement management data, including PCI condition data, historical data, models, treatments 10 MB FWD Deflection Data Network Project Pavement response to impulse loading, providing measure of pavement structural integrity 45 MB LiDAR Point cloud of data 128 GB Profile Transverse (rutting) and longitudinal (roughness) profile data 12 MB 3-D Laser Image Laser imaging of pavement surface 37 GB Video Video images of pavement and ROW 45 GB Table 15. Approximate file sizes for typical pavement datasets (file size estimates based on an airport with 4,000,000 ft2 of pavement).

Data Storage, Maintenance, and Access 65 types of pavement condition data for a sample network of 4,000,000 ft2 of pavement. This shows that file sizes for data generated by older, established technologies (e.g., PAVER, FWD) are in the MB range of sizes, while the file sizes for data generated by some of the newer technologies are in the GB range (1,000 times larger). Another consideration with internal data storage is ensuring access to the data by all legitimate stakeholders. This requires communication so that each stakeholder knows which version of the dataset is current. In addition, if a dataset is being regularly updated, other potential users must be aware that edits are in progress or know where to find the most current set of data. Internal storage of pavement condition data may be a good idea for the agency with multiple users needing regular access. Since there is no outside party responsible for data storage, the agency assumes full responsibility for the data. Depending on the data specifications, the internal data could be stored on a local computer or a network. A local computer may be appropriate if only one person requires access to the data and is able to extract and deliver data to others as necessary. Wherever the data are stored, the need for security, accessibility, and reliability or redundancy should be remembered. Data stored on a network will be available to more indi- viduals and are likely to be backed up on an appropriate schedule. Data stored on an individual computer must also be secured and backed up frequently. If the airport stores data internally, it is good practice to develop and communicate a formal plan for data handling and access management. This identifies who is responsible for which por- tions of the dataset and ensures stakeholders are aware of relevant practices. Such a plan would include the following elements: • Definition of data types, file size, and software version needed to access the software; • Assignation of responsibility for data integrity (database version control); • Identification of stakeholders and associated levels of access (e.g., view only, edit); • Required update frequency; • Defined responsibilities and procedures for archiving and data restore procedures; and • Data specifications on the associated metadata about each specific pavement dataset. External Data Storage External data storage refers to pavement condition data stored by someone other than the owner, such as the contractor who collected the data. Like internal data storage, this could include specific files or specialized software used to store data. The agency still needs to be aware of the current state of the data and have access to it upon request for planning purposes or compli- ance reporting. It is also a good idea for the owner to store a copy of the data if possible or even to conduct scheduled downloads of updated data. A contractual relationship that identifies roles and responsibilities will help to ensure that the agency accomplishes its goals with external storage. For some agencies, the use of external data storage will be appropriate. Some agencies may have contracts in place with consultants to manage other types of data externally—pavement data could be included with the other types. An agency that does not have the technological resources to manage an internal network should consider external data storage. An agency that does not have or does not want to invest in software or hardware to store and access the data may also want to consider external storage. Managing data storage also occupies staff. An agency with a limited staff may not want to burden employees with additional responsibilities and could turn to external data management. For contractors developing and storing condition data, their internal handling of the data- bases faces the same issues as internal data storage. The technical component of the data storage must be addressed and the contractor needs proper processes to handle the data. In addition,

66 Guidelines for Collecting, Applying, and Maintaining Pavement Condition Data at Airports accurate and timely edits may need to be made to the current dataset and a process should be established to manage the access to data. One benefit to external data storage is that it eliminates the agency’s responsibility to main- tain datasets. In transferring this to a contractor, the agency can focus on using the data instead of maintaining the data. However, transferring responsibility for storing the data does not elim- inate all concerns. An agency must be able to trust the external agent with their data. The loss of direct control of the data may be troubling to stakeholders within some agencies. In addition, the agency must have a relationship with the external agent that is based on good communica- tion. The external agent may not share the agency’s priorities, and it is the responsibility of the agency to convey what data format is needed so that the data can be used effectively. Processes for sharing data between a consultant and agency need to be developed and maintained. Cloud-Based Data Storage A subset of internal or external data storage is cloud-based data storage, sometimes also called infrastructure as a service (IaaS). With cloud-based storage, data are placed on a third-party server and can be accessed over the internet. This approach allows data to be stored where it can be accessed by stakeholders in different locations. Cloud-based servers can store large amounts of data effectively, and, as with other network-based data, permissions for individual users can be assigned to control access to the data. Examples of cloud-based data storage include Amazon S3, Microsoft Azure Storage, and Google Cloud Storage. There are several advantages to cloud-based data storage. It can facilitate access to a large number of individuals who are physically dispersed, which in turn can lead to an increase in collaboration. A cloud-based data storage system can also overcome restrictive technology bar- riers. For example, some agencies are limited to which software programs can be installed on their local system. By hosting data within a cloud, many of these restrictions can be overcome. Cloud-based data storage is also ideal for large datasets. Other potential benefits of cloud-based data storage are that the agency does not have to use internal server space to store the data, the agency could rely on the third-party provider to back up the data, and the agency could allow the data to be shared with other parties (e.g., consultants) outside of the agency’s internal firewall restrictions. There are also disadvantages to cloud-based storage. The agency must have an internet con- nection with enough bandwidth to handle the transfer of data, both for uploading and down- loading. The setup of the storage must be properly tailored for the user’s purpose. As needs may change over time, the cloud may need to be reconfigured periodically. The cost to main- tain cloud-based storage is generally higher than local storage. Proper steps must be enacted to ensure the cloud-based storage is secure. Software as a Service In recent years, software as a service (SaaS) has become more and more popular with busi- nesses. This type of software is not installed on the end user’s machine; rather, it is accessed through a web browser. Examples of SaaS include Google applications such as Google Mail and Google Docs, Citrix GoToMeeting, Cisco WebEx, etc. One of the advantages of SaaS is that it requires very little IT oversight. Since the application and the data are stored in the cloud, hardware and maintenance expenses are reduced. However, a typical SaaS requires monthly or annual licenses that are based on the number of users. A disadvantage of SaaS is that, since the data are stored in the cloud, it may be difficult to download it locally for use with other software or when switching providers. SaaS solutions may also pose security challenges, but because the user is not as involved with the host, the user may just not be aware of those challenges.

Data Storage, Maintenance, and Access 67 SaaS offerings may be a good option for storing pavement data, depending on the software functionality, the agency’s needs, and the speed and robustness of its internet connection. The advantage of SaaS over cloud-based data storage is that it provides additional functionality, such as the option to view the data, maintain the data, and share the information with others within and outside of the organization. Some offerings may lead to additional costs related to the size of the data stored online. It is important to understand the SaaS offering’s cost model in order to get an accurate estimate of the real cost of the solution. Maintaining Data Integrity Data integrity and security may not be identified by airports as significant concerns, but these issues are not trivial and should be addressed. Each agency should make an active deci- sion on the level of security needed for pavement data and identify risks associated with their data. Depending on the specifics of their pavement data, an agency may decide to have various levels of data security. Safeguards should also be installed to ensure current or historic data are not lost. Potential causes for lost data include file corruption, malware and malicious internal or external attacks, inaccessibility due to changes in software versions, or hardware failures. The perceived data integrity can be reflected with how frequently databases are updated. Each agency can choose to update databases when new data are available, at a specified frequency, or during each reporting cycle. If datasets are not updated as soon as new informa- tion is available, they may be viewed as outdated by some stakeholders. If the data are accessed regularly, it is recommended that updates occur when new data are available. Another issue is to identify which stakeholders are permitted to edit datasets to ensure data integrity. There may be certain stakeholders who only need to view, and not edit, the datasets. Identifying who can edit datasets can protect against both unintentional errors and malfeasance. Ensuring those who edit the datasets have proper training will also help maintain data integrity. Data Access The ability to access pavement data is important to stakeholders generally and specifically to users of the data. “Data access” is defined as the ability to view data, to use data, to update existing data or add new data, and to combine multiple datasets so that either multiple condi- tions at a single location or changes in condition over time become more readily identifiable. Each agency will create its own system for data access depending on the type of data storage used and the organization structure. The amount of access required should match the needs of each member within the agency. Given the different types of pavement data handled, there are various options to view the data, such as with specialized software, general software platforms, and as raw data. Software licensing can be expensive, and it may not be practical for every member within a department or agency to have direct access to all data. Every agency must decide which stakeholders have direct access to the data and which stakeholders can be given data when needed. Another consideration is the amount of training given to employees. Even with external data storage, there needs to be sufficient training for employees to be able to access pavement condition data. A target is to strike a balance between having adequate training so that employees are able to access the data but without spending resources unnecessarily. The usability of a dataset is often tied to the data format. Each individual dataset needs to be in a user-friendly format and include all available relevant data. If the data are usable, it is more likely that stakeholders will access that data frequently to make decisions.

68 Guidelines for Collecting, Applying, and Maintaining Pavement Condition Data at Airports A larger problem is that each dataset collected may not be compatible with other data. For example, network-level pavement condition data, project-level deflection and coring data, and records of maintenance repairs may not be viewable on the same platform. In addition, some data may be provided primarily in narrative form, such as a petrographic analysis, which is not easily merged with discrete datasets. Incompatibility between datasets requires users to view datasets independently and combine pavement characteristics manually. Many of the potential issues associated with managing pavement condition databases are associated with how databases are designed. All data are eventually stored in data tables, and the design can address important factors associated with those data, including the following: • Linkage between datasets, • Inclusion of location information with all collected data, • Data quality control and maintaining of data integrity, and • Access to data, including who can see data, who can alter data, and how data can be combined, filtered, or otherwise manipulated. From the exploratory survey, agencies reported their primary concerns as not having the appropriate data available to develop operating budgets, recommend capital projects, or make decisions. Another concern was that the presentation of results was not useful for the target audience. For example, project-level reports may provide exceptional data analysis; however, the data may not be easily grasped or used for decision making. Based on the exploratory survey, there is room for improvement in the manner pavements assets are being managed by improv- ing data viewing, usability, and compatibility. Geographic Information Systems As airports evolve and grow, so do their need for and use of pavement condition data. For medium- to large-size airports, making the investment in a comprehensive GIS can reap rewards at multiple levels. A GIS is a system that stores geographic data digitally and can be used as an integration point with other airport business systems. Pavement condition, data in particular is inherently spatial by nature, and so using a GIS to display or access pavement condition, data not only provides a visual view of the data, but allows users to investigate and query the data to identify trends over time and place, perform analyses, and much more. There are two main types of geospatial data: vector and raster. GIS provides the ability to combine and overlay vector and raster data for visualization and analysis, as shown in Figure 32. Vector data are composed of features that are points, lines, and polygons comprising a spatial location, usually an x, y, and z. Raster data are like, and often are, an image: even-sized cells cover a certain area where each cell has one or more values associated with it. Such values could describe the cell’s color as shown in Figure 33, but may also provide other information such as the elevation at that location, as shown in Figure 34. In general, raster datasets tend to take up more space than vector datasets. The size of a raster dataset depends on the size of its resolution and the geographic area covered. Vector datasets can range from very small to very large, depending on the type of geometry stored (points are simpler than complex polygons), the number of attributes, and the number of features. (Regard- less of the size of the organization, a well-thought-out data storage plan, with regular backups, is critical for continuity, whether due to staff changes, disasters, or human errors.) When an airport has an accurate map of its property in a GIS, it can safeguard its physical assets, such as reducing the likelihood of breaking a utility line during construction, maximizing

Data Storage, Maintenance, and Access 69 Source: United States Geological Survey Figure 32. Vector and raster data in GIS layers. © 2018 Woolpert Figure 33. Raster data as orthophotograph of Hartsfield-Jackson Atlanta International Airport.

70 Guidelines for Collecting, Applying, and Maintaining Pavement Condition Data at Airports its revenue through better management of its revenue-generating spaces, and enhancing safety by keeping better track of its critical airside assets. Pavements are one such asset. By keeping track of the pavements’ condition and issues, both geographically and over time, the airport can notice trends, better predict breakdowns over time, and improve its maintenance decision- making process. This is, in effect, also what is accomplished with an APMSs. Inspecting pavements on a regular basis and keeping a historical record of the results is only beneficial if the data are analyzed and used in meaningful ways, such as for asset management, return on investment (ROI) analyses, and total cost of ownership management. These, in turn, lead to more cost-effective operations and maintenance, more accurate operating and capital budgets, and many other financial and operational improvements. A comprehensive data man- agement solution, more encompassing than managing airport-related information in silos, leads to better management. With this in mind, airports will ideally look at their organization as a whole and ultimately consider integrating all of this information into a single location, with access provided to staff as needed. A GIS is one such potential repository. At a minimum, having pavement condition data visible on a map in relation to other features and over time provides end users with some basic information that cannot be grasped from a static report. For example, if a section of the pavement needs to be reconstructed, what other projects could be done at the same time in that area to reduce impact to operations? In a more advanced, enterprise-level environment, the GIS will not only store the geographic information but will be integrated with other business sys- tems, such as its asset management software or pavement management system, providing much more detailed and extensive possibilities to improve the management of the airport’s assets and providing staff with a clearer overall picture. Data Governance Standards In order to tie all of these data together, airports should set and apply data governance stan- dards for both their activities and those of any contractors they engage. Standards can vary, but in general the following apply: • Spatial accuracy requirements, • Spatial reference information, • Data structure (how are data organized, what are the attribute fields, what are valid values), © 2018 Woolpert Figure 34. Raster data with elevation data at Hartsfield-Jackson Atlanta International Airport.

Data Storage, Maintenance, and Access 71 • Data update cycles, • Access considerations, and • Security considerations. An effort should be made to work in either non-proprietary or industry standard data for- mats. This will improve the airport’s ability to integrate different datasets and help the airport future proof its investment. Often there are various levels of data. Some are “raw” data files, such as the result of a LiDAR data collection. The raw files may be helpful to keep, but the processed files that give the end user the information needed have a higher level of importance. The raw files could be stored on an archived drive or offsite for safekeeping, but the processed files should be available for easy access by airport staff. The advantage of such an approach is that the size of the data needed on a regular basis will be much smaller than trying to keep all data generated from pavement investigations. Table 16 provides suggestions for data storage discussed in this chapter, based on a number of different factors. For example, one set of factors considers different types of data, such as reports and field data, and addresses data format issues. Another set of factors provides considerations and general recommendations associated with data storage. This is followed by a second set of data storage factors with recommendations related to airport size. Airport size can be considered a proxy for the size of staff and the availability of staff with specialized knowledge and access to technological resources. Of course, requirements for archiving or retaining records must also be adhered to, both by the airport and any consultants acting on its behalf. Summary Because of the varied types and quantities of airport pavement condition data, agencies should consider what data need to be stored, where they should be stored, how long they should be stored, and how they should be safeguarded so that they remain useful for as long as necessary. Thought must also be given to how data are to be accessed. As more data are collected and avail- able in an electronic format, file sizes require that data storage is not an afterthought. Options include internal, external, and cloud-based data storage. Each has advantages and disadvantages that must be considered based on the amount of data, the size of the organization, and the ease of access. Data integrity, access, and security are interrelated issues and are, or should be, concerns to an airport. As discussed in this chapter, these topics are addressed through policies that identify who is given access to what data by regularly updating databases and verifying that both past and current data remain compatible with installed software and by taking active steps to protect data, both by defining different types of access and by implementing appropriate data storage and backup practices. GISs are increasingly deployed at airports, and georeferenced pavement condition data can be incorporated into systems that were established for other purposes, such as utility infrastruc- tures. It is not far-fetched to imagine GIS platforms being used to manage pavement networks in the future. As more pavement condition data are presented in a digital format, data standards will become a concern. Standards are needed for data accuracy and location precision, data structure, update cycles, access, and security.

Table 16. Summary of data storage characteristics. Factors Category Internal Pavement Data Storage (Create, Edit, View and Store Data) External (Cloud) Pavement Data StoragE (Edit, View, and Store Data) SaaS Pavement Data Storage (Create, Edit, View, Store and/or Query Spatial Data) Storage/Ownership Hard Drive or Server Equipment Owned by Airport (Internal or External) Cloud Storage Owned by Others Online Software Services and Storage Owned by Others D at a Ty pe s Reports Digital written reports and spreadsheets. PDF recommended for final deliverable documents. Source or Field Information Digital source data used to create or update the report. Possible data types include PAVER database, LiDAR files, AutoCAD, GIS file formats, etc. Digital source data used to create or update the report not common with SaaS (though it can be used). Data Formats Format should be compatible with software the airport owns or can use for free. Additional open source software exists but care should be given in selecting and identifying them for rollout as they commonly require specific knowledge and training. D at a St or ag e C on si de ra tio ns an d G en er al G ui da nc e Primary Backup Store digital data files on an organizational server (or primary computer) and at least one backup storage device, such as a backup tape, external hard drive, or a flash drive. Avoid CDs or outdated technology that may be more difficult to restore in future. Hard copy version of reports/maps stored on site. Store electronic and paper data both locally and off site in case of disaster or human error. Keep copies in final and intermediate deliverable data format. Secondary Backup Require IT or consultant (if available) to keep a copy of the source data and all deliverables for a specified number of years. Require contractor to keep a copy of the source data and all deliverables for specified number of years. Ensure access to historic data in a SaaS at least until the next study must be conducted. In most cases, SaaS data should be owned by the airport and maintained by the airport and its consultants. Staffing and Experience Requires less experienced personnel and staff to manage, but common to have IT support. -Requires less experienced personnel and staff to manage and use, but common to have IT support for contracting, setup, and upgrades as required. May require more experienced personnel and staff to implement, manage, and use unless system is simplified or users are very efficient (highly qualified). Common for interface with other Sponsor entities (City, County, and/or state systems).

D at a St or ag e C on si de ra tio ns an d G en er al R ec om m en da tio ns Capital and Maintenance Budgets Requires an annual capital budget and maintenance budget as needed to store/manage data, and equipment can become obsolete or out of date more quickly, requiring upgrades. - Requires no capital budget and an annual maintenance budget with periodic cost increases to maintain or store data with little risk of obsolete equipment. Cost based on tailoring and needs of usage. Requires minimal capital budget and an annual maintenance budget with periodic cost increases to maintain or store data with little risk of obsolete equipment. Cost based on tailoring, needs, usage and upgrades. Data Transfer Requires transfer of data through storage hardware with limited sharing. Available and useful when internet connection is down, security is major concern, or high-speed connections are not available. Useful to share large amounts of source data with large number of individuals at the same time (e.g., owner, agencies and contractors) through secure, high-speed internet connections. May require more experienced user to easily share source data with others through secure, high-speed internet connections. Data Accessibility Sorting and filtering of data possible depending on software used. Data can be more easily incorporated (copied) into other applications with more common software. Sorting and filtering of data possible. Data must be downloaded and exported into other programs or applications for use. Data Viewing Spatial representation (maps) of data possible with single user desktop GIS applications. Spatial representation (digital maps) of data possible. Spatial representation of data (maps and GIS)with shared applications and tools. D at a St or ag e: A irp or t S iz e C on si de ra tio ns Small (GA) Most common data storage method used, including for backup onsite. However, larger data sets (e.g., LiDAR and imagery), can be more problematic at airports with storage capacity limits. When used, it is for storing source data and deliverables for easy access and to best ensure access is available even if staff leaves. Recommend considering with organization-wide development (city, county, state, etc.) Not commonly used. If used, either spatial representation of pavement data or GIS-based data (medium/large airports) is recommended, based on airport staff and IT infrastructure. Medium (Commercial Airline Non-Hub) Common data storage method used including for backup onsite (if not stored externally). Common for airports to have larger storage capacity limits. Ideal for storing source data and deliverables for easy access and to best ensure access is available even if staff leaves. Recommend using only standard organization set storage options and for cloud hosting options consider making the cloud- hosted data part of organizations network. Occasionally used. Airport should host all data (including distress data) in GIS format (static and dynamic) with attribute information in spatial reference for access via a browser. Historical files (static) are recommended to be included as separate files or links. Several levels of access should be included, such as viewer-only, editor, and administrator. SaaS account should be owned and maintained by airport. Geographic data should be viewable on a map and not be limited to static images or files. Will require high-speed internet connectivity at all times. Alternatively, host data internally through web- based applications (apps) for access by internal airport staff (on or off line). Large (Commercial Airline Hub) Ideal for storing source data and deliverables for easy access and to best ensure access is available even if staff leaves. Consider organization-wide storage options with minimal IT knowledge or requirements. External storage particularly relative for static source/data files. SaaS more appropriate for dynamic data.