Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Location, Location, Location

Today, map-enabled systems run the gamut from big government endeavors down to gadgets in your PDA, your cell phone and, yes, even your car. Despite an upcoming slew of "location-based services," the killer GIS app has yet to be discovered.

Three years ago, a story attributed to The Observer made the rounds of the Web, about a German motorist and his companion who learned firsthand about "ground truth" in geographical information systems (GIS).

Their BMW's cartographic system was state-of-the-art, a marvellous global positioning system—driven moving-map display with purported "pinpoint accuracy." It led them from road to road, onto a bridge over the Havel River. So on they drove, serenely confident in their electronic navigator, though perhaps a bit bewildered by the stop signs, flashing red lights and gesticulating folks they passed as they crossed from the bank onto the bridge.

Except for one little discrepancy: There was no bridge where the nav system depicted one. And the ferry happened to be out at that moment.

The motorists got out OK, but had to suffer the ignominy of watching their car being fished out of 12 feet of water.

"I think of it as the Achilles' heel of GIS," says Dr. Michael Goodchild, director of the Center for Spatially Integrated Social Science at the University of California, Santa Barbara. "Accuracy: the question of ensuring that the database is an accurate representation of something in the real world. Unfortunately, for various reasons, it's not as accurate as you might expect. Up until now, the field has not cared too much about accuracy, and a lot of my agenda concerns convincing people that it's important."

Beyond accuracy issues, economics, privacy and GUI limitations form further hurdles to GIS success. Impressive feats are being accomplished today with GIS technology, but it behooves us to remember that, at best, what's in the computer is a model of the real world. It's the oldest story in computing: garbage in, garbage out (in this case, about $40,000 worth of car converted to "garbage out").

From Cholera to Computers
Today, map-enabled systems are becoming ubiquitous, running the gamut from big government projects (the census or your local Department of Natural Resources) down to gadgets in your PDA, your cell phone and, yes, even in your car. There are full-fledged GIS application development environments from such companies as ESRI, Intergraph and MapInfo, as well as an upcoming slew of "location-based services," by which, for example, a shipping container can tell you where it is.

Many GIS concepts are really nothing new. The idea of using overlays, or layers, on a map goes back to at least the American Revolutionary War, when French cartographer Louis-Alexandre Berthier plotted the Battle of Yorktown using hinged overlays to show troop movements. In the 1850s, an "Atlas to Accompany the Second Report of the Irish Railway Commissioners" superimposed population, traffic patterns, geology and topography. And, famously, in that same decade, mapping cholera deaths in London helped Dr. John Snow with his analysis showing that the cases clustered around public wells, thus indicating that the disease was related to contaminated water.

It wasn't until the 1960s, however, that computers and maps began to converge. As with almost any computing application, there was a Dinosaur Age: large mainframe systems, primarily for government projects that simply couldn't be accomplished without computers. Among these behemoths were integrated transportation plans produced for the cities of Detroit and Chicago, which had to portray common endpoints, the routes between them and loads at various times. For a network as complicated as a major city's road plan, paper simply wasn't an option.

Recall that at this time, several key technologies were becoming well-understood, especially techniques for the manipulation and display of vector and raster graphics, as well as relational databases. By the mid-'60s, two seminal centers emerged to invent many of the concepts that make up modern GIS: the Canadian government's Land Inventory project and the Harvard Laboratory for Computer Graphics and Spatial Analysis.

The goal of the Canadian effort was to analyze data generated by an inventory of rural land in the world's second-largest country and to assist in land-use planning; to this end, the Canada Geographic Information System (CGIS) arose essentially from scratch, using invented technologies as needed. From a miasma of cost overruns, schedule slips and all the rest of the hobgoblins attending big, ground-breaking software projects, the foundation of most of what we think of as modern GIS emerged. To generate the geometry, project leaders scanned maps and converted them to vector data. They organized their thematic data horizontally—the road network in one set, the soil type into another and so on. This idea of layers, or themes, is still in use today. CGIS had a single adjustable-precision coordinate system for the whole country. Since the entire database was too big to work with en masse, CGIS broke it into sheets, or tiles, and could map across tile boundaries.

CGIS eventually succeeded, and did the job it was invented to do. However, it was a classic example of a stovepipe system: a custom-built piece of software with no obvious upgrade path. By the 1980s, it had been largely eclipsed by commercially-available GIS packages, some of which grew out of the work done at another GIS wellspring: the Harvard Laboratory for Computer Graphics and Spatial Analysis.

Like the Canadian effort, the Harvard Laboratory did some ground-breaking. Not only did the lab invent new technology, it turned it into widely used software that helped popularize the notion of GIS. The SYMAP package, released in the mid-1960s, output crude maps on line printers, but indicated the promise of the new computer-based mapping technology. Significantly, it was simple to use, freeing mapmaking from the exclusive realm of cartographers. After SYMAP came CALFORM, SYMVU, GRID, POLYVRT and finally ODYSSEY in the mid-1970s. Each package added new functionality—perspective views with SYMVU, raster data with GRID and so on. By the time they had created ODYSSEY, the Harvard Lab had settled on essentially the modern organization of GIS data: geometry in one database that could be optimized exclusively for that purpose, and thematic or "attached" data in standard relational tables. With ODYSSEY, Harvard had created perhaps the first truly useful GIS analysis package.

"It was really a case of the right people in the right place at the right time," says Scott Morehouse, now director of software development at ESRI in Redlands, California, originally founded as the consulting firm Environmental Systems Research Institute. Morehouse joined the Harvard Lab in 1977, and says that in addition to its pivotal role in developing GIS technology, the lab also served as an incubator, training people who would go on to have a big impact in the field. "And it was a lot of fun to work there," he admits. At ESRI, Morehouse helped create ARC/INFO. First released in 1981, it ran on the then-new "supermini" computers. In 1986, ESRI came out with purpose-built ARC/INFO workstations built on the IBM PC platform and took off from there.

A Whole 'Nother Ball Game
After 40 years of development history, the field apparently has things pretty well figured out. But that's not to say that problems don't remain. For one thing, GIS applications have imitated the rest of the industry: Starting out as monolithic programs running on mainframes, they migrated to stand-alone applications on PCs; now, much of the data and processing is moving back up to servers again, as the Internet becomes the computing platform. And as anyone who's ever built one knows, a distributed application is a whole 'nother ball game.

"A lot of things are called Web-GIS, but they're not doing any analysis; they're just for display," says Dr. Sam Batzli, a faculty member at the Michigan State University's Department of Geography. Batzli, who specializes in visualization and historical geography, has had a role in developing several Web-based GIS systems. He described one display-only example his team built atop ESRI products. The site is a map-based interface to an aerial-photography database. "The foundation is your spatial data. The most efficient method is to use a database like Oracle or some kind of SQL server—those can be spatially enabled with ESRI's Spatial Database Engine. That provides an interface so that you can do spatial queries on your database, queries on intersecting polygons, unions and so forth. Then we build the next step, a map service, using ARC Internet Map Server. It gives you a set of software programs that will grab information from the database and generate a JPG or PNG to the Web browser.

"That's the back end; the front end can be done with Java tools. We have some problems with browser and platform compatibility (ESRI's solutions tend to favor Windows and Internet Explorer). We tend not to use Java applets—we use more of a HTML/JavaScript viewer. There are still some compatibility issues, and it's fairly heavy on the client-side JavaScript."

According to Batzli, another application, for the Tropical Rain Forest Information Center, begins to approach true Web-based GIS. The TRFIC browser "allows users to upload their own shape files, and do their own digitizing on the screen." (Translated, this means that the user can add his or her own geometry to the Web-based GIS, whether prebuilt in files, or constructed on-the-fly in a browser, using the tools provided by the site.) TRFIC also approaches a truly distributed application; for example, it uses a database server at the Jet Propulsion Laboratory for some kinds of queries.

Some of the technologies involved are proprietary, and Batzli would prefer to go with open standards. "There is the Open GIS Consortium; they have been working on distributed datasets, but it's just not there yet," he says. "The problem with the open-standards process is that it's very slow. Features that are available through the standard interfaces are pretty rudimentary. The technology is changing so quickly, it's tempting to jump on proprietary solutions."

Distribution at the Desktop
Batzli sees two hot topics in play currently: "Standards, and whether they can keep up with the demand for functionality; the other is related: to be able to tap distributed data stuff." In that arena, he says, "ESRI has made an effort to push their own product; they're members of the OGC, and what they've done is the 'geography network'. It demonstrates the distributed capacity, and it's actually quite nice. In current versions, you can click on a toolbar button and pull in data layers from different parts of the world, and apply it to your map on your desktop." For example, one ecological study Batzli worked on had to take into account the effects of wildfires on the landscape. "I was building a global map, clicked on a button, searched for 'fire,' came up with a map of Africa, and was able to just overlay that with my LANDSAT footprint, right on my desktop." Again, while the database is indeed distributed, the data flow is mostly one-way. True collaborative distributed GIS is still a current research area.

"Unfortunately, there's no universal theory of distributed databases," admits ESRI's Morehouse. "Solutions to the problem of how you synchronize detached databases are not generic. Within each domain like spatial data or personal information management, issues like synchronization are reasonably well understood, and solutions exist. The research comes in when you're doing editing—a huge community of people all editing the database. It's analogous to having a community editing a source tree. The problem is tractable; it needs a number of things to come together. The infrastructure needs to be there as far as networks and Web services, as well as services for geographic data dissemination and management. You can certainly build one-of-a-kind, customized systems right now to do distributed data management, but we're always looking to build a generic tool so that you don't have to hand-code things."

No More Holy War
ESRI has been around long enough to see distributed-computing technologies come and go, but they're making a bet today on Web services. "We're leveraging Web services very heavily," says Morehouse. "I think it's the right architecture for building loosely coupled distributed systems. It's a better answer to the question than systems like CORBA tried to address in the past. We like Web services because it's loosely coupled and doesn't require session state to be maintained. And it bridges the religious wars, the J2EE versus Microsoft 'one ring to rule them all' problem. It doesn't require a lot of rewriting—we're not intending to rewrite our mapping engines and such. We end up kind of plugging into these middleware systems as 'enterprise information systems'" or, he laughs, "'legacy code.'"

"One of the frustrating things," Morehouse complains, "is that neither platform is particularly good at integrating legacy code into its frameworks. They've done a good job of integrating databases, but if you want to hook in your own code written in another language, in some ways you're swimming upstream. In the Java case, OK, you want all the advantages of the platform ... just rewrite your system!" he laughs. "With Microsoft, it's not quite so bad—you can run 'unmanaged code' together with the Common Language Runtime, or you can use some of the older COM+ technology. The strategy that we're taking is to build nice XML API wrappers around our code, not to rewrite it, and to use Java and .NET as glue to orchestrate these services." The ARC/IMS product, with its Map Services features, was actually developed before Web services came out; Morehouse says that ESRI plans to migrate their ARC/XML API to be SOAP- and XML Schema-compliant.

Researchers in the field are also excited about the prospect of come-as-you-are distributed GIS. "The best things I've seen in the field in the past couple of years," enthuses Goodchild, "are the various technologies that integrate the desktop with the Web, so that a dataset on the Web and desktop can integrate without explicit downloading. Unless all the layers are on your hard drive, this is extraordinarily difficult." Organizational and institutional issues are also involved: "What we currently have is a very complicated system across sets of Web sites; people are working on a unified view. The U.S. Geological Survey and the Environmental Protection Agency are independently pursuing similar projects. The Federal Geographic Data Committee is working on higher-level integration."

One ambitious project, the Digital Earth, has been affected by the political winds of change since November 2000—it was the brainchild of Vice President Al Gore, who proposed a "multiresolution, three-dimensional representation of the planet, into which we can embed vast quantities of geo-referenced data." It was an attempt to create standards and to access software and data warehouses that allow any person to view and use the terabytes of data on our planet that the U.S. federal government has accumulated. Though the high-profile project under the "Digital Earth" name is moribund, a scaled-down effort is still very much alive ( see http://gai.fgdc.gov/ ), and Goodchild notes that other efforts like OGC's Web-mapping and ESRI's geography network are in fact making the vision of integrated Web GIS happen. He also feels that the most significant recent developments have nothing to do with traditional desktop GIS, but affect the new industry called "location-based services." "My laptop can show me a clock," he says, "but not a map." Once the hardware and software for location-based services are in place, says Goodchild, we'll see it used in commercial establishments, direct marketing and credit-card-use geocoding. But the biggest applications, he says, "may turn out to be not in consumer applications at all, but in things like shipment tracking. And people using cell phones to keep track of where their kids are … we probably haven't thought of the one that'll turn out to be the killer app."

Cost, Privacy and Purpose
Aside from technology, Goodchild sees four major institutional or political challenges facing the field. First, he says, "There've been some dramatic changes in the economics of GIS in the past decade." Previously, the expense of doing the survey work meant that only large government agencies like the USGS could afford to do mapping. But the advent of inexpensive, highly accurate, digital GPS technology has changed all that, allowing states, cities, even individuals to do accurate surveys. Second, there's the issue of charging for the data. In the U.S., historically geographic data has been generated by the federal government and is in the public domain. But now, with the data coming from localities, other countries and the private sector, one can no longer rely on free access.

Privacy is also going to be a big issue, according to Goodchild. "The general sense is that a lot of geospatial data verges on the problematic with regard to privacy," he says. Now that satellite-photography data is available with 0.6-meter resolution, clearly it's going to be harder to stay out of the view of anyone purchasing that data. Goodchild also forsees privacy problems stemming from simple database linking: "A lot of new technologies, even cell phones, have the potential for privacy issues." Not to mention questions of national security: "Since September 11, there is a tendency to regard geographic data as a national security asset and remove it from public view."

Finally, there's the UI issue. GIS software has never been something that a novice can pick up in an afternoon. Many frustrated users wonder if it's the developers' fault. Goodchild doesn't think so: "It's just hard. There's an enormous complexity in the UI. There are too many different representations," he says; too many different ways to look at the same set of data. "I like to use a parallel with statistics: I would certainly take a stats course first, then start using a package. For some reason, we assume that we ought to be able to learn GIS by picking up a GIS package, instead of taking a formal course."

Morehouse agrees: "You have to understand who the audience is that you're trying to address with issues of usability. A lot of the people who use our software are geographical scientists, GIS professionals. They have the job of taking this generic toolbox and kind of applying data to it and bringing it to life, making it do something. Those are the same people who just love Linux and shell scripts and stuff. They say, 'Give me that and I can make it happen.' There's another group of users who are not GIS people per se, but just want to work with it in their professional capacity, like a farm operator, or a military planner or a policeman, somebody doing a zoning study. They want to use the system to get their job done; they like a point-and-click UI. There's a third class: untrained, mass-market—they want to know where the nearest shoe store is."

Staying in Business—and Out of the River
So a sophisticated GIS is potentially much more than an end-user application; it's a development environment in itself. For some people intimately familiar with the field, a GIS is a useful tool. For others, concerned with reaching out to domain specialists or the general public, a GIS is just a starting point for developing an application.

After all, none of us work on systems that are goals in and of themselves. Sure, it's fun to work on Enterprise JavaBeans, or bring up a complex application. But we're all in the business of communication—getting information out to people who can use it to purchase products, run their businesses ... or just keep their cars out of the river.

Acknowledgments: The author would like to thank Sam Batzli, Michael Goodchild and Scott Morehouse, who all took sizable chunks of time out of their schedules to alleviate his ignorance. In addition to the people quoted herein, thanks are due to Drs. John Norman and Christine Molling of the University of Wisconsin, and Dennis Adams of Sonic Foundry, for their valuable assistance.

RELATED ARTICLES Parallel Pattern 5: Stencil Distributing Work Across Cores Using .NET Other Voices: Knowledge Management Basics Inform System Release Lifecycle Server+client Fusion: An Architectual Proposal The Power of 'Random'		TOP 5 ARTICLES No Top Articles.