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.

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.

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

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.