Statement_of_Work_Final.docx

Statement of Work

INTRODUCTION

The purpose of this SON is to develop a stand-alone version of the Digital Shoreline Analysis System (DSAS) software that operates outside of proprietary software to be fully open access. DSAS has been a central component of developing the U.S. Geological Survey’s national database of historical shoreline positions and rates of change. It is the tool used to compute a robust suite of regression rates in a standardized and easily repeatable method that can be executed on large volumes of data collected at a national scale. The DSAS software was designed to facilitate the shoreline change-calculation process and to provide rate-of-change information and the statistical data necessary to establish the reliability of the calculated results. The tool has a global user base and national and state governments worldwide have used DSAS in support of resource management and critical coastal decision-making.

BACKGROUND

The DSAS software was originally developed in the early 1990’s and has undergone continuous refinement. DSAS version 1.0 (1992) was written in the C and awk programming languages for use with the MapGrafix and ArcInfo Geographic Information Systems. DSAS version 2.0 was written in Avenue for ArcView 3.x. DSAS version 3.x (ArcGIS 9), DSAS version 4.2 (ArcGIS 9) and DSAS version 4.3.4730 (ArcGIS 10) were written in VB.NET using the ArcObjects Object Library for ArcGIS. Each version of DSAS includes many improvements that are described in the documentation.

The Digital Shoreline Analysis System project page was accessed 277,235 times between April 2021 and May 2022. The Github repository was accessed 15,500 times with 12,500 downloads. The basic workflow video has been viewed 5.2k times, and as of October 2022 the DSAS v5+ software has been cited in over 230 scientific publications. The current version of DSAS (version 5.1) was released in November 2021 and is publicly available as an Esri add-in file. While the DSAS software tool is freely-available, it works within proprietary software.

SCOPE

The objective of this SON is to implement a new DSAS from scratch with functionality described in the technical requirements as well as a fixed set of essential general feature editing tools such as moving, reshaping, buffering, splitting. General data preparation (except any specifically called out in the technical requirements) are performed outside of standalone DSAS, inside the user's choice of GIS environment.

TECHNICAL REQUIREMENTS

1. DSAS phase I

a. Load shoreline data

b. Load or create baseline data (mid, on or offshore),

c. Provide editing tools to:

i. Add attributes to shoreline and baseline features.

ii. Ensure baseline orientation/flow is correct

d. Set Default Parameters

i. Select baseline/shorelines

ii. Select seaward or landward intersection.

e. Cast transects.

i. Clip to shoreline option.

ii. Allow user to set search distance and smoothing distance? SET limits and make auto 5X transect spacing.

iii. Output: transects w/metadata

f. Edit transects

i. Must have base map for reference

g. Find intersection of transects with shorelines (and allow user to export these)

i. Output: intersect points w/metadata

h. Calculate rates

i. Output: rate transects w/metadata

i. Make summary doc and metadata file

i. Output: summary report

Overview of GIS-like tools for Phase 1:

1. Create new and edit existing features (shoreline, baseline or transect)

2. Add and populate attributes (like things needed by DSAS, ‘group’ or ‘Year_’ for example)

3. Display a reference base map of imagery under data for review.

4. Connect the attribute table to map view – highlighted features in table show up in map.

5. Basic symbology (line style, color) based on feature attributes, with some sort of “flow” symbology for the baseline settings.

2. DSAS phase II

a. Import transects from older versions of DSAS/datatypes

b. Attribute wizard (easily allow user to select existing data columns for analysis).

c. Allow adjustable search distance and smoothing distance per baseline segment.

d. Nice data viz of rates

e. Bias (important to also provide bias shifted shoreline intersections)

f. Shoreline forecasting

g. Advanced transect editing

a. Clip to SCE

b. Extend transects

h. Allow for update/recalculation of summary report stats – in the case where transects have been removed from the rate transect file.

i. Updated log file output with version numbers, and detailed error messages that provide context for diagnostics and troubleshooting user issues.

j. Allow user to select range of dates for analysis without highlighting or requiring the creation of a redundant data file. For example, if you have a compiled dataset that includes data from 1900-2018, you could ask DSAS to do the work of picking the shorelines – from whatever time range you would like.

i. Adding a “YEAR” column as a requirement might be helpful

3. DSAS phase III

a. Data driven transects

b. Satellite shorelines, need to process hundreds of shoreline intersections at a single transect

c. Store beach slope (point value) with shoreline position (line value). This is a point/line issue, not a DSAS issue but it would be great to find a solution. People want/need beach slope and we have it.

d. Allow DSAS to calculate change without dates. (Obviously rate information cannot be provided, but distances can) examples:

i. if we have a shoreline and a dune toe from the SAME day, we cannot now calculate the distance between the two features

ii. with satellite shorelines it is possible to get two shorelines for the same day

iii. We also have had users want to analyze data that HAS no date – so a simple net shoreline movement without the need to enter “fake” dates (which BTW is what we do for beach width or other features with the same date).

e. Provide some type of query option, “What is the most erosional shoreline after 2010?”, “What is the end point rate of shoreline change from Aug 2010 to Aug 2011?” “Which time period is more variable, 2000-2010 or 2010-2020?” (These questions could be answered if DSAS could provide analysis across a date range over which to calculate all its rates. Perhaps include standard deviation or RMSE.) This might also make calculating short-term rates easier.

f. Other advancements/features that surface in development of phase 1 and 2

CONTRACTOR PERFORMANCE

The Contractor’s performance shall be measured in the following manner:

Phase 1 Phase 1A: (2 months after receipt of order) Scoping and prioritization Diagram requirements Phase 1B: (6-8 months after phase 1A) Development/iteration Phase 1C deliverable: (2 months after phase 1B) Documentation Production version, publication-ready

Phase 2 Phase 2A: (2 months after phase 1 deliverables) Scoping and prioritization Diagram requirements Phase 2B: (6-8 months after phase 2a) Development/iteration Phase 2C deliverable: (2 months after phase 2B) Documentation Production version, publication-ready

Phase 3:

Phase 3A: (2 months after phase 2 deliverable) Scoping and prioritization Diagram requirements Phase 3B: (6-8 months after phase 3a) Development/iteration Phase 3C deliverable: (2 months after phase 3B)) Documentation Production version, publication-ready

Iterative testing and feedback will occur throughout the development cycle and a complete integrated analysis and test combining all functionality will be performed on production version to demonstrate that the contractor has provided USGS with accepted software functionality as specified.