Bratton, John F. , and Cross, VeeAnn A. , 2005, Raw Continuous Resistivity Profiles Collected in the Neuse River, May 4, 2005:.This is part of the following larger work.Online Links:
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, Coastal and Marine Geology Program, Woods Hole Science Center, Woods Hole, MA.Online Links:
(508) 548-8700 x2254 (voice)
(508) 457-2310 (FAX)
To provide the raw resistivity data as collected by the AGI SuperSting system.
1) 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. 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. 2) 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. 3) 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. The joined shapefile table was then exported to a text file. 4) 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. This happened to gps_fixing.shp 5) 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). 6) 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. 7) 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. 8) 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. **Because my distance and azimuth readings are based on the shapefile being projected, I exported the files as projected shapefiles. 9) 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 (gps_fixing) with the DISTANCE FIELD being sum_dist, and the AZIMUTH FIELD being new_bear. Select all the fields for the new shapefile. What's happening is that only points that need moving have values other than zeros in the sum_dist and new_bear fields, So those are the only points that need to be moved are moved. The new shapefiles were called: templ2f1_fix.shp, templ3f1_fix.shp, templ5f1_fix.shp, templ6f1_fix.shp 10) 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. 11) 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. 12) 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. 13) I then took these text files and ran them through the awk script "awknewgps" to output repaired GPS files for use with Marine Log Manager.
Of note, even though the navigational fixes are duplicates in the original GPS files, the fathometer and temperature values are assumed to be valid.
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.
Downloadable Data
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.
(508) 548-8700 x2251 (voice)
(508) 457-2310 (FAX)
vatnipp@usgs.gov