Continuous Resistivity Profile Tracklines of Data Collected in 2005 in the Neuse River, North Carolina

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

Frequently anticipated questions:

What does this data set describe?

Title:
Continuous Resistivity Profile Tracklines of Data Collected in 2005 in the Neuse River, North Carolina
Abstract:
The Neuse River Estuary in North Carolina is a broad, V-shaped water body located on the southwestern end of Pamlico Sound. This estuary suffers from severe eutrophication for which several water quality models have recently been developed to aid in the management of nutrient loading to the estuary. In an effort to help constrain model estimates of the fraction of nutrients delivered by direct ground-water discharge, continuous resistivity profile (CRP) measurements were made during the spring of 2004 and 2005. CRP is used to measure electrical resistivity of sediments, a property that is sensitive to difference in salinity of submarine ground water. The 2004 and 2005 surveys used floating resistivity streamers of 100 m and 50 m respectively. The depth penetration of the streamers is approximately 20% of the streamer length which translates to approximately 20-25 m with the 100 m streamer and 12-14 m with the 50 m streamer. These data were processed using AGI's EarthImager 2D software. CRP data enables the mapping of the extent and depth of the fresher ground water within the estuary.
  1. How might this data set be cited?
    Bratton, John F., and Cross, VeeAnn A., 2005, Continuous Resistivity Profile Tracklines of Data Collected in 2005 in the Neuse River, North Carolina: Open-File Report 2005-1306, U.S. Geological Survey, Coastal and Marine Geology Program, Woods Hole Coastal and Marine Science Center, Woods Hole, MA.

    Online Links:

    This is part of the following larger work.

    Cross, VeeAnn A., Bratton, John F., Bergeron, Emile, Meunier, Jeff K., Crusius, John, and Koopmans, Dirk, 2005, Continuous Resistivity Profiling Data from the Upper Neuse River Estuary, North Carolina, 2004-2005: Open-File Report 2005-1306, U.S. Geological Survey, Reston, VA.

    Online Links:

  2. What geographic area does the data set cover?
    West_Bounding_Coordinate: -77.033752
    East_Bounding_Coordinate: -76.812000
    North_Bounding_Coordinate: 35.124350
    South_Bounding_Coordinate: 34.936783
  3. What does it look like?
  4. Does the data set describe conditions during a particular time period?
    Beginning_Date: 03-May-2005
    Ending_Date: 05-May-2005
    Currentness_Reference:
    ground condition
  5. What is the general form of this data set?
    Geospatial_Data_Presentation_Form: vector digital data
  6. How does the data set represent geographic features?
    1. How are geographic features stored in the data set?
      This is a Vector data set. It contains the following vector data types (SDTS terminology):
      • String (19)
    2. What coordinate system is used to represent geographic features?
      Horizontal positions are specified in geographic coordinates, that is, latitude and longitude. Latitudes are given to the nearest 0.000001. Longitudes are given to the nearest 0.000001. Latitude and longitude values are specified in Decimal degrees. The horizontal datum used is North American Datum of 1983.
      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?
    restracklines_05
    Information unavailable from original metadata. (Source: Information unavailable from original metadata.)
    FID
    Internal feature number. (Source: ESRI) Sequential unique whole numbers that are automatically generated.
    Shape
    Feature geometry. (Source: ESRI) Coordinates defining the features.
    ID
    Number corresponding to unique trackline, not polyline. (Source: Software generated.)
    Range of values
    Minimum:0
    Maximum:10
    LINENAME
    String representing the prefix of the original resistivity line name. (Source: Data processor.) character set
    COL_TIME
    The time at which data collection began, UTC time. (Source: Software.) time in hr:min:sec
    COL_DATE
    Date of data acquisition. (Source: Software.) data in the format of DDMMYR
    SPLITPART
    Prefix filename assigned to the datafile if the STG file was split. This value is the same as Linename if no split occurred. (Source: Data processor.) character set
    LENGTH
    Length of the trackline in meters, based on the UTM, zone 18, NAD83 projection. (Source: Software computed.)
    Range of values
    Minimum:1231.614
    Maximum:18532.95
    Units:meters

Who produced the data set?

  1. Who are the originators of the data set? (may include formal authors, digital compilers, and editors)
    • John F. Bratton
    • VeeAnn A. Cross
  2. Who also contributed to the data set?
  3. To whom should users address questions about the data?
    VeeAnn A. Cross
    U.S. Geological Survey
    Marine Geologist
    384 Woods Hole Rd.
    Woods Hole, MA

    (508) 548-8700 x2251 (voice)
    (508) 457-2310 (FAX)
    vatnipp@usgs.gov

Why was the data set created?

This shapefile is provided to show the tracklines were continuous resistivity profile data were collected.

How was the data set created?

  1. From what previous works were the data drawn?
    raw crp data (source 1 of 1)
    U.S. Geological Survey, Unpublished material, Raw CRP Data.

    Type_of_Source_Media: hard disk
    Source_Contribution:
    These data were acquired with an AGI SuperSting Marine system that is described at the website: www.agiusa.com/marinesystem.shtml. The particular system used for this acquisition was an 11 electrode array with electrodes spaced 5 meters apart. The potential electrodes are made of graphite, with the remaining electrodes stainless steel. A dipole-dipole configuration was used for the data collection in which two fixed current electrodes are assigned with the measurement of voltage potentials between electrode pairs in the remaining electrodes. Each line of data acquisition records several files. The two files necessary for processing are the *.stg and *.gps file. The STG file contains the resistivity data, while the GPS file contains the navigation information. During the 2005 survey, we had large time periods where no navigation was recorded. A duplicate navigation value was recorded in the GPS file. The lines affected by this problem were L2F1, L3F1, L5F1, and L6F1.
  2. How were the data generated, processed, and modified?
    Date: Unknown (process 1 of 23)
    The GPS files were processed using an AWK script to parse out the navigational information from the $GPRMC string and concatenated into a single file. Data sources used in this process:
    • *.gps
    Data sources produced in this process:
    • allgps.txt
    Date: Unknown (process 2 of 23)
    This comma delimited text file was then imported as a table into ArcView 3.3, loaded as an event theme, and then converted to a shapefile. Data sources used in this process:
    • allgps.txt
    Data sources produced in this process:
    • allgps.shp
    Date: Unknown (process 3 of 23)
    The allgps shapefile was copied to a new shapefile (tempall) and a field called record was added. This field was filled with the record number so that each point had a unique identifier. Data sources used in this process:
    • allgps.shp
    Data sources produced in this process:
    • tempall.shp
    Date: Unknown (process 4 of 23)
    The extension pathfind.avx (Path, with Distance and Bearings, v. 3.2) was loaded into the ArcView project. Clicking on the pathfind button brings up a dialog. Select the shapefile (tempall) and the ID field and SERIES field. In this case, both are the "record" field in the shapefile. For the RESULTS table, I checked the option RESULTS table and Join results with Theme Attribute table. Select NO LINES for connection lines. ***Because I think in terms of meters, not decimal degrees for distance measure, I had set the View Properties to UTM, Zone 18, NAD83 projection.
    Date: Unknown (process 5 of 23)
    The joined shapefile table was then exported to a text file. Data sources produced in this process:
    • temp.txt
    Date: Unknown (process 6 of 23)
    This exported text file was then reloaded as a table, added as an event theme, and converted to a shapefile. Three new fields are now in the shapefiles as a result of the pathfind extension: To_ID, Cent_Bear, Cent_Dist. (The record field is the fromID). The navigation problem, which manifests itself as the same fix for a long period of time is now readily obtainable. The Cent_Bear value becomes -999 and the Cent_Dist is 0.000. Data sources used in this process:
    • temp.txt
    Data sources produced in this process:
    • gps_fixing.shp
    Date: Unknown (process 7 of 23)
    Three new fields are added to the shapefile: new_dist, new_bear, sum_dist. The new_dist field is for the value that I want to be between each navigation point, assuming the ship is traveling at a constant speed. This value is calculated by using the Cent_dist value that appears right after the 0 values, divided by the number of -999 azimuth values plus 1. That Cent_dist value records the large distance jump once the navigation started acquiring valid values. For example, if there are 9 values of -999, then I divide the large distance value by 10. This resulting value needs to be placed in the 2nd -999 row, through to one row after the lat -999 value (in the new_dist column).
    Date: Unknown (process 8 of 23)
    The sum_dist field simply sums the distance covered by each new distance section. Select the records from a section for an individual line that needs this calculation. Use the calculate button (table must be in edit mode) and enter the equation: sum_dist = new_dist *([To_ID]-xxxx] where xxxx is the record field value of the first row in the selection.
    Date: Unknown (process 9 of 23)
    To properly populate the new_bear field, I used the extension dist_az_tools. For each gap, I measured the azimuth between the last good point and the point where the gps started working again. This value was then placed into the appropriate section.
    Date: Unknown (process 10 of 23)
    I decided to do the rest of the processing on the individual lines that need the repairs. I selected all the points from each line of interest and saved them as a new shapefile resulting in: templ2f1.shp, templ3f1.shp, templ5f1.shp, templ6f1.shp. **Because my distance and azimuth readings are based on the shapefile being projected, I exported the files as projected shapefiles.
    Date: Unknown (process 11 of 23)
    The distance_azimuth tool now lets me create a new shapefile based on distances and azimuths. Run the tool for each new shapefile, select the second option (Input theme, using unique distances and azimuths). Next window, select the shapefile with the DISTANCE FIELD being sum_dist, and the AZIMUTH FIELD being new_bear. Select all the fields for the new shapefile. What the script does is take the point and move it to a new location based on the distance and azimuth as specified in those fields. The result is that only points that need moving have values other than zeros in the sum_dist and new_bear fields, therefore those are the only points that are actually moved. The new shapefiles were called: templ2f1_fix.shp, templ3f1_fix.shp, templ5f1_fix.shp, templ6f1_fix.shp
    Date: Unknown (process 12 of 23)
    Because these shapefiles are projected, I needed to convert them back to geographic. I used ArcToolbox (9.0) to define their projection as UTM, Zone 18, NAD83, and then reprojected them to Geographic, NAD83. Resulting files were: templ2f1_fixgeog.shp, templ3f1_fixgeog.shp, templ5f1_fixgeog.shp, templ6f1_fixgeog.shp
    Date: Unknown (process 13 of 23)
    These geographic shapefiles were loaded back into ArcView 3.3 and I used a modified form of the addxycoo.ave script to add back in the xy (latitude, longitude) fields. The modification to the script had it write 6 decimal places instead of 5.
    Date: Unknown (process 14 of 23)
    I then "turned off" all the fields except the ones I needed: col_time, col_date, depth_m, temp, x-coord, y-coord and exported the table to a comma delimited text file. These files were: l2f1_gpsfix.txt, l3f1_gpsfix.txt, l5f1_gpsfix.txt, l6f1_gpsfix.txt
    Date: Unknown (process 15 of 23)
    These fixed text files were concatenated into a single file: lines2_6navfix.txt and brought into ArcView as an event theme.
    Date: Unknown (process 16 of 23)
    The original navigation text files that did not need navigational fixes were concatenated into restoflines.txt and brought into ArcView as an event theme.
    Date: Unknown (process 17 of 23)
    The geoprocessing wizard was used to merge restoflines.txt event theme and lines2-6navfix.txt event theme into a single shapefile called merge_clnpnts.
    Date: Unknown (process 18 of 23)
    An avenue script, navpnts2lines, was used to convert merge_clnpnts to a polyline shapefile with each line based on the unique identifier in the "Line" field.
    Date: Unknown (process 19 of 23)
    In processing the resistivity data, several of the lines needed to be split into multiple parts. To reflect this in the trackline shapefile, ArcMap 9.0 was used to split the polylines based on distance along to reflect the same parts in the split resistivity files.
    Date: 01-Nov-2016 (process 20 of 23)
    Edits to the metadata were made to fix any errors that MP v 2.9.34 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 process steps without process dates had the date set to unknown. The distribution liability, format and network resource had to be added. 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. Person who carried out this activity:
    U.S. Geological Survey
    Attn: VeeAnn A. Cross
    Marine Geologist
    384 Woods Hole Road
    Woods Hole, MA

    508-548-8700 x2251 (voice)
    508-457-2310 (FAX)
    vatnipp@usgs.gov
    Date: 20-Jul-2018 (process 21 of 23)
    USGS Thesaurus keywords added to the keyword section. Person who carried out this activity:
    U.S. Geological Survey
    Attn: VeeAnn A. Cross
    Marine Geologist
    384 Woods Hole Road
    Woods Hole, MA

    508-548-8700 x2251 (voice)
    508-457-2310 (FAX)
    vatnipp@usgs.gov
    Date: 18-Nov-2019 (process 22 of 23)
    Crossref DOI link was added as the first link in the metadata. Person who carried out this activity:
    U.S. Geological Survey
    Attn: VeeAnn A. Cross
    Marine Geologist
    384 Woods Hole Road
    Woods Hole, MA

    508-548-8700 x2251 (voice)
    508-457-2310 (FAX)
    vatnipp@usgs.gov
    Date: 08-Sep-2020 (process 23 of 23)
    Added keywords section with USGS persistent identifier as theme keyword. Person who carried out this activity:
    U.S. Geological Survey
    Attn: VeeAnn A. Cross
    Marine Geologist
    384 Woods Hole Road
    Woods Hole, MA

    508-548-8700 x2251 (voice)
    508-457-2310 (FAX)
    vatnipp@usgs.gov
  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?
  3. How accurate are the heights or depths?
  4. Where are the gaps in the data? What is missing?
    Information unavailable from original metadata.
  5. How consistent are the relationships among the observations, including topology?
    Information unavailable from original metadata.

How can someone get a copy of the data set?

Are there legal restrictions on access or use of the data?
Access_Constraints None.
Use_Constraints The U.S. Geological Survey must be referenced as the originator of the dataset in any future products or research derived from these data.
  1. Who distributes the data set? (Distributor 1 of 1)
    John F. Bratton
    U.S. Geological Survey
    384 Woods Hole Rd.
    Woods Hole, MA

    (508) 548-8700 x2254 (voice)
    (508) 457-2310 (FAX)
  2. What's the catalog number I need to order this data set? Downloadable Data
  3. What legal disclaimers am I supposed to read?
    These data were prepared by an agency of the United States Government. Neither the United States government nor any agency thereof, nor any of their employees, make any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed in this report, or represents that its use would not infringe privately owned rights. Reference therein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States government or any agency thereof. Any views and opinions of authors expressed herein do not necessarily state or reflect those of the United States government or any agency thereof. Although all data published in this report have been used by the USGS, no warranty, expressed or implied, is made by the USGS as to the accuracy of the data and related materials and/or the functioning of the software. The act of distribution shall not constitute any such warranty, and no responsibility is assumed by the USGS in the use of this data, software, or related materials.
  4. How can I download or order the data?

Who wrote the metadata?

Dates:
Last modified: 18-Mar-2024
Metadata author:
VeeAnn A. Cross
U.S. Geological Survey
Marine Geologist
384 Woods Hole Rd.
Woods Hole, MA

(508) 548-8700 x2251 (voice)
(508) 457-2310 (FAX)
whsc_data_contact@usgs.gov
Contact_Instructions:
The metadata contact email address is a generic address in the event the person is no longer with USGS. (updated on 20240318)
Metadata standard:
FGDC Content Standards for Digital Geospatial Metadata (FGDC-STD-001-1998)
This page is <https://cmgds.marine.usgs.gov/catalog/whcmsc/open_file_report/ofr2005-1306/restracklines_05.shp.faq.html>
Generated by mp version 2.9.51 on Mon Mar 25 16:05:24 2024