Seismic Reflection, Geometrics multi-channel streamer common midpoint navigation, USGS field activity 2017-003-FA, Mississippi River Delta front offshore of southeastern Louisiana (CSV text and Esri point shapefile, GCS WGS 84)

A SIOSEIS (version 2015.3.1) seismic processing software script (sio_segd2segy) was used to read Geometrics SEG-D formatted (SIOSEIS process SEGDDIN) traces and write them (SIOSEIS process DISKOX) to SEG-Y Rev. 1 format (IEEE floating point) for each line.
This process step and all subsequent process steps were conducted by the same person - Wayne Baldwin.

OpenCPS (version 3.3.0) seismic processing software was used to perform the following series of processing flows:
1. read_segy.flow - SegyTapeRead read the traces. HeaderMath and UTMLatLong were used to convert the source lat/lon positions from seconds of arc to decimal degrees, project them to UTM Zone 16N WGS 84 meters, and write each to new header words (NRP_LAT, NRP_LON, NRP_X, and NRP_Y). DBWrite wrote the UTM positions for the first channel of each FFID to an internal OpenCPS database table. Finally, Output wrote the traces to a new file "*.sht-raw.seis" in the internal OpenCPS format.
2. geom.flow - Input read the "*.sht-raw.seis" file and sorted the traces to FFID/CHANNEL. The custom Python module ShotlineLayback (developed by Nathan Miller of USGS-WHCMSC) was used to define the source shot and streamer geometry based on measured horizontal offsets from the DGPS antenna to the source (-17.35 or -22.35) and the centers of the first (1) and last (32) channel groups (-73.43/-112.8) of the active streamer section. The algorithm interpolated a sail line from the source shot positions (NRP_X and NRP_Y), then computed layback positions for the source shot and 32 channel groups for each FFID by translating them back along the sail line by their respective measured offsets. Midpoint positions along the sail line were also computed for each shot/receiver pair, allowing the traces to be binned by common midpoints (CMPs) spaced evenly (by 0.781 m) along the sail line. Output wrote the traces to a new file "*.sht-raw_geom.seis" in which the trace header words SRC_X, SRC_Y, REC_X, REC_Y, MPT_X, MPT_Y, BIN_X, BIN_Y, and OFFSET were populated to reflect the layback Source X and Y, layback Receiver X and Y, layback Source/Receiver Midpoint X and Y, and CMP BIN X and Y positions, as well as the offset value (computed by sqrt((REC_X - SRC_X) * (REC_X - SRC_X) + (REC_Y - SRC_Y) * (REC_Y - SRC_Y))) for each trace in the resulting CMPs. *A limitation of the ShotlineLayback module is the inability to layback source shot/receiver locations that would have occurred prior to the start of the interpolated sail line (i.e. it does not project the sail line backward). This results in erroneous computation of those shot/receiver locations and their respective midpoints, making them unable to be stacked by bin location in the subsequent step. Consequently, up to 40 dead traces exist at the start of each common midpoint stack profile.*
3. brute_stack.flow - Input read the "*.sht-raw_geom.seis" file and sorted the traces to CMP/OFFSET. The Python module Butterworth applied an Obspy version (modified from Scipy version 0.17.1) of a zero-phase, four corner Butterworth bandpass filter to the traces, between 450 and 1800 Hz for data shot with the S-Boom, or between 350 and 1400 Hz for those shot with the mini sparker. NormalMoveout applied a travel time correction to each trace based on offset and a constant velocity of 1530 m/s (water column sound speed), as well as a 60 percent stretch mute with a 30 ms taper. Stack summed the traces within each CMP, computed the average amplitude for each trace sample, and wrote the computed samples to a single CMP trace, as well as averaging the Midpoint positions of the input traces and updating the header words MPT_X and MPT_Y with the resulting averaged values. Output wrote the stacked traces to a new file "*.stk-brute.seis" in the internal OpenCPS format.
4. geom2geojson.flow - Input read the "*.stk-brute.seis" file and sorted the traces to CMP. The custom Python module Header2GeoJSON (developed by Nathan Miller of USGS-WHCMSC) exported the stacked trace navigation (using coordinates from the BIN_X and BIN_Y headers) as point features in the GeoJSON format. Attributes for CMP, BIN_X, BIN_Y, linename, surveyid, vehicleid, and deviceid were also included in the GeoJSON output.

A batch shell script, MCSGeojson2SQL, was executed on the output GeoJSON file from the previous step. First, ogr2ogr (version 2.1.1) was used to import the GeoJSON formatted CMP navigation point geometries into a Spatialite (version 4.3.0) enabled SQLite (version 3.21.0) database table, and in the process add fields for the coordinates converted from UTM Zone 16N WGS 84 meters to GCS WGS 84 decimal degrees. Second, GJpts2lines.py created two new database tables, one containing line geometries generated from the CMP point navigation (with sort order defined by the linename and CMP fields), and another containing CMP navigation filtered to maintain the first and last CMPs, and CMPs at multiples of 100.

The MCS first, last, and multiple of 100 CMP features were added (Add Data) into ArcGIS desktop (version 10.3.1) from the SQLite database, and then exported (Right click on database feature class > Data > Export Data) to the new Esri point shapefile 2017-003-FA_MCS_100cmp.

Added keywords section with USGS persistent identifier as theme keyword.