| | |
Information about October - December field activity data collection at <http://walrus.wr.usgs.gov/infobank/s/s1009mb/html/s-10-09-mb.fmeta.faq.html>.
Read and fully comprehend the metadata prior to data use.
Acknowledge the U.S. Geological Survey (USGS), the Originator, when using the data set as a source. Any use of trade, firm, or product names is for descriptive purposes only and does not imply endorsement by the U.S. Government.
Share data products developed using the source data set with the Originator.
Data should not be used beyond the limits of the source scale. This information is not intended for navigational purposes.
The data set is NOT a survey document and should not be utilized as such. Some USGS information accessed through this means may be preliminary in nature and presented without the approval of the Director of the USGS. This information is provided with the understanding that it is not guaranteed to be correct or complete and conclusions drawn from such information are the responsibility of the user.
Bathymetric surveys were conducted using a 234.5 kHz SEA (AP) Ltd. SWATHplus-M phase-differencing sidescan sonar. The sonar was pole-mounted on the 34-foot USGS mapping vessel R/V Parke Snavely. The R/V Snavely was equipped with a CodaOctopus F180 attitude and position system for the duration of the survey. The F180 is running F190 firmware, and receives real-time kinematic (RTK) corrections directly. The RTK GPS data (2 cm error ellipse) are combined with the inertial motion measurements directly within the F190 hardware so that high-precision position and attitude corrections are fed in real-time to the sonar acquisition equipment. The WGS84 (G1150) Epoch 2002.0 3-dimensional reference frame was used for all measurements.
GPS data and measurements of vessel motion are combined in the F180 hardware to produce a high-precision vessel attitude packet. This packet is transmitted to the Swath Processor acquisition software in real-time and combined with instantaneous sound velocity measurements at the transducer head before each ping. Up to 20 pings per second are transmitted with each ping consisting of 2048 samples per side (port and starboard).
Sound Velocity Measurements
Sound velocity profile (SVP) measurements were collected on average every two hours throughout the survey. A total of 440 SVPs were collected for this survey. 114 SVPs were collected during cruise S-7-09-MB and 326 SVPs were collected during S-10-09-MB. In general, SVPs were collected every 2 hours, or when the survey vessel moved to a different survey block. Typically two SVPs were collected every four lines. Water column sound velocity profiles varied significantly throughout the survey, however this frequency of SVP collection was sufficient to correct for variations in sound velocity. Only one line from cruise S-7-09-MB (BlockA_230_044) shows an artifact from an uncorrected sound velocity error (smile), for part of it's length. Insufficient sound velocity data were available to correct this line, and no attempt was made to synthesize data.
SVPs were collected with an Applied Micro Systems, SvPlus 3472. This instrument provides time-of-flight sound velocity measurements using invar rods with a sound velocity accuracy of +/- 0.06 m/s, pressure measured by a semiconductor bridge strain gauge to an accuracy to 0.15% (Full Scale) and temperature measured by thermistor to an accuracy of 0.05 C (Applied Microsystems Ltd., 2005). In addition, an Applied Micro Systems Micro SV accurate to +/- 0.03 m/s was deployed on the transducer frame for real-time sound velocity adjustments at the transducer-water interface.
The returned samples are projected to the lake bottom using a ray-tracing algorithm working with measured sound velocity profiles in SEA Swath Processor (version 3.05.18.04). A series of statistical filters are applied to the raw samples that isolate the lake bottom returns from other uninteresting targets in the water column. Finally, the processed x,y,z, amplitude data is stored line-by-line in both raw (.sxr) and processed (.sxp) trackline files. For this cruise, processed files were filtered across-track with a mean filter at 0.5m resolution.
Bathymetry Processing
Processed (.sxp) files were run through sxpegn (build 151) by David Finlayson (USGS) to remove erroneous data from the files and make valid gain-normalized amplitude data for CARIS HIPS and SIPS (version 7.0.1.0 Service Pack 1) Processed .sxp files were imported to CARIS, and field sheets were created within CARIS and defined to the nearest even integer meter in ground coordinates (WGS84(G1150) UTM Zone 10), to approximately match CA State Waters Quads 36 - 41. Because quads 38 & 39, and quads 40 & 41 had very little horizontal overlap, a horizontal overlap was added to the eastern quads in both cases; that is, the western bounds of quads 39 and 41 were extended to create overlap between field sheets.
Survey line width were filtered (trimmed) in CARIS to remove adjacent line data from nadir gaps. Target overlap between lines was 25 - 30%, though values ranged from ~10% to <50% depending on line spacing and data quality. CARIS Swath Angle BASE surfaces were then created for each map block at 2m resolution, and the subset editor was used to examine each field sheet and clean artifacts from biological targets and other unwanted soundings. Cleaned data were exported in Generic Sensor Format (GSF).
Amplitude Processing
Amplitude values are co-registered with bathymetry data. xy amplitude values were normalized by range using the entire cruise dataset by processing with sxpegn (build 151), nadir gaps were filled using sxpmagic (build 44) to interpolate amplitude values near-nadir to the nadir. Both pieces of software were developed by David P. Finlayson (USGS CMG, Santa Cruz, CA).
Normalized, nadir-filled amplitude data were gridded by line at 2m resolution using SEA Grid Processor (version 3.0.18.04) and exported as x,y, amplitude files. Files were imported as multipoint feature classes to a file geodatabase in ArcGIS 9.3.1 using the 3D Analyst ASCII 3D to Feature Class tool. Each line was then converted to a raster. For each survey block, Individual lines were mosaicked to a new raster using the ArcGIS BLEND algorithm. Blocks were then mosaicked together with the same algorithm to create a 2m raster for the entire project area. One interpolation pass was used to fill gaps in the dataset with a 3x3 focalmean function. The data were then exported as a 16-bit unsigned integer GeoTIFF, and a worldfile was generated from the GeoTIFF properties.
Bathymetric surveys were conducted using a 234.5 kHz SEA (AP) Ltd. SWATHplus-M phase-differencing sidescan sonar. The sonar was pole-mounted on the 34-foot USGS mapping vessel R/V Parke Snavely. The R/V Snavely was equipped with a CodaOctopus F180 attitude and position system for the duration of the survey. The F180 is running F190 firmware, and receives real-time kinematic (RTK) corrections directly. The RTK GPS data (2 cm error ellipse) are combined with the inertial motion measurements directly within the F190 hardware so that high-precision position and attitude corrections are fed in real-time to the sonar acquisition equipment. The WGS84 (G1150) Epoch 2002.0 3-dimensional reference frame was used for all measurements.
GPS data and measurements of vessel motion are combined in the F180 hardware to produce a high-precision vessel attitude packet. This packet is transmitted to the Swath Processor acquisition software in real-time and combined with instantaneous sound velocity measurements at the transducer head before each ping. Up to 20 pings per second are transmitted with each ping consisting of 2048 samples per side (port and starboard).
Sound Velocity Measurements
Sound velocity profile (SVP) measurements were collected on average every two hours throughout the survey. A total of 440 SVPs were collected for this survey. 114 SVPs were collected during cruise S-7-09-MB and 326 SVPs were collected during S-10-09-MB. In general, SVPs were collected every 2 hours, or when the survey vessel moved to a different survey block. Typically two SVPs were collected every four lines. Water column sound velocity profiles varied significantly throughout the survey, however this frequency of SVP collection was sufficient to correct for variations in sound velocity. Only one line from cruise S-7-09-MB (BlockA_230_044) shows an artifact from an uncorrected sound velocity error (smile), for part of it's length. Insufficient sound velocity data were available to correct this line, and no attempt was made to synthesize data.
SVPs were collected with an Applied Micro Systems, SvPlus 3472. This instrument provides time-of-flight sound velocity measurements using invar rods with a sound velocity accuracy of +/- 0.06 m/s, pressure measured by a semiconductor bridge strain gauge to an accuracy to 0.15% (Full Scale) and temperature measured by thermistor to an accuracy of 0.05 C (Applied Microsystems Ltd., 2005). In addition, an Applied Micro Systems Micro SV accurate to +/- 0.03 m/s was deployed on the transducer frame for real-time sound velocity adjustments at the transducer-water interface.
The returned samples are projected to the lake bottom using a ray-tracing algorithm working with measured sound velocity profiles in SEA Swath Processor (version 3.05.18.04). A series of statistical filters are applied to the raw samples that isolate the lake bottom returns from other uninteresting targets in the water column. Finally, the processed x,y,z, amplitude data is stored line-by-line in both raw (.sxr) and processed (.sxp) trackline files. For this cruise, processed files were filtered across-track with a mean filter at 0.5m resolution.
Bathymetry Processing
Processed (.sxp) files were run through sxpegn (build 151) by David Finlayson (USGS) to remove erroneous data from the files and make valid gain-normalized amplitude data for CARIS HIPS and SIPS (version 7.0.1.0 Service Pack 1) Processed .sxp files were imported to CARIS, and field sheets were created within CARIS and defined to the nearest even integer meter in ground coordinates (WGS84(G1150) UTM Zone 10), to approximately match CA State Waters Quads 36 - 41. Because quads 38 & 39, and quads 40 & 41 had very little horizontal overlap, a horizontal overlap was added to the eastern quads in both cases; that is, the western bounds of quads 39 and 41 were extended to create overlap between field sheets.
Survey line width were filtered (trimmed) in CARIS to remove adjacent line data from nadir gaps. Target overlap between lines was 25 - 30%, though values ranged from ~10% to <50% depending on line spacing and data quality. CARIS Swath Angle BASE surfaces were then created for each map block at 2m resolution, and the subset editor was used to examine each field sheet and clean artifacts from biological targets and other unwanted soundings. Cleaned data were exported in Generic Sensor Format (GSF).
Amplitude Processing
Amplitude values are co-registered with bathymetry data. xy amplitude values were normalized by range using the entire cruise dataset by processing with sxpegn (build 151), nadir gaps were filled using sxpmagic (build 44) to interpolate amplitude values near-nadir to the nadir. Both pieces of software were developed by David P. Finlayson (USGS CMG, Santa Cruz, CA).
Normalized, nadir-filled amplitude data were gridded by line at 2m resolution using SEA Grid Processor (version 3.0.18.04) and exported as x,y, amplitude files. Files were imported as multipoint feature classes to a file geodatabase in ArcGIS 9.3.1 using the 3D Analyst ASCII 3D to Feature Class tool. Each line was then converted to a raster. For each survey block, Individual lines were mosaicked to a new raster using the ArcGIS BLEND algorithm. Blocks were then mosaicked together with the same algorithm to create a 2m raster for the entire project area. One interpolation pass was used to fill gaps in the dataset with a 3x3 focalmean function. The data were then exported as a 16-bit unsigned integer GeoTIFF, and a worldfile was generated from the GeoTIFF header information with an AML script.
To convert the data from the WGS84 (G1150) epoch 2002.0 ellipsoid to NAD83 (CORS96) epoch 2002.0, data were exported from ArcGIS as an ESRI ASCII grid, and converted to an xyz point file in a python script. Next, a 14-parameter Helmert transformation was applied to the data set with time-dependent transformation parameters calculated for January 1, 2002 according to methods outlined in Soler and Snay (2004). Calculations were applied using cs2cs(Version 4.4.6), an open-source program developed as part of the PROJ.4 Library, originally developed by Gerald Evenden while working for the USGS. Changes to the Z (Amplitude) values were discarded. Data were then re-gridded in ArcGIS, and a final NAD83(CORS96) amplitude grid was exported in ESRII ASCII GRID (.ASC) and .TIF formats.
The files in this archive are 2 meter grids in ESRI ASCII GRID format. Each ASCII Grid was split in two parts to reduce the file size below the 2 gb limit for 32-bit .zip archives. These grids can be reassembled seamlessly in ARC with the mosaic function.
NAD 83 grids are in NAD83(CORS96/NSRS2007) epoch 2002.0, UTM Zone 10 N. ArcGIS cannot accurately represent this reference frame. The closest analog appears to be NAD83(HARN) UTM Zone 10N.
For most applications it will be sufficient to use the WGS84 and NAD83 UTM Zone 10 projections.
ESRI ASCII GRID format:
(Copied from the ArcGIS Desktop 9.3 Help File)
The ASCII file must consist of header information containing a set of keywords, followed by cell values in row-major order.
The file format is:
<NCOLS xxx>
<NROWS xxx>
<XLLCENTER xxx | XLLCORNER xxx>
<YLLCENTER xxx | YLLCORNER xxx>
<CELLSIZE xxx>
{NODATA_VALUE xxx}
row 1
row 2
.
.
.
row n
where xxx is a number, and the keyword nodata_value is optional and defaults to -9999. Row 1 of the data is at the top of the grid, row 2 is just under row 1 and so on.
For example:
ncols 480 nrows 450 xllcorner 378923 yllcorner 4072345 cellsize 30 nodata_value -32768 43 2 45 7 3 56 2 5 23 65 34 6 32 54 57 34 2 2 54 6 35 45 65 34 2 6 78 4 2 6 89 3 2 7 45 23 5 8 4 1 62 ...The nodata_value is the value in the ASCII file to be assigned to those cells whose true value is unknown. In the grid they will be assigned the keyword NODATA.
Cell values should be delimited by spaces. No carriage returns are necessary at the end of each row in the grid. The number of columns in the header is used to determine when a new row begins.
The number of cell values must be equal to the number of rows times the number of columns, or an error will be returned.
Any use of trade, firm, or product names is for descriptive purposes only and does not imply endorsement by the U.S. Government.
Although this Federal Geographic Data Committee-compliant metadata file is intended to document the data set in nonproprietary form, as well as in ArcInfo format, this metadata file may include some ArcInfo-specific terminology.
Please recognize the U.S. Geological Survey (USGS) as the source of this information.
Physical materials are under controlled on-site access.
Some USGS information accessed through this means may be preliminary in nature and presented without the approval of the Director of the USGS. This information is provided with the understanding that it is not guaranteed to be correct or complete and conclusions drawn from such information are the responsibility of the user.