Link to USGS home pageBlue spacerBay image

mb_nad83_amp1

Metadata also available as - [Outline] - [Parseable text] - [XML]

Frequently-anticipated questions:


What does this data set describe?

Title: mb_nad83_amp1
Abstract:
USGS Western Coastal & Marine Geology scientists mapped the Monterey Bay area from Ano Nuevo to Moss landing between August and December 2009 using a SEA SWATHplus interferometric sonar system. Data were collected as part of the cooperative California Seafloor Mapping program, during field activities S-7-09-MB and S-10-09-MB. Backscatter was normalized for the survey area and gridded to 2m resolution. This is a preliminary GEOTIFF product produced by mosaicing 2m gridded backscatter data from each survey line into a single raster and interpolating using a rectangular 3x3 focalmean algorith in ArcGIS.
Supplemental_Information:
Information about August-September 2009 field activity data collection at <http://walrus.wr.usgs.gov/infobank/s/s709mb/html/s-7-09-mb.fmeta.faq.html>.

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>.

  1. How should this data set be cited?

    U.S. Geological Survey (USGS), Coastal and Marine Geology (CMG), Menlo, 2010, mb_nad83_amp1.

    Online Links:

  2. What geographic area does the data set cover?

    West_Bounding_Coordinate: -122.338215
    East_Bounding_Coordinate: -122.099598
    North_Bounding_Coordinate: 37.111178
    South_Bounding_Coordinate: 36.862544

  3. What does it look like?

    <http://walrus.wr.usgs.gov/infobank/s/s709mb/html/s-7-09-mb.index.png> (PNG)
    Illustration of ship tracklines for data collection field activity S-7-09-MB.
    <http://walrus.wr.usgs.gov/infobank/s/s1009mb/html/s-10-09-mb.index.png> (PNG)
    Illustration of ship tracklines for data collection field activity S-10-09-MB.

  4. Does the data set describe conditions during a particular time period?

    Beginning_Date: 13-Aug-2009
    Ending_Date: 22-Dec-2009
    Currentness_Reference: ground condition

  5. What is the general form of this data set?

    Geospatial_Data_Presentation_Form: raster digital data

  6. How does the data set represent geographic features?

    1. How are geographic features stored in the data set?

      This is a Raster data set. It contains the following raster data types:

      • Dimensions 13706 x 10506 x 1, type Grid Cell

    2. What coordinate system is used to represent geographic features?

      The map projection used is Transverse Mercator.

      Projection parameters:
      Scale_Factor_at_Central_Meridian: 0.999600
      Longitude_of_Central_Meridian: -123.000000
      Latitude_of_Projection_Origin: 0.000000
      False_Easting: 500000.000000
      False_Northing: 0.000000

      Planar coordinates are encoded using row and column
      Abscissae (x-coordinates) are specified to the nearest 2.000000
      Ordinates (y-coordinates) are specified to the nearest 2.000000
      Planar coordinates are specified in meters

      The horizontal datum used is D_North_American_1983_HARN.
      The ellipsoid used is Geodetic Reference System 80.
      The semi-major axis of the ellipsoid used is 6378137.000000.
      The flattening of the ellipsoid used is 1/298.257222.

  7. How does the data set describe geographic features?

    amplitude_16.vat
    Gain-normalized backscatter. Higher values are higher amplitude backscatter.

    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. (Source: USGS)

    Rowid
    Internal feature number. (Source: ESRI)

    Sequential unique whole numbers that are automatically generated.

    VALUE
    amplitude values (Source: USGS)

    Sonar amplitude data values

    COUNT
    For the description of this attribute, contact Andy Ritchie, email: aritchie@usgs.gov. (Source: USGS)

    sum of data points

    Ampl_Interp.tif.vat
    This is the .TIFF file's internally stored value table name. (Source: USGS)

    ObjectID
    Internal feature number. (Source: ESRI)

    Sequential unique whole numbers that are automatically generated.

    Value
    These data are processed amplitude values from swath sonar returns, normalized by distance and beam angle for the entire cruise dataset. Higher amplitude returns are represented by higher values. values are 16-bit unsigned integer. (Source: USGS)

    Sonar amplitude data values

    Count
    For the description of this attribute, contact Andy Ritchie, email: aritchie@usgs.gov. (Source: USGS)

    sum of data points


Who produced the data set?

  1. Who are the originators of the data set? (may include formal authors, digital compilers, and editors)

  2. Who also contributed to the data set?

  3. To whom should users address questions about the data?

    USGS Western Coastal & Marine Geology
    c/o Guy Cochrane
    Geophysicist
    400 Natural Bridges Drive
    Santa Cruz, CA 95062
    USA

    (831) 427-4754 (voice)
    (831) 427-4748 (FAX)
    gcochrane@usgs.gov


Why was the data set created?

California State Waters Mapping


How was the data set created?

  1. From what previous works were the data drawn?

    S-7-09-MB (source 1 of 2)
    U.S. Geological Survey, Coastal and Marine Geology Program, 2009, USGS CMG S-7-09-MB Metadata.

    Online Links:

    Type_of_Source_Media: online
    Source_Contribution:
    Cruise S-7-09-MB contributed swath mapping data from Point Ano Nuevo to Table Rock, and a block near Soquel Canyon, in Monterey Bay National Marine Sanctuary. These data are primarily the western 1/3 of the survey area.

    S-10-09-MB (source 2 of 2)
    U.S. Geological Survey, Coastal and Marine Geology Program, 2009, USGS CMG S-10-09-MB Metadata.

    Online Links:

    Type_of_Source_Media: online
    Source_Contribution:
    Cruise S-10-09-MB contributed swath mapping data to this survey from Table rock to Moss Landing, in Monterey Bay National Marine Sanctuary. This comprised approximately the eastern 2/3 of the survey area.

  2. How were the data generated, processed, and modified?

    Date: 2009 (process 1 of 2)
    Data Collection and Processing

    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.

    Person who carried out this activity:

    U.S. Geological Survey, Coastal and Marine Geology Program
    c/o Andy Ritchie
    400 Natural Bridges Drive
    Santa Cruz, CA 95060-5792-5792
    US

    831-427-4791 (voice)
    831-427-4748 (FAX)
    aritchie@usgs.gov

    Date: 07-Apr-2010 (process 2 of 2)
    Coordinate System Transformation

    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.

  3. What similar or related data should the user be aware of?


How reliable are the data; what problems remain in the data set?

  1. How well have the observations been checked?

  2. How accurate are the geographic locations?

    Accuracy should be on the order of 2 meters due to datum transformations and grid cell size.

  3. How accurate are the heights or depths?

  4. Where are the gaps in the data? What is missing?

    GPS Data Collection and Processing

    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.

  5. How consistent are the relationships among the observations, including topology?

    These are raw data with uninterpreted results. for updated on this dataset, search for cruise S-7-09-MB and S-10-09-MB on USGS Coastal & Marine Geology InfoBank, or email: dfinlayson@usgs.gov.


How can someone get a copy of the data set?

Are there legal restrictions on access or use of the data?

Access_Constraints:
If physical samples or materials are available, constraints on their on-site access are described in "WR CMG Sample Distribution Policy" at URL: <http://walrus.wr.usgs.gov/infobank/programs/html/main/sample-dist-policy.html>
Use_Constraints:
Not suitable for navigation

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.

  1. Who distributes the data set? (Distributor 1 of 1)

    U.S. Geological Survey, Coastal and Marine Geology Program
    c/o Andy Ritchie
    400 Natural Bridges Drive
    Santa Cruz, CA 95060-5792
    US

    831-427-4791 (voice)
    831-427-4748 (FAX)
    aritchie@usgs.gov

  2. What's the catalog number I need to order this data set?

    Downloadable Data

  3. What legal disclaimers am I supposed to read?

    This information is not intended for navigational purposes.

    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.

  4. How can I download or order the data?


Who wrote the metadata?

Dates:
Last modified: 04-May-2010
Metadata author:
U.S. Geological Survey, Coastal and Marine Geology Program
c/o Andy Ritchie
400 Natural Bridges Drive
Santa Cruz, CA 95060-5792
US

831-427-4791 (voice)
831-427-4748 (FAX)
aritchie@usgs.gov

Metadata standard:
FGDC Content Standards for Digital Geospatial Metadata (FGDC-STD-001-1998)
Metadata extensions used:


Accessibility   |   FOIA   |   Privacy   |   Policies and Notices
U.S. Department of the Interior | U.S. Geological Survey
URL: https://pubs.usgs.gov/ds/514/
Maintained by: Mike Diggles
Page last modified and
Generated by mp version 2.9.8 on Tue May 4 15:07:37 2010