- Date: 2006 (process 1 of 16)
-
The data were transferred from the logging computer via AGISSAdmin software version 1.03.09. The data files available for this day are L7F1, L8F1, F9L1, F10L1, L10F2, L11F1, L12F1, L13F1, L14F1, L15F1, L16F1, L17F1, L18F1, and L19F1. These files were then transferred via a thumb drive to the processing computer.
- Date: 2006 (process 2 of 16)
-
The first step is to check the navigation recorded in the *.gps file for each line of acquisition. I extracted the $GPRMC line from the CRP GPS files using an AWK script. (* refers to the line name, which for this day are L7F1, L8F1, F9L1, F10L1, L10F2, L11F1, L12F1, L13F1, L14F1, L15F1, L16F1, L17F1, L18F1, and L19F1).
AWK script awkit_tmp:
BEGIN {
FS=","
}
{
FS= ","
ARGC = 2
if ($1=="$GPRMC") {
gpstime = $2
hr = substr($2,1,2)
min = substr($2,3,2)
sec = substr($2,5,2)
latdeg = substr($4,1,2)
latmin = substr($4,3,6)
londeg = substr($6,2,2)
lonmin = substr($6,4,6)
declat = latdeg + (latmin/60)
declon = (londeg + (lonmin/60)) * -1
date = $10
day = substr($10,1,2)
month = substr($10,3,2)
year = substr($10,5,2)
printf("%8.6f, %8.6f, %s:%s:%s, %s, %s\n",declon, declat, hr, min, sec, date, ARGV[2])
}
}
This AWK script was initialized by "doawk" - shell script run under CYGWIN (UNIX like environment that runs under Windows):
files=`ls *.gps | cut -d. -f1`
for file in $files
do
awk -f awkhold $file.gps $file >> resnav_jd250.txt
done
Data sources used in this process:
Data sources produced in this process:
- Date: 2006 (process 3 of 16)
-
This text file (resjustnav_jd250.txt) was loaded as an event them into ArcView 3.3. Displaying these points allowed me to flag the sections of bad navigation.
Data sources used in this process:
- Date: 2006 (process 4 of 16)
-
An ANSI text file containing the ship's navigation and fathometer information was transferred from the ship's system using a thumb drive.
Data sources used in this process:
- Date: 2006 (process 5 of 16)
-
The ship's text navigation file was reformatted using an AWK script into a comma-delimited ANSI text file suitable for loading in the GIS.
AWK script "awknav":
{
shipdate = $1
gpstime = $2
latdeg = substr($5,1,2)
latdecmin = $6
declat = latdeg + (latdecmin/60)
londeg = substr($7,1,3)
londecmin = $8
declon = -1 * (londeg + (londecmin/60))
depmeters = $10 printf("%s, %s, %9.6f, %9.6f, %s\n",shipdate, gpstime, declat, >declon, depmeters)
}
Data sources used in this process:
Data sources produced in this process:
- Date: 2006 (process 6 of 16)
-
I was than able to extract each segment of reformatted ship's navigation that corresponded to the time gaps within my resistivity navigation.
Data sources used in this process:
Data sources produced in this process:
- l7f1_gap1.txt
- l7f1_gap2.txt
- l8f1_gap1.txt
- l8f1_gap2.txt
- Date: 2006 (process 7 of 16)
-
When the navigation glitched for the Lowrance, records were sent to the GPS file, but the times and fixes were bogus. Chuck Worley discovered the glitches were a result of a bad wire associated with the navigation cable. These bogus records start by recording a time of 000001 with the second record showing a time of 000006. Based on the navigation in the rest of the file which has fixes roughly every five seconds, I'm assuming that although the times themselves are bogus, the time interval in seconds is accurately represented. Based on this, I manually went through the ship's navigation segments and manually removed the records I don't need - keeping only those ship fixes that were closest in time to the fixes I believed I needed. Of course the times in the ship's navigation don't match exactly with the times I need from the Lowrance system as the ship's navigation records a fix every 3 or 4 seconds. But simply keeping the closest ship fix in time all fixes were within 1 second relative to the resistivity navigation fix I needed. The resulting files are *trim.txt (where the * refers to the initial gap files from the ship navigation).
Data sources used in this process:
- l7f1_gap1.txt
- l7f1_gap2.txt
- l8f1_gap1.txt
- l8f1_gap2.txt
Data sources produced in this process:
- l7f1_gap1trim.txt
- l7f1_gap2trim.txt
- l8f1_gap1trim.txt
- l8f1_gap2trim.txt
- Date: 2006 (process 8 of 16)
-
I use an AWK script to reformat the "trimmed" ship's navigation and write the output in the $GPRMC, $SDDPT and $SDMTW strings that the resistivity system will need. The ship system doesn't have temperature, so I used a constant value of 24.3 based on the existing temperature information from the Lowrance system. The new files are *.gps (where * refers to the trim prefix file name)
AWK script awknewgps:
BEGIN {
FS=","
}
{
FS=","
alltime=$2
hr=substr($2,1,2)
min=substr($2,4,2)
sec=substr($2,7,2)
month=substr($1,1,2)
day=substr($1,4,2)
yr=substr($1,9,2)
depth=$5
declon=$4 * -1
londeg=int(declon)
lonmin=(declon-londeg)*60
declat=$3
latdeg=int(declat)
latmin=(declat-latdeg)*60 >printf("$GPRMC,%s%s%s,A,%02d%06.3f,N,%03d%06.3f,W,000.0,0,%s%s%s,0,W*73\n",hr,min,sec,latdeg,latmin,londeg,lonmin,day,month,yr)
printf("$SDDPT,%s,0.0*56\n",depth)
printf("$SDMTW,24.3,C*01\n") }
Data sources used in this process:
- l7f1_gap1trim.txt
- l7f1_gap2trim.txt
- l8f1_gap1trim.txt
- l8f1_gap2trim.txt
Data sources produced in this process:
- l7f1_gap1trim.gps
- l7f1_gap2trim.gps
- l8f1_gap1trim.gps
- l8f1_gap2trim.gps
- Date: 2006 (process 9 of 16)
-
I then used VI text editor to insert these properly formatted files into the necessary sections of the resistivity navigation files that had "holidays". I also noticed that each navigation stop/start on the Lowrance system incremented the date stamp by a day. As a precaution, I copied l7f1_mod.gps to l7f1_mod2.gps before fixing this date error. Once I was confident I was fixing it correctly, in line 8 I didn't take the intermediate step.
Data sources used in this process:
- l7f1_gap1trim.gps
- l7f1_gap2trim.gps
- l8f1_gap1trim.gps
- l8f1_gap2trim.gps
Data sources produced in this process:
- l7f1_mod2.gps
- l8f1_mod.gps
- Date: 2006 (process 10 of 16)
-
The STG files that accompany these GPS files also had to be modified. As noted, each glitch in the navigation system caused the date to increment and the times to reset to 000000. I used VI to edit the dates and times in the STG files to correspond to the date and times in the GPS files.
Data sources used in this process:
Data sources produced in this process:
- L7F1_mod.stg
- L8F1_mod.stg
- Date: 2006 (process 11 of 16)
-
Two other lines had navigation gaps. These gaps were the actual absence of any information, so these lines had to be split to enable the resistivity software to process the data. Simply used Microsoft WordPad to delete the one portion of the original navigation and save the file under a new name.
Data sources used in this process:
Data sources produced in this process:
- L10F2_part1.gps
- L10F2_part2.gps
- L13F1_part2.gps
- L13F1_part2.gps
- Date: 2006 (process 12 of 16)
-
To account for the navigation gaps, the STG files of l10f2 and l13f1 also had to be split. This was done in the same manner as splitting the GPS files, where the file was brought into WordPad, the unwanted section deleted, and the file saved under a new name.
Data sources used in this process:
Data sources produced in this process:
- L10F2_part1.stg
- L10F2_part2.stg
- L13F1_part2.stg
- L13F1_part2.stg
- Date: 27-Oct-2016 (process 13 of 16)
-
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 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.
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 14 of 16)
-
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 15 of 16)
-
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 16 of 16)
-
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
