Point Shapefile of Interpreted Base of Mud Isopach Based on Seismic-Reflection Profiles Collected in Apalachicola Bay in 2006 from U.S. Geological Survey Cruise 06001 (BASEMUD_GEOG.SHP, Geographic, WGS84)

Two different seismic systems acquired data in Apalachicola Bay in 2006. One system was the EdgeTech FSSB 424 (4-24kHz) aboard the R/V Rafael. These data were acquired as SEG-Y files using SBLogger. The second seismic system was also an EdgeTech FSSB 424 chirp system mounted on the USGS autonomous vehicle IRIS. These data were acquired with JSTAR in JSF format and converted to SEG-Y format using a C-program written by Tom O'Brien (USGS, Woods Hole). These SEG-Y files were then converted from IEEE format to IBM floating point using SIOSEIS, and the shots were renumbered starting at one. With initial preparation work on the seismic data complete, these data and navigation needed to be loaded into Landmark SeisWorks software for interpretation. In order to load the seismic data and navigation into Landmark SeisWorks software the navigation needed to be extracted from the header of the seismic data. An AWK script was used to extract the navigation from the seismic data headers and export in UTM, Zone 16 eastings and northings, rounded to the nearest meter.

Once the navigation is extracted from the seismic data, this navigation has to be loaded into the interpretation software. In this case, that's Landmark SeisWorks version R2003. The navigation is loaded using Data - Management - Seismic Data Manager. A new survey is created (06001 for the Rafael data, asv06 for the IRIS data). Then, Data - Import - Seismic Data Loader and point to the navigation text file. When loading the navigation, use a decimation of 0, use first shot point if duplicates are found, and overwrite data in target project if necessary. A decimation of zero was used because the IRIS navigation had already been decimated to take every 5th record from the complete navigation extracted from the headers of the IRIS seismics. The Rafael data did not need decimation. The Rafael data had a 1/4 second fire rate while the IRIS data fired at approximately 15 shots per second. Once the navigation is loaded and verified, then the actual seismic data can be loaded. To do this, use PostStack Data Loader. There was a small issue in working with seismic data in SeisWorks where it's better to have all the seismic profiles at the same sample rate. It's a display issue in the interpretation phase where opening a profile in a window with a different sample rate than the previously loaded profile doesn't always refresh the window properly. The result is an incorrect interpretation - the interpreted line falls in the wrong spot vertically. The seismic data were resampled to the same sample rate to eliminate this problem. The Rafael acquired data used to different sample rates: 40 microseconds and 80 microseconds. The Rafael seismics were all resampled to 40 microseconds in the PostStack data loader. Additionally, the lines had an automatic 8-bit scaling applied to each profile. The IRIS seismic lines were acquired with two sample rates - 23 microseconds and 46 microseconds. All of the lines were resampled to a 40 microsecond sampling interval in PostStack data loader and had an automatic 8-bit scaling applied to each profile. With the seismic data now loaded, the project has to be modified so these changes are reflected in the surveys and the data can be interpreted.

The base of mud surface separates the late Holocene estuarine deposits into two units based on changes in the depositional history of the bay. The older unit is characterized by closely-spaced weak-amplitude reflectors that locally are capped by a single high-amplitude flat-lying reflector. The younger unit is acoustically transparent, buries the weak-amplitude unit and onlaps and in places completely buries the high-amplitude reflectors. The unit is best represented as an isopach due to the nature of the surface (sometimes very thin but present and in other places uninterpretable from the seismics). The base of mud horizon in some areas of the seismics pinches out and other areas it couldn't be interpreted. These areas that were uninterpretable have to be accounted for, otherwise when this horizon is merged with the sea floor to generate the isopach map - the non-interpretable areas would appear as pinch outs. The interpreter (Dave Twichell) actually generated several base of mud horizons in Landmark - and all of these horizons had to be merged together. Landmark only allows two horizons to be merged at a time, so these individual horizons were merged in a series of process steps. The obvious data were in the horizon "base_of mud". These interpreted lines were merged with base_of_mud-poor_data to form basemud_mrg1. Then basemud_mrg1 was merged with base_of_oyster-top _of_delta_sand to form basemud_mrg2. In order to distinguish where mud pinched out and where the mud just couldn't be seen to interpret, a new horizon "mud_cant_interpret" was created. This horizon will be in the water column - exactly where it's located doesn't matter as long as it's above the sea floor. The idea is that this horizon can be merged with the mud prior to merging the mud horizon with the sea floor. Then when the sea floor horizon is subtracted from the mud horizon to generate the isopach unit the negative values will be obvious and can be deleted. So the next merge is to merge basemud_mrg2 with mud_cant _interpret to form basemud_mrg4. Then to generate a complete unit over the study area, merge basemud_mrg4 with sea floor to create basemud_mrg5. And finally, the mud isopach data is placed in basemud_mrg5_minus_sf by basemud_mrg5 minus seafloor. The interpretation of the various surfaces was done by Dave Twichell while the merging of the interpreted layers was done by VeeAnn Cross.

Once the interpretation is complete, the unit is exported as a text file with the line name, easting, northing, and the depth to the unit - in this case that depth represents an isopach thickness - in milliseconds (two-way travel time). This process step and all subsequent process steps were overseen by the same person - VeeAnn A. Cross.

A header line is added to the exported text file, and converted from a tab-delimited file to a comma-delimited file. The negative millisecond values are deleted at this time.

ArcMap 9.2 was used to load this text file as an event theme using Tools - Add XY data. The projection is defined on input as UTM, Zone 16, WGS84.

This event theme is converted to a shapefile by right mouse click - Data - Export Data and generating the output shapefile bmmrg5.shp.

Any points falling outside Apalachicola Bay were deleted. The attribute filter_ms was added to the shapefile. Any points known to fall within 75 meters of man-made features such as spoil areas and dredged navigation channels had the filter_ms attribute set to a value of -9999 (standard NODATA value). These points were flagged using the Selection tool - Select by Location. Points were selected in the shapefile that intersected with ApalachicolaBaseMap polygon shapefile with a buffer applied to the polygon of 75 meters. The ApalachicolaBaseMap polygon is available from USGS Open-File Report 2006-1381. Field calculator was used to fill the attribute filter_ms with -9999 values in the selected records.

The attribute "mtrs_1800" was added to the shapefile. Field calculator was used to convert the seismic two-way millisecond travel time to meters using a speed of sound of 1800 meters per second. Records with the value -9999 in the filter_ms attribute were selected and the -9999 value was copied to the mtrs_1800 attribute.

The original shapefile in UTM, Zone 16, WGS84 was projected to Geographic, WGS84 using ArcMap 9.2 - ArcToolbox - Data Management Tools - Projections and Transformations - Feature - Project. No datum transformation was necessary.

Edits to the metadata were made to fix any errors that MP v 2.9.32 flagged. This is necessary to enable the metadata to be successfully harvested for various data catalogs. In some cases, this meant adding text "Information unavailable" or "Information unavailable from original metadata" for those required fields that were left blank. Other minor edits were probably performed (title, publisher, publication place, etc.). The source information was incomplete and had to be modified to meet the standard. The distribution format name was modified in an attempt to be more consistent with other metadata files of the same data format. The metadata date (but not the metadata creator) was edited to reflect the date of these changes. The metadata available from a harvester may supersede metadata bundled within a download file. Compare the metadata dates to determine which metadata file is most recent.

Added keywords section with USGS persistent identifier as theme keyword.