ome of the most interesting features of modern web sites are based on Geographical Information System (GIS) technologies. GIS techniques essentially give you a way to manage and show geographical data in your systems. For example, a manufacturing company can display a map showing every building it occupies, every office in a building, or the location of every sale it makes—worldwide—or a cab company can use GIS data to track the position of its cabs nearly in real time.
Not too long ago, the expense and rarity of the maps themselves hindered the use of GIS data in applications, but today, full-featured maps are available through Google Maps, Google Earth, and Microsoft Virtual Earth (among others) that you can use to display your GIS data in web applications. The advent of such mapping systems is one of the most exciting technologies to emerge in the last few years—and they’re still undergoing constant and rapid evolution. Today, you can easily collect geographical data, analyze and filter that data, and merge it with a mapping provider to create maps that display the data to your users. This article gives you a launch point by exploring what GIS data is, how to collect it, and how to manage it.
Understanding Positional Data
Finding a point on Earth, specifying that point as positional data, and displaying it on a map (such as on a computer screen) is an ancient challenge, and many different solutions have been tried. Among these solutions is one called the absolute latitude and longitude system. Using this solution, you can find any point on earth if you know its latitude (distance from equator), longitude (distance from the Greenwich Meridian), and altitude—that is, the vertical distance from sea level.
That may sound simple, but unfortunately there are many ways to define and notate latitude and longitude, and most are difficult to manage. Most strategies use a degree-minutes-seconds structure to specify positional information, but this article will use the simplest kind: decimal notation. For example, to find a point in Bergamo, Italy, you can look for latitude 45.703909, longitude 9.66276, and altitude 376. Simply enter those values into a GIS-aware application, and you’ll get a beautiful view of the city.
The GIS software you choose to render the data handles the really hard work—creating a usable view of the earth at any point of interest. For the most part, you don’t have to worry about how this happens; if you are able to collect and manage single points, you can extend that know-how to manage lines and areas, letting you can create geographically enabled applications.
| Author’s Note: The altitude portion of a GIS point is not strictly required for most applications, because most maps use a 2D layout, and the third dimension is irrelevant and can’t be shown. You need altitude only when you want to show data on a 3D rendering engine such as Google Earth. However, there’s not much overhead involved in collecting altitudinal data, and because the value may be useful at some future point, I suggest that it’s better to save it than discard it. |
Collecting Data
The first step in developing a GIS business system is to collect the geographical data, a process interchangeably called geomapping or geocoding. Both terms refer to the process of retrieving the real-world position of the objects or places you want to map. This process is simple for single-pointed objects, either static or moving, such as a building, a car, an antenna—objects you would show as a point on a map. But the process becomes more difficult when you want to map lines and areas. Fortunately, the technologies involved are basically the same; first you learn how to work with points, and then you extend the process to work with lines (pairs of points) and then areas (sequences of lines).
There are two ways to geomap a point. The first requires that you go “on the road” and detect the position of a point using a Global Positioning System (GPS) device. This way is my favorite because the data’s accurate, and it’s easy. Using a GPS is also the only way to map the position of moving objects—for example, a car or a bus. The second way is to map a point using an existing map or a geocoded photograph (for example, a satellite photo opened with a GIS client such as Google Earth). With this approach you don’t have to leave the office, but you do need a detailed map or photo, and you can geomap only positions that can be detected clearly on the map, such as buildings, bridges, and so forth.
Acquiring Data with a GPS
To get started, you need a simple GPS receiver, such as the ones that standard car navigators use. GPS navigators have become both common and fairly inexpensive over the last few years.
| Author’s Note: If you don’t already have a GPS receiver, I suggest you buy a model that uses the SIFR Star III chip, which I’ve found has great precision and performance. You can use it with a laptop or (better) with a handheld device. I work with an Axim and a standard Bluetooth GPS, but you could use a phone running Windows Mobile 5 or 6, with either an integrated or external GPS receiver. |
A GPS receiver receives signals from special satellites in geosynchronous orbit. There are enough of these satellites to make a signal available nearly everywhere on earth. The signals are timed, and the GPS uses the timing information to calculate its distance from the signal, and using that, to find your position. The GPS must be able to receive a signal from a minimum of four satellites to calculate your position on earth accurately (four values provide the system with the four position variables: latitude, longitude, altitude, and time). The more satellites the GPS can “see,” (those above the horizon at your position) the more precisely it can calculate your position.
Most receivers calculate your position, your speed, your heading, and other data approximately once per second, and can stream the calculated positional data to an external device through a standard serial port, as rows of text. Therefore, when you connect your laptop or handheld device to the GPS receiver, your device will receive a text string containing the calculated positional data about once each second. The strings are encoded in NMEA format. A GIS application receives the data, parses the string, and extracts your position. After that, you can manage the positional data however you like; you can store it in a database, you can save in an XML file, you can show it on a map, and so on.
It’s quite easy to write an application that receives a flow of GPS data and parses the NMEA—at least, it doesn’t require much special knowledge. The process involves only a little COM port interface programming and some string parsing. While you’re perfectly free to build those features yourself, you don’t have to; there are several pre-existing libraries that take care of those low-level tasks for you.
Windows Mobile 5 and 6 include a “GPS intermediate driver,” which opens the COM port, receives the GPS flow, parses the NMEA data, and raises events whenever a position is available. The driver exposes a simple API through which you can subscribe to the events, receiving positions every time the GPS calculates them. If you use .NET as your environment, you can find a working example in the .NET CF SDK, which makes it easy and fast to build a working application. Other options are open source libraries, such as OpenNETCF, and commercial products such as GeoFrameworks or the Franson GPS Tools. All these libraries implement a COM listener that connects to the GPS receiver, listens for data flow, parses NMEA, and raises events to which your application can subscribe.
The GPS data flow generated by receivers contains two important values along with the position: the Horizontal Dilution Of Precision (HDOP) and the Vertical Dilution of Precision (VDOP), which measure the error of the calculated position. An HDOP or VDOP value of 1 means you’re getting very accurate data. HDOP and VDOP values that exceed 1 mean worse positional data. You may check these values to discard positional data values that are too inaccurate for your business requirements. For example, if you need to locate a small object with high precision, you need to discard data with HDOP or VDOP values greater than 2 or 3. In contrast, if fine-grained accuracy isn’t a problem, you might discard only those positions with HDOP or VDOP values greater than 6 or 7.
Acquiring Data from Maps and Photos
With good-quality maps or geocoded photographs, you can acquire positional data without having to be physically present with a GPS receiver to collect the data. For example, you could easily work from maps or photos if you needed to locate only your office building or acquire similar data. However, I suggest you avoid this method if your business truly depends on accurate geographical information.
If complete accuracy is not important, you can use any GIS software that provides location data and good maps. For example, you can use Google Earth for most simple purposes. As an example, launch Google Earth and locate your home. When you find it, hover over it with the mouse; the status bar shows you its position, and you can note it. There are other ways to acquire the data as well, but the concept is always the same: identify a point on your map, and then read the coordinates for that point.
Storing Data
After collecting your geographical data, you need to store it somewhere. You can use any solution you use to store standard business data such as files or databases, but larger applications typically use a relational database. You need only a standard table with three numeric columns for latitude, longitude, and altitude. The column precision depends on your project’s requirements. Latitude and longitude can have fine precision; to avoid rounding errors, you don’t want to limit your data to only a few decimal points. Altitude measurements can have fine precision as well, but for most applications you can safely store altitude data in an integer column.
Applying the Data
There are many ways you can apply stored geographic data, depending on your goals. For example, a point-of-sale system can bind marketing information to geographical positions to create maps that show different icons for different POS results, such as plotting appropriately sized markers to show the sales volume in various locations. Or you might create a detailed plan of a city mass-transit system, binding bus-stop data, route lines, schedules, tourist attractions, and other points of interest, as this PalmBUS system does.
The process of relating geographic points to “attributes” that facilitate creating the map view you want is always the same: You associate point data to other information, and then display the information on a map. You can do all this using any standard database and any standard GIS rendering engine.
| Author’s Note: Take care that your applications always treat the three point values as a single entity. Isolated latitude, longitude, and altitude measurements aren’t usually very useful. You always need at least the latitude and longitude values to plot an accurate point—and most systems require all three values. |
 | Â |
| Figure 1. Map Coordinates: You can jump to a specific Google Map view by entering latitude/longitude coordinates such as “45.703909N 9.66276E” in the Google Map address field. |
After collecting your points as described earlier, you can test them using Google Maps or Google Earth. For example, open Google Maps. This web-based mapping application accepts addresses in text form, but it can also accept latitude/longitude coordinates. For example, if you enter 45.703909N 9.66276E (which means latitude 45.703909 North, longitude 9.66276 East) in the application’s “Search the Map” field, and then click “Search Maps” (or just click Enter), you will go to the map shown in Figure 1, which has the coordinates you entered.
Working with Google Earth is quite different from Google Maps, but more exciting. Google Earth renders data defined in XML files. For example, to show a map at a point you’ve collected, you create an XML file containing the data. To try it, open Notepad, and paste in the following XML:
Arena di Verona.kml Arena di Verona 10.99394514599905 45.44023503220072 200 759.5637314343327 58.7902038199754 0.8203667851755632 relativeToGround 10.99451099760466,45.43891075160266,0 The preceding Google Earth XML structure is written in an XML language called Keyhole Markup Language (KML). The most important portion of the code is the
 | Â |
| Figure 2. Arena di Verona: You’ll see an image similar to this one in Google Earth when you open the “myPoint.kml” file that specifies the coordinates and the viewing position. |
Another important feature of the KML you defined above is the
To view the point in Google Earth, save the Notepad file in some convenient folder as myPoint.kml and then open the file with Google Earth, by clicking the File ? Open menu and selecting the saved file. You’ll see a satellite map view similar to Figure 2 (depending on your Google Earth settings, you may see a different image.
| Author’s Note: Google Earth shows position in degrees, minutes, and seconds (DD, MM SS format) by default, but you can switch to decimal notation through the configuration menu. |
As you can see, getting started with GID applications is quite simple. You collect points via GPS or existing maps, and render them using a mapping application. You don’t need expensive hardware, and you can write simple software without too much work. With a little effort, you can write exciting business applications that feature 2D maps or 3D earth-rendering systems.
