GPS Consumer Series: Translating GPS Data to a GIS, CAD System or Database Format, Part III By Chuck Gilbert Introduction This column in October 1996 was the first of a series of columns regarding the importance of software in a GPS-based data collection system; specifically export programs. Export programs are used to export GPS data from its native GPS storage format to a GIS, CAD, or 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. However, there are many additional capabilities to look for that can enhance this process, making it much more powerful and useful. This month continues the discussion of export programs included with GPS-based data capture systems; specifically features that control details of the selected output format. Coffee or Tea? 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 GIS or database interchange format of the user's choice. There are dozens of industry standard interchange formats to choose from. However, in any given data format, there can be a variety of options available. The past two columns described several "non-format-specific" options that ought to be considered by a user, such as the coordinate system or units that are used to represent the data. A good example of a "non-format-specific" option might be whether the altitude units are presented in feet or meters. In virtually any format it would be valid to choose either feet or meters. (Of course only one would be appropriate to the user's GIS, but use of either unit is allowed by the rules that define the structure of the data format.) Let us consider, however, a few options that are "format specific." Coffee? With or without sugar? Consider, for example, the DXF format. This is a specific, well-defined format used throughout the GIS industry. The use of DXF has become so widespread that DXF files can even be read by some word processors and other non-GIS applications. However there are a multitude of ways that a given set of data could be expressed in the DXF format. To begin with, the DXF format exists in two very different flavors; there is a binary variety of the DXF format, and an ASCII variety. If your GIS or CAD can read only one of these versions, then the other version would be totally useless to you. If you rely on DXF for data interchange, make certain that the export program you buy can provide the appropriate variety. Also specific to the DXF format is the insertion point. When a data set is expressed in DXF format the user may wish to control the value that is used as the insertion point. The insertion point value will impact where the data appears spatially with respect to the coordinate system used by your GIS, CAD or database. Figure 1 depicts a control that allows the user to choose an insertion point of 0,0 or to have one computed automatically based upon the centroid of the data to be exported. Another option specific to the DXF format is the concept of blocks. Whether the user elects to export GPS data to the DXF format in blocks or not in blocks will have an impact on how the attribute data is handled upon later import. When shopping for a GPS, inquire whether the GPS export software gives users the option of whether or not to utilize DXF block structure. (See Figure 1.) Whether or not you use blocks or an insertion point value, you will still have a DXF file, however which options are selected could determine how easy it is to later import the file or even whether your GIS is able to import the file at all. The above are examples of options that pertain specifically to DXF files. There are also several format-specific options that are common amongst several different formats. Following are descriptions of a few additional format options that can apply to virtually any GIS, CAD or database interchange format. Control of layer usage When an export program allows export to formats that can support multiple data layers, there should always be an option to control use of these layers. Figure 1 depicts a control that allows the user to select whether all feature types (such as trees, manholes, roads, wetland areas, etc.) are put into separate layers or whether they are all written together into one big layer. Code values The use of code values is a useful feature that spans both the field data collection software and the office export software. In the field, some GPS-based data collectors will allow the user to select attributes from a pre-defined menu. To simplify this task even more for the user in the field, some systems will provide the pre-defined menu in terms of clear, complete words or phases; although the intention is to later export an abbreviated database code value. For example, for the attribute "Material," the field user may select from a list that contains Concrete, Asphalt, Wood, Steel, Aluminum, and Brass. However the export program will contain a related option that allows the GIS coordinator to choose whether to export the actual word (such as "Steel") or rather to export an appropriate code value (such as "ML67") as depicted below. This functionality allows export of the desired information while keeping the equipment easy to use in the field. Concrete TR17 Asphalt TR22 Wood WD08 Steel ML67 Aluminum ML43 Brass ML59 Illegal character replacement Whenever the field user is typing in information there is potential for conflict with the target database. The user may enter characters that are invalid or otherwise unacceptable to the destination program. A classic example would be when the data will ultimately be exported as a comma delimited file; and the field operator types in a single attribute value such as "very, very, large" or "14,385." There is danger that the target database may interpret the string as multiple values rather than as one value (e.g. one attribute value of "14" and another attribute value of "385"). Alternatively, a similar problem may occur if the attribute value contains illegal characters such as ( ) ? / \ { } * etc. A very handy option in an export program is the ability to detect illegal characters and to automatically replace them with some other innocuous character. Configurable starting ID Some formats require that the spatial data and the attribute values be written to separate files. When this is the case it may be necessary for a unique identification number to be assigned to each attribute. This number will preserve the relationship between any features attributes and spatial coordinates. Some export program give the user some control over the initial value for such identification numbers. (See Figure 2.) Export to DOS, UNIX or Macintosh platforms The majority of GPS export programs are written to be run on a personal computer. However, the target database may be a program that runs on a UNIX platform or perhaps on a Macintosh computer. Other tools exist, and it is generally not too difficult to transfer data between these systems. However, that's just one more thing for the user to remember and to deal with. Another useful feature allows the user to simply select the target platform and the data will be written appropriately. 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 the applicable potential pitfalls described above. It is a trivial programming task to simply dump the GPS data and attributes into a different format. However, if you expect to be able to import that data easily, you may require a lot more control over a few of these format options. There are many benefits to using a GPS-based data capture system. Most people immediately think of the advantages in spatial accuracy, attribute validation, and reduced time in the field. However, one of the biggest benefits of using GPS can be the extremely easy and efficient transfer of that data from the GPS to your GIS, CAD, or database. There are GPS recievers that can make the export process extremely elegant. It's an injustice to the GPS industry when somebody purchases a system that allows them to collect data efficiently, but does not allow them to efficiently transfer that data to the application where it is really needed. 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 care of EOM, 13741 E. Rice Place, Suite 200, Aurora, CO 80015, fax to 303-690-2522, or send via e-mail: [email protected] Back |