JD104GPS_BESTDEPTH.SHP: Point shapefile of navigation and best depth values at ship positions during continuous resistivity profiling data collection in the Indian River Bay, Delaware, on April 14, 2010, on U.S. Geological Survey Field Activity 2010-006-FA (Geographic, WGS 84)

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

Frequently-anticipated questions:

What does this data set describe?

Title:
JD104GPS_BESTDEPTH.SHP: Point shapefile of navigation and best depth values at ship positions during continuous resistivity profiling data collection in the Indian River Bay, Delaware, on April 14, 2010, on U.S. Geological Survey Field Activity 2010-006-FA (Geographic, WGS 84)
Abstract:
A geophysical survey to delineate the fresh-saline groundwater interface and associated sub-bottom sedimentary structures beneath Indian River Bay, Delaware, was carried out in April 2010. This included surveying at higher spatial resolution in the vicinity of a study site at Holts Landing, where intensive onshore and offshore studies were subsequently completed. The total length of continuous resistivity profiling (CRP) survey lines was 145 kilometers (km), with 36 km of chirp seismic lines surveyed around the perimeter of the bay. Medium-resolution CRP surveying was performed using a 50-meter streamer in a bay-wide grid. Results of the surveying and data inversion showed the presence of many buried paleochannels beneath Indian River Bay that generally extended perpendicular from the shoreline in areas of modern tributaries, tidal creeks, and marshes. An especially wide and deep paleochannel system was imaged in the southeastern part of the bay near White Creek. Many paleochannels also had high-resistivity anomalies corresponding to low-salinity groundwater plumes associated with them, likely due to the presence of fine-grained estuarine mud and peats in the channel fills that act as submarine confining units. Where present, these units allow plumes of low-salinity groundwater that was recharged onshore to move beyond the shoreline, creating a complex fresh-saline groundwater interface in the subsurface. The properties of this interface are important considerations in construction of accurate coastal groundwater flow models. These models are required to help predict how nutrient-rich groundwater, recharged in agricultural watersheds such as this one, makes its way into coastal bays and impacts surface water quality and estuarine ecosystems. For more information on the survey conducted for this project, see <http://woodshole.er.usgs.gov/operations/ia/public_ds_info.php?fa=2010-006-FA>.
  1. How should this data set be cited?

    Cross, VeeAnn A. , 2014, JD104GPS_BESTDEPTH.SHP: Point shapefile of navigation and best depth values at ship positions during continuous resistivity profiling data collection in the Indian River Bay, Delaware, on April 14, 2010, on U.S. Geological Survey Field Activity 2010-006-FA (Geographic, WGS 84): Open-File Report 2011-1039, 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, V.A., Bratton, J.F., Michael, H.A., Kroeger, K.D., Green, A., and Bergeron, E., 2014, Continuous Resistivity Profiling and Seismic-Reflection Data Collected in April 2010 from Indian River Bay, Delaware: Open-File Report 2011-1039, U.S. Geological Survey, Reston, VA.

    Online Links:

  2. What geographic area does the data set cover?

    West_Bounding_Coordinate: -75.194617
    East_Bounding_Coordinate: -75.074800
    North_Bounding_Coordinate: 38.615317
    South_Bounding_Coordinate: 38.570800

  3. What does it look like?

    <http://pubs.usgs.gov/of/2011/1039/data/navigation/resistivity/jd104gps_bestdepth.gif> (GIF)
    Thumbnail image showing the location of resistivity navigation points collected April 14, 2010. The coastline is included for spatial reference.

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

    Calendar_Date: 14-Apr-2010
    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):

      • Entity point (5137)

    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 D_WGS_1984.
      The ellipsoid used is WGS_1984.
      The semi-major axis of the ellipsoid used is 6378137.000000.
      The flattening of the ellipsoid used is 1/298.257224.

      Vertical_Coordinate_System_Definition:
      Depth_System_Definition:
      Depth_Datum_Name: Local surface
      Depth_Resolution: 0.1
      Depth_Distance_Units: meters
      Depth_Encoding_Method: Attribute values

  7. How does the data set describe geographic features?

    jd104gps_bestdepth
    ESRI point shapefile (Source: ESRI)

    FID
    Internal feature number. (Source: ESRI)

    Sequential unique whole numbers that are automatically generated.

    Shape
    Feature geometry. (Source: ESRI)

    Coordinates defining the features.

    FID_1
    Internal feature number from the original JOIN shapefile. (Source: ESRI)

    Unique whole numbers that were automatically generated.

    gpstime
    GPS time in the format HHMMSS. GPS time is +4 hours from local time during the survey. (Source: U.S. Geological Survey)

    Although the value is represented as a number, the number as a whole doesn't have a particular meaning. Only when the individual parts for hours, minutes, and seconds are broken out does the number have meaning.

    gpsdate
    The date recorded in the GPS navigation in the format DDMMYY. Because of the time offset from local time, this date could actually be different than the local acquisition date. (Source: U.S. Geological Survey)

    Although the value is represented as a number, the number as a whole doesn't have a particular meaning. Only when the individual parts for month, day, and year are broken out does the number have meaning.

    longitude
    Longitude coordinate of the point in decimal degrees, WGS84. (Source: U.S. Geological Survey)

    Range of values
    Minimum:-75.194617
    Maximum:-75.0748
    Units:decimal degrees

    latitude
    Latitude coordinate of the point in decimal degrees, WGS84. (Source: U.S. Geological Survey)

    Range of values
    Minimum:38.5708
    Maximum:38.615317
    Units:decimal degrees

    depth_m
    Depth of the water below the fathometer in meters recorded by the ship's fathometer/navigation system. Datum is local surface (no tides taken into account). A value of -9999 indicates no data. Apparent spuriod data points were not edited or deleted. (Source: U.S. Geological Survey)

    Range of values
    Minimum:0.3
    Maximum:9.5
    Units:meters

    temp_c
    Water temperature in degrees Celsius as recorded at the Lowrance fathometer transducer. A value of -9999 indicates no data. (Source: U.S. Geological Survey)

    Range of values
    Minimum:10
    Maximum:17.9
    Units:degrees Celsius

    line
    The alphanumeric name corresponding to the prefix of the GPS filename. This name reflects the name assigned to the line of data acquisition and incorporates modifiers to reflect modification of the GPS file if the GPS file was split into more than one part. (Source: U.S. Geological Survey)

    Character set.

    FID_2
    Internal feature number from the JOINED shapefile (representing HYPACK navigation). (Source: U.S. Geological Survey)

    Unique whole numbers that were automatically generated.

    gpstime_1
    GPS time in the format HHMMSS from the JOINED HYPACK navigation. GPS time is +4 from local time during the survey. (Source: U.S. Geological Survey)

    Although the value is represented as a number, the number as a whole doesn't have a particular meaning. Only when the individual parts for hours, minutes, and seconds are broken out does the number have meaning.

    longitud_1
    Longitude coordinate of the JOINED HYPACK navigation point in decimal degrees, WGS84. (Source: U.S. Geological Survey)

    Range of values
    Minimum:-75.192233
    Maximum:-75.074783
    Units:decimal degrees

    latitude_1
    Latitude coordinate of the JOINED HYPACK navigation point in decimal degrees, WGS84. (Source: U.S. Geological Survey)

    Range of values
    Minimum:38.5708
    Maximum:38.615317
    Units:decimal degrees

    depth_m_1
    Depth of the water below the fathometer in meters recorded by the ship's fathometer/navigation system in the JOINED HYPACK file. Datum is local surface (no tides taken into account). Apparent spurious data points were not edited or deleted. (Source: U.S. Geological Survey)

    Range of values
    Minimum:0.3
    Maximum:198.5
    Units:meters

    Distance
    Distance in meters (UTM, Zone 18, WGS84) between the CRP GPS point and the closest HYPACK navigation point. (Source: Software defined and calculated in the Spatial Join function.)

    Range of values
    Minimum:0.000102
    Maximum:414.482178
    Units:meters

    timediff
    Represents the time difference between the original CRP navigation and the JOINED HYPACK navigation. Calculated by gpstime - gpstime_1. (Source: U.S. Geological Survey)

    The value represents a number which in most cases is the time offset between the original shapefile and the joined shapefile in the units of seconds. However, because of the format of the GPSTIME fields, this value does not always represent a seconds time difference. Most notably the problem arises around the minutes and hours boundaries.

    fixdepth
    An attempt to establish valid depth values based on existing CRP depths, HYPACK depths, and best guess based on surrounding points. Specific criteria are discussed in the process steps. (Source: U.S. Geological Survey.)

    Range of values
    Minimum:0
    Maximum:20
    Units:meters

    hyptidecor
    Depth in meters at the point extracted from an interpolated bathymetric grid based on the HYPACK fathometer data. These values have been tide corrected. (Source: U.S. Geological Survey)

    Range of values
    Minimum:0.39508
    Maximum:8.288633
    Units:meters

    jday
    This number represents the Julian day of data collection based on the GPS day. Julian day is the integer number representing the interval of time in days since January 1 of the year. (Source: U.S. Geological Survey)

    Range of values
    Minimum:104
    Maximum:104
    Units:days

    addedtide
    This value represents the hyptidecor attribute value with the tidal component removed using calculations in MATLAB. (Source: U.S. Geological Survey)

    Range of values
    Minimum:0.341818
    Maximum:8.889661
    Units:meters

    bestdepth
    The best available depth in meters based on various calculations and criteria discussed in the process steps. (datum is local surface - no tide corrections) (Source: U.S. Geological Survey)

    Range of values
    Minimum:0.3
    Maximum:9.5
    Units:meters

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?

    VeeAnn A. Cross
    U.S. Geological Survey
    Marine Geologist
    Woods Hole Coastal and Marine Science Center
    Woods Hole, MA 02543-1598

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

Why was the data set created?

This point shapefile has several purposes. First, this shapefile provides the ship's XY position during the collection of continuous resistivity profile data in the Indian River Bay on April 14, 2010. Additionally, attributes in this shapefile account for extensive processing to derive acceptable depth values (not tide corrected) at each CRP data acquisition point. These depths improve the processing of the CRP data. This shapefile also acts as an archive of this dataset.

How was the data set created?

  1. From what previous works were the data drawn?

    (source 1 of 1)
    Source_Contribution:
    The continuous resistivity profile (CRP) system used on this cruise was an AGI SuperSting marine system described at the website: www.agiusa.com/marinesystem.shtml. The particular system used for this acquisition was a 50-m streamer with an 11 electrode array with electrodes spaced 5 meters apart. The source electrodes are graphite, while the receiver electrodes are 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 potential between electrode pairs in the remaining electrodes. The maximum depth below the water surface the streamer can reach is approximately 1/4 the streamer length. So for the 50-m streamer, maximum depth is about 12.5 meters. Each line of data acquisition records several files. The two files necessary for processing are the *.stg and the *.gps file. The STG file contains the resistivity data, while the GPS file contains the navigation information. The navigation system used in concert with the CRP system is a Lowrance LMS-480M with an LGC-2000 GPS antenna and a 200 kHz fathometer transducer. The antenna and fathometer transducer were mounted on the starboard side of the boat. The streamer tow point was on the port side aft. The layback offset between the navigation antenna and the first electrode was 17.6 meters on April 13 and 14. On April 15 the antenna and transducer were moved 1.6 m aft changing the layback offset to 16 m. This layback offset is accounted for by the acquisition system. The approximately 2 m lateral offset is not accounted for. The Lowrance transducer also contains a temperature sensor. Lowrance indicates the speed of sound used by the system is 4800 feet/second. Both the temperature and depth information are recorded in the logged GPS file. There are instances where no depth or temperature information is recorded due to an equipment problem. The CRP system images the subsurface electrical properties of an estuarine, riverine or lacustrine environment. Resistivity differences can be attributed to subsurface geology (conductive vs less conductive layers) and hydrogeologic conditions with fresh water exhibiting high resistivity and saline conditions showing low resistivity.

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

    Date: Mar-2010 (process 1 of 14)
    The data were transferred from the logging computer via AGISSAdmin software version 1.3.2.165. These files were then transferred via email to the processing computer. The files included in this publication are the *.crs, *.cmd, *.gps, and *.stg. The two files essential for processing are the GPS and STG files. The GPS file contains the navigation, and in the case of the Lowrance system also includes water depth and temperature. The STG file contains the resistivity measurements from each of the electrodes. The CRS file contains the contact resistance readings. The CMD file contains the parameters for data collection. These last two files aren't necessary for data processing, but can be useful in terms of troubleshooting. This process step, along with all subsequent process steps, was performed by the same person: VeeAnn A. Cross.

    Person who carried out this activity:

    VeeAnn A. Cross
    U.S. Geological Survey
    Marine Geologist
    Woods Hole Coastal and Marine Science Center
    Woods Hole, MA 02543-1598

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

    Date: Apr-2010 (process 2 of 14)
    An AWK script was used to extract the navigation, bathymetry, and temperature information recorded in each individual GPS data file for each day of data acquisition. AWK script "awkhold": 
    BEGIN {
FS = ","
}
{
FS = ","
ARGC = 2
depth = -9999
temp = -9999
if ($1=="$GPRMC")
	{
	utctime = $2
	utcdate = $10
	latdeg = substr($4,1,2)
	latmin = substr($4,3,6)
	declat = latdeg + (latmin/60)
	londeg = substr($6,1,3)
	lonmin = substr($6,4,6)
	declon = -1 * (londeg + (lonmin/60))
	if (NR==1) {
		holddepth = -9999
		holdtemp = -9999
		}
	else {
		printf("%s, %s, %9.6f, %9.6f, %5.1f, %5.1f, %s\n", holdutctime, holdutcdate, holddeclon, holddeclat, holddepth, holdtemp, ARGV[2])
	}
	holdutctime = utctime
	holdutcdate = utcdate
	holddeclon = declon
	holddeclat = declat
	holddepth = -9999
	holdtemp = -9999
	}
if ($1=="$SDDPT")
	{
	depthreal = $2
	holddepth = depthreal
	}
if ($1=="$SDMTW")
	{
	tempreal = $2
	holdtemp = tempreal
	}
}
END {
printf("%s, %s, %9.6f, %9.6f, %5.1f, %5.1f, %s\n", holdutctime, holdutcdate, holddeclon, holddeclat, holddepth, holdtemp, ARGV[2])
}
    This AWK script was initialized by "dohold" - shell script run under CYGWIN (UNIX like environment that runs under Windows). This shell script reads all the files in a folder with the extension "gps" and processes them. This is the script used for the April 14 data collection: 
    files=`ls *.gps | cut -d. -f1 | tr "[A-Z"] ["a-z"]`
for file in $files
do
	awk -f awkhold $file.gps $file > $file.holds
done

    Data sources used in this process:

    • *.gps

    Data sources produced in this process:

    • *.holds

    Date: Apr-2010 (process 3 of 14)
    Each of the resulting *.holds files were concatenated together using a shell script running under Cygwin. The shell script is as follows: 
    cat l6f1_mod.holds \
l6f2.holds \
l6f3.holds \
l6f4.holds \
l6f5.holds \
l6f7_mod.holds \
l6f9.holds \
l6f10.holds \
l6f11.holds \
l6f12.holds \
l7f1.holds \
l7f7_mod.holds \
l7f10.holds \
l7f12.holds \
l7f13.holds \
l7f14.holds \
l7f17.holds \
l7f18.holds \
f7l19.holds \
l8f1.holds \
l9f1.holds \
l9f3.holds \
l10f1.holds \
l11f1.holds \
l11f2.holds \
l12f1.holds \
l13f1.holds \
l14f1.holds \
l15f1.holds \
l16f1.holds \
l17f1.holds \
l18f1.holds \
l19f1.holds \
l19f2.holds \
l19f3.holds > jd104gps_mod.csv
    The files with "mod" in the filename have had the original GPS files edited to remove obviously bad points.

    Data sources used in this process:

    • *.holds

    Data sources produced in this process:

    • jd104gps_mod.csv

    Date: Apr-2010 (process 4 of 14)
    The text editor VI was used under Cygwin to add the following header line to the text file: 
    gpstime, gpsdate, longitude, latitude, depth_m, temp_c, line
    This text file was then imported to ArcMap 9.2 using Tools - AddXY Data. The X field is longitude; Y field is latitude, and the coordinate system was defined as Geographic, WGs84. This "Event Theme" was converted to a shapefile by right-mouse clicking on the layer - Data - Export Data.

    Data sources used in this process:

    • jd104gps_mod.csv

    Data sources produced in this process:

    • jd104gps_mod.shp

    Date: Apr-2010 (process 5 of 14)
    Using ArcMap 9.2 - ArcToolbox - Projections and Transformations - Feature - Project, project the shapefile from Geographic, WGS84 to UTM, Zone 18, WGS84. Parameters: input - jd104gps_mod.shp; input coordinate system - GCS_WGS_1984 (default, read from file); output - jd104gps_mod_utm18.shp; output coordinate system - WGS_1984_UTM_Zone_18N. No transformation necessary.

    Data sources used in this process:

    • jd104gps_mod.shp

    Data sources produced in this process:

    • jd104gps_mod_utm18.shp

    Date: Apr-2010 (process 6 of 14)
    With the jd104hypack.shp (available from <http://pubs.usgs.gov/of/2011/1039/html/ofr2011-1039-catalog.html>) loaded in ArcMap 9.2, set a definition query on the shapefile where depth_m <> -9999. Then with jd104gps_mod_utm18.shp the active shapefile in the table of contents do a join on jd104gps_mod_utm18.shp: Join data based on spatial location; join layer - jd104hypack. Select the option to give all the attributes of the joined shapefile, along with a distance field. Output to a new file: jd104gps_mod_spatjoin.shp. The distances reported are in the units of the data layer initiating the join - hence the reason for projecting the CRP navigation shapefile to UTM, Zone 18. Units of meters are much easier to make sense of than decimal degrees distances.

    Data sources used in this process:

    • jd104gps_mod_utm18.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin.shp

    Date: Apr-2010 (process 7 of 14)
    The join function changes the order of the records in the original starting shapefile (jd104gps_mod_utm18.shp). So to put the records back in the order of time, the shapefile needs to be sorted by the FID_1 attribute. Resorting the shapefile was accomplished with an extension written by VeeAnn Cross in Woods Hole, MA - VAC Extras v. 2.1. Using VAC Extras - FeatConv - Table Sort, jd104gps_mod_spatjoin.shp was sorted with the primary sort field FID_1 in ascending order, no secondary field chosen, and the output sent to jd104gps_mod_spatjoin_sort.shp.

    Data sources used in this process:

    • jd104gps_mod_spatjoin.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Date: Apr-2010 (process 8 of 14)
    Several additional attributes were added to the shapefile: timediff, fixdepth. Because these depths are not tide corrected, not only do I need to replace the missing CRP depths with values that are close in proximity, but have to be cognizant of the time offset. And although the gpstime and gpstime_1 are in the format HHMMSS, subtracting these values still has some benefit. First, set a definition query on jd104gps_mod_spatjoin_sort.shp to only display the records with depth_m = -9999. Then use the field calculator to calculate gpstime - gpstime_1. For the new fixdepth attribute, select all records where depth_m <> -9999, then use field calculator to set fixdepth = depth_m. Basically, this is just bringing over the good depths. To work on the rest of the depths used a query to select all records where ("timediff" < 60 AND "timediff" > -60) AND "Distance" < 20 AND "depth_m" =-9999. This query attempts to select those records that are spatially close (less than 20 meters), where there are no valid depths (depth_m = -9999) and have a relatively small time difference, which means tidal effect should be minimal. With these records selected, use the field calculator to have fixdepth = depth_m_1. There are a number of anomalous depth values in these records where the HYPACK depth values are 198.5. These values are clearly wrong and the fixdepth values were set to surrounding depth readings of 0.6. The remaining "fixdepth" values were set manually. In most cases this means extrapolating the value of close (spatially and temporally) valid points from either the HYPACK or the CRP system. In some instances these values are probably acceptable, but in some places the gaps are too large to trust these values.

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Date: May-2010 (process 9 of 14)
    Using a bathymetry surface (of all positive values) generated from tide corrected bathymetry points (see irb_bathy to understand processing available at <http://pubs.usgs.gov/of/2011/1039/html/ofr2011-1039-catalog.html>), use VACExtras v 2.1 to extract the bathymetry values at each point location and place in the new attribute hyptidecor. However, the extracted depths are tide corrected, and what are needed in this case is the uncorrected bathymetric values - so the tide information needs to be added back into these values. Within ArcMap 9.2, also add the attribute jday to place the Julian day (104).

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Date: May-2010 (process 10 of 14)
    Then use XTools Pro 5.2 to export the shapefile to a text file. Export jd104gps_mod_spatjoin_sort to jd104gps_mod_spatjoin_sort_exp.txt with the exported fields of gpstime; longitude; latitude; hyptidecor; jday.

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin_sort_exp.txt

    Date: May-2010 (process 11 of 14)
    Run the files through an AWK script to reformat for loading into MATLAB to extract tide information. The tidal correction procedure is described in detail in irb_bathy (available at <http://pubs.usgs.gov/of/2011/1039/html/ofr2011-1039-catalog.html>). In this case, because the tides are being added back in, the MATLAB code is modified slightly so instead of: 
    h_corrected_ir=htrack-tidetrack_ir;
h_corrected_rd=htrack-tidetrack_rd;
use:
h_corrected_ir=htrack+tidetrack_ir;
h_corrected_rd=htrack+tidetrack_rd;

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort_exp.txt

    Data sources produced in this process:

    • bathy.dat

    Date: May-2010 (process 12 of 14)
    Proceed with converting the results to a shapefile and using the weighted distance calculations described in irb_bathy (available at <http://pubs.usgs.gov/of/2011/1039/html/ofr2011-1039-catalog.html>) to ADD the tide information back into the depth values. Now in the jd104gps_mod_spatjoin_sort.shp, add the attribute "addedtide" as double. Since the spatial locations are the same, a spatial join is not necessary, and the shapefiles can be joined record for record based on the FID attribute. Once joined, copy the value from the "tideadded" attribute to the newly created "addedtide" attribute. Then removed the join.

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Data sources produced in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Date: May-2010 (process 13 of 14)
    In order to select the best depth value for every CRP location, it's a combination of already valid values, valid values based on temporal and spatial offset, and values derived by adding tides back to a tidally corrected surface. For this reason, in ArcMap 9.2 a new attribute was added called "bestdepth" as type double to the shapefile jd104gps_mod_spatjoin_sort.shp. First priority is to use actual values, then fill in voids with derived values. Did a query where depth_m <> -9999 and then copied those values to bestdepth. Then did a query: ("timediff" <= 10 AND "timediff" >= -10) AND "timediff" <>0. The "timediff" <> 0 was necessary because where timediff = 0 is where I have valid original CRP depths. The timediff attribute is the result of gpstime - gpstime_1 where gpstime_1 is the HYPACK navigation time. Copy these selected records over to bestdepth from depth_m_1. A value of 10 was chosen because the boat was travelling around 4 knots (2m/sec). That means a value of 10 represents points within 20 meters of the actual navigation reading. That seems reasonably conservative. What this leaves is some within 10 seconds, but that go around the minute mark. For example, if the gpstime is 130355 and the gpstime_1 is 130404, then the timediff is displayed as -49. But in reality, it's only 9 seconds - all an issue with how time is recorded as an attribute. Additional queries were run to accommodate this time oddity.
    Query: "timediff" <= -41 AND "timediff" >= -50
    These are all within 10 seconds, so set bestdepth = depth_m_1.
    Likewise, the opposite situation needed to be handled such as gpstime = 131601 and gpstime_1 = 131554.
    Query: "timediff" >= 41 AND "timediff" <= 50
    And if there's an hour change:
    "timediff" >=4041 AND "timediff" <=4050 (this didn't have any records) "timediff" >=-4050 AND "timediff" <=-4041 (this didn't have any records)
    Now any records without a "bestdepth" ("bestdepth" = 0) the values from "addedtide" were copied over.

    Date: Dec-2010 (process 14 of 14)
    Using ArcMap 9.2, jd104gps_mod_spatjoin_sort.shp was projected from UTM, Zone 18, WGS84 to Geographic, WGS84 using ArcToolbox - Data Management Tools - Projections and Transformations - Feature - Project. The output file was jd104gps_bestdepth.shp (no transformation necessary).

    Data sources used in this process:

    • jd104gps_mod_spatjoin_sort.shp

    Data sources produced in this process:

    • jd104gps_bestdepth.shp

  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?

    The navigation system used was a Lowrance 480M with an LGC-2000 Global Positioning System (GPS) antenna. The antenna was located directly above the fathometer transducer mount point, and approximately 2 meters starboard of the mount point of the towed continuous resistivity profile streamer. GPS data are assumed to be accurate within 10 meters on this survey.

  3. How accurate are the heights or depths?

    All collected bathymetry values were collected by the 200 kHz Lowrance fathometer. The fathometer was mounted starboard side, directly below the GPS antenna. The Lowrance manufacturer indicates the speed of sound used by the system to convert to depths is 4800 feet/second. The depth values are not corrected for the approximately 0.2 m transducer draft. All values are assumed to be accurate to within 1 meter. Some of the depths recorded as attributes are extracted from a gridded surface and are assumed to be accurate within 1 meter.

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

    This point shapefile represents every valid GPS point collected by the Lowrance navigation system recorded by the resistivity acquisition software.

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

    All of the files were handled in the same manner.

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:
Not to be used for navigation. The public domain data from the U.S. Government are freely redistributable with proper metadata and source attribution. Please recognize the U.S. Geological Survey as the originator of the dataset.

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

    VeeAnn A. Cross
    U.S. Geological Survey
    Marine Geologist
    Woods Hole Coastal and Marine Science Center
    Woods Hole, MA 02543-1598

    (508) 548-8700 x2251 (voice)
    (508) 457-2310 (FAX)
    vatnipp@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?

    Neither the U.S. government, the Department of the Interior, nor the USGS, nor any of their employees, contractors, or subcontractors, make any warranty, express or implied, nor assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, nor represent that its use would not infringe on privately owned rights. The act of distribution shall not constitute any such warranty, and no responsibility is assumed by the USGS in the use of these data or related materials. Any use of trade, product, or firm names is for descriptive purposes only and does not imply endorsement by the U.S. Government.

  4. How can I download or order the data?

  5. What hardware or software do I need in order to use the data set?

    This zip file contains data available in Esri point shapefile format. The user must have software capable of uncompressing the zip file and reading/displaying the shapefile.

Who wrote the metadata?

Dates:
Last modified: 30-Jun-2014
Metadata author:
VeeAnn A. Cross
U.S. Geological Survey
Marine Geologist
Woods Hole Coastal and Marine Science Center
Woods Hole, MA 02543-1598

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

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

Generated by mp version 2.9.6 on Mon Jun 30 15:48:04 2014