Improved SCAT data workflow to increase efficiency and data accuracy

The Shoreline Cleanup Assessment Technique (SCAT) process has continued to evolve with oil spill response, utilizing technologies available at the time to provide the most accurate documentation of the extent of oiling (Tarpley et al. 2014). The current Shoreline Cleanup Assessment Technique (SCAT) data workflow has remained consistent over the past several decades (Michel et al., 2001). While effective, this workflow inherently has places where errors can be introduced due to the numerous steps involving multiple data streams and personnel, and is subject to data access issues due to the multiple data sources and the way in which the data are processed and stored. With increased reliance on data collected through the SCAT process during the lifetime of a spill from response operations, response endpoint definitions, and ultimately the distinctly separate but concurrent Natural Resource Damage Assessment (NRDA), there is an opportunity to update the current SCAT workflow (Lamarche & Owens, 1997). New technologies and further advances in information technology have created new opportunities for collecting and sharing information to different audiences.

Multiple organizations have been undertaking an effort of integrating mobile technologies for SCAT data collection but often are lacking the database component, here we present our effort being undertaken to improve the traditional SCAT workflow based on our own experience. This improved workflow utilizes a mobile data collection application along with an accessible web-enabled database to help decrease errors in the collected data, increase the speed with which SCAT data are processed and better manage the multiple sources of data. Teams can easily review and manage the data they collect, resulting in higher quality data, and all SCAT data are more easily accessible by personnel involved in the SCAT program and overall response.

SCAT data consists of three main components: Data collection, data storage and data reporting (NOAA, 2013). Data collection is performed by field teams and involves the documentation of shoreline oiling data including descriptions, photographs and geospatial extents of oiling conditions. Oiling attribute data are traditionally collected on notebooks or paper forms, spatial data with a handheld GPS and photographs with a digital camera. Oiling attribute data are transcribed first by the field personnel onto standardized paper forms, provided to data entry personnel who then enter the data into a local database residing on a single computer. Original paper forms are typically scanned and/or copied if needed and filed. Data storage usually includes a database consisting of either a simple excel spreadsheet for small spills or a more robust, localized, SCAT specific database for larger ones (Lamarche et al., 1998). Photographs are typically georeferenced, watermarked and then stored in a photo-database if available or an alternate defined file structure. Geospatial data are typically collected, processed and then stored in a geodatabase and an alternate defined file structure by GIS data personnel. Usually any QA/QC is conducted by data entry personnel, a data manager and/or a SCAT coordinator for completeness of forms and data entered into the database. Data reporting can include a variety of productions including oiling maps, summary tables and dashboards, most of which are produced by data and GIS personnel or data managers (Lamarche et al., 1999).

The advantages of the traditional SCAT workflow are that forms are easy to understand and use since they are the basis for all SCAT training classes. Other than using handheld GPSes and digital cameras, little technical knowledge is required. Data collection is flexible and easily adjustable within this framework. It is also easy to quickly set up the initial data management process of a SCAT program as all that is required are paper forms, cameras and GPSes. Excel spreadsheets and even SCAT specific local databases are usually straight forward to setup and begin entering data.

The use of the traditional workflow has been well established on many responses proving to be effective, but often has limitations which can decrease the quality and usefulness of the data. These limitations include the introduction of errors, timeliness of data processing and accessibility of the data.

Reviews of SCAT data from previous responses have shown that there are multiple stages in the data workflow where errors can be introduced. Field teams transcribing data from notebooks to forms can write down the incorrect information. These errors are rarely found as the forms become the official source of raw data. Additionally, field teams may not completely fill in the forms, leaving critical data fields blank. Another way to introduce error includes the transposition of numbers or other entries on forms or the misreading of written observations, which is often compounded by poor handwriting from the field teams. Data entry personnel are typically not field team members and may not be able to correctly identify potential errors on a data form. Data entry often occurs when the teams have either departed the command center for the evening or are in the field so clarification may not happen immediately, slowing the process down. Errors of omission or transcription from form to database can sometimes be caught later if a robust QA/QC process is in place, however, rarely do the field teams review the data they collected once entered into the database so it is unlikely that transcription errors from notebooks to forms will be discovered. GIS mapping is usually based off GPS tracklines and hand drawn sketch maps, once again leading to interpretation issues by non-field people that may not be resolved adequately. While errors in SCAT data that are not discovered are unlikely to affect clean-up and response operations, they can present challenges to SCAT tracking metrics during the response and long-term monitoring or NRDA efforts after the response.

Timeliness of SCAT data processing is an important consideration during a response. There are two main time delays in getting data from the field into the database. The first is processing the field data into a format for data entry. This effort includes capturing the oiling data onto standard oiling summary forms, downloading and annotating photographs and downloading GPS data. Depending on how the data were collected it may take up to several hours to get the forms, photos and GPS data ready for entry. These data are then provided to data entry personnel where the second main time delay occurs, entering the data. As traditional SCAT databases are usually single-access databases (i.e. Microsoft Access™) it is not possible to have multiple people entering data into the database at the same time. With the large volume of data collected during a SCAT survey, especially with multiple teams, data entry and final data product creation can lag significantly behind data collection. This delay in SCAT data processing and entry can affect the response by delaying the dissemination of the data to the proper decision makers.

Access to previous data by SCAT personnel is hampered by the fact that the multiple streams of data coming into the SCAT data manager are usually stored in different locations. Oiling data is entered into a single-access SCAT database. Forms are copied and scanned with hard copies filed and scanned copies saved to a local computer or potentially shared cloud storage. Select photos may be printed with the forms but originals are saved on a local computer, photo-database or potentially shared cloud storage and unless relabeled may not be easily linked to the form data to which they relate. GPS data may be stored in a defined file structure or possibly a geodatabase. The multiple locations these data reside make it difficult to find, assess and use previously collected data, both during and after the response.

Additionally, the three different types of data (forms, photos, GPS data) are not directly connected. It is only processing by data personnel that ties the data together by associating the oiling data on the forms with GPS waypoints and georeferencing photos with GPS tracklines. Photos are only associated with segments and/or zones if their labels are changed, they are printed and included with the oiling forms or they are added to a photo-database and attributes applied to them. All of these options require additional work and can potential introduce additional errors and may result in timeliness issues described above.

We examined the potential for addressing SCAT program challenges with an updated and streamlined SCAT data workflow which would decrease the potential for introduction of errors, increase the timeliness of data processing and improve data access. After reviewing the limitations of the traditional data workflow, a new workflow utilizing emerging technologies may be used to improve the field data collection and data storage components. These emerging technologies include handheld, mobile “smart” devices (e.g. iPhones™, iPads™, Android based phones and tablets) with applications for field data collection, and web-enabled repositories for SCAT data management and storage.

A survey of both mobile applications and web-enabled database systems was conducted to identify those components which would are viable for the creation of the new workflow. Current mobile solutions consist of a large range of different options on various operating systems with a wide a variety of different features. We reviewed several mobile applications including both SCAT specific applications, such as Coral™ and SCATMAN™, and general data collection applications from 3^rd party providers, such as Fulcrum™, GeoJot+™, GeoODK and GISCloud™, which require customizing forms for SCAT data collection. Most of the data collection applications were feature-rich and could be used successfully for SCAT data collection. None of the applications, however, had robust databases for SCAT data management and storage as standard features. General web-enabled database solutions range from open source solutions which require a higher degree of end-user knowledge to commercial off-the shelf solutions (e.g. ESRI™ products) which often come with a higher price tag. There is no commercially available, SCAT specific web-enabled database. Ultimately, we customized a 3^rd party application for mobile data collection and worked with a GIS/web developer to create a SCAT specific, web-enabled database.

In addition to emerging technologies to help improve the SCAT workflow, we felt a greater reliance on the field teams to manage their data throughout the workflow would help decrease errors and increase efficiency. The goal is not to circumvent established QA/QC procedures but instead decrease the number of times the data are “handled” by non-field personnel and allow the field teams to see how their data are represented in the database.

Following the development of the new SCAT workflow, testing was conducted to identify where gaps might exist in relation to the traditional workflow. A population of users consisting of students from SCAT training classes and people who have been members of a SCAT team during previous incidents were utilized for collecting information. These users represented a spectrum of experience with collecting SCAT information, from beginners still learning SCAT terminology and methods to individuals who had response experience using the traditional SCAT workflow, which provided a well-rounded testing group. Users collected information, stepped through the QA/QC process and queried the database allowing us to assess how quickly the different tasks were mastered. Questions or concerns about what went well or could be improved were noted. Data reporting components and other summary data products created were shown to test groups with the goal of soliciting advice for additional features and reports which could be incorporated into the workflow.

The original SCAT workflow was modified while maintaining its effectiveness and eliminating the disadvantages that have been identified. The main items we identified to change in the traditional work flow were to use mobile data collection devices in the field to collect oiling data, photos, and geospatial data, and to use a single, web-enabled repository for all data storage to allow for data review and access. Main observations include decreased potential for errors associated with the data processing, increased speed and efficiency of data collection and review, and increased data accessibility though a single portal. Figure 1 places the traditional SCAT workflow next to the improved workflow to help provide a visual comparison of how each of the different steps have been streamlined using current available technologies.

Figure 1 illustrates how the improved workflow allows for a SCAT team to collect their data in the field utilizing mobile data collection devices and upload those data to a web-enabled, cloud based database. Teams are able to review and edit their data once in the database along with other QA/QC personnel as necessary. All data (forms, photos, GPS data) ultimately reside in one location and can accessed by end-users through the web interface. This workflow eliminates multiple data handling steps, can speed the processing of the data and results in easier access to the data for a broader group of users.

While the use of mobile devices for SCAT data collection has been discussed and attempted over the past decade (Tarpley et al. 2014), it is only the increases in mobile technology over the past few years that have made smartphones and tablets viable options. Potential advantages of adding mobile devices to the workflow include an increase in timeliness, decrease in errors and an improvement in relating the multiple data types together. Directly entering field observations into a mobile device can save time by not requiring transferring data from notebooks to the forms. Forms developed on these devices also force controlled vocabulary (with flexibility) and provide basic error checking features (e.g. calculated values, suggested entries, etc.) which can prevent handwriting errors and incorrect entries, and provide consistency in data amongst multiple teams. Certain fields can be required and data entry forms can provide some checks and balances to decrease errors. Mobile devices can also provide additional situational knowledge such as accurate maps and layers, helping teams determine where they are without having to rely on paper maps which can help speed up surveys.

The use of mobile devices to collect oiling data, photos and geospatial data allows all the data to be related to each other without post processing. Oiling data are associated with geospatial data as they are collected and photos can be automatically georeferenced and linked with segments, zones and or pits as they are collected. Additionally, photograph descriptions and keywords can be collected with the photos and do not need to be added later as a separate log or photo-database.

In reviewing mobile data collection applications, we found that most of the applications provided the above described benefits to the workflow, and are good solutions for mobile SCAT data collection. Our preference was for a 3^rd party application called Fulcrum™ which fit most of our needs including being flexible and scalable. We created all the standard SCAT forms (e.g. Shoreline, River, Arctic, etc.) within Fulcrum™ and integrated the data export with the webenabled data repository described below. Figure 2 shows examples of forms and map displays in Fulcrum™ which are used when inputting SCAT data in the field.

Potential advantages of including a web-enabled database in the workflow include an increase in timeliness, improved access to all SCAT field data and greater field team oversight of the data collected. The use of the mobile application allows for the creation of standardized data export which can be formatted and uploaded into the centralized, web-enabled database. This direct import decreases the amount of time required to enter the data sources into the repository and limits data handling and the potential introduction of errors. A single repository for all the data sources results in easier access to oiling data, photos, and geospatial information and saves time through the simplifying of data management. A web-enabled database with multi-user access provides the opportunity for not only quicker data review but also broader access to the data by end-users compared to the traditional single-user access database. Having more than one user, however, requires tiered permissions for various user groups with different read/write abilities. Field teams have the ability to view their data once uploaded to the database and edit and review their data within the database as opposed to data entry personnel.

In our review of web-enabled database solutions for the improved workflow we found few viable options that could quickly, and cost-efficiently, be customized for SCAT data. Ultimately, we decided the best solution was to work with a GIS/web developer to create a SCAT specific, web-enabled database. The result was the Polaris Integrated SCAT Management Application or PRISM.

Interaction with PRISM is controlled through a web-interface with user authentication creating different levels of access to information. In the improved workflow, SCAT data can be uploaded to PRISM once converted from mobile data collection devices. As mentioned before, our preference is for Fulcrum™ as a data collection application, however, any application can be used as long as the data can be downloaded and converted into the proper format for PRISM. Additionally, data collected using traditional workflow methods (i.e. paper forms, camera, GPS) can be entered into PRISM via the web-interface. Administrative reports such as Shoreline Treatment Recommendations (STRs) and Shoreline Inspection Reports (SIRs), which are normally not created in the field, can also be created through the PRISM web-interface. Once logged in, field team members review and edit their own data and then approve those data for data manager review. The data are visible to other PRISM users only after the data manager has approved the field team reports (QA/QC).

Oiling data, reports (e.g. STRs, SIRs), photographs and GPS files are all stored within PRISM and end-users can access these data at a single source as opposed to searching multiple locations and trying to match up the multiple data sets. Data with a spatial component (e.g. segments, zones, photographs, etc.) can be viewed, queried and accessed on a map (Figure 3) while all data stored within PRISM can be queried by date, data type, attributes or keywords (Figure 4). Photographs and GPS files can be downloaded, oiling and administrative reports can be printed out and all oiling data can be exported as comma separated values files (CSV), shapefiles (SHP) or keyhole markup language files (KML) for further review or additional processing to create traditional SCAT reporting products.

PRISM is not a single piece of software, it contains several components that work together (Figure 5). The database component resides in a cloud server instance along with an open-source GIS server which distributes WMS layers not only to the map view in PRISM but other web GIS data viewers or COPs as well. As mentioned before most interactions with PRISM take place through the web-interface including data entry, review, query and export. Imagery for the mapping component of PRISM is served by an imagery provider or spill-specific collected imagery can also be used. Setting up and maintaining these multiple components during an incident is more labor intensive than using the traditional single access database.

The rollout of the revised SCAT workflow began as an internal project with several different brainstorming and implementation stages leading to the identification of technologies which, when used together, form a complete process from field observation to querying through a web portal. Adjustments to the overall process were made as experienced SCAT personnel identified different user prompts or aids which help ensure complete data capture using the mobile data collection technology. These training sessions began by capturing features in a parking lot to familiarize people with the technology then more formal data collection sessions taking place on shorelines were undertaken. Conducting these types of sessions allowed for the workflow to be tested and critiqued by a larger audience leading to identification and clarification of any issues.

The use of mobile devices to collect SCAT data during a response took place in Louisiana during 2014 and 2015. Experienced SCAT field personnel used the Fulcrum™ application with SCAT specific customized forms on both Android and iOS enabled smartphones. Initially, data collection was slower than the traditional method for the first two to three days as the field team leads became accustomed to collecting data using mobile devices. As the comfort level increased, the speed with which data were collected also increased and after a few days was comparable to the traditional method. Oiling data were also collected in field notebooks by the field team leads, alongside the mobile devices, as a hard copy backup. This added time to the surveys and required additional work. As SCAT teams are usually comprised of at least three team members, future use of mobile devices could entail one team member using the mobile device and other team members collecting data in field notebooks. This eliminates additional delay to surveys, provides a backup for data collected on mobile devices and would support communication regarding observations amongst the team members.

Further testing of the entire workflow (mobile data collection and web-enabled database) has been conducted within the context of SCAT training classes for Western Canadian Marine Response Corporation (WCMRC) and the British Columbia Ministry of Environment. Students who have tested the revised workflow have ranged from seasoned SCAT team leads to those who are just beginning to be introduced to the concept of SCAT. Users were able to successfully collect a complete set of field observations after a 30-minute lesson on the primary concepts of the mobile data collection application. Once data were loaded into PRISM, students logged into the web-interface and conducted a QA/QC of their data to ensure that information captured corresponded to what was observed in the field. Feedback from the students is being incorporated for future testing.

The revised SCAT data workflow utilizes new technology to update the traditional workflow which meets the need for quality SCAT data to be quickly collected, reviewed and approved for distribution. The use of mobile data collection devices and a web-enabled database allow for SCAT teams to efficiently collect, import and review their own data. This workflow enables SCAT data to be collected and reviewed quickly and more efficiently and with a decrease in errors as a result of less processing steps between recording of field observations and entry into the database. The connectivity and relation between the different information components using this workflow which are collected out in the field, i.e. photos, GPS and attribute data of field observations are easier to query and review through the web portal. The use of a centralized repository of SCAT information throughout an incident will allow for the standardization of data collection, improved QA/QC, information querying and reporting.

Disadvantages of the new workflow are an increased reliance on technology, a steeper learning curve for users, internet required at the command post, and more complex initial set up and maintenance during a response than the traditional workflow. Many of these disadvantages may require a greater effort between spills in the form of testing and training or at the front end of a spill for initial set up. Most spills already have technology-intensive components with the utilization of a COP and thus internet requirements are becoming less of a concern.