An implementation of the Open Geospatial Consortium Web Feature Service (WFS) and Web Map Service (WMS) specifications in an open source desktop GIS is presented together with a discussion of considerations for improving the use of web services data in desktop applications. In our implementation, WFS and WMS services are consumed by a plug-in to MapWindow GIS [1], allowing the end user to view WFS, WMS and ArcIMS data, including data from the ESRI Geography Network, in a transparent manner that can be configured for either data analysis and modeling, or data visualization. This implementation in an open source GIS allows for others to view and use the code, improve it, and otherwise implement the suggested considerations in other GIS platforms. Specific considerations proposed here include: pre-fetching through envelope optimization, tile display, and feature complexity reduction. These strategies improve the speed and responsiveness with which data can be viewed and analyzed. Comparisons made with other web-based data access implementations are used to evaluate whether these techniques provide performance benefits, and under which circumstances.
Web-based geographic information system (GIS) tools are increasingly used for basic mapping and data visualization tasks (e.g. Google Maps, MapQuest.com, and ArcIMS) and complex web mapping and data analysis software tools continue to be developed. In spite of this apparent migration of GIS to the web-platform, desktop or client-side GIS tools are likely to continue to be needed for a variety of use cases in the foreseeable future. The primary standards issuing entity for the GIS community, the Open Geospatial Consortium (OGC) has released web-based GIS specifications which are arguably the most widely adopted of its standards, and are used primarily for web based GIS tools. OGC standards such as the Web Map Service (WMS) and Web Feature Service (WFS) have proven to be useful for normalizing and improving the manner in which data is shared across the Internet, and as such they are expected to grow in popularity and usage. The purpose of this paper is to present a case study with lessons learned from the implementation of both WFS and WMS support in a client side desktop GIS application.
The stated mission of the OGC is “to lead the global development, promotion and harmonization of open standards and architectures that enable the integration of geospatial data and services into user applications” [
This is accomplished through the authoring of specifications which are created by “structured committee programs and consensus process” by which participants in a wide range of scientific disciplines may contribute to the specifications. A specific goal of the OGC is to address the problem of data sharing—a problem that includes both interoperability and communication—and ultimately arrive at “a world in which everyone benefits from the use of geospatial information and supporting technology”. OGC has attempted to address some of the fundamental problems of data sharing by specifying common formats for wide-scale understandability in distribution, for facilitating geoprocessing, and for interoperability between disjoint software products.
Web based GIS systems are not suitable for every GIS task because they can be slow and unresponsive due to large data sizes and in many cases do not provide access to raw data sources. For example, the US Geological Survey Seamless Data Server [
Geoprocessing can also be challenging when working with strictly web based GIS tools because of data transfer speeds and general web based geoprocessing capabilities. An example of a web based GIS that can perform advanced geoprocessing is the USGS StreamStats [
Many of the challenges associated with web based mapping tools are largely overcome through the use of desktop GIS applications following the client-side computing model. Speed of visualization and data interaction is rarely an issue on desktop based GIS tools using graphics technologies such as GDI+, DirectX or OpenGL [
In spite of these benefits of traditional desktop based GIS tools, client-side GIS systems can suffer from two obvious problems: outdated data sources and the inability to easily share data. Both of these are areas in which the web based GIS tools excel. One could argue that a mixed approach, combining the best features and capabilities of client-side and web based GIS tools, would be ideal. We explore an approach for making use of web-oriented OGC standards in a desktop GIS application. The result is a system that benefits from local processing and data storage capabilities while using web based data services to solve the problems of outdated data sources and difficult data sharing. Specifically, the WMS and WFS specifications are implemented in a client-side GIS in a case study that tests several optimization methods, improving performance for data visualization and analysis on a local desktop GIS platform. The methods presented here can be implemented together with other established optimization techniques including data caching, multithreading and pyramids for raster data [
The open source MapWindow GIS desktop application [
The first optimization uses an envelope optimizer referred to as a detail square grid (DSG). This is a recursive grid or quadtree structure (
some data transfer bandwidth may be consumed in the overhead of multiple requests to download multiple tilesrather than fetching all data at once, the design of the DSG is intended to provide the user with data as quickly as possible. This allows the user to examine and work with the data while additional data continues to download in the background.
The view optimizer instantiates the DSG object with the corner coordinates, the desired cell size, and the number of rows and columns of the data in question. Priorities are established for each grid cell; these priorities are updated through function calls. The most important function in this process increases the priority level by two for tiles which are entirely contained within the given extents, also called an envelope, and increases the priority level by one for tiles partially intersected by the given extents. As the user zooms, pans and interacts with the data, this continual update of prioritization creates an effective preference map for cells in the DSG. When a new tile is ready to be retrieved, a function call to the optimizer provides the envelope for the highest priority data that is pending retrieval. The optimizer works solely in terms of extents or envelopes, separating it from the type of data being optimized. The technique is illustrated in
The key difference is that Google Maps provides low resolution data followed by higher resolution data on every zoom or pan, whereas the DSG technique continues to retrieve high-resolution data for areas outside of the current view, choosing tiles in an arrangement determined to be optimal to retrieve areas likely to be viewed next. This difference can be attributed to different target audiences and intended uses of a simple web based map viewer, versus a desktop GIS intended for complex data analyses.
After retrieving the desired data envelope to download, a request may be formulated using extensible markup language (XML) [
A second approach involves using GIS drawing engine optimizations to avoid examining images that are not in view or which are covered. In this case, a low-resolution backdrop is added as the first layer, and then high-resolution tiles are added to the map as they are downloaded and become available (
When requesting feature data, it can be important to retrieve any feature which falls within the requested envelope, and return the entire feature rather than a feature clipped to the requested boundary. The OGC Filter Encoding Implementation Specification [
A WFS server returns data to the client using the geographic markup language (GML), an XML grammar; ESRI servers typically return data in the ArcXML format, a proprietary but published format. For our case study implementation, this data must be converted to the more common shapefile format which is natively supported by many GIS software packages. This step occupies a small but notable portion of CPU time. Presumably a desktop GIS with native GML support would not experience this specific delay.
A number of methods for efficient transfer of vector data have been proposed an implemented in different software packages [13,14]. In our implementation, for feature simplification optimization, once data has been downloaded and converted to the shapefile format it is added to the GIS application’s map view window. If optimization for geoprocessing has been selected, the features will be immediately merged into a single shapefile to facilitate analysis functions. If optimal visualization is selected for the data download method, each individual tile will be added to the map, thus using a form of the tiled display optimization developed for WMS services. Additionally, this visualization method will attempt to simplify vector features for a smaller number of overall vertices. The goal is to remove all vector vertices from the data that have no notable effect on the final display of the data due to their density (
The visualization optimizations described above result in multiple individual parts present in the map, all associated with a single data layer but stored in separate files. Because of this, it is crucial to track all temporary files used, both for timely cleanup and to aid in correct project saving functionality. When a map project is saved, it is necessary to ensure that layers originating from an online data source do not get saved to the project file from temporary locations. If this were to occur, the project would reference a temporary file that will not persist upon reopening the project file. MapWindow allows plug-ins to specify settings which are saved to, and loaded from, the main project file. This allows the software to prepare an XML segment detailing the source of all online data layers in enough detail to rebuild the project from the online data when reloaded. This has the added advantage that a project compiled from online data sources takes a very small amount of disk space to store (typically less than 50 KB). One potential downside to this approach is that when the project is re-opened and the computer does not have an active internet connection, the datasets will not be viewable unless initially the user specified download of local copies of the data.
The client-side GIS approach and case study implementation presented here resulted in a viewing system for online data that can be easily integrated with existing local data on a desktop GIS. The approach addressed the goal of building upon the strengths of both web based and client-side GIS tools in an integrated “web-enabled” GIS system that optimizes viewing and download of data for analysis.
Our WFS and WMS case study implementation was compared with on-line data functionality in two existing GIS systems: uDig, ArcExplorer, and ArcIMS HTML Viewer. A dataset comprised of several different data types (vector and raster) was accessed using each GIS application, with twenty replicates of the same dataset tested using the same client computer and network connection, and connecting to the same server. Tests were
repeated for varying numbers of features and varying raster resolutions. The time to acquire an initial view of the dataset for both vector and raster data was measured (ti), as well as the time to download and display all data (tf). Initial and final raster quality (qi and qf, respectively) were evaluated qualitatively using a one-to-ten scale, where ten is highest. Data sources tested include point, polyline and polygon vector data and a raster image representing a 30-meter digital elevation model (DEM). Datasets were served using both ArcIMS in the ArcXML data format, and by MapServer using OGC WFS or WMS as appropriate. The measured values for ti and tf from each application were averaged for each given data type and metric.