Upon returning from the field, each member of the data collection team needs to download the data from their GPS and load it into the relation database management system. This may be a direct download to the database, or it may involve more steps. For the purpose of this protocol set, we will use more steps to ensure data quality.

This is more likely to be necessary if you are using members of a community who have not had much training in emergency procedures or GPS units.

To begin with, download the raw waypoint and track data from GPS to a text file. Next, label this file with the date of data collection (in reverse format), the letter “r” (indicating raw data), underscore, and first waypoint name (i.e. “060416r_ 0101011). By including the first waypoint in the file name you will be identifying the GPS (possibly the user) and the area surveyed.

Next, import the file into a spreadsheet. This will allow for easy and efficient data checking and editing if necessary, essential for quality control. Each user should be responsible for checking their own data for accuracy. If necessary, this should be done with a member of the GIS team.

Next, import the “clean” data (waypoints and tracks) into the database. All of the waypoints can go into a single table. The waypoint naming convention ensures that each waypoint can effectively be used as a primary key value. Additionally, the naming convention allows for extracting information related to a single GPS or survey area. The database administrator (DBA) may want to import track data into tables designed for each GPS. This would be the easiest and most effective way to distinguish one set of GPS tracks from another.

The RDBMS will need to have a set of reference tables and transaction tables. The example set listed below uses the Unalaska Trail Mapping Project (UTraMP) model. The UTraMP model is particularly useful in that it is the easiest to understand and modify for single attribute acquisition, like stream surveys or search and rescue operations.

GPS reference table (tbl_GPSId)
• cGPS_ID (GPS receiver Id number in the database)
• cGPS_Make (Manufacturer)
• cGPS_Model (Model of GPS)
• cGPS_SN (Serial number)
• cGPS_Owner (Owner or operator)
• cGPS_Name (Written on the case of the GPS, i.e. “CRC-1,” in this case it meant the first GPS unit for that organization. Others were labeled CRC-2, CRC-3, etc.)

Trails reference table (tbl_TrailInfo) • cTrail_ID (Trail ID number in the database)
• cTrail_Name (Name)
• nTrail_Length (the trail length in linear distance)
• nTrail_Time (the amount of time it takes to go out and come back)
• cTrail_Difficulty (on a scale of 1 ~ 3)

Trail Attribute table (tbl_WayPtsId)
• cTrail_AttributeID (This was the primary key value for the table and the waypoint key value for the naming protocol)
• cTrail_AtributeDescription (This was the description of the ID value, i.e.: 1 = Start of trail; C = Cabin. Note that the Attribute ID was a mnemonic to the description.

GPS Waypoints table (tbl_WyPts)
• cType (this field is information generated by the GPS unit to indicate whether the data is a waypoint or track point)
• cWypt_Name (a user defined field, in this case, this is where the attribute information for the specific location is stored)
• Figure 2, Data flow from the GPS unit to the RDBMS
• nLat (Latitude, generated by the GPS receiver)
• nLon (Longitude, generated by the GPS receiver)
• dtTime (Time and date, generated by the GPS receiver)

GPS Tracks table (tbl_Trax)
• cType (this field is information generated by the GPS unit to indicate whether the data is a waypoint or track point)
• nLat (Latitude, generated by the GPS receiver)
• nLon (Longitude, generated by the GPS receiver)
• nAlt (Based on the GPS datum, generated by the GPS receiver)

Data manipulation is done through the use of queries: either by combining tables or queries of related data and/ or running calculations on them. In this database, the common data manipulation is parsing the Waypoint Name field (cWyPt_Id) and “joining” or linking the newly created parsed fields with the primary key fields of the associated attribute table.

Figure 3, is an illustration of the data flow for the Selandang Ayu Data Model for oil spills. The illustration is simplified from the actual RDBMS. In the actual RDBMS all data tables become queries before any relation is applied. This is done as a precaution to protect the integrity of the original data.

At this point, the geospatial data is ready for visualization in a GIS. Now the management team can see what areas have been surveyed, who surveyed them and what was found. Most likely, you will have had to acquire or create our own base maps. You will have had to ensure that all of the maps and data are in the same projection with the same datum and you will have had to create symbology for the different attributes of your data.

At this point, you are also ready to perform advanced analysis on your data. From here you can buffer points and lines; and use other tools that will allow you to clip, merge and intersect your GPS data with other map features. Also, if this were a disaster, you could use advanced statistical calculations on the collected data in order to evaluate the nature and spread of a given contaminate. If this were a SAR operation, a view shed analysis could be performed from the elevation of the hiker and a maximum area of observation could be obtained.

A coastal resource assessment protocol has been investigated using this protocol. As of this time it is still in development. It was originally a modified version of the Oil Spill model, but going through a list of items and plugging them into a GPS was overly tedious and time consuming. Possibly, a better model, soon to be tested, involves limiting the number of items of concern to subsistence species or indicator species or both. In this case the data field would identify either a Boolean value of either presence or no presence, or presence and quantity.

The elimination of Selective Availability and the incorporation of WAAS and
DGPS have greatly increased the accuracy and precision of the consumer-grade GPS. This new, high precision tool has the potential to greater xpand
the resources of communities to respond to challenging situations that require immediate geospatial information. Additionally, having this information and the knowledge that comes with it, as an emergency unfolds, can empower a community to make better decisions with the hope of a better outcome.

The author would like to thank Wendy Svarny-Hawthorne and the shareholders of the Ounalashka Corporation for their support in the UTraMP project, without them this protocol concept and method could not have been so rigorously field tested. Further thanks go out to University of Alaska Fairbanks professors, Anupma Prakash and Michael Sfraga, both of whom gave their time and support to write up this project. Anupma was kind enough to read and comment on several drafts. Finally, Tom Heinrich from the Geographic Information Network of Alaska encouraged this project and helped clean up several working drafts of this document. His kindness and talents are greatly appreciated.