Barrier island geomorphology and seabeach amaranth metrics at 50-m alongshore transects, and 5-m cross-shore points for 2008 — Assateague Island, MD and VA.

Process overview: These data provide barrier island characteristics along Assateague Island National Seashore for points distributed at 5 m intervals along cross-shore transects. The point dataset includes values extracted for the entire transect ('ASIS_transects.shp') and values extracted at each individual point (final file, 'asis_2008pts.csv'). The following process steps describe the appending of data to transects, the conversion of transects to points, and the appending of additional data to the point dataset. All processing was completed by either Benjamin T. Gutierrez or Aaron Turecek.

Step 1) Extension of existing transect data (NASC transects) to cover the full width of Assateague Island, resulting in a new transect shapefile (ASIS_transects.shp). All processing was done in ArcMap ver. 9.3.
'NASC transects' (Himmelstoss and others 2010) were extended 2000 m inland to cover the width of the barrier, starting at the startlon startlat coordinates (or the landward end vertex of each transect), and using the attribute “Azimuth” with the “Bearing Distance To Line” function ( ArcToolbox >> Data Management Tools >> Features >> Bearing Distance to Line). The field value ‘TRANSORDER’ is retained from the source data to serve as a transect identifier and to provide a reference to the source data. The extension of the transects to span the full island width results in some overlapping transects. In addition, the data was projected (ArcToolbox >> Data Management Tools >> Projections and Transformations >> Project) from WGS84 to UTM Zone 18N NAD83.

Step 2) Extraction of six shoreline morphology elements from existing tabular (Shoreline morphology) and raster (2008 DEM) data to interim datasets which will be used in subsequent process steps. All processing was completed in MATLAB ver. 2009. MHW shoreline positions, beach slope ('sh_slope'), foredune crest positions and elevation ('crest_dh_z'), dune toe positions and elevations were extracted from Doran and others (2017; dataset 08LTS05 dataset). Beach width ('beach_w') and beach height ('beach_h') are calculated based on the difference in position between two points: the position of the estimated mean lower-low water (MLLW) shoreline along a transect (ASIS_transects.shp); and the dune toe position (Doran and others, 2017). The MLLW shoreline was estimated by using the beach slope ('sh_slope') to extrapolate the MLLW elevation intersect (-0.76 m NAVD88 at the NOAA Tide Gauge # 8570283, Ocean City, Maryland, Tidal datum analysis period: 08/01/2002 - 07/31/2008). To do this, the horizontal distance between the MHW shoreline intersect and the MLLW intersect were estimated by dividing the vertical offset between the two (0.34 m and -0.76 m) by the tangent of the beach slope. The resulting horizontal distance value, the transect azimuth (using the ‘distance.m’ function), and the MHW shoreline intersect was used in the ‘reckon.m’ function to extrapolate the MLLW shoreline position and determine the MLLW shoreline coordinates. The beach width ('beach_w') was then calculated as the euclidean distance between the MHW shoreline coordinates and the MLLW coordinates in the ‘distance.m’ function in MATLAB. In some cases, the dune toe is not present in the dataset. Where these values were missing, subject matter experts on the research team determined that the foredune dune crest position should be inserted as a substitute if available and if its elevation is less than or equal to 2.0 m (NAVD88). If no dune features are encountered within 10 m of a transect, foredune crest height, dune toe elevation, beach height and beach width are given a NoData value of -99999. The maximum elevation along a transect ('max_z') was added using MATLAB. Elevation referenced to NAVD88. Derived from the corresponding pixel in the 5-m DEM. The maximum elevation for each transect was calculated in MATLAB and appended to the cells corresponding to each transect.

Step 3) Append morphology from Step 2 to entire cross shore transects ('ASIS_transects.shp') resulting in a new transect output: 'ASIS_trans2_morphology.shp'. This processing was completed in ArcMap ver. 9.3. 'ASIS_transects.shp' is populated with the linear regression shoreline change rate values ‘LRR’ from the original 'NASC transects', and morphology from the previous step: dune crest height (‘crest_dh_z’), beach slope (‘sh_slope’), beach width (‘beach_w’) and beach height (‘beach_h’). Values are populated for each transect through a series of manual steps using ArcToolbox (ver. 9.3). The “Spatial Join” function (ArcToolbox >> Analysis Tools >> Spatial Join) was used to match these variables to each transect. If any of the variables did not occur within 10 m of the transect, null values were returned for that variable and later replaced with NoData values used for this dataset (-99999).

Step 4) Using an existing barrier island boundary ('ASIS Boundary') and the 'MHW shoreline positions' data, two new shoreline files were created: an ocean facing shoreline ('MHW shoreline feature'), and a polygon that encompasses the full shoreline extent ('full shoreline polygon'). All processing was completed in ArcMap ver. 9.3.
Some terminology before processing: The MHW shoreline is the oceanside shoreline defined by the MHW contour line adjacent to the open ocean, and bounded (north and south) by either tidal inlet or the study area extent. In some cases, we may use MHW shoreline interchangeably with oceanside shoreline. The back-barrier shoreline refers to the boundary between land and water on the inland side of the island. The ‘full shoreline polygon’ outlines the boundary between land and water for the entire study area from the oceanside shoreline (MHW) to the back-barrier shoreline.
The back-barrier shoreline was obtained from a National Park Service data layer (‘ASIS Boundary’), that contained a high resolution back-barrier shoreline (digitized from 2003 orthophotos). The back-barrier shoreline was manually clipped from this polygon at the inlet locations. The ‘MHW shoreline points’ (which occur every 10 m along the ocean facing shore) were converted to a polyline using the “Points To Line” function (ArcToolbox >> Data Management Tools >> Features >> Points to Line). The two shorelines, MHW and back-barrier, were merged to form a single polygon (ArcToolbox >> Data Management Tools >> General >> Merge). Gaps occurring at Ocean City Inlet to the north and Chincoteague Inlet to the south, were connected by manually drawing the shoreline using 2008 digital orthophotos as a guide (Source data: 2008 Ortho). The resulting polygon was saved as the ‘full shoreline polygon’

Step 5) Calculated the distance from each transect to Ocean City Inlet (‘dist2OCI’), then determined the distance from each transect to the closest inlet (‘Dist2Inlet’). Assateague Island is bounded by Ocean City Inlet to the north, and Chincoteague Inlet to the south. Values appended to fields in new transect shapefile ('ASIS_trans3_inlets.shp').
The distance to Ocean City ('dist2OCI’) is computed in ArcMap ver. 9.3 as the alongshore distance of each transect location from Ocean City Inlet. The calculated distances include changes in the path of the oceanside shoreline rather than just a straight-line distance between each transect and the inlet and reflects sediment transport pathways. The MHW shoreline feature and the ‘Create Routes’ tool (ArcToolbox >> Linear Referencing Tools >> Create Routes) were used to calculate distance values. Locate Features Along Routes (ArcToolbox >> Linear Referencing Tools >> Create Routes >> Locate Features Along Routes) was used to orient the direction of the calculation by specifying starting coordinates at Ocean City Inlet. ‘Join Field’ and ‘Calculate Field’ in the Data Management Tools were used to merge the routes with ‘TRANSORDER’ and calculate distances along the routes respectively.
Distance to nearest inlet ('dist2inlet') was calculated in Matlab using the ‘dist2OCI’ field from the previous step by identifying the mid-point distance along Assateague Island and subtracting that value from values greater than the mid-point value.

Step 6) Calculated island width from the ‘full shoreline polygon’ (created in Process Step 4), appended fields ('WidthLand', and 'WidthFull') and clipped transects ('ASIS_trans3_inlets') to shoreline extent, resulting in a new file 'ASIS_trans4_width.shp'. All processing was completed in ArcMap ver. 9.3. Barrier island width ('WidthLand') is calculated as the width between the back-barrier and oceanside shorelines along the transect using the 'full shoreline polygon'. 'WidthLand' does not include where transects cross waterways that intersect them. We also measure the shore-to-shore extent of the island ('WidthFull'), which includes space occupied by waterways. These are calculated as follows: (1) Clip the transects to the 'full shoreline polygon' (ArcToolbox >> Analysis Tools >> Clip); (2) for 'WidthLand', get the length of the multipart line segment from "SHAPE_Length" feature class attribute using ‘Calculate Field’ (ArcToolbox >> Data Management Tools >> Fields >> Calculate Field), which will include only the remaining portions of the transect; (3) for 'WidthFull', use ‘FeatureVerticesToPoints’ (ArcToolbox >> Data Management Tools >> Features >> Feature Vertices to Points) to obtain the first and last intersects with the island boundary polygon. Following this ‘PointsToLine’ (ArcToolbox >> Data Management Tools >> Features >> Points to Line) was used to construct a line segment between these vertices. ‘Calculate Field’ (ArcToolbox >> Data Management Tools >> Fields >> Calculate Field) was then used calculate the length of each transect using these line segments. Island width field values were appended to a new shapefile, 'ASIS_trans4_width.shp'.

Step 7) Append metric for human modification to 'ASIS_trans4_width.shp' from previous step, with a new output created 'ASIS_trans5_human.shp'. Processing was completed in MATLAB ver. 2009.
Human modification polygons were manually assigned coded values(in MATLAB ver. 2009) for human modifications and management activities undertaken on Assateague Island, by comparing the transect positions to ancillary datasets (viewed in ArcGIS 9.3). These datasets included the inventory of geomorphic environments (Morton and others, 2008; Krantz and others, 2009), available aerial imagery (2008 Orthos), and unpublished NPS management reports for Assateague Island (ASIS sediment). The field value ‘Human_mod’ was appended to existing data in 'ASIS_trans4_width.shp'. Each transect was assigned a value based on the intersection with the source data referenced above and these data. Six values were defined for the field: no modification or management activity (value = 1); constructed features present (value = 2), occasional modification (value = 3), construction plus occasional restoration (value = 4), ongoing restoration (value = 5), and ongoing restoration plus construction (value = 6).

Step 8) Modified ASIS transects data from all previous steps ('ASIS_trans5_human') was converted to a point dataset within ArcMap ver. 9.3. All existing transect attributes from previous steps are preserved and carried over to the new point shapefile ('ASIS_trans_points.shp').
This dataset represents 5 m sampling of the land along each shore-normal transect. The point file is created from the modified transect file ‘ASIS_trans5_human.shp’ as follows: 1) Convert transects to individual segments using ‘Multipart to Single Part’ (ArcToolbox >> Data Management Tools >> Features >> Multipart to Singlepart), 2) split transects into segments every 5 m using XTools Pro function ‘Split Polylines’, 3) convert segments to center points using ‘Feature to Point’ (ArcToolbox >> Data Management Tools >> Features >> Feature to Point), 4) add x and y coordinates (seg_x, seg_y; UTM zone 18N NAD 83) for each center point (ArcToolbox >> Data Management Tools >> Features >> Add XY Coordinates).

Step 9) The following fields were calculated within ArcGIS (ver. 9.3): 'pID', 'dist2MHW', dist2MHWBay, ptZ, ptSlp, VegRech, HabNPS. Results were appended to the transect point data from the previous step (ASIS_trans_points.shp) and were saved as a new point file ‘ASIS_trans_pts2.shp’. Point identifier: We populate the point shapefile from the previous step (‘ASIS_trans_points.shp’) with a numerical point identifier ('pID') Values were assigned after sorting by order along oceanside shoreline (‘TRANSORDER’) then by distance from the oceanside shoreline (‘dist2MHW’). Distance fields: ‘dist2MHW’ and ‘dist2MHWBay’ measure the distance of the transect point from the shoreline adjacent to the open ocean and the shoreline adjacent to the back-barrier waterbody respectively. 'dist2MHW’ is calculated using ‘Calculate Field’ (ArcToolbox >> Data Management Tools >> Fields >> Calculate Field) to calculate a distance for each point to the ‘MHW shoreline feature’. ‘dist2MHWBay’ is calculated by subtracting the ‘dist2MHW’ value from the field 'WidthLand'. A NoData value for ‘WidthLand’ prevents the calculation of dist2MHWBay. Elevation and slope fields: 'ptZ' and 'ptSlp' are the mean elevation (NAVD88) and mean slope of elevations within the 5 m cells centered at each seg_x and seg_y coordinate. We used the 5 m DEM (2008 DEM) to generate an elevation and a slope surface (ArcToolbox >> 3D Analyst Tools >> Raster Surface >> Slope). The elevation and slope values are assigned to the points using the Extract Multi Values to Points tool (ArcToolbox >> Spatial Analyst Tools >> Extraction >> Extract Multi Values to Points). VegRech: This field was derived from Masterson and others (2013; ASIS recharge) which was assembled using a 1993 vegetation dataset for the Maryland portion of Assateague Island. The ‘Spatial Join’ function in the Analysis Tools of ArcToolbox was used to sample the ‘VegRech’ layer to each coordinate (seg_x, seg_y). The layer consisted of four landcover categories: 111 = wetland, 222 = shrubland or forest, 333 = sandy, and 444 = unknown. HabNPS: This field is based on piping plover habitat maps (ASIS Habitat) that approximate vegetation zones on the northern 9.5 km of Assateague Island. The values of this dataset consist of a map consisting of five vegetation cover categories: 11 = water, 22 = sparse, 33 = herbaceous, 44 = dense herbaceous, and 55 = forest or shrubland. The Extract Multi Values to Points tool in Spatial Analyst of ArcToolbox was used to sample the ‘asis_pipl_habitat2008.tif’ layer to each coordinate (seg_x, seg_y).

Step 10) Additional metrics were calculated to adjust certain fields to MHW. The following fields (described in detail below) were added within MATLAB (ver. 2009) to the point shapefile from the previous step (‘ASIS_trans_pts2.shp’): dhz_mhw, ptZmhw, max_z_mhw, mean_Z_mhw. The resulting file was output as a .csv point dataset, ‘ASIS_trans_pts3.csv’.
The existing attributes ‘crest_dh_z’, ‘ptZ’, and ‘max_z’ elevations were adjusted to the local MHW datum by subtracting 0.34 m. This value was developed by Weber and others (2005) and represents local/regional differences of MHW elevation from NAVD88. These new fields were labeled ‘dhz_mhw’ for the adjusted foredune crest elevation, ‘ptZmhw’ for the elevation, and ‘max_z_mhw’ for the maximum elevation along the corresponding transect.
Mean barrier elevation (‘mean_Z_mhw’) was calculated using ‘ptZmhw’ for only those transects having less than 20 percent missing values within the 5-m points. Locations not satisfying this criterion are assigned a fill value of -99999.

Step 11) Additional fields were recalculated for consistency with published data from Sturdivant and others (2019). The following fields (described in detail below) were added within MATLAB (ver. 2018) to the point file from the previous step (‘ASIS_trans_pts3.csv’): 'DZnew', 'distDHnew', 'uBW', 'uBH' and 'Human_modV2'. The resulting file was output as a .csv point dataset, ‘ASIS_trans_pts4.csv’.
In order to sample the data consistently with data from Sturdivant and others (2019), adjustments were made to several variables in the 2008 dataset and appended as additional fields using Matlab. The original data extraction sampled shoreline metrics within 10 m of a transect. Sturdivant and others (2019) conducted this sampling with a wider sampling window of 25 m on either side of a transect. Updated dune metrics and resulting beach width and height calculations were redone to ensure that data used in this study were sampled consistently with the updated methods. Consequently, foredune crest height (’dhz_mhw’) and corresponding locations were resampled by identifying the nearest foredune crest height and dune toe locations within 25 m for each transect from the Doran and others (2017) dataset. In addition, the threshold of 2 m was increased to 2.5 m to insert dune crest elevations where dune toe elevations and positions were not available.
The new fields were labelled ‘DHZnew’ for the foredune crest elevation. Distance to foredune crest (‘distDHnew’) was again calculated as the distance from the dune toe to the MHW shoreline. Upper beach width (‘uBW’) was calculated for each transect using the dune toe and MHW locations described previously. This represents the horizontal distance from the dune to the mean high-water shoreline. Beach height (uBH) was calculated as the vertical difference between the dune toe elevation and the MHW shoreline. This represents a difference from the original calculation of beach_w and beach_h, which were referenced to the MLLW shoreline.

Step 12) The original field ‘human_mod’ was reclassified using fields as defined by Sturdivant and others (2019), and the output saved to a new field ‘human_modV2’, and saved to a new output transect point file ‘ASIS_trans_pts4.csv’
Human_modV2: The original Human_mod field (ASIS_trans_pts3.csv) was redefined by combining the Nourishment, Development, and Construction fields defined for Sturdivant and others (2019) into a single category consistent with the original definitions in Human_mod. These values were defined as 0 = no development (111), no nourishment (111), and no construction (111); 1 = light development (222), no nourishment (111), and no construction (111); 2 = moderate development (333), no nourishment (111), and no construction (111); 3 = no development (111) and either nourishment or construction >111; 4 = light development (222) and either nourishment or construction >111; 5 = moderate development (333) and either nourishment or construction >111; 6 = no development (111), frequent nourishment (333), and no construction (111); 7 = light development (222), frequent nourishment (333), and no construction (111); 8 = moderate development (333), frequent nourishment (333). In these definitions, nourishment refers to any activity involving the placement of sand on the beach or in the surf zone to offset long-term erosion. The results were saved to a new field ‘Human_modV2’ in the output file ‘ASIS_trans_pts5.csv’

Step 13) Three additional parameters were included with these data to capture the presence of seabeach amaranth: 'd_trans07', 'nd30', and 'plant_present'. Field collected seabeach amaranth (Amaranthus pumilus) data from ‘Seabeach Amaranth Field Data’ was appended to the original 'ASIS_transects' data using MATLAB (ver. 2009). Results were appended to the transect points file from previous steps 'ASIS_trans_pts5.csv', and exported to the final output file ‘asis2008_pts.csv’
‘d_trans07’ is the absolute value of the minimum distance to the nearest plant from the previous year from a transect. This was processed in Matlab by calculating the Euclidean distance of each plant location from the previous year to the transect. For these data from 2008, plant locations from 2007 were used. The absolute value of the minimum Euclidean distance from the nearest plant was then calculated.
‘nd30’ is the number of plants occurring within 30 m of a transect. This was computed in Matlab by calculating the Euclidean distance of each plant location from the previous year to the transect. For these data from 2008, plant locations from 2007 were used. Transects occurring within 30 m of a plant location were then recorded. Repeating transect values were then identified and counted resulting in the number of plants occurring within 30 m of a transect.
‘plant_present’ is a presence-absence field that specifies whether there was a seabeach amaranth plant located withing 30 m of a transect. ‘plant_present’ was calculated in Matlab by calculating the Euclidean distance of each plant location to the transect. Transects matched with plants were then recorded and a list of unique transect values was retained. Corresponding transects were then coded with a ‘1’. The remaining transects, where no plants were located within 30 m, where then coded with a ‘0’. Data from transects appended to transect points using a spatial join.

An author name in a source citation was misspelled and fixed. (20230510)