Modern Geographical Information Systems (GIS) [1] provide a service-oriented architecture for interacting with geographical data sets and related maps. Web-based GIS systems are architected around the same principles as more general Web service systems based on SOAP [2], WSDL [3], and REST. Mirroring the World Wide Web Consortium and OASIS Web service standards-making bodies, the Open Geospatial Consortium [5] defines open standards for messages, XML data formats, and access protocols that are specific to the GIS community. In addition to OGC-based services, there are many companies (such as ESRI and AutoDesk) that provide proprietary, commercial solutions. Services from these various providers are not normally interoperable.

The methods of the traditional GIS community have been challenged in the last two years by the emergence of new, lighter-weight approaches towards building clients and integrating data. The availability of Google Maps, Google Earth, Microsoft’s TeraServer, Yahoo! Maps and similar systems has enabled enthusiasts and part-time developers to make highly interactive Web interfaces to these companies’ services and to integrate their maps with local data. Google Maps in particular is an important example of the so-called Web 2.0 development approach [6]: Google has built and maintains a high performance, highly scalable map service (available for free) that has a relatively simple, JavaScript-based programming interface. This simple but powerful public interface to a very complicated service is the hallmark of Web 2.0, since it democratizes the client development process: very little programming skill is required to build custom Web applications and to combine them with data from other sources (so-called Web “mash-ups”). The ProgrammableWeb [7] is an excellent source for browsing mash-ups and discovering APIs to on-line services. Currently over 380 services make themselves available for mash-up building. Google Maps is used in about 50% of the registered mash-ups.

Google Maps also provides an important lesson in interactivity: by storing data in map tiles and by using a programming technique known as Asynchronous Javascript and XML (AJAX) [8], they are able to provide highly interactive interfaces that don’t rely on direct user requests for map updates. Instead, the user drives the map updates indirectly by panning and zooming.

AJAX is a development technique rather than a new programming language. It relies heavily on the relatively recent standardization of XmlHttpRequest within JavaScript engines in most major browsers. XmlHttpRequest provides a mechanism for the page running in a browser to call back to its original Web server to obtain additional information without going through the direct, user driven HTML

submission process. That is, the browser’s request/response cycle does not have to be directly initiated by a user hitting a submit button. Instead, it can be initiated indirectly by user interactions. In the case of Google Maps, for example, the user’s map panning can initiate a request to the server for more map tiles to be cached locally. From the user’s point of view, the panning process is seamless, and minimal interruption in interactions takes place. We present in this paper an examination of these issues through a specific case study: federating Google Map data with more detailed county data obtained from map servers run by state and local governments in Indiana.

This is a particularly interesting example of federation, since there are 15 counties with public, on-line GIS services as well as a collection of state-wide services. These services collectively span four different, non-interoperable GIS products (ESRI ArcIMS, ESRI ArcMap, Autodesk MapGuide, and the OGC-based Minnesota Map Server). The county services have very detailed layer information: Marion County (Indianapolis) GIS services [9], for example, provide more than 100 map layers (such as park boundaries, parcel boundaries, voting precincts, and school districts) that are obviously not available from Google. These maps also provide higher level zooming capabilities and pin-point addressing that are superior to Google’s geocoding service.

What the county GIS services lack, however, is scope: county GIS services stop at the county boundaries, but natural and man-made disasters (floods, tornadoes, chemical spills, etc) do not. There is currently no means for integrating data from multiple services into a unified view. Thus we see integrating local GIS services with Google’s broader coverage into a single system as both an interesting Computer Science challenge as well as an activity with potential benefits to emergency management, disaster planning, and similar problems.

Download pdf Implementing a Caching and Tiling Map Server: a Web 2.0 Case Study


Related Posts