Localizing Ecological Marine Units, Flower Garden Banks National Marine Sanctuary

Ecological Marine Units (EMUs), traditionally created at the global scale, provide information about ocean ecosystems from sea surface to sea floor. However at the current scale, areas as small as FGBNMS do not benefit from these classifications. EMUs also do not analyze seafloor attributes such as slope and terrain ruggedness. FGBNMS needed information about the seafloor as well as water column to determine the best expansion boundaries.


Chapter 1 -Introduction
To answer fundamental scientific questions about environmental effects on our oceans, Ecological Marine Units (EMUs) are used to provide users with ecological information about ocean ecosystems globally. The current EMUs do not provide high resolution information about small areas such as coral reefs, coasts, and marine protected areas. This project used sea floor and water column data from Flower Garden Banks National Marine Sanctuary to adapt the current EMU framework to a smaller scale to provide detailed ecological information about the sanctuary. Using a localized approach allows for EMUs to be used by the sanctuary and aids in its efforts of sanctuary expansion.

Client
The clients for this project were Flower Garden Banks National Marine Sanctuary (FGBNMS) and Esri. FGBNMS is in the Gulf of Mexico and is one of fourteen underwater areas protected by the National Oceanic and Atmospheric Administration (NOAA) (Flower Garden Banks National Marine Sanctuary, 2018). The Sanctuary has goals to expand its current boundaries and this effort would be aided by the creation of localized EMUs, giving more information about the seafloor and which areas are ideal to protect. The contact for this project was Marissa Nuttall, a research specialist at the sanctuary, who provided the data as well as defining the fundamental scientific questions to be answered by this project. The study area for the project can be found below in Figure 1-1.

Figure 1-1: Study Area
Currently the sanctuary consists of three separate areas: West Flower Garden Bank, East Flower Garden Bank, and Stetson Bank labeled above in Figure 1 The sanctuary has submitted its Draft Environmental Impact Statement (DEIS) for sanctuary expansion plans. An EIS is a document required by the National Environmental Policy Act for federal actions that "significantly affect the quality of the human environment" (EPA, n.d.). The sanctuary is currently in the public comment period, and this project will be submitted, in addition to the DEIS, to validate or negate the expansion plans. There are five alternatives proposed in the DEIS, and the preferred alternative by the sanctuary and NOAA is alternative number three which includes 11 boundary areas and 383 square miles, an increase from the current sanctuary boundaries of only 56 square miles. Alternative number three, the preferred alternative, serves as the study area for the project and can be seen in Figure 1-1.

Figure 1-4: Boundary Expansion Alternatives 1-5
The addition of the localized EMUs for the sanctuary will provide valuable scientific information as to why certain reefs and banks in the Gulf of Mexico are significant and unique to the oceans ecosystem.
The second client, Esri, has goals to use this project as an example of the workflow for localizing EMUs, showing that the global EMU format can be reconfigured for a local scale and be more relevant and useful to small areas such as marine sanctuaries. The contacts from Esri were Keith VanGraafeiland, Product Engineer for the Content Team, and Kevin Butler, Product Engineer for the Spatial Statistics Team. These clients defined the scope of the project as well as provided data and technical aid throughout the project.

Problem Statement
Ninety-five percent of ocean environments are a mystery (National Oceanic and Atmospheric Administration, 2018); EMUs provide detailed data-driven information about ocean ecosystems that can be used as a foundation for environmental, ecologic, and economic research and planning. Since current EMUs provide data for the entire globe, they do not supply the level of high resolution necessary to implement critical scientific research to preserve and protect our oceans. Esri's global EMUs are at a resolution of 27x27 km (Esri, n.d.), but FGBNMS was not aided by that resolution of EMUs given the small size of the sanctuary (145 sq. km) and at the low resolution of the global EMUs. Global EMUs do not significantly distinguish the individual banks proposed in the expansion goals.
The sanctuary has expressed goals to focus on benthic (seafloor) parameters for the EMUs of their sanctuary versus the original EMUs which focus more on the volumetric water column. This project explored detailed data about FGBNMS to supplement scientific investigation on deep water corals, and to develop workflows to influence similar work at other NOAA Marine Sanctuary locations. Using high resolution data (0.05x0.05 km) these localized EMUs would allow the sanctuary and citizens to see the significance of the expansion areas and why they should be protected.

Proposed Solution
Creating localized Ecological Marine Units is valuable to FGBNMS in delivering evidence of the value of the area and supplementing expansion goals. Without scientific evidence about the areas included in the sanctuary's expansion plan, there is no concrete way to prove ecologically that the proposed locations are worth protecting. Providing an easy to understand map for citizens is also essential in the expansion, since without the public approval it cannot be passed. Using seafloor analysis is essential for FGBNMS to understanding its expansion areas and potentially aiding in defining boundaries to be protected. The sanctuary expects the localized EMUs as well as public maps to be created and completed before the review period of the DEIS is over.

Goals and Objectives
This project had four major objectives, including create a web map, static maps, story maps and a 3D visualization. The first objective of creating a web map was necessary for the localized EMUs to be displayed and explored by the sanctuary, scientists and the public. This would allow the sanctuary to apply visual research to the EMUs and assist its goals of expansion. The second goal was to create static maps that displayed information about the sanctuary such as location, boundary expansion goals and seafloor analysis. These maps were valuable in highlighting what areas are being researched in this project and how the seafloor analysis was conducted.
The third objective, creating story maps, is important for sharing the importance and meaning of the localized EMUs to the public for both clients (FGBNMS and Esri). The fourth objective was to create a way to visualize these EMUs as 3D volumetric water columns symbolized by the various class numbers. For example, if there are 6 EMUs each of those 6 units should be symbolized by a unique color. For this to be useful for the sanctuary and for Esri, the EMUs were created using a workflow developed by Esri to localize EMUs.
These localized highly detailed EMUs addressed the problem that the current global EMUs possess, which is that they are too generalized and are based on 50-year averages (Esri, n.d.). The localized EMUs were calculated over shorter time spans such as seasons to provide more relevant information to be used for analysis. They will also be created over distinct boundaries based on the areas provided in the sanctuary's expansion goals.

Scope
This project included analyses on only one area, Flower Garden Banks National Marine Sanctuary. The data was provided by the sanctuary, the United States Geological Survey (USGS) as well as NOAA's World Ocean Database. The localized EMUs only included the data provided during the span of the project; it did not be look to include future data following project completion. The project was handed over to the client upon completion along with documentation of the analysis methods, therefore the sanctuary can update its EMUs in the future if wanted.
The responsibilities of the clients were to provide data and information on what ecological attributes they deem important to include in the localized EMUs, as well as come up with a classification scheme for the seafloor analysis. This project did aim to accomplish any further analyses of the data after the EMUs are localized and the seafloor analyzed.
This project was completed with Esri software. The analyses was completed with ArcGIS Pro, the web map and story map was created with ArcGIS Online. The sanctuary is currently transferring from ArcMap to ArcGIS Pro so the transfer of information at the end of the project will not cause any issues due to software incompatibilities.

Methods
There are several steps to be taken to achieve the project's objectives. The first step is to resample the data to the same scale, as the rasters (images) provided by FGBNMS are at different resolutions and locations in the expansion areas. After resampling the data, it will have to be analyzed based on the parameters provided by FGBNMS (depth, standard deviation of depth, slope, standard deviation of slope, broad and fine benthic position index and terrain ruggedness). This data will need to be converted from raster to point data to run the statistical analysis necessary to create the classification of the area based on the seafloor characteristics. The attribute data provided by Esri will need to be analyzed to determine if the parameters in the global EMUs are relevant and available for this area.
Once this is completed, the next step is beginning the clustering analysis by determining what properties of the sanctuary's water column and seafloor are the most valuable for the ecological preservation in the area. Using ArcGIS Pro geoprocessing tools, the analysis and clustering will be completed. The data provided by FGBNMS are separate bathymetry rasters throughout the expansion area. These rasters will be merged into a mosaic raster, then the seafloor analysis will be completed using geoprocessing tools provided in ArcGIS Pro such as slope and block statistics. The Benthic Terrain Modeler toolbox will be downloaded from ArcGIS Online and used in ArcGIS Pro to calculate the benthic position index (broad scale and fine scale) and terrain ruggedness. Once the new rasters are produced for each parameter they will collectively be converted to a point feature class that can be used in the Multivariate Clustering tool in ArcGIS Pro.
The statistical clustering will be conducted to determine similar areas based on the seafloor parameters, and to create a framework for the 3D EMUs. Once the clustering was completed and classification was given by FGBNMS, the 3D EMUs provided by Esri can be attributed with the seafloor clusters. The next step is to create the 3D EMUs using ArcGIS Pro and its 3D functionality. The final products will be created based on these 3D EMUs, the story maps and web map.
The story maps will be completed with ArcGIS Online to display the meaning of EMUs and seafloor analysis to allow the public to visualize the importance of the sanctuary and its expansion efforts. The web map will be created with ArcGIS Online as well; it will provide functionality for the sanctuary, scientists, and citizens to use the EMUs with their own data and to perform individual analyses outside of the web map. The 3D visualization and seafloor classification will be generated with ArcGIS Pro.

Audience
The audience for this project report are people familiar with the basics of geography and have been introduced to GIS. Primarily this report is aimed at marine sanctuaries who have goals to use a similar workflow in creating boundary expansion plans.

Overview of the Rest of this Report
Following this chapter are six chapters which will dive deeper into the logistics and details of how the seafloor analysis was performed and how the EMUs were created. Chapter 2 will review literature on similar projects that used various techniques to identify protection areas. Chapter 3 will provide an overview of the project plan, system design and analyze the requirements of the project. Chapter 4 reviews the database design and provides information on the data used. Chapter 5 discusses the implementation of the project and explores the analysis process. Chapter 6 provides the results and elaborates on the analysis conducted. Chapter 7 provides the conclusions from the analysis and introduces ideas for future work related to this project.

Chapter 2 -Background and Literature Review
According to Sylvia Earle, although "the sea contains 97 percent of the planet's water, governs climate and weather, generates most of the oxygen in the atmosphere, absorbs carbon dioxide, shapes planetary chemistry, and provides home for most of life on earth, the aquatic two thirds of the planet has been largely neglected" (Wright & Earle, 2002, p. ix). The ocean is amazingly undiscovered despite the amount of space it takes up on our planet and the benefits it provides for us. It is essential to explore similar projects that have uncovered techniques that may also be useful in this project. This chapter is organized as follows, first research that discusses the benefits of protecting marine areas will be discussed to show the importance of this project and FGBNMS expansion goals. Next, the topic of using units to classify terrestrial and marine ranges to compare areas and identify important protection areas will be addressed, followed by an introduction to different algorithms for identifying protection areas this algorithm provides an example of the techniques that may prove successful in a similar goal. Finally, this chapter will discuss information related directly to this project, explaining what the Benthic Terrain Modeler is and what Benthic Position Index and Terrain Ruggedness are and how the clustering tool works. All this information will be useful in understanding the project overall.

Marine Protection
In an article about using GIS to determine what marine areas should be protected, Friedlander and others focus their research on the effects of recognizing parts of the neglected ocean which include Marine Life Conservation Districts (MLCDs), and what repercussions can occur when marine areas are given protection (Friedlander, Brown, & Monaco, 2007). They used remote sensing among other techniques in the study area of Hawaii to govern the outcome of marine protection and provide information on whether it is necessary or helpful for marine ecosystems at all. What they found was that within MLCDs there was an overall higher volume of fish biomass and biodiversity versus areas not protected (Friedlander, Brown, & Monaco, 2007). Using maps of protected areas and adjacent non-protected areas they could determine the efficacy of marine protected areas for habitat health. It is very clear that through this research it was determined that marine areas, in this study area, provide the results they should, they have more fish biomass then areas outside of the marine protection. Overall this paper provides an overview of how GIS can be used to determine marine locations that should be protected.

Terrestrial and Marine Units
Using defined units to categorize a phenomenon or ecological feature for scientific interpretation has been successfully utilized by Host et al (1988) and Wallace et al (2010). Host used Ecological Land Units (ELUs) to measure the variation in overstory biomass and average annual biomass of upland forest stands. He defined ELUs "based on combinations of ground-flora vegetation, soil and physiography" and used these units as a reference for measurement techniques (Host, Pregitzer, Ramm, Lusch, & Cleland, 1988). While Host provided a unit for the earth's land surface, Wallace represented units in relation to a marine environment. Wallace used Regional Management Units (RMUs) to georeference marine turtle information into layers to analyze with a GIS. The RMUs classified the turtle habitats into units based on protection levels and provided valuable references for spatial planning. Host's and Wallace's unique units provided a useful reference for their studies and successfully demonstrated the importance of providing a baseline measurement, such as units, to compare other measurements in hopes of reaching goals like conservation or economic productivity.

Protection with Algorithm
Several techniques have been used to decide on which locations to designate as protected marine areas. Airamé et al (2016) devised an algorithm that produced multiple network options to achieve the goals of a marine reserve, using the Channel Islands of California as a test site. This algorithm provided a way to test the viability of a marine reserve design using ecological criteria. The purpose of this algorithm was to meet the needs of both commercial fisheries and protective reserves (Airamé et al., 2016). A different method used was Esri's creation of a 3D representation of data from the ocean surface to bottom to provide information in the form of ecological marine units (EMUs) (Witze, 2017). EMUs are used as an attempt to span the entire globe in three dimensions as opposed to previous 2D methods that were unable to show data from sea surface and bottom. This method attempts to show trends in certain areas, such as where there are low oxygen levels, to display why such specific trends are occurring. This data could provide the United Nations with the information necessary to designate marine areas in need of conservation with very detailed boundary lines. However, this data currently relies on averages over five decades and would be more useful if recorded over shorter periods of time (Witze, 2017). With a shorter time span, more detailed data could be provided and updated regularly giving more precise information about an area and eliminating the generalizations that result from using an average. Using a localized area, such as a specific marine sanctuary in need of protection, EMUs could also provide higher resolution and seasonal spatial information for scientists and citizens concerned with our ocean's health.

Benthic Terrain Modeler and Benthic Position Index
The Benthic Terrain Modeler is a tool created for ArcGIS software that uses bathymetry (depth) data to create a classification of various marine areas to be used for research or territory management (Lundblad et al., 2004). This tool has several different analyses that can be performed individually; this project uses the Benthic Position Index (BPI) tools and the Terrain Ruggedness tool. Benthic Position Index "is a second-order derivative (as it is derived from the first derivative, slope) of bathymetry" (Lundblad et al., 2004). The output of the BPI calculations gives a range of negative to positive numbers. The negative numbers usually represent valleys and positive numbers can suggest ridges (Lundblad et al., 2004). BPI is calculated by comparing cells of the bathymetry dataset within a specified neighborhood. There are two ways to calculate the BPI, fine and broad BPI, the broad BPI simply uses a larger neighborhood size where the fine uses a smaller neighborhood. For more information refer to the information below from Lundblad et al. (2006). BPI was derived as a measure of where a georeferenced location, with a defined elevation, is relative to the overall landscape. The derivation involves evaluating elevation differences between a focal point and the mean elevation of the surrounding cells within a user defined rectangle, annulus, or circle. For example, where a user has an elevation grid that has 1 m resolution, he/she may choose to analyze the grid with an annulus. The annulus, having an inner radius of 2 units and an outer radius of 4 units, would be used to analyze spatially each grid cell in comparison to its neighboring cells that fall within that annulus. BPI was calculated in the ArcGISTM raster calculator using the focal mean calculation described above; the resulting grid values are converted to integers to minimize the storage size of the grid and to simplify symbolization (Algorithm 1). Algorithm 1 creates a BPI grid using bathymetry and user defined radii: scalefactor = outer radius in map units multiplied by bathymetric data resolution, irad = inner radius of annulus in cells, orad = outer radius of annulus in cells, bathy = bathymetric grid, and rad = radius (if using circle instead of annulus). BPI_scalefactor_ = int((bathyfocalmean(bathy, annulus, irad, orad)) + 0.5) or BPI_scalefactor_ = int((bathy-focalmean(bathy, circle, rad)) + 0.5) The cells in the output grid are assigned values within a range of positive and negative numbers. The 0.5 is added before the integer conversion and is meant to force floating point values, regardless of the sign of the value, to round up if the value has a decimal of greater than.5 and to round down if the value has a decimal of less than.5. The variable is not necessary if a user chooses to allow the floating point values to be rounded downward consistently for positive and negative values. A negative value represents a cell that is lower than its neighboring cells (valleys). A positive value represents a cell that is higher than its neighboring cells (ridges). Larger numbers represent benthic features that differ greatly from surrounding areas (such as sharp peaks, pits or valleys). Flat areas or areas with a constant slope produce near-zero values. (p. 96-97) Another definition for BPI was provided in a tutorial for using the Benthic Terrain Modeler written by Dawn Wright and can be found below.
Bathymetric Position Index (BPI) data sets are created through a neighborhood analysis function. Positive cell values within a BPI data set denote features and regions that are higher than the surrounding area. Therefore, areas of positive values generally characterize ridges and other associated features within the benthic terrain. Likewise, negative cell values within a BPI data set denote features and regions that are lower than the surrounding area. Areas of negative cell values generally characterize valleys and other associated features within a bathymetric data set. BPI values near zero are either flat areas (where the slope is near zero) or areas of constant slope (where the slope of the point is significantly greater than zero) (Weiss 2001). BPI data sets are created from an input bathymetrc data set by applying an algorithm that utilizes a focal or neighborhood function. Neighborhood functions produce an output raster in which the output cell value at each location is a function of the input cell value and the values of the cells in a specified "neighborhood" surrounding that location. The BTM Tool utiziles the Raster Map Algebra Operation object, available through the ArcGIS Spatial Analyst extension, to apply the following algorithm and create an output BPI data set: BPI<scalefactor> = int((bathy -focalmean(bathy,annulus,irad,orad)) + .5) scalefactor = outer radius in map units * input bathymetric data set resolution(cell size) bathy = input bathymetric data set irad = inner radius of annulus-shaped analysis neighborhood in cells orad = outer radius of annulus-shaped analysis neighborhood in cells. (slides 3-4) Terrain Ruggedness identifies areas of the terrain that are uneven or bumpy. The output of this tool creates something comparable to a Triangular Irregular Network (Wright, n.d.). Rugosity "captures variability in slope and aspect into a single measure" (Esri, 2013). This tool from the Benthic Terrain Modeler can return values from 0 to 1 where 0 indicates no variation in the terrain and 1 indicates complete terrain variation. However, values for typical terrain range from 0 to 0.4 (Esri, 2013). This project will be using this ruggedness calculation to see if this calculation is useful or identifies rugged areas in the study area. The rugosity calculation while different then the slope calculation does have a relationship to rugosity. Rugosity and slope are positively correlated; therefore, a higher rugosity indicates a higher slope and a lower rugosity indicates a lower slope (Lundblad et al., 2004).

Clustering Tool
The tool used to cluster the data for this project (slope, depth, benthic position index, etc.) was an ArcGIS Pro tool called "Multivariate Clustering". This tool works two ways, the user can define the number of clusters to be created or it can let the software decide. When the software chooses the clusters, it uses the K-Means statistic/algorithm to find the optimal number of clusters so that the similarities within each cluster are maximized and the differences between clusters is maximized (Esri, n.d.). This tool allows the user to input the analysis fields to base the clustering on; in this project those fields were slope, standard deviation of slope, terrain ruggedness, depth, standard deviation of depth, broad benthic position index and fine benthic position index.
When the software chooses the optimal number of clusters it is using the Calinski-Harbasz pseudo F-statistic which is a ratio that shows within cluster similarity and between cluster differences. This tool produces a pseudo F chart and the highest point is the most optimal number of classes; however any other peaks could be a reasonable number of classes as well. An example of a pseudo F chart created from this tool is shown below in

Summary
This chapter was a way to explore various techniques used to achieve similar goals to this project. Using very similar procedures, creating units to classify characteristics of the area has proven successful in previous projects. Exploring why it is important to protect marine areas was also necessary to show the purpose of this project on a large scale. Observing different techniques for achieving similar goals proves useful in giving perspective on how the same goal can be achieved with multiple methods. This gives a more robust understanding of the study area and how these various methods can be adjusted to fit this project and area more directly.

Chapter 3 -Systems Analysis and Design
This chapter describes the system design and requirements for the clients, Flower Garden Banks National Marine Sanctuary (FGBNMS) and Esri. Section 3.1 restates the problem the project is addressing for the client. Section 3.2 discusses the requirements, both functional and non-functional, of the project. Section 3.3 describes the system design and how the requirements were fulfilled for the clients. Last of all, section 3.4 defines the project plan and how that plan changed throughout the course of the project.

Problem Statement
Ninety-five percent of ocean environments are a mystery (National Oceanic and Atmospheric Administration, 2018); EMUs provide detailed data-driven information about ocean ecosystems that can be used as a foundation for environmental, ecologic, and economic research and planning. Since current EMUs provide data for the entire globe, they do not supply the level of high resolution necessary to implement critical scientific research to preserve and protect our oceans. Esri's EMUs are at a resolution of 27x27 km (Esri, n.d.) and FGBNMS is currently not aided by that resolution of EMUs given the small size of the sanctuary (145 sq. km) and at the low resolution of the EMUs. They do not significantly distinguish the individual banks proposed in the expansion goals.
The sanctuary has expressed goals to focus on benthic (seafloor) parameters for the EMUs of their sanctuary versus the original EMUs which focus more on the volumetric water column. This project will explore detailed data about FGBNMS to supplement scientific investigation on deep water corals, and to develop workflows to influence similar work at other NOAA Marine Sanctuary locations. Using high resolution data (0.05x0.05 km) these localized EMUs will allow the sanctuary and citizens to see the significance of the expansion areas and why they should be protected by the sanctuary. FGBNMS has stated that the most valuable piece of analysis for this area is the seafloor (slope, terrain ruggedness, benthic position index, etc.) and this seafloor analysis will be combined with information from the water column (such as salinity and temperature at different depths) to create EMUs that are configured to fit the needs and characteristics of the sanctuary. Global EMUs do not provide the level of detail necessary for a small area such as FGBNMS, therefore it serves as a perfect project for Esri in determining the success of their workflow in creating EMUs given more detailed local information. Without adapting EMUs to fit the smaller area of the sanctuary they cannot be used to supplement the sanctuary's expansion goals nor provide helpful scientific information for potential research.

Requirements Analysis
This project is made up of both functional and non-functional requirements. The functional requirements are what must be accomplished to create a successful output for the client, the non-functional requirements are what will be done to increase the quality of the project but are not necessarily required for the project to succeed. The client, FGBNMS, is primarily interested in how EMUs could be used to classify and explore their marine sanctuary. Ideally, FGBNMS is aiming to use this project in the FGBNMS internal review as information to help guide the final boundary selection. The first functional requirement for FGBNMS is a classification of the seafloor that is applied to Esri's EMU framework, which currently does not include such analysis.
The second functional requirement was primarily for the supplementary client, Esri. The project must use localized data that includes a depth factor to create 3D points throughout the study area, like the global EMUs. This is depicted in the image below.

Figure 3-1: Esri's Global EMUs (Esri, n.d.)
The final functional requirement states that FGBNMS will provide multiple raster images for analysis which must be used to cover the entire study area. Since there is no single raster of the study area, multiple raster images must be mosaicked together and resampled to perform the desired seafloor analysis.
This project had two non-functional requirements. The first requirement being the output story maps and web maps must be public facing, a preference of FGBNMS and Esri to display the success of the project and the importance of preserving the new sanctuary boundaries. The second requirement demands the raster images be high resolution; while this is not required to bring the project to completion it is preferred by FGBNMS to capture the details in the area. Table 1 and Table 2 below display the functional and non-functional requirements respectively.

System Design
To layout the project's architecture the system design has been used to explore what will be used to fulfill the goals of the project. The system design was created using the requirements of the clients as a basis. This project starts with the data and ends with web maps and web applications published on ArcGIS Online as depicted in Figure 3-1.

Figure 3-2: System Design
The project began with the data provided by the clients, then the data was stored in a geodatabase using ArcGIS Pro. ArcGIS Pro was then used to perform various analyses of the data and create outputs also stored in the geodatabase as feature layers. Those feature layers were then shared as a feature service on ArcGIS Online and used to create the web maps and web applications (story map) required by FGBNMS and Esri for project completion.

Project Plan
This project had four major phases: plan, develop, map design and deployment. The first phase, planning, was essential in establishing the projects overall design and what the client wanted out of the project. The client would provide the goals of the project as well as provide the data. Once given the data, it would need to be resampled before the next phase could begin. The next phase, develop, is where the analysis of the data took place. After analysis was complete and a classification scheme was created for the area in association with FGBNMS, the third phase could begin, map design. In the map design phase all the maps for this project were created, both static maps and online interactive maps. In the final phase, deployment, the project was shown to the clients and the project advisor and was edited as necessary, to fulfill the project requirements. Finally, the project document and final version of the project were submitted. The original plan that was drafted at the beginning of the project is displayed in Table 3 below. The original project plan shown in Table 3 above was not entirely the plan that was executed. As the project developed plans shifted or changed. Initially a major part of the project was creating the 3D EMUs from scratch, however, after talking with FGBNMS the sanctuary had more interest in a seafloor analysis and not necessarily the 3D component of the EMUs. After connecting with Esri, the project changed to fulfill FGBNMS goals of a seafloor analysis and classification maps of that analysis as well as complete testing of Esri's localization EMU workflow. Keith VanGraafeiland and Kevin Butler from Esri had created ArcGIS Pro Tasks that would create the 3D EMUs for FGBNMS, but instead of creating the EMUs from scratch they requested the project to test their workflow and identify any problems with the tasks.
ArcGIS Pro Tasks are a step by step guide that walk you through a workflow (Esri, n.d.). In the case of this project the tasks walk you through the process of creating the localized EMUs for your location, from importing the data to creating the 3D mesh. This kind of tutorial is meant to be understood by non-GIS experts so that they can create localized EMUs with no deep knowledge of the processes that were used to create them. The interface of tasks is shown in Figure 3-3 below.

Figure 3-3: ArcGIS Pro Tasks
Due to changes in the project scope as well as the addition of a secondary client, Esri, in February 2018, the project plan had to change. In addition to a change in scope, the project also had to complete certain tasks, map design and deployment, in a shorter amount of time. The updated project plan that was implemented is displayed in Table 4 below.

Summary
This chapter discussed the system design and analysis. Starting by restating the problem that this project is addressing, this chapter then laid out the requirements of the project, both functional and non-functional. The system design was then stated showing the major components of the project and what was necessary to complete the project. Finally, the project plan was shown to illustrate changes in the plan and the tasks carried out to complete the project.

Chapter 4 -Database Design
This chapter is a detailed description of the database design (conceptual and logical models) as well as the data used in the project. Since there are two different clients, this project created two separate databases, one for each respective client. The database designs support the requirements of each client and fulfill the goals of the project. Section 4.1 discusses the conceptual data model, Section 4.2 illustrates and describes the logical data model, and Section 4.3 lists and defines the data sources. Section 4.4 explains the data scrubbing and loading methods used in the project, and lastly, Section 4.5 is a summary of the chapter.

Conceptual Data Model
There are two conceptual data models for this project based on the needs of the two clients. The conceptual design describes the entities in the project and their relationships to one another. Figure 4-1 below illustrates the conceptual data model for Flower Garden Banks National Marine Sanctuary.

Figure 4-1: Conceptual Data Model for Seafloor Classification
The data model included three main entities: study areas, depth, and Remotely Operated Underwater Vehicles (ROV) images. The study areas for this project are various marine banks included in the sanctuary's Alternative # 3 proposed in their Draft Environmental Impact Statement (DEIS). Each of those areas must have a depth factor, or in other words, each area must possess a bathymetry raster to complete the analysis required by the client. The model must also include ROV images taken in the study areas in order for users to visualize real life photos of the area.
The second conceptual data model was created for Esri. This data model is illustrated in Figure 4-2 below.

Figure 4-2: Conceptual Data Model for Generating Local EMUs
The conceptual model for Esri also included three entities: study area, depth and physical components. While the models look similar, in this case the study area was a single area, not multiple banks as were provided in the FGBNMS conceptual model. The study area has both depth and physical components. Those physical components were used to create 3D EMUs and cluster the physical data (salinity, temperature, etc.) into groups.

Logical Data Model
The conceptual model describes the large-scale entities and relationships in the data model. The logical data model delves into the data used and data types for the project. This model also explains how that data are organized within the system. This project created two databases, one for each client, and therefore two logical data models were made. Each data model used an Esri geodatabase as the database format to store and organize the data. The first logical data model that will be illustrated is the model for FGBNMS shown below in Figure 4-3.

Figure 4-3: Logical Data Model for Seafloor Classification
The database created for FGBNMS included rater datasets, feature classes and tables. The raster datasets involved a bathymetry mosaic that was create by merging all the individual study areas into one raster and clipping it to fit the extent of Alternative # 3 in FGBNMS DEIS. From that bathymetry raster, several rasters were created, which are displayed in the "Analysis Rasters" section of Figure 4-3. By combining the information from each of those rasters, a classification feature class was created. That classification feature class is in the form of polygons which contain the attributes listed above in the figure, the most important being grid code. The grid code is the cluster ID, which differentiates the polygons from one another based on the attributes derived from the analysis rasters. When the clustering was performed a table was yielded, as evident in the "Clustering Table" section above. That table contained the attributes listed in the figure, the pseudo F being the most valuable, which shows why the number of groups was chosen statistically; more detail about this table can be found in Chapter 5.
The other feature class in the data model contains points of where (latitude and longitude) ROV images were taken. That feature class contains attachments of the ROV images, which requires the ROV match table in order to pair the attachments to the correct location based on ObjectID and Filename/Photo Name.
The second logical data model created is for the data provided by Esri, shown in Figure 4-4 below.

Figure 4-4: Logical Data Model for Generating Localized EMUs
The database created for Esri has eight feature classes as well as a table and raster dataset. The first six feature classes (temperature, oxygen, nitrate, silicate, salinity and phosphate) were created by converting raw data into a feature class that can be stored in the database. Each of those features has the same attributes with their associated values for each physical component (temperature, oxygen, etc.). A 3D mesh was created which requires a bathymetry raster to determine the depth of the area. The mesh was filled with the data from the six feature classes (temperature, oxygen, etc.) making an output cluster feature class. The cluster feature class produced a table similar to the table created from clustering the data in the previous model for FGBNMS. This table shows statistically why the produced number of groups was selected.

Data Sources
The data used for FGBNMS's part of the project was provided by the sanctuary and United States Geological Survey (USGS). USGS provided bathymetry rasters for a majority of the banks, FGBNMS provided just three bathymetry rasters containing the bathymetry of Elvers Bank, Parker Bank, and Horseshoe Bank. Horseshoe Bank was derived from a raster that covered a large area; this large raster was clipped to the area of Horseshoe Bank. In Figure 4-5 below the raster outlined in red is the large raster (called FGB Combined in Table 5) and the area labeled Horseshoe Bank is the area the raster was clipped to.

Figure 4-5: Horseshoe Bank Data Merging Process
This large raster was also used to fill in the gaps between banks when mosaicking the raster to a single image as shown in Figure 4-6 below. The first image in the figure shows the raw data before any merging took place, the second image is after the images were merged (mosaicked) together, and the last image is after they had been resampled to a 50-meter resolution and clipped to the area of Alternative # 3.

Figure 4-6: Bathymetry Data Mosaicking and Clipping
Each raster area, resolution and source are provided in Table 5 below. The ROV images were provided by FGBNMS along with an Excel spreadsheet gathered in WGS84. For the second part of the project, the 3D EMUs for Esri, Esri provided the data for the study area. This data was originally from the World Ocean Database which was a project started by the Intergovernmental Oceanographic Commission with the intent to create an international ocean database formed by exchanging data and accessible without restriction ("World Ocean Database Project", n.d.). The World Ocean Database has various profiles for different physical characteristics of the ocean gathered by several instruments. The profiles used in this project were: temperature, phosphate, salinity, oxygen, nitrate and silicate. To create the 3D EMUs this project also required a bathymetry raster, this required data was also provided by Esri and its origin was Scripps Institution of Oceanography. However, the client downloaded the raster from ArcGIS Online and clipped it to the extent of the study area in the WGS 1984 spatial reference.

Data Scrubbing and Loading
The data provided from FGBNMS had to be resampled and edited. The rasters were all different resolutions, all of which were mosaiced into a single raster dataset and then resampled to 50-meter resolution. The reason the resolution had to be no less than 50 meters was because the geoprocessing tool, Multivariate Clustering, used in the project was not able to handle the large number of pixels that come with a higher resolution image. The process used to do this mosaicking and resampling began with using the ArcGIS Pro geoprocessing tool "Add Rasters to Mosaic Dataset" where all of the rasters listed in the data section above and in Table 5 were added. Following the completion of that tool the next ArcGIS Pro geoprocessing tool was run, "Mosaic to New Raster" using the output from the previous tool. Finally, the new raster created was resampled to a resolution of 50x50 meters using the bilinear resampling technique and that output was clipped to Alternative #3 using the "Extract by Mask" geoprocessing tool. The resampling technique of bilinear was chosen because it is ideal for continuous data such as depth.
To load the rasters into the database, first the original rasters were added to ArcGIS Pro, then the resampling took place and the output mosaic raster was clipped to the study area. This was saved to the database and then the analysis rasters and clustered feature class were created and saved to the database as they were produced.
The ROV images and the Excel file associated with those images had to be formatted correctly to use the geoprocessing tools and to add attachments successfully. The Excel file had a field called Photo Name, and the ROV image file names were linked to that field. Figure 4-7 below shows an example of the image file names before reformatting.

Figure 4-7: ROV Images
The names were formatted differently. To make sure they matched, the spaces had to be removed from both file names in the image folder as well as the Excel sheet. The image file names were edited using a Python script and the Excel sheet was edited using features in Excel. Next, the image file names were copied into the Excel sheet to cross match and find the file names that needed to be edited. The Excel sheet was edited to match the image file names and the ones that had no match were deleted.
To load the ROV images into the database, first the Excel sheet was converted into a CSV file and then added to ArcGIS Pro, then that CSV was made into an XY event layer. Since the XY event layer is temporary the data had to be exported into the database as features. Next, the attachments were enabled on the newly created feature class and a match table was created using the feature class field "PhotoName" and the folder containing the ROV images. Then the attachments (ROV images) were added to the feature class.
The data from Esri did not require any scrubbing or cleaning. It was loaded into the database by using the ArcGIS Pro tasks provided by the client. The first task in the workflow added the data into the database by converting the raw data form the World Ocean Database into a feature class stored in the geodatabase.

Summary
This chapter outlined the database requirements for the project and gave detailed descriptions and illustrations of the conceptual data model and logical data model created for both clients. The conceptual data model demonstrated the big picture components of the database and the relationships between those. The logical model introduced the data used in the project, what would be stored in the database, and how it would be stored. The data sources for this project were described and the scrubbing used for that data was also discussed. Following the cleaning of the data, the technique used to load the data into the database was reported. This chapter and the data used was crucial in creating a reliable and accurate database.

Chapter 5 -Implementation
This chapter will discuss all the analyses performed in this project in detail. This project was implemented in a series of steps and each section describes those steps. Section 5.1 explores the seafloor and all the tools and outputs created by analyzing the seafloor. Section 5.2 discusses the process of converting the seafloor analysis rasters into points, so they could be analyzed and classified using the ArcGIS Pro Multivariate Clustering geoprocessing tool. Section 5.3 briefly explains how the previous mentioned clustering tool was verified to ensure standardization before classifying. Section 5.4 discusses the process of converting the ROV image attachments to web map pop-ups. Section 5.5 discusses the ArcGIS Pro tasks used to generate localized EMUs. Section 5.6 will provide a summary of the entire chapter.

Seafloor Analysis
This project first converted a series of individual bathymetry datasets of the study area into a single raster as discussed in Chapter 4.4. After creating a single bathymetry raster, the analysis could begin. This project used various ArcGIS Pro geoprocessing tools which will be shared in each step.
First, slope was calculated using the bathymetry raster with the "Slope" tool to create an output slope dataset in degrees. Next, the "Block Statistics" tool was used to calculate the standard deviation of slope and of depth (bathymetry). For both slope and depth, a rectangular 5x5 size cell was used as the neighborhood to calculate the standard deviation. Next, the Benthic Terrain Modeler toolset was used to calculate the broad benthic position index (BPI), fine BPI and terrain ruggedness. The broad BPI was calculated using an inner radius of 25 meters and outer radius of 250 meters. The fine BPI was calculated using an inner radius of 3 meters and an outer radius of 25 meters. BPI produces a range of negative to positive values where negative indicates valleys and positives indicate ridges. Fine BPI identifies small features in the terrain and broad BPI identifies larger features. The detailed definition of BPI can be found in Chapter 2.4.
Lastly, the terrain ruggedness was calculated using a neighborhood size of 3x3. This final output of terrain ruggedness did not provide any significant results, as the index ranges from 0-1 with 0 being no topographic variation and 1 being complete variation. On average the values for typical terrain range from 0-0.4 (Esri, 2013), however for this study area the highest value was approximately 0.03, therefore rugosity did not provide any meaningful analysis as all the values were very close to 0.
The seven analysis outputs can be seen in Figures 5-1 and 5-2 below.

Raster to Point and Classification
The goal of this project was to create a classification of the study area, to do this the "Multivariate Clustering" tool provided in ArcGIS Pro was used. This tool finds the optimal number of clusters based on attributes provided by the user, in this case those attributes were: slope, depth, standard deviation of slope, standard deviation of depth, broad BPI, fine BPI, and terrain ruggedness (VRM); more detail on this tool can be found in Section 2.5. To use that tool and perform the clustering of the seafloor attributes, the rasters had to be converted to points. To get from raster to point, first the bathymetry raster was converted to points using the "Raster to Point" tool. This created a point feature class that included a field in the attribute table for the depth (bathymetry). Next, the "Extract Multi Values to Points" tool was used to extract the values from the other six rasters (standard deviation of depth, slope, standard deviation of slope, broad benthic position index, fine benthic position index, and terrain ruggedness) to the newly created point feature class. The point feature class then contained fields in the attribute table for each analysis parameter.
In this point feature class, there were some null values for slope, standard deviation of slope and terrain ruggedness. This is expected since these calculations are performed using a neighborhood and suffer from edge effect; as expected all the null values in the point feature class fall along the edges of the study area. Figure 5-4 below shows a small location within the point feature class and has been symbolized by the slope attribute.

Figure 5-4: Point Feature Class with 7 Seafloor Attributes
Each seafloor attribute was extracted and added into this point feature class. Therefore, the final feature class includes attributes for depth, standard deviation of depth, slope, standard deviation of slope, broad BPI, fine BPI, and terrain ruggedness.
Many of the features have a slope less than 1 degree or close to 0 degrees due to there not being significant changes in the terrain and the depth. With the point feature class containing all the required attributes the clustering could then be performed. The "Multivariate Clustering" tool was used with the point feature class and the analysis fields included each field in the point feature class attribute table (slope, depth, terrain ruggedness, etc.). This tool took about 12 hours to run to completion. When letting the tool choose the number of clusters, three clusters were concluded as ideal for this area using all seven fields. The output of this tool was another point feature class (focused on Geyer Bank) as shown below in Figure 5-5.

Figure 5-5: Clustered Point Feature Class-Geyer Bank
After looking at the output and the data, it was determined that 6 classes would also provide a good result, making each class similar within a class and different between classes. Therefore, the tool was run again inputting into the tool for 6 classes to be made.
The output provided much more interesting results and FGBNMS agreed that 6 classes was ideal for this area. The final output of Geyer Bank is shown in Figure 5-6 below.

Figure 5-6: Clustered Raster-Geyer Bank
To make the data load faster and easier to interpret by viewers, the point feature class was converted back to raster. The tool used to do this was "Point to Raster" and the cell size used was 50 since these points were 50 meters apart to avoid any loss of data using a cell size of 50 preserved all the values in the feature class. The output raster of the area is shown below in Figure 5-7. A more detailed look at the output classification along with the legend created will be discussed and displayed in Chapter 6.

Testing Clustering Tool
To test that the "Multivariate Clustering" tool was standardizing each field before running the analysis, new fields for each parameter (slope, depth, etc.) were added to the feature class with the z scores for each field. The z score was calculated by subtracting the value for each field from the mean and then dividing by the standard deviation. Next, the clustering tool was run, and the output was the same, therefore proving that the tool did standardize the values before clustering.

ROV Images as Attachments to Pop-Ups
Flower Garden Banks National Marine Sanctuary (FGBNMS) provided a CSV file and a folder with ROV images in it that had file names corresponding to a field in the CSV file. After reformatting and cleaning the file names and image names as described in Chapter 4, the CSV was added to ArcGIS Pro using the "Make XY Event Layer" tool. Since that tool only creates a temporary layer the data was exported into a new feature class into the geodatabase.
Next, attachments were enabled on the feature class using the "Enable Attachments" tool. The "Generate Attachment Match Table" tool was then used to create a table that would be used with the "Add Attachments" tool. The match table was created by referencing the folder containing the images (attachments) as well as the attribute table with the file names from the CSV file. When there was a match between the file names in the image folder and the CSV, it was added to the match table. After the match table was created, the "Add Attachments" tool was used and the feature class containing the ROV image points then had the correct attachments for each point.
Once the images were added as attachments to the feature class, the feature class was shared to ArcGIS Online. Once online and added to a web map, the attachments could not be shared as images in the pop-ups, instead they just showed a link to the image that would open in a new window. The goal of this web map was to show the ROV images directly in the pop-ups. Using a geoprocessing Python tool created by Jake Skinner and shared on GeoNet (downloaded from: https://community.esri.com/docs/DOC-7445show-attachments-in-web-map-popup?commentID=45720), the attachments were able to be added to the web map and shown in the pop-ups.

3D Ecological Marine Units
The 3D EMUs were created using a set of ArcGIS Pro tasks created by Esri and shared with this project by Kevin Butler and Keith VanGraafeiland. The first step that needed to be completed before starting the ArcGIS Pro tasks was to download the data for the area. The data were downloaded from the World Ocean Database. There were 6 physical components: salinity, dissolved oxygen, temperature, phosphate, silicate, and nitrate. After downloading the data, each physical component was saved into a separate folder. for each instrument used to gather the data, and within those folders is the actual data.

Figure 5-8: EMU Data
The next step to be completed before the tasks is to define the coordinate system. When opening ArcGIS Pro, a local scene was created, then the local coordinate system was defined. In this project the coordinate system used was WGS 1984 UTM Zone 15N.
The last step to be completed before starting the tasks is to find a bathymetry raster for the whole extent of the study area. The details about the source of the bathymetry raster used in this project can be found in Chapter 4.3.
The first task converts the NOAA World Ocean Database data into feature classes. The task parameters can be found in Figure 5-9 and the output of the task can be found in Figure 5-10. The figures below are just showing the inputs and outputs for temperature, and this task needs to be repeated for each attribute (nitrate, oxygen, phosphate, salinity, silicate and temperature).  The second task is called visualize and summarize. This task is divided into two steps and these steps must be repeated for each physical variable (temperature, salinity, etc.). The first step creates three charts: a histogram of the values, a scatterplot of the values by depth, and a graph of the observations collected over time. Examples for each of these charts is shown in Figure 5-11. The histogram is helpful in finding the mean value of the values and understanding other statistics in the dataset. The scatterplot is very helpful identifying how the values, such as temperature, vary with depth. This figure shows the deeper in the ocean the colder the temperature. It's also possible to reveal outliers that do not follow the general trend for future analysis. The final graph with the dates and collection counts is helpful in finding the dates when most of the values were collected; in the case of temperature it can be seen that most of the temperatures were collected around 1992 and 2012.
The second step of Task 2 explores the point spacing of each layer (temperature, salinity, etc.). This provides an idea of the 2D and 3D spacing between points which can be helpful information for Task 3 in building the 3D mesh. In Figure 5-12 below is the message output shown when completing this step.

Figure 5-12: Task 2 Point Spacing
This task evaluates the neighbor distances. The message describes the average 2D and 3D distances. The assumption is that the 2D distance is the horizontal distance between data collections and the 3D distance is the distance between data collections vertically.
The third task is building the 3D mesh, in this task the study area is specified and the horizontal cell size for the mesh is also specified. In this project 10 square kilometers was used because it gave the best results and allowed enough detail without crowding the space horizontally. In this task the bathymetry dataset is also used to specify the depth to be used throughout the mesh. This creates an empty mesh that is ready to be filled with the values from the physical data. In Figure 5-13 below the task interface is shown and in Figure 5-14 the output is displayed. To see the difference between the initial observations of values and the filled and interpolated 3D mesh, Figure 5-17 shows the observed temperature values above and the filled 3D mesh of the temperature values below. Since the values are initially collected over various times, locations, and depths, it is irregular and non-uniform which is why the 3D mesh needs to be created and interpolated to become uniform and create the 3D EMUs.

Figure 5-17: Observations Versus Interpolated Mesh
The fifth and final task is performing the clustering. The inputs to the task are shown in Figure 5-18 below.

Figure 5-18: Task 5 -Cluster
This task does exactly what the "Multivariate Clustering" tool does for the seafloor analysis. It identifies the optimal number of clusters using the pseudo F statistic; in this case, it found that the optimal number of clusters was 2. The output is shown below in Figure 5-19.

Figure 5-19: Task 5 Output
Along with the output clustered feature class, this task also creates a pseudo F chart which is shown below in Figure 5-20. While the chart indicates that 2 clusters is the optimal number of clusters, there is also a peak at 7 clusters. Seven clusters would produce more variation visually and it makes more sense for the area since more variation can be concluded from 7 clusters than can be concluded from 2 clusters.

Figure 5-20: Task 5 Pseudo-F Chart
Finally, what needs to be done is to symbolize the 7 output clusters, create a useful legend using the box-plots, and create a web scene. This information and how it was done as well as the outputs can be found in Chapter 6.

Summary
This chapter discussed the analyses performed in this project in detail. Everything that was created for this project was aimed at the purpose to develop a seafloor classification of the study area and localize EMUs. Those results were aimed to be displayed in various web formats such as web maps and web applications. The final outputs of the project will be discussed and displayed in Chapter 6. Developing a 2D and 3D classification of the study area provides FGBNMS with information that can be used in identifying critical areas to protect and give them more information on their sanctuary.

Chapter 6 -Results and Analysis
In this chapter, the results and the analysis along with the deliverables will be described. The goal of this project was to create a classification of the seafloor for Flower Garden Banks National Marine Sanctuary as well as test the workflow and ArcGIS Pro tasks created by Esri for generating localized EMUs. Both goals were fulfilled and will be displayed in this chapter. In section 6.1, the seafloor classification will be described, section 6.2 will discuss and display the web map that was created for FGBNMS, section 6.3 will display an overview of the the web application created and the story map, section 6.4 will discuss the output 3D localized EMUs in ArcGIS Pro and the web scene created to display the EMUs to the public, and lastly section 6.5 will provide a summary of this chapter.

Seafloor Classification Results
After running and testing the output of the "Multivariate Clustering" tool and collaborating with FGBNMS, descriptive titles were given to each cluster. Based on the box plots shown in Figure 6-1, a research specialist, Marissa Nuttall, proposed the name for each class of the seafloor.

Figure 6-1: Classification Box Plots
As we can see from the box plots, the mean value for each class/cluster is shown by the class color dot in each category. For example, the red class (1) contains the outliers for terrain ruggedness which also reflects in its name-steep slopes to basins, and accounts for its rarity throughout the output classification map.
The output classification map is shown below in Figure 6-2.

Figure 6-2: Classification Map
To get a better understanding of the classification Figure 6-3 below shows a single bank-Geyer Bank.

Figure 6-3: Seafloor Classification-Geyer Bank
Each color represents a unique classification of the seafloor. The red represents areas that have steep slopes to basins; the orange areas are areas of the seafloor that contain steep ridges; the yellow are flat areas in the lower-mesophotic zone. "Mesophotic coral ecosystems are found in tropical and subtropical regions at depths ranging from almost 100 feet to over 490 feet below the ocean's surface. The dominant communities providing structural habitat in the mesophotic zone are corals, sponges, and algae" (NOAA, n.d.). The dark green sections have gentle mounding areas as well as flat and shallow zones in the upper mesophotic zone; the light green areas have gentle basins or extended flats in the rariphotic zone (the area below the mesophotic zone); and the blue area have steep slopes to mounds.
Since the ROV images have been added as attachments they can be used to understand the classifications even more. An image from each class is shown below in Figure 6-4 from McGrail Bank.

Figure 6-4: Seafloor Classification-ROV Images McGrail Bank
Each of these images represents their descriptive class. Since these images are just attachments, they cannot show users the necessary information in an easily accessible way. To display the images to users, they needed to be displayed in a web map through pop ups as well as shown in an easy to navigate web application.

Web Map and Pop-Ups
There were two maps created for this project, one for the seafloor classification and another for the 3D EMUs. The seafloor classification web map was created to show the classification of the area (the six clusters) along with the ROV images of the area. The web map for the 3D EMUs was created to allow users to explore the EMUs and click on various areas to learn more about that location and depth; this web map will be described in section 6.4.
The web map of the seafloor classification was created by sharing the seafloor classification as polygons to a hosted feature layer on ArcGIS Online. Along with the feature layer came the ROV images as attachments. However, since ArcGIS Online does not currently allow attachments to be directly shown in the pop-up, a Python script tool created by Jake Skinner and downloaded from GeoNet (downloaded from: https://community.esri.com/docs/DOC-7445-show-attachments-in-web-mappopup?commentID=45720) was used to convert the attachments to pop-ups. The output web map has the bathymetry dataset beneath the seafloor classification so that users can toggle between the two and see the bathymetry slightly through the transparent classification. Users can click on the classification polygons and get information about the area they click, shown in Figure 6-5. Users can also click on a point containing an ROV image and get a pop-up with information about that point, displayed in Figure 6-6.

Web Application and Story Map
The first web map, the seafloor classification, was also used to create two web applications, one application for the main purpose of exploring the ROV images and another for a narrative of the analysis (Story Map).
The web application lets users easily navigate from one bank to the other to view the ROV images from that area. A screenshot from the web application is shown below in Figure 6-7.

Figure 6-7: ROV Image Exploration-Web Application
Above we can see that the web application lets the users tab through the various banks and scroll through the ROV images taken there. The users can also click on a specific point on the map and view that exact image.
The Story Map was created to display what was done in the project as well as display the web map of the seafloor classification and the web application of the ROV images. The Story Map is aimed at the public who are interested in the expansion plans of FGBNMS as well as learning more about this project. Below in Figure 6-8 is an overview of the Story Map; all the pages from the Story Map can be found in Appendix B.

Localized EMUs Result
After completing all five tasks to create localized EMUs, only two classes were created. However, as stated in Chapter 5 there were indications in the statistics that 7 classes or clusters would also be reasonable. Therefore, the final task was repeated and specified seven classes which provided much more visually significant results. One of the final outputs is shown in Figure 6-9 and the mean values for each class are shown in Figure 6-10.

Figure 6-9: 3D EMUs
The figure above shows the output 3D EMUs and each color represents a different EMU. Since EMUs are categorized by their mean values for the physical components: dissolved oxygen, temperature, salinity, silicate, nitrate, and phosphate; creating meaningful descriptive names for each class as was done for the seafloor classification could not be done. Therefore, each EMU is described based on its mean values for each of those physical components, a legend for the EMUs can be found below in Figure 6-10.

Figure 6-10: EMU Legend
In the legend the red numbers are the highest for each component and the blue are the lowest for each category. Using this legend, it can be seen that EMU seven has the highest temperature which makes intuitive sense since it can be seen that EMU seven tends to be at the top of each 3D cylinder. Higher temperature correlates to shallower ocean depths. Each physical component is used to describe the EMUs.
The 3D web scene created for this project ran into several rendering and display issues. When sharing to ArcGIS Online the symbology had to be converted to real world units which created poor rendering of the EMUs. The individual 3D polygons should be distinguishable and able to be selected individually to display information about the EMU selected, however due to the poor display the individual polygons could not be selected. In Figure 6-11 below an example of a 3D column with multiple EMUs is shown before converting to real world units (meters), and in Figure 6-12 is what the units look like after converting the units. As can be seen in the figures above it can be seen that there is a break between the red and blue EMUs. This could be due to interpolation at these locations being obtained from sampling at different times/seasons.
After sharing online, the 3D web scene did not provide the desired results as well as shown in Figure 6-13.

Summary
This chapter described the final outputs of the project. Starting with the output seafloor classification and the web maps and applications created from that. The 3D EMUs were also displayed and described in this chapter along with the web map created for the public to explore the localized EMUs of the sanctuary.

Chapter 7 -Conclusions and Future Work
This project set out to create a seafloor classification of Flower Garden Banks National Marine Sanctuary (FGBNMS) and test Esri's ArcGIS Pro tasks for generating localized Ecological Marine Units (EMUs). Since FGBNMS is working to expand its boundaries to include more vulnerable marine areas this project set out to support the sanctuary's goals and give FGBNMS more information about its area using GIS. This project fulfilled the goals and provided the sanctuary with various maps of the area along with a classification of the seafloor for its ideal expansion boundaries and provided Esri and the sanctuary with 3D physical information about the area, successfully creating localized EMUs. This chapter will discuss the conclusions made in the project and provide idea for future work that could be pursued in relation to this project.

Conclusions
The first main goal of the project was to create a seafloor classification of the area using the parameters required by the client: depth, slope, standard deviation of depth and slope, benthic position index (fine and broad), and terrain ruggedness. This goal was completed by creating an ArcGIS Pro project containing the classification as well as a web map and web application as shown and discussed in Chapter 6.
An extra addition to the project and classification was the addition of over 1000 underwater ROV images of the area, available to be explored by the public and the sanctuary.
The second main goal of the project was to generate localized EMUs using the ArcGIS Pro tasks provided by Esri. This was also completed with several flaws found in the tasks, in task 3 to find the point spacing it could not complete for temperature perhaps because of an error in the Python script being run or due to temperature having the largest amount of data in this project potentially overloading the tool. Even with that small error the EMUs could be created, and 7 unique EMUs were created for this localized area of FGBNMS.
The functional requirements were: multiple images for analysis, obtain data with a z factor, and seafloor analysis clustered for classification. All of these were successful. Multiple bathymetry rasters were used to generate a single mosaicked bathymetry dataset for the analysis; the data used for the 3D EMUs had a depth property so the 3D EMUs could be created; and the seafloor analysis and classification was completed. The nonfunctional requirements: public accessibility and high resolution were also completed successfully. The web maps and applications are public facing and the bathymetry dataset used for the analysis was 50 meters.
To understand the difference between the global and local EMUs Figure 7-1 below shows the global EMUs at the same location as the local EMUs.

Figure 7-1: Global vs. Local EMUs
As we can see in the image above where the global EMUs provided just two EMUs the local provide over 50, giving much more detail and information on the area, so this localization process can be considered a success.

Future Work
The project met the requirements of the client, however there are several things that could be done to improve the project. The first improvement would be to use higher resolution bathymetry data. For this project the bathymetry was resampled to 50 meters, due to the limitations of the processing device used in the project. However, using higher resolution data, perhaps 10 meters, would be valuable in identifying even more features in the study area.
The next improvement would be to perform the analysis for a larger area. In this project the study area was clipped to small banks that were not connected into one large raster. To improve this project and perhaps identify larger differences along the study area a large raster covering the entire study area would be beneficial. This would also require high processing power to run the "Multivariate Clustering" tool in a timely manner.
The third improvement would be to use a high-resolution bathymetry layer for the 3D EMUs to increase the accuracy of the depth for the 3D mesh and the output EMUs. In this project the bathymetry raster had a resolution of approximately 1 km, so using anything higher than that would be an improvement, a resolution of less than 50 meters is suggested.
The fourth improvement would be for users to be able to set limits on the nearest neighbor distances when interpolating the physical components to the 3D mesh, the user could choose to interpolate in 2D, 3D, or both. The fifth improvement would be for the users to be able to interpolate the data based on the season. Currently the interpolation is averaging all the data collected no matter the date, which might be leading to problems with the legitimacy of the interpolation.
The sixth and final improvement would be to perform the seafloor classification for the individual banks, not over the entire study area. This is because when performing the classification over the entire area there may be a loss in detail for the individual banks. If the individual banks were not mosaicked into a single dataset, each of the bathymetry datasets could be analyzed and classified. This could potentially lead to a more accurate classification of the area with a larger number of classes appropriate for the specific banks.
The next three suggestions are ideas for future projects. The first suggestion would be for future marine sanctuaries around the world to repeat this project. Using this project as a guideline and step by step walkthrough would allow future sanctuaries to learn more about their area and create valuable classifications of their area for future research and education.
The second future project suggestion would be to combine the physical components and the seafloor attributes. Currently the EMUs and the seafloor classification are separate projects. Combining these would create EMUs that provide more comprehensive information about marine areas. Creating clusters and then descriptive names of units that include seafloor and physical components would be highly valuable. Future EMUs could potentially have information like high salinity, steep slope, low temperature.
The final future work suggestion is to create a web application for exploring the 3D EMUs that allows users to identify important features and interact with the map. For example, there could be a filter containing marine species that allows users to only see the EMUs and areas that have those marine species. https://dusk.geo.orst.edu/djl/samoa/BTM_Exercise.pdf