IN WHICH you learn approaches to converting GPS-software1data files to GIS-software data files,^practice with sample GPS and digitized shape files and coverages, and then under take the process on your own.
OVERVIEW
Another Datum Lesson: I teach at the University of Kentucky’s Department of Geography, in Lexington. Several years ago I borrowed a GPS receiver from Trimble Navigation to use in a class. It had occurred to me that our departmental faculty directory listed names, office and home addresses,phone numbers, and so on, but not, as seemed appropriate for geographers,their geographic coordinates. So I sent my students out to park in my colleagues’ driveways and collect GPS data, which we convened to an ArcInfo coverage based on World Geodetic System of 1984 (WGS84) Universal Transverse Mercator (UTM) coordinates.
We then digitized the major roads from Lexington-area U.S. Geological Survey (USGS) 7.5 minute topographic quad maps based on the North American Datum of 1927 (NAD27). The maps indicated that to convert NAD27 toNAD83 (which is within centimeters of WGS84), one should move the gridlines 4 meters south and 6 meters west—hardly an issue for us, because our accuracy was limited by selective availability to perhaps 50 meters when calculated over a number of measurements. It was, therefore, distressing when a graphic overlay of these two coverages put the current departmental chair’s house smack in the median of Lexington’s limited-access beltway.(He, in fact, lives a couple of football fields north of there.)
What I learned, the embarrassing way, was that while the area’s latitude and longitude coordinates were adjusted by a few meters in the 1927-to-1983 datum change, the UTM coordinates were adjusted by more than200 meters in a north-south direction! So the statement on the map that the gridlines can be moved only a few meters was misleading—it referred only to the latitude and longitude grid lines. The UTM grid and the State Plane grid had much greater changes.
Reviewing What You Know
You have been given, or you have collected, files with the extensions SSF (Standard Storage Format) or COR (for differentially CORrected) files. These files have been processed and displayed using the Trimble Pathfinder Office software. Your goal now is to use these data files in a Geographic Information System (GIS) where they can be considered with many other data sources that you may have available. This is not a difficult process but you really must be careful: it is quite easy to get what looks like a reasonable GIS file, but one that has the locations wrong, thus making the activity worse than useless.
The key to converting from Trimble files to ESRI files is to know that you need only convert from SSF (or COR) files to what is called an ArcInfo coverage or to an Arc View shapefile. Once a coverage or shapefile has been obtained, the entire range of ESRI products is available for your use. It is also true that, no matter which Trimble products you use, ultimately you will have files in their standard file format. So it is as though you have a "data tunnel," with wide ranges of products on each side but with the restriction that the data must flow through a narrow passage (please see Figure 6—1).
The process of making an ESRI coverage begins with the Pathfinder Office software. This GPS software will generate a set of files. These files are not ESRI coverage files, but rather are files that ArcInfo commands will use to create the proper coverage. So you will be executing a multistep process. The result ultimately will be an ArcInfo coverage, which is a DOS, Windows, or UNIX directory (aka a folder) containing a number of files.
The process of making an Arc View shapefile is more direct. Pathfinder Office generates a shapefile file (actually, three or more you will be executing a multistep process. The result ultimately will be an ArcInfo coverage, which is a DOS, Windows, or UNIX directory (aka a folder) containing a number of files.
Figure 6-1. Data Tunnel: Trimble GPS data to ESRI products.
The process of making an Arc View shapefile is more direct. Pathfinder Office generates a shapefile file (actually, three or more files in the same directory are needed to make an Arc View "shapefile") that are read directly by Arc View.
The reason to use a GIS with GPS data is to combine locational data from a variety of sources. So, first and foremost, you must ascertain the parameters of the existing ESRI coverages or shapefiles into which you wish to integrate the GPS data. If you get this wrong, everything will be wrong thenceforth. Among the things you must consider are:
• geodetic datum (and work in North America choices are usually NAD27, NAD83, WGS84)
• projection, if any, used to convert the data from latitude-longitude representation to a Cartesian coordinate system,
• units of linear measure, (e.g., meters, miles, survey feet, and many more), and
• units of angular measure (almost always degrees, but the issue of how fractional parts of a degree are represented can complicate things).
Prescription for Failure: Incorrect Parameters
In the United States, the values are different in the north-south direction about 200 meters, due primarily to humans learning more about the shape of their Earth. In the Western United States the east-west difference can be around 100 meters (e.g., Seattle area: 93 meters; San Diego area: 79 meters); it is usually less in the eastern part of the country (e.g., Bangor, ME area: 50 meters; Miami area: 17 meters; Lexington, KY area: 2 meters). You need to be concerned that you convert the GPS file to the datum used by any shapefile or coverage you wish to combine with the GPS data. You may determine the datum of the coverage in a variety of ways. If your data are in ArcInfo coverage format there may be an ASCII "prj" (projection) file that describes the parameters of the dataset. If you are using shapefiles the information may be present as well; it would be found in a file with the extension "prj" appended to the name of the shapefile. A projection file contains information such as:
|
Projection |
STATEPLANE |
|
Zone |
3976 |
|
Datum |
NAD83 |
|
Zunits |
NO |
|
Units |
FEET3 |
|
Spheroid |
GRS1980 |
|
Xshift |
0.00000000000 |
|
Yshift |
0.00000000000 |
|
Parameters |
You should probably carefully investigate the sources of the data and their processing history so you can be certain of the datum and other projection parameters used.
Projection: As you will recall, the 2-D components of the Trimble SSF and COR files represent data in the latitude and longitude datum of WGS84, though they may be displayed in other forms. A fundamental dilemma of a spatial analyst is that the most accurate way to depict a point on the earth’s surface is with latitude and longitude, but the numbers that represent such a point are in a coordinate system (spherical) that makes it harder to use these numbers in calculation for such quantities as distance and direction. Making these calculations in a projection is easier, but, of course, you get a (usually, slightly, if you are careful) wrong answer.
Further, maps that cover a lot of area that are shown in latitude-longitude are (usually) badly distorted visually, so most GIS users elect to store data in some projection in which the horizontal and vertical distances on the map correspond to the east-west and north-south distances on the Earth’s surface. These maps appear (generally) much less distorted. However, there is now actual mathematical distortion for all but a few points. There is really no good solution to this dilemma; you must accept some inaccuracy.
What’s vital, however, is that you tell the Trimble conversion process the correct projection to use so that the inaccuracies in your GPS data will be consistent with those in the other data your are working with. Arc View 3.x allows you to display data in another coordinate system besides the one in which it is recorded. Further, Arc View 3.2 contains routines which allow you to convert original data from one projection to another.
Linear Measurement Units: The choices are meters, feet (international), and survey feet. Survey feet formed the basis of the NAD27 datum4; international feet were used in NAD83 and WGS84. What’s the difference? Not much, but enough to be significant in some situations. The differences come from a slight distortion of each English unit to make it conform to the metric system. An international foot is based on the idea that there are exactly 0.0254 meters in an inch. A survey foot is based on the equality of exactly 39.37 inches and a meter. If these two conversions were equivalent, you should get exactly the pure, unitless number one (1.0000000…) when you multiply them (0. 0254 meters per inch times 39.37 inches per meter). They aren’t and you won’t. What is the product? Use a calculator.
The fractional part may look like an insignificant number, but it can mean a matter of several feet across a State Plane Coordinate zone.
Angular Measurement Format: Angular measurement units are important only if you are converting a file to a coverage which uses the lat-lon graticule directly. If you do use the graticule, you will want to select degrees, and decimal fractions thereof, because ESRI products don’t directly utilize minutes and seconds as coordinate values.
The Old Conundrum: the "Spherical" Earth and the Flat Map
The GPS data in the receiver and in SSF files are stored in latitude, longitude, and height above ellipsoid coordinates. You can, of course, make ESRI shapefiles or coverages with latitude and longitude directly, as long as you select degrees and fractions of a degree as the output numbers, being sure to use enough decimal places. You may want to do this if you are going to combine the data with other coverages that are stored in that "projection." After all, this is the most fundamental, accurate way. You must realize, however, that any graphic representation of these data will be badly distorted, except near the equator where a degree of longitude covers approximately the same distance as a degree of latitude. Anywhere else, any image of the coverage is visually distorted, and the lengths of most lines is virtually meaningless, since the "length" is based on differences between latitude and longitude numbers. Such numbers do not provide a Cartesian two-dimensional space. (Recall the old riddle: where can you walk south one mile, east one mile, and north one mile, only to find yourself back at the starting point?5 Not on any Cartesian x-y grid, for sure. Descartes, for his plane, insisted that a unit distance in the "x" direction be equivalent to a unit distance in the "y" direction.)
