| GPS: GPS Consumer Series: Translating GPS Data to a GIS, CAD System or Database Format, Part III
By Chuck Gilbert Introduction
Last month began a series of columns about the importance of the software component of a GPS-based data collection system. This month continues the discussion of the software component of such systems.
All GPS' designed for GIS data collection have associated software. The software is the component that determines how much power and flexibility the data collection system will have. Software alone can make the difference between a powerful GIS data collection tool, and a sophisticated plaything. Therefore, it's no surprise that sometimes the software is included in the purchase price of a GPS, other times it is only available at an additional cost of hundreds or even thousands of dollars. When comparing prices, be sure to ask for a price that includes ALL of the "optional" software components that might be required. A few things to think about regarding data export
The last step in GPS-based data collection is to transfer the data from the field device to the target GIS or database. In order to efficiently handle large quantities of data, most GPS' store data internally in their own proprietary formats. Data transfer from a GPS receiver to a GIS is typically done by running an export program that will convert the data from the proprietary, internal storage format to the database interchange format of the user's choice.
At the most basic level, this data export can be handled in a very simplistic manner: simply dumping the coordinates and attributes as a comma delimited file. Last month we described several additional capabilities to look for that can enhance this process making it much more powerful and useful. A few examples of these additional capabilities included:
• batch processing
• creation of metadata
• various ways of presenting QA/QC information
• creation of macro files
• geodetic datum transformations
• customizable ASCII output formats
• automatic generation of new features and attribute values What you see is what you get? (Not always!)
When evaluating GPS/GIS export software it is always advisable to look at the exported product. The first consideration is accuracy. Are the exported data an exact match to the data that was collected in the field? This might appear to be an overly simplistic check, however there are several items that are worth examining more closely.
Did all of the attribute data get exported? Check to ensure that all of the attribute data recorded in the field was actually exported to the output file(s). For example, suppose you have recorded "Utility Poles" with 75 attributes associated with each pole. There are data collection systems on the market that will allow you to store dozens of attribute values for every feature that you visit in the field. However, when you attempt to export your data, you may find that a maximum of only seven or eight attributes can be exported for any given feature! The first several attribute values are exported, however the last 60 or 70 attributes are simply discarded by the export program. This is not a good sign.
Are all of the attribute and feature names transferred accurately to the GIS? Some GPS' are primitive to the point that the user is unable to pre-define the features and attributes to be collected. In this case the user might have to type in a long character string at each feature (including delimiters such as commas) and this string would later be exported. However, most systems are now sophisticated enough to store a predefined list of the features, attributes, and attribute values.
When this pre-defined data structure is exported, check to see whether the overlying structure is exported along with the attribute values. For example, in the Pole feature described above there are several attribute names such as height, material, loading type, pole ID, etc. These attribute names will normally serve as field names in the target database as depicted in Figure 2b.
Figure 2b depicts an example of an export process where the original attribute names have been irrecoverably lost and replaced with dummy names such as ATTRVAL1, ATTRVAL2, etc. In this scenario it may be impossible for the user to tell various attribute values apart. The problem is most severe with numeric attribute values and with Boolean attribute values. For example, with the values 12, 64, 3.7, and 1.203348 depicted in Figure 2b; after export, it is impossible to know which of these values represents "height," which is "voltage," which is "line tension," etc.
Are different features automatically placed into the appropriate data layers? It is also important that different types of data are appropriately segregated. For example, suppose your data collection session will involve the collection of three different types of point features (perhaps Poles, Hydrants, and Trees). At a minimum, when the data is exported the poles should end up together in a single data layer, the trees together in a different layer, and so on. ( A really nice program might even give the user an option to choose how the various features are grouped into various data layers) A well designed export program will not allow the user to accidentally put all features, regardless of data structure, into the same data layer. This would result in a hopelessly mixed up database, as shown above. Show me the future...
The old adage "What you see is what you get" makes the assumption that you actually can "see" something. A very simple, yet helpful, feature to look for in an export program is a summary of exactly "what" is about to be exported. There are often so many options, switches, user choices, and settings, that it can be difficult to know exactly how the program is presently configured to export the data. Look for an obvious, easily accessible summary screen that indicates at least what format, coordinate system, and datum are presently set for the export process.
Additionally, such a summary should indicate which features are about to be exported; and which, if any, will not be exported. Typically, the user will only have to export the file one time. This is because if all features have been sorted automatically into their respective layers by the program, the user will be able to run the program once and all of the features in the file will have been handled appropriately. It is very nice if the program will "filter" the data, allowing the user to choose which features to export and which not to export. (Next month's column will discuss filtering of exported GPS data in greater detail.) At the other extreme are programs that can export only one type of data at a time (such as "point features" only, or "line features" only) thus forcing the user to make multiple export runs just to export the data from a single file. Summary
Collecting data in the field is a pointless endeavor if you cannot effectively export this new data to your database. Before purchasing any GPS data collection system a user would be wise to insist upon an actual demonstration of many (if not all) of the potential pitfalls described above.
It is a trivial programming task to simply dump the new data to an ASCII file. However, you may require a lot more in order to have an accountable data source that is suitable for use in your GIS. Bear in mind that the data you collect could be used for many years and for applications that you cannot foresee. Automation and data validation are important features in an export program not only for the time they will save but even more so for the errors that they can help prevent. 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. Back |
