Introduction
The topic this month concerns flags. Not the flapping banners that inspire us with pride and patriotism, but rather position flags. Position flags are markers that provide information about each position in a file. The inspiration for the topic this month comes from an incident in Florida.

The scene of the crime
A GIS coordinator was recently discussing her GPS data with the GPS manufacturer. Her questions were quite straight forward. The field crews were collecting water well locations utilizing real-time differential GPS. Apparently some field crews did not have access to a real-time transmission, and thus stored uncorrected position data. All of the field data from all of the field workers was combined for import to a GIS. However, because some of the data was real-time corrected and some was not, the final data had a wide variance in spatial accuracy. The real-time corrected data was typically in the 1-2 meter range. Meanwhile, the uncorrected data was only accurate to about 100 meters. The GIS coordinator was seeking guidance about which GPS position data were accurate and which were not. Her goal was to isolate the uncorrected data so that she could correct these positions via post-processing before transferring them into the GIS.
      The GPS service technician back at the manufacturer looked at the data and had a rather unexpected answer for the coordinator. His answer was, "This isn't GPS data!" The manufacturer examined something known as position flags to determine which positions were accurate and which were not. However, these same flags store a lot more detail than only accuracy. An experienced user (or any user who read the manual) could glance at the positions in the file and know instantly that these positions were not computed by a GPS receiver, but rather were simply "random numbers" typed in at the front panel by the user in the field. It seems that rather than run around in the hot sun all day, some of her 'less reliable' field laborers had spent the day in the pub and manually typed in approximate coordinates that they had simply read off of paper maps!
      Fortunately the GIS coordinator was able to easily determine which positions were bogus and could then arrange to have the appropriate data recollected (and to have a few workers flogged). And everybody lived happily ever after.

What is a flag?
The story above is true. This illustrates the necessity to have access to background details about your GPS data. The details need not be limited to accuracy information. Individual positions or features in a data file can be tagged with details about receiver type, correction status, statistical details, PDOP, number of satellites used, data origin (e.g. GPS/non-GPS), or a variety of other details in addition to the expected accuracy.
      Unfortunately, very few GPS manufacturers are presently storing such useful details. Of those who are, they are usually only storing a limited set of information. If you are attempting to evaluate this aspect of a GPS-based data collection system, here are a few thing to keep in mind. Figure 1 is an example of some GPS positions that have flags attached.

Things to look for in flags
Which details are stored?
      There is presently no GPS manufacturer who stores every detail possible. Typically, your application will dictate which details are most important to you personally. For example, if your greatest concern is data accuracy, and you are pushing the accuracy limit of your equipment, you will want some statistical position flags that ensure that your data does indeed meet your accuracy requirements. On the other hand, it may be that you are perfectly satisfied with the general accuracy of your system and you are more concerned with the data integrity. In this case, you may be more interested in the data collection history. Position flags such as receiver type used, configuration settings, operator name, or whether the position was indeed computed from GPS satellites as opposed to having been manually entered.

How are the details stored?
      • Are they actually stored in the data file(s)? In some systems a report is presented on the screen of your PC. You are free to print and save this report, however, no details are actually stored in the file. This is better than nothing, however, if the report is misplaced, you no longer have access to the required details.
      • When details are indeed stored in the file, are they stored as separate records in the file (in addition to the position or satellite data)? Alternatively, are they stored as an integral part of each position record or feature? Consider the impact on the overall size of the resulting file. Depending on what kind of details you require, you may have to sacrifice a considerable amount of memory that could otherwise be used for collecting more data in a day.
      • Are the position flags stored automatically? Do you have to turn them on/off? Alternatively, are these details always written without you having to configure them manually?
      Ultimately, there is no one method of handling flags that is superior to all others. You'll just have to evaluate all scenarios in the light of what you require for your application.

Can the flags actually be used?
This may seem like a silly question. However you would be wise to determine whether the GPS system includes tools that can be used to read, evaluate, and/or filter your data based upon the flag details. For example, does the GPS system include software that can be used to filter data? If so, a file which contains a random mixture of corrected and uncorrected data be selectively filtered to retain only the accurate, corrected data. Alternatively, does the GPS system include software that can be used to filter a file based upon PDOP? If so, data files that were accidentally collected with a mixture of high and low PDOP could be selectively divided based upon the PDOP of the satellites used from moment to moment. This allows the user to surgically remove from a data file only the positions that may be inaccurate due to high PDOP conditions. Such tools can prove to be extremely valuable in the process of applying quality control to the GPS data for your GIS.

About the Author:
Chuck Gilbert has over a decade of experience as a GPS user. He has been employed as an applications engineer for Trimble Navigation since 1989. If you have a suggestion or request for a future article, please drop a line to Chuck.

Back