February 1, 2003

The New GIS Landscape

With GIS Web services, now even small companies can benefit from analytically rich geospatial information

by Michael L. Gonzales

It's becoming more difficult for leading companies to ignore the value geographical information systems (GIS) bring to the business intelligence (BI) table. On a constant quest to provide informational content to a voracious user community, companies around the world have made GIS and related spatial analysis a top priority. Sears — arguably the best example of what GIS can do for your business — invested a few million dollars in GIS technology for its logistics application and saves $52 million per year as a result.

Even so, GIS technology is still emerging and evolving, exploiting the distributed computing platform offered by the Internet as well as the emerging Web services model in such a way as to literally create a "digital globe" (to use the term coined by ESRI president and founder Jack Dangermond).

What Are GIS Web Services?

A Web service, of course, is a software component that can be accessed over the Web for use in other applications. GIS Web services, such as Microsoft MapPoint .Net and ESRI's ArcWeb Services, provide commercially hosted spatial data and GIS functionality via the Internet to packaged and custom Web applications. In essence, ArcWeb Services let developers include GIS content and capabilities in their applications without having to host the data or develop the necessary tools themselves. The result is significant savings of development time, expense, and computer resources.

GIS Web services use data and related functionality to perform basic geoprocessing tasks such as address matching, map image display, and routing. Application developers can use GIS Web services to perform real-time processing on the computers hosting the Web services and return the results to their local applications — all over the Internet. You don't have to maintain GIS application tools or the associated geographical data on your local system to use them in your custom application.

As you might expect, GIS Web services depend heavily on Simple Object Access Protocol (SOAP) infrastructure. SOAP standardizes the way a Web service communicates with a client and allows programs written in different languages and on different platforms to communicate. SOAP works with standard Web protocols including XML, HTTP, and TCP/IP, as well as emerging Web services protocols such as Web Services Description Language (WSDL).

GIS Web services are published on the UDDI registry, a universal database of Web services. Developers can search any UDDI site to discover services on the registry, making UDDI a powerful resource for publishers and consumers alike. Discovery happens either through a vendor-managed Web interface (www-3.ibm.com/services/uddi/protect/registry.html, for example) or SOAP calls.

GIS Web Services In Action

Let's look at ArcWeb Services' Place Finder to see how SOAP works. Place Finder uses a method called LocationInfo findPlace (String place). To use this service, the client invokes findPlace, enters a place name, and receives a location for the place. Because the Place Finder object is remote and resides across the Internet, something must happen behind the scenes to transfer the findPlace request to the remote object, and the remote object must somehow return the result.

SOAP makes this process work; it defines a clear mapping between parameters and function calls. (See Listing 1.) Disregarding the wrapping tags, you'll find that findPlace is a tag and inside it are the parameters of the function, which are also tags. Place Finder listens for this kind of request and returns a response that contains the location information. Without SOAP, a client would have to create an XML request, send it in a POST message to a URL over HTTP, and then parse the request using an XML parser.

Listing 1: An example use of SOAP.
<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:xsi=
'http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd=
'http://www.w3.org/2001/XMLSchema'
xmlns:soap=
'http://schemas.xmlsoap.org/soap/envelope/'
xmlns:soapenc=
'http://schemas.xmlsoap.org/soap/encoding/'
soap:encodingStyle=
'http://schemas.xmlsoap.org/soap/encoding/'>
<soap:Body>
<n:findPlace xmlns:n=
'http://www.geographynetwork.com/PlaceFinder'>
<arg0 xsi:type='xsd:string'>Redlands</arg0>
</n:findPlace>
</soap:Body>
</soap:Envelope>


WSDL is another XML syntax (and W3C standard) that communicates with local applications. A WSDL document defines the target service so the client knows what the service does. WSDL defines such things as which methods are available, what their parameters are, and the parameters' types.

WSDL documents are most useful if used in conjunction with a Web services development toolkit, such as Microsoft Visual Studio .Net or Cape Clear Software Inc.'s CapeStudio. Toolkits decrease the amount of work developers have to do to integrate their applications. (Because of their comprehensive approach, toolkits are often called "frameworks.") For example, a toolkit will automatically read WSDL documents and generate client code for the service. Some toolkits also create a context menu that displays all possible methods and arguments. Without a toolkit, the developer needs to more fully understand the SOAP exchange between the server and client, as well as construct SOAP requests and make an HTTP post to the server URL. With a toolkit, all you have to do is point the toolkit to the WSDL.

The toolkit converts all parameters and requests into a SOAP message, which it sends to the service. It also takes care of converting the returned SOAP message into a usable object.

What's The Upside?

GIS Web services are proliferating around the world. Viewed as a network, these geographical systems form a global, information-rich infrastructure that is adding a new dimension to the GIS industry by blending multiple and disparate application services into a cohesive solution set.

GIS Web services will revolutionize how companies use and interact with geospatial information. Consider the example of Joe's New Web Service offering. (See Figure 1.) The Web service is a composite of services provided by three subordinate GIS providers: One provider maintains and offers detailed street data, one focuses on city zoning for specific metropolitan areas, and a third provides extensive demographic data. Joe's service allows builders examining a specific metropolitan area to research street detail, including freeway access, schools, churches, shopping centers and residential developments, and combines that information with the city's zoning laws, as well as layering on demographic data of the areas of interest.

Joe's customers, armed with the analytic, rich information provided by his Web service, can ask questions such as: Where can I build a strip mall that is located on a major city intersection, within a 15-minute drive of a freeway exit ramp, surrounded by middle-class neighborhoods with professional, single families?

That's a powerful, strategic question to be able to answer, although that's not what's truly fantastic about the example. What's compelling is that Joe never had to maintain any of the GIS environments necessary to get his customers that analytic rich landscape.