Consumer-grade GPS for efficient GIS and mapping applications

The GPS is a ubiquitous tool on the planet today. Its ability to pinpoint a person’s position on the globe, and store information about that location has been one of the most significant contributions to society in the latter Twentieth Century. Currently, the systematic collection of geospatial attribute data is limited to very expensive GPS receivers and specially trained personnel. The general procedure for collecting geospatial attributes with the consumer-grade GPS has required the use of “add-ons”, such as hand-held computers, laptops and palm pilots. These add-ons are frequently outside of the financial and technical reach of many communities, organizations and under funded agencies. The protocols and procedures presented here are designed to modify and merge existing methods and technologies to overcome these financial and technical barriers.

Methodology

The GPS provides four major data collection functions:

(1) precise location (waypoints);
(2) precise time (a date/time stamp at waypoint collection);
(3) a name for that location; and
(4) tracks (routinely collected by the GPS, which in turn can display an area surveyed).

While items: One (1), Two (2) and Four (4) are self descriptive: item number Three (3) is the data collection engine for this naming convention protocol. It is in the waypoint name that the user is able to record specific data attributes about that location. For example, currently and commonly the waypoint name provides a location attribute such as “HOME,” for a persons’ domicile or an abbreviation like “ST_J_LK,” for a place like St. John’s Lake. In the GPS receiver’s small database, the waypoint name is also the primary key field, in which no two names can be alike. A common number of character spaces provided on today’s GPS’ are ten and the number of available alphanumeric characters are 36 (10 numerals and 26 letters).

By using a data dictionary and a set of data structures for the waypoint name, even casual GPS users can provide organizations with high quality, accurate and sophisticated geospatial data. This data, created with the waypoint name, is both a unique descriptor for that location and the primary key value for the relational database. Also, once the waypoint name is parsed, a set of data fields are created with very specific attribute information about the location surveyed. At a minimum, the waypoint name and subsequent parsed fields should describe: the GPS (including the operator); data id and something about that location. In the event of an oil spill, additional data might include information on: shoreline type; presence of oil; vegetation; birds; animals; mammals and fish. An entire list of possible items need not be included in the lists to describe the shoreline, vegetation, etc. just those most common to the area. All of the fields created in and parsed out from the naming convention will be sorted out in the RDBMS.

Prior to any field use, a data dictionary should be established. The nature of the survey will determine the format and content of the naming protocol and structure. For example a set of protocols for mapping out a trail system might only have five data entries in the name: GPS ID, Trail ID, Data ID, and Trail Attribute ID. The number of character spaces allotted for each data ID will depend on the number of items involved in the survey. If you do not expect to ever have more than 36 GPS receivers in your database, then one character space will be enough. The same is true for the number of trails to be surveyed. On the other hand, if the number of GPS units (or trails) can be expected to exceed the amount of 36 over the life of the project, then two character spaces should be allocated. Two character spaces will provide 1296 alphanumeric ID combinations. So, a small trail mapping project might only have one character space allocated for the GPS ID, one space allocated for the Trail ID, two spaces assigned to the Data ID and one space allocated to the Trail Attribute ID. The waypoint name might look like this: “270C4”. This waypoint name, parsed out in the database provides the following information: GPS #2 (owner, make and model); Trail #7 (St. John’s Lake Trail, 23.8 km, moderate difficulty, average round trip speed 6 ~ 8 hours); Data ID #0C (the 12th data entry for that trail); Trail Attribute ID #4 (a bridge). Connect this data into a GIS and you have a trail made from tracks whose symbology indicates moderate difficulty and a waypoint on that trail that indicates a bridge. This same set of protocols and database design can now be modified for Search and Rescue (SAR): Trail ID becomes Sector ID; and the Trail Attribute ID becomes Hazard/Item of Interest Attribute ID. Everything else stays the same.

Now imagine, 15 SAR personnel going out looking for a lost hiker. Each has their GPS receiver turned on, recording their tracks. Each member of the team also has a waypoint naming convention key that explains how to enter the waypoint name. As each person returns to base, the data in the GPS is downloaded directly into a database and immediately displayed in the GIS for review and analysis. At the end of the day a map document is produced of their efforts, with minimal effort and within a few minutes.

Coastal Oil Spill Model

Often when an environmental disaster strikes, the nearest local community is the first to know and the first to respond. Federal and state government resources, along with private contractors, though experts in their field, often take days to fully mobilize. During that time, precious information is lost through the absence of data. This is an opportunity where members of the community, with local knowledge of plants, wildlife, and terrain, can be mobilized to collect high quality, precision data with simple, consumer-grade GPS receivers.

If a community is fortunate: then they have a flexible response plan in place and have had an opportunity practice that plan. The elements of a response plan are likely to look like the following outline:

• Purchase GPS units (or find out who has them)
• Develop a data dictionary
• Develop a database (more precisely known as a Relational Database   Management System or RDBMS)
• Figure 1, GPS waypoint naming convention for the oil spill model
• Store the Data Dictionary in the RDBMS (this can then be printed and distributed on a moments notice)
• Simulate emergency situations and train with the GPS receivers and GIS resources

In Figure 1, it is important to note that several of the fields only allow for the specific choice of 33 values, where three input values are reserve characters for Not Present (0), Not Known (1) and Other (Z). This is particularly useful when a single character space is being used to identify an attribute. In many cases, 33 variables will be enough to identify the presence of a common feature of concern

Data Collection

Once and emergency has been identified it will be important to contact community members with knowledge of all aspects of the local geography, including the weather, vegetation and wildlife. Next, pass out GPS receivers, the naming convention keys and a map, along with a track line or area to cover.

In the field, the waypoint data is collected according to established protocols. This means that each waypoint is given a name, and each character in the waypoint name corresponds to a specific attribute value in the data dictionary and that attribute value is specific to the location in the waypoint name. A written record is made of the data point and this includes:

• Time of data entry
• Waypoint name
• Attributes identified

Additionally, tracks from the GPS are collected according to protocol. Most likely this will simply involve setting the “polling” rate or the position data collection rate at a specific interval. This may be a standardized rate of 10, 20, 30 or 60 seconds, or it may vary with each GPS in order to distinguish
one GPS unit from another.

Data Integration

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.

Data Management

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.

UTraMP Reference Tables:

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.

UTraMP Transaction Tables:

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

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.

Data Analysis

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.

Summary

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.

Acknowledgements

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.