Embed Size (px)
Citation preview
APPLICATION OF OPEN GEOSPATIAL CONSORTIUM SPECIFICATIONS TO
CLIENT-SIDE GEOGRAPHIC INFORMATION SYSTEMS
by
Christopher Michaelis
A thesis
submitted in partial fulfillment
of the requirements for the degree of
Master of Science in the Department of Geosciences
Idaho State University
April 2007
Copyright 2007 Christopher Michaelis
ii
Acknowledgements This research was funded by the Pacific Northwest Regional Collaboratory as part of a
Pacific Northwest National Laboratory project, funded by NASA through Grant No.
AGRNNX06AD43G.
Thanks are also given to Cassidy Michaelis, who spent many hours waiting while her
husband worked on the computer; and to Daniel Ames, who gave a great deal of feedback during
creation of these tools and publications.
iii
Table of Contents
ABSTRACT .............................................................................................................................................................. IV
CHAPTER 1: INTRODUCTION AND BACKGROUND........................................................................................1
CHAPTER 2: LITERATURE REVIEW ...................................................................................................................7
CHAPTER 3: AN APPROACH TO IMPLEMENTATION OF OGC WMS AND WFS SPECIFICATIONS IN
CLIENT-SIDE GIS ...................................................................................................................................................11
ABSTRACT ..............................................................................................................................................................11
1. INTRODUCTION...................................................................................................................................................12
2. METHODS ...........................................................................................................................................................15
Request Envelope Optimization: The Detail Square Grid ...............................................................................16
Tiled Display Optimization................................................................................................................................17
Feature Retrieval and Feature Simplification Optimization ...........................................................................18
File Management and Project Saving Considerations ....................................................................................20
3. RESULTS AND DISCUSSION.................................................................................................................................20
FIGURES AND TABLES ............................................................................................................................................24
CHAPTER 4: EVALUATION AND IMPLEMENTATION OF THE OGC WEB PROCESSING SERVICE
FOR USE IN A CLIENT-SIDE GIS ........................................................................................................................34
ABSTRACT ..............................................................................................................................................................34
1. INTRODUCTION...................................................................................................................................................35
2. WHAT IS THE WEB PROCESSING SERVICE (WPS)? ..........................................................................................36
3. WHY AND WHEN SHOULD A WEB PROCESSING SERVICE BE USED? .................................................................39
4. WPS IMPLEMENTATION CONSIDERATIONS ......................................................................................................40
5. SUGGESTED ENHANCEMENTS, PROBLEMS AND POTENTIAL SOLUTIONS ........................................................44
6. SOFTWARE IMPLEMENTATION OF DESIGN........................................................................................................48
7. CONCLUSION ......................................................................................................................................................53
FIGURES .................................................................................................................................................................55
CHAPTER 5: CONCLUSIONS ................................................................................................................................64
APPENDIX 1: REFERENCES.................................................................................................................................66
APPENDIX 2: CD-ROM CONTENTS ....................................................................................................................71
iv
Abstract
APPLICATION OF OPEN GEOSPATIAL CONSORTIUM SPECIFICATIONS TO CLIENT-
SIDE GEOGRAPHIC INFORMATION SYSTEMS
Idaho State University (2007)
The most popular of Open Geospatial Consortium specifications, Web Feature Service and Web
Map Service, can be effectively implemented in client-side GIS. An optimized approach for
using these services in desktop applications is presented, including intelligent pre-fetching
through envelope optimization, tiled display and feature complexity reduction. A developed
client implementation incorporates each of these optimization strategies to improve system speed
and responsiveness. Comparisons are made with other web-based data access implementations to
evaluate the validity and extent of the speed benefits gained.
The Web Processing Service proposed specification is evaluated as a solution for developing
web-based geoprocessing tools, for easily sharing algorithms and providing geoprocessing
functionality. An implementation approach which minimizes developer effort is presented.
Challenges are discussed and enhancements are introduced, including a mechanism for client
applications to provide correct data and a means to list available server-side data. The
enhancements are implemented in a demonstration implementation.
1
Chapter 1: Introduction and Background
The standards proposed by the Open Geospatial Consortium (OGC) form a solid basis for
developing Geographic Information Science (GIS) software. The OGC is a non-profit consensus
standards organization which concerns itself primarily with releasing open standards for
interoperability between commercial and open-source GIS tools. These standards are broadly
accepted, being formed through “structured committee programs and [a] consensus process” in
which “OGC members develop, review, and release OpenGIS Specifications” (Open Geospatial
Consortium, 2006). Because these standards are compiled by some of the most active GIS
software researchers and developers in the field, they are a collage of the ideas from around the
world which are most likely to be widely applicable and useful. Despite the clarity and depth of
the planning going into these OGC standards and specifications, they are written with a
pronounced preference toward fully web-based software and Internet driven applications, with
little or no focus on desktop GIS applications. The purpose of this thesis is to explore the
application of OGC standards to client-side, or desktop, GIS tools.
Web-Based Versus Client-Side GIS
The benefits of fully web-based applications are very tangible and valuable. The need to
verify the versions of software and data is greatly reduced, and lower local storage costs are
observed. Web GIS extends the technology to those users without the tools or without the
necessary skills to make use of a full desktop GIS system (Wright et al, 2003). The computers
that use the technology typically have very low system requirements, merely an internet
connection and a supported web browser (ESRI, 2006a). Internet-based and web GIS solutions
are appearing everywhere, with interest beginning with the Internet boom in 1995 (Wright et al,
2
2003). There is no sign that this trend will stop; there will likely continue to be a high demand
for web GIS in the immediate future (Wuthrich, 2005). The most common of these web-based
solutions are examined in the literature review.
Despite the increasing popularity of fully web-based GIS, there are drawbacks and
problems with the medium. “The primary problem is speed; GIS relies on extensive use of
graphics. Connection speeds over the Internet can make heavy use of graphics intolerably slow
for users” (Alesheikh et al., 2002). Other problems with web GIS include the inability to perform
advanced geoprocessing on the available data (i.e., watershed delineation, raster mathematics, or
network analysis), since web-based GIS platforms are typically limited viewers only, rather than
full-featured solutions to working with GIS data. The inability to save local copies of data
(usually the raw data are stored exclusively on the remote server) is also a typical user concern,
with the ever-present danger of communications or server failure. A study (Long et al., 1995)
shows Mean Time to Failure of observed systems to be 13 days, with Mean Time to Repair at 4
days. While the Internet is making great strides since the time of that study, reliability continues
to be a worry for many users.
Many of these disadvantages disappear when using a client-side GIS platform. Data may
be stored locally, advanced geoprocessing may be performed, image display is quick, and there
is little concern over network or server failure. A desktop system is very responsive since it does
not need to transfer large amounts of information through a communications channel. Advanced
graphics technology, such as DirectX or OpenGL, may be used, as opposed to less elegant and
slower techniques like simple bitmap transfer and display. At the same time, client-side GIS
platforms can suffer from outdated software, obsolete data, and the inability to participate in the
global sharing of data that takes place with online GIS.
3
The best of both approaches (web-based GIS and client-side GIS) can be obtained by
extending client-side GIS to make it web-aware, rather than completely web-based. Google
Earth (Google, 2005a) is an example of combining client-side and web-aware elements to reap
the benefits of both types of systems. The software accesses online data, thus incorporating a
web-aware component and eliminating the concern of having the most up-to-date data. This is
achieved by allowing the software to execute on the desktop and also access online data
maintained by Google staff. In this manner it is able to use client-side graphics acceleration
technologies while benefiting from online data sources. In contrast, Google Maps, a part of the
Google Local system (Google, 2005b), is a fully web-based approach. The Google Maps
interface responds much more slowly than Google Earth, making the effective and efficient use
of map data a much greater challenge for users.
Beginning with Established Client-Side GIS Tools
Client-side GIS tools are a more mature platform than the relatively new fully web-
enabled approaches. Arc/Info 1.0 was one of the first large commercial desktop GIS applications,
introduced in 1982; in comparison, the first effective web-based GIS system wasn’t introduced
until 1997 with ArcIMS (ESRI, 2005). MapWindow GIS (MapWindow OSS Team, 2006) is one
of many examples of an established and stable client-side GIS platform (see www.osgeo.org for
others). Beginning with an open source platform enables the user to make use of the software in
any way desired, including modifying the software for any purpose (Open Source Initiative,
2006). MapWindow GIS is an efficient and full-featured client-side GIS platform for displaying,
modifying and computing geospatial data. It is not web-aware in any way; thus it is an ideal
candidate for extension. In this thesis I demonstrate how MapWindow GIS can be easily
4
extended to make effective use of web-based data, including the ESRI Geography Network
(ESRI, 2006c). This will be done through the creation of a MapWindow GIS plug-in to
transparently access and work with data stored on servers conforming to the Open Geospatial
Consortium (OGC) standards for Web Feature Service (WFS) (Open Geospatial Consortium,
2005a) and Web Map Service (WMS) (Open Geospatial Consortium, 2001b). A suitable and
easy to implement approach to using these web-focused standards in a fully client-side GIS will
be outlined.
Key Contributions of the MapWindow GIS Online Data Plug-in
Extending MapWindow GIS to use online data brings an important and useful aspect to
the system. Concerns over the version of data are nonexistent with data from an online source.
As the data is updated, MapWindow GIS will automatically and seamlessly use the updated data.
Sharing of common geospatial data is made easier through popular services such as the ESRI
Geography Network. The rich and responsive interface typical of client-side systems can merge
coherently with the dynamic and fluid web GIS environment. The locally executing code will
allow intelligent caching, pre-buffering and predictive pre-fetching to create the most efficient
environment. The implementation of these algorithms will include the primary contributions of
designing and developing a request envelope optimizer to determine what data to download, as
well as the design and implementation of a tile-based display approach and vector feature
simplification techniques. The software is expected to demonstrate that these optimizations are
indeed beneficial for data analysis and display within a desktop GIS platform.
Web Processing Service Support for MapWindow GIS
5
Most fully online GIS tools stop at simply viewing data. For example, the USGS
Seamless Data Distribution website (United States Geological Survey, 2004) and the Interactive
Numeric and Spatial Information Data Engine (INSIDE) Idaho website (INSIDE Idaho, 2006)
are tools intended only to view data and provide downloadable data. A notable exception is the
USGS Streamstats (USGS, 2005) system, which allows computation of watershed characteristics
online. In general, however, processing data through a web browser is infeasible due to the
difficulty of providing workable interfaces to do so. Loading online data into a client-side GIS
allows the user to perform advanced geoprocessing on that data in an environment better suited
to processing tasks. MapWindow GIS, like most client-side GIS platforms, requires that any
advanced geoprocessing code is stored locally (in the form of a binary plug-in or script). The
next step in bringing the benefits of the web into client-side GIS applications is to allow
execution of remote code for geoprocessing. The Open Geospatial Consortium has proposed a
specification to accomplish this goal, called the Web Processing Service (WPS). The OGC
requested public comments on the proposal for a time, closing the forum on February 4, 2006.
MapWindow GIS may also be used to evaluate the feasibility and applicability of this
specification with regard to potential use in client-side GIS. Creation of online tools conforming
to the proposed WPS standard using both ASP.NET (a Microsoft programming language) on
Windows 2003 Server and using PHP (a cross-platform scripting language) on Linux
demonstrates the lack of platform or language constraint in the specification as well as
demonstrating clean and simple interoperability of online tools running on different platforms
and in different languages. The MapWindow GIS implementation illustrates that the WPS
proposal is appropriate and effective, while also identifying opportunities for improvement and
enhancement.
6
Summary of Contributions
Implementing the Open Geospatial Consortium specifications in MapWindow GIS
demonstrates the applicability of the standards not only to fully web-based systems but also to
client-side GIS platforms. The implementation of the WPS specification in MapWindow seeks to
illustrate that algorithms may be used easily by desktop GIS through the Internet, solving the
long-standing problem of updating desktop GIS software to latest versions. By executing certain
algorithms on remote servers, the processing taking place with the submitted data is guaranteed
to be using the latest version of the algorithm. At the same time, the implementation of WFS and
WMS solve the problems of data sharing and data updates typical of client-side GIS systems
while expanding the ability of users to share common data. These extensions to MapWindow
GIS can easily be used by the large MapWindow GIS user base, yielding immediate benefits to
the studies and questions being answered using MapWindow GIS. Beyond developing tools for
immediate use, these implementations will develop approaches, optimizations and techniques
which may be applied to other existing systems, creating broader impacts to the GIS society at
large. Further, the implementation of these OGC specifications is anticipated to highlight areas
of potential improvement for future versions of the specifications, as well as providing an
example for others who wish to adopt the standards.
7
Chapter 2: Literature Review
As early as 1997, cooperation between GIS competitors to develop standards became
apparent. At that time, it was noted that the competing GIS vendors “have shown extraordinary
cooperation in teaming to submit OpenGIS Specifications” (Information Today, 1997). Kurt
Buehler, OGC Vice President of Technology, said that this “indicates the tremendous desire on
the part of the geospatial technology community to solve problems which have hindered
geospatial information access for many years.” He goes on to say that “our members’
achievement makes it clear that the OpenGIS process will result in the industry-standard
interoperability architecture that we all hope for” (Information Today, 1997).
As indicated by recent GIS literature, the Open Geospatial Consortium standards are
clearly beginning to be viewed with a good deal of respect throughout the academic and
commercial community. Peng and Zhang (2004) evaluated the roles of Geography Markup
Language (GML), Scalable Vector Graphics (SVG) and Web Feature Service (WFS) using two
case studies. They found the interoperability and portability of these standards to be excellent,
solving the problem of “interoperability among heterogeneous systems and geospatial data”
(Peng and Zhang, 2004). As a wider community of people evaluate and adopt these
specifications, they will begin to guide the future developments in the GIS world.
Kraak (2004) pointed out the utility of web mapping for dissemination of geospatial data
indicating that internet maps can “function as they have always done, as an abstraction of
geographic reality,” or that they can be used in combination with search engines as a hyperlinked
portal to spatially referenced data.
The popularity and growth of web-based GIS is continuing to grow. Isaacs (2000) states
that local governments are beginning to provide more data online. Verniel, assistant town
8
manager for Blacksburg, Virginia, illustrates this: “Web GIS is one part of giving information to
residents and getting them involved in local government” (Isaacs, 2000). Isaacs points out that
providing communitywide GIS data enables community members to be involved in new and
innovative ways: for example, printing out a customized map for a community meeting. Evans et
al (1998) continue this idea of public involvement with a case study to evaluate the feasibility
and usability of web-based GIS by the public at large. In this case, the resulting web-based
system was found “both useful and popular” (Evans et al, 1998).
Despite the growing popularity of web-based GIS, there are a couple of drawbacks. Peng
(1997) points out the two issues that are perhaps the largest relating to the development of
Internet GIS:
There are basic functions for interactive map view such as zoom, pan and query.
However, there lacks [sic] more advanced GIS analysis functions such as buffering,
spatial object overlay, network analysis, to name a few […] the second issue is
performance. GIS data, especially raster and image data are large in volume and take long
time [sic] to transfer over the Internet (Peng, 1997).
The second issue that Peng mentions is lessening in importance as the Internet grows in
power and speed, as 8 years have now passed since he made these comments. Despite all of this
time, both of these issues do still exist and are large hurdles to overcome. One way to overcome
the problem of speed is to embrace new display technologies such as adaptive zooming. Cecconi
and Galanda (2002) indicate that adaptive zooming includes two common concepts – adjusting
the level of detail truly necessary for visualization, and generalization of vector features for
display. To this end, Cecconi and Galanda use the W3C Scalable Vector Graphics (SVG)
9
standard for their map displays. The same principles may also be extended to client-side GIS
systems which make use of graphics technologies other than SVG.
The GIS research and user community is now beginning to address the first of Peng’s
points, namely the lack of any advanced geoprocessing in web-based GIS. Hecht (2002) notes
that the Internet is moving toward services rather than just data. Limp (2002) continues this idea,
pointing out that the next major move in Internet GIS will be web service-based geoprocessing,
which he refers to as “Web Geoprocessing Services.”
Indeed, GIS software is “moving from isolated, standalone, monolithic, proprietary
systems […] to smaller web-based applications and components offering specific geo-processing
functionality and transparently exchanging data among them” (Anderson and Moreno-Sanchez,
2003). Noting this, Anderson and Moreno-Sanchez sought to support a land use planning system
in Mexico with online geoprocessing capability. Wishing to avoid the high cost of commercial
alternatives, they used open specifications and open source software to accomplish their goals.
They report that the process is “straightforward and accessible to a broad audience of geographic
information scientists and developers,” and that open source software and specifications “allow
the development of web-based spatial information solutions that are low-cost, simple to
implement, compatible with existing information technology infrastructure, and have the
potential of interoperating with other systems and applications” (Anderson and Moreno-Sanchez,
2003).
Choi and Engel (2003) have also shown that geoprocessing via the web is possible,
through creation of a web-based watershed delineation system. Their tool uses the University of
Minnesota’s MapServer (University of Minnesota, 2006) as the backend engine, using this map
system to obtain an outlet point from the user to begin the delineation process. Their
10
implementation uses a “double-seed array-replacement algorithm to obtain a watershed boundary
form point coordinates.” Although Choi and Engel do not mention conformance to any particular
OGC standard, they do illustrate that geoprocessing via the web is feasible and useful.
Another example of successful web-based geoprocessing is given by Anselin et al (2004)
in their Java-based geoprocessing extensions. Their “specific focus is on methods to identify and
visualize outliers in maps for rates or proportions.” This project is not explicitly focused on
conformance to any particular OGC standard, but because they chose to begin with the open-
source GeoTools (Geotools Project, 2006) package, which is a heavy supporter of OGC
specifications, they do benefit from the specifications. Beginning with Geotools, they extended it
with a set of custom Java classes. They find that “Java as a language is not optimal as a platform
for highly intensive numerical operations,” yet they were still able to demonstrate that the
framework is feasible.
In summary, the literature demonstrates a vibrant and active development effort among
researchers that addresses many of the major concerns of web-based GIS (including display
optimization and web-service geoprocessing). However, further development to better solve the
issues is needed. Specifically, well-designed algorithms, such as those proposed in this thesis, are
needed to illustrate these mechanisms and explore potential enhancements to the OGC
specifications.
11
Chapter 3: An Approach to Implementation of OGC WMS and WFS
Specifications in Client-Side GIS
This paper has been submitted for publication in Transactions in GIS in February of 2007.
Referenced figures and tables appear after the text, as per submission guidelines. References
indicated in text are collected in Appendix 2: References.
Abstract
Open Geospatial Consortium (OGC) standards for the exchange of geospatial data form a
consistent foundation for the development of geographic information system (GIS) software. The
most widely adopted of these standards are written with a clear focus on web based software and
fully internet based server side applications, as evidenced by the OGC Web Feature Service
(WFS) and Web Map Service (WMS) specifications. In this paper, we demonstrate how the WFS
and WMS specifications can be effectively implemented in a client-side GIS and we present an
optimized approach for using web services data in desktop applications. An implementation of
the approach is presented in which WFS and WMS services are consumed by a plug-in to an
open-source GIS platform. This plug-in allows the end user to view and work with WFS, WMS
and ArcIMS data, including data from the ESRI Geography Network, in a transparent manner
that can be optimized for either data analysis and modeling or data visualization. Specific
contributions of the work include the concepts of intelligent pre-fetching through envelope
optimization, tile display and feature complexity reduction. The developed client implementation
of the target services incorporates each of these optimization strategies to improve the speed and
responsiveness with which the data can be viewed and analyzed. Comparisons are made with
several other web-based data access implementations to evaluate the validity and extent of the
speed benefits gained.
12
1. Introduction
Web-based geographic information system (GIS) tools are becoming common for basic
mapping and data visualization tasks (e.g. Google Maps, MapQuest.com and ArcIMS).
However, desktop or client-side GIS tools are likely to continue to be used by government,
academic and commercial users requiring a high degree of custom data management, modeling
and analysis functionality. The primary standards issuing entity for the GIS community, the
Open Geospatial Consortium (OGC), has released many specifications which are not necessarily
web-specific, yet the most widely adopted of its standards are used primarily for web based GIS
tools alone. Because of this, it is likely that most GIS users and tool developers (specifically
those developing tools for the desktop GIS environment) are unaware of OGC standards and
specifications, and their potential implications. Specific OGC standards such as the Web Map
Service (WMS) and Web Feature Service (WFS) have significant potential for normalizing, and
hence improving, the manner in which data is shared across the Internet.
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” (Open Geospatial Consortium, Inc., 2006). This is
accomplished through the authoring of specifications which are created by “structured committee
programs and [a] 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”. The OGC has attempted to address some of the fundamental
problems of data sharing by specifying a common format for wide-scale understandability in
13
distribution, for facilitating geoprocessing and for interoperability between disjoint software
products.
The most widely adopted of the OGC specifications are intended primarily for fully web
based GIS, as evidenced by the names of several key specifications: Web Map Service (WMS),
Web Feature Service (WFS), Web Catalog Service (WCAS) and Web Coverage Service (WCS).
This can be a challenge for several reasons. Web based GIS tools can be very slow and
unresponsive. The U.S. Geological Survey Seamless Data Server (United States Geological
Survey, 2004) is an example of a particularly useful web based GIS system that is plagued by
slow connections and lack of responsiveness. Indeed, when large geospatial data sets are
required for visualization and analysis, web based tools tend to be slow and unresponsive. Any
typical MapServer (University of Minnesota, 2006) or ArcIMS (Environmental Systems
Research Institute, 2006a) website interface will demonstrate this lack of responsiveness;
particularly with multiple concurrent users; e.g., see the Idaho State University Campus Map
(Idaho State University, 2006). Interestingly, both of these web GIS products offer very scalable
service (e.g. they are fast, and remain fast for many simultaneous users) when simply providing
data via WFS, WMS, or ArcXML (an ESRI specific XML specification used by ArcIMS)—
suggesting that the interface overhead can be large when viewed through a website. Simple map
servers such as Google Maps, Yahoo Maps and MapQuest are improving rapidly in their ability
to create a seamless, interactive map viewing experience for end users; however, browsing and
acquiring scientific geospatial data tends to continue to be a slow and tedious process.
Geoprocessing is another point of difficulty 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 successfully is the USGS
14
StreamStats system (United States Geological Survey, 2005). This tool allows one to zoom to,
and select, a point on a map. A contributing watershed is delineated from this point, and several
catchment properties are calculated. A web service such as this can easily make simple
calculations and provide results through a web browser. However, more complex analytical and
mathematical analyses can be challenging to operate in this way—especially when calculation of
results requires a long period of time.
Another problem with strictly web based GIS tools is the typical inability for the user to
keep local copies of data, giving the freedom to use local processing functionality. Although high
speed internet connections are becoming more ubiquitous, GIS analysts are likely to feel more
comfortable having local copies of data in the event of communications or server failure, and
some specialized software products require local data for operation.
The challenges of web based GIS tools are largely overcome by common desktop GIS
applications following the “client-side computing” model that has been popular for at least two
decades. Speed of visualization and data interaction is rarely an issue on desktop based GIS tools
using graphics technologies such as GDI+, DirectX or OpenGL. Additionally, inexpensive
desktop computer storage and memory can be used to improve upon computing speed and
display capabilities. When working on a local or client-side computer, local copies of data are
always available, and advanced, often time consuming geoprocessing tasks may be performed.
In spite of these benefits of traditional desktop based GIS tools, client-side GIS systems
suffer from two main challenges: outdated data sources and the inability to easily share data.
Both of these are areas in which the web based GIS tools excel. An individual or entity hosting a
web based GIS tool has the ability to update data instantly for all users of the system, and,
because of the nature of the Internet, data can be readily and easily shared between users.
15
One could argue that a mixed approach, combining the best features and capabilities of
client-side and web based GIS tools, would be ideal. In the remainder of the paper, we propose a
methodology and introduce a set of software tools and concepts that make 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 manner that demonstrates several
optimization methods which improve performance for data visualization and analysis on a local
desktop GIS platform.
2. Methods
The open source MapWindow GIS (MapWindow Open Source Team, 2006) software
application (Fig. 1) was selected as a demonstration platform for the study because of its use of
the Microsoft Dot Net software development kit, which provides a rich set of web access tools
and technologies. Also, MapWindow GIS is highly extensible using a plug-in architecture that
allows one to construct extensions to the base system using any Microsoft Dot Net Framework
compatible language. The MapWindow GIS plug-in architecture was used in the development of
a plug-in entitled MapWindow Online Data Plug-in (MWODP). As a plug-in, the code and
techniques used in the project can easily be transferred to other GIS applications and platforms.
The primary goal of MWODP is to provide local desktop access to WFS data for feature
(vector) data such as points, lines and polygons, and WMS data for preassembled map imagery.
ArcXML (Environmental Systems Research Institute, 2006b) data sources such as ESRI ArcIMS
Servers are also supported to make use of the large data volume presently available in that form.
16
In addition to providing access to these remote data sources, MWODP demonstrates three
specific data visualization and downloading optimizations including request envelope
optimization, tiled display and feature simplification. MWODP also allows data to be
downloaded and saved locally. Possible optimization modes when using data directly from
online sources include optimization for geoprocessing without attributes, optimization for
geoprocessing with attributes, or optimization for simplified viewing. The main optimization
techniques are discussed in the following sections.
Request Envelope Optimization: The Detail Square Grid
The first optimization takes place through an envelope optimizer referred to as a detail
square grid (DSG). This is a recursive grid (Fig. 2) of short integer data indicating the current
status of each cell within that grid. The initial size of the grid and the initial size of grid cells are
determined by user-configurable options. Each tile of this grid is downloaded separately,
allowing optimization to take place based on the time that a given cell takes to transfer. After
each dataset tile is transferred, the time that the transfer took is evaluated and each grid cell may
be broken down into sublevels. In this case, each grid cell contains another instance of a DSG
which further divides that cell. All functions from outside the optimizer are called on the outer
level DSG. This means that analysis functions are all recursive in order to “dig” through multiple
sublevels of grid cells. Since the grid may have a large depth of grid cells, this provides a great
deal of scalability in quickly providing data updates to the user, automatically adapting to the
connection and transfer speeds available. While some data transfer bandwidth may be consumed
in the overhead of multiple requests to download multiple tiles, rather than fetching all data at
once, the design of the DSG is intended to provide the user with data as quickly as possible,
17
allowing the user to begin to examine and work with the data while downloading of additional
data continues 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 entirely from the type of data being optimized. A flowchart
indicating the operation of this optimizer is presented in Figure 3.
Tiled Display Optimization
After retrieving the desired data envelope to download, a request may be formulated
using extensible markup language (XML) for WMS or WFS, and using ArcXML for ESRI
services.
In the case of WMS, this request will return an image of the map tile requested. Merging
this new data with already-displayed data can present a problem with respect to speed and
seamless interaction. One approach is to dynamically merge newly downloaded high-resolution
imagery with a low-resolution backdrop, resulting in one image file with mixed quality (i.e.
merged tiles of varying resolution). Following this approach, additional imagery transfers would
18
then cause the single client-side image file to be composed of increasingly high resolution
elements. This approach is relatively slow and ineffective because of radically different cell sizes
caused by a resized viewing window and recomputed download tile sizes at different transfer
speeds. Indeed, the most effective high-speed mosaic algorithm tested still resulted in gross
image distortion.
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 (Fig. 4). This approach is superior for visualization because
the GIS drawing engine displays new layers almost instantaneously as no merging is required. In
the MapWindow GIS implementation of this approach, an odd side-effect was the appearance of
legend entries for each separate tile as a new layer in the MapWindow legend. This was avoided
by flagging the additional layers as invisible to the legend, and capturing legend events such as
display customization changes on the single legend item shown. Once captured, these “change
events” may be propagated through to each of the detailed tile layers which are invisible in the
legend, yet still shown in the map. This results in an effective display mechanism for showing
increasingly detailed data with no speed loss.
Feature Retrieval and Feature Simplification Optimization
When requesting feature data, it is desirable 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 indicates that the bounding
box operation “should identify all geometries that spatially interact with the box in some
19
manner” (Open Geospatial Consortium, Inc., 2001c), making the bounding box operation well-
suited for this task. When formulating an ArcXML request, the “area_intersection” operation
performs this same task. For speed purposes, it is also desirable to drop attribute data if it is
unneeded (a preference specified by the user). ArcXML provides a mechanism for this, although
the OGC WFS specification lacks the ability to ignore or drop attributes from received data.
OGC WFS specification requires that data is returned to the client using the geographic
markup language (GML) and ESRI servers typically return data in the ArcXML format. For our
test implementation of MWODP, 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. In a future implementation of MWODP, this step can be
avoided by using GIS software that supports GML directly.
Continuing with the 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 by having all high-priority data loaded in a single
file. 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 outlined above.
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 (Fig. 5) because they are numerous and too close
together. A final pass over the shapefile is made using a modified implementation of the
Douglas-Peucker algorithm (SoftSurfer, 2004), which was originally intended to simplify
20
polyline point arrays. The adaptation used in this tool operates directly on both polygon and
polyline shapefiles, resulting in a faster image display and in smaller file sizes.
File Management and Project Saving Considerations
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 keep track of 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 GIS and other GIS software tools allow plug-ins to
specify settings which are saved to, and loaded from, the overall project file. This allows
MWODP 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 challenge with this approach is that when the project is re-
opened, if the computer does not have an active internet connection, the datasets will not be
viewable unless initially the MWODP “Download Local Copy” option was chosen.
3. Results and Discussion
The client-side MWODP methodologies and implementation presented here resulted in a
relatively efficient viewing system for online data that can be easily integrated with existing local
data. The approach satisfied the goal of building upon the strengths of both web based and client-
21
side GIS tools in an integrated “web-enabled” GIS system that optimizes viewing and download
of data for analysis.
The end-user steps for use of MWODP are illustrated in Figures 6, 7 and 8. Specifically,
the user will first locate the desired data with a “Catalog Browser” (Fig. 6). Next an “Add Layer”
button is used to display the Add Layer dialog (Fig. 7) where the user may specify optimization
options. Repeating these two steps allows the user to construct a project with multiple online
layers that may or may not be accompanied by existing client-side data in the project. An entirely
online project is shown in Figure 8.
The MWODP implementation presented here was compared with on-line data
functionality in several existing GIS systems. The tested tools vary widely in technique and
capabilities; though all have the ability to visualize online data in some form (some lack the
ability to save local copies or cache data locally). A dataset comprised of several different data
types (vector and raster) was accessed using each of the different existing GIS tools. Specifically,
twenty replicates were tested using the same client computer, same network connection and
connecting to the same server, to minimize the chance of differing connection speeds affecting
timing results. 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). All data was served by both ArcIMS
using 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.
22
Figure 9 shows the time analysis results from this comparative study, with MWODP
results on the Y axis and results from the tested tools on the X axis. A 1:1 line is shown for
reference. It is clear from the plots that MWODP performs faster than ArcExplorer over half of
the time, though times may vary from extremely fast to much slower. This is consistent with
designed behavior where an initial display is presented as quickly as possible, yielding the fast
initial access (ti) times. After initial view, the remaining data is downloaded in prioritized pieces
in the background, yielding the slower final display (tf) times. MWODP performs better than
uDig in almost all cases, with the exception of two, and performs better than the ArcIMS HTML
Viewer in all but one case.
Mean values for ti and tf are shown in Table 1. Here it is notable that the complete data
load (tf) of polyline features in MWODP takes a full 170 seconds while ArcExplorer only takes
68 seconds. MWODP consistently falls behind ArcExplorer for a complete data load, but
provides an initial view (ti) several seconds faster. MWODP is typically faster than uDig for
initial display by a large margin, and is faster than uDig for a complete data load in several cases.
The qualitative measures of raster quality indicate that the initial quality in MWODP is less than
that of comparison products, but that the final load quality in MWODP was higher than
comparison products. All testing was done with software versions as available on the Internet on
January 8, 2007.
The US EPA’s Better Assessment Science Integrating Point & Nonpoint Sources
(BASINS) (United States Environmental Protection Agency, 2006) version 4.0 watershed
modeling system is an example end-user application that can benefit from the online data
optimization approaches presented here. BASINS makes heavy use of GIS data for visualization
as well as analysis of watersheds and streams. MWODP will allow BASINS users to easily
23
access data which is maintained online by other entities. In addition to vector data used for
modeling purposes, BASINS users also rely on preassembled map imagery for visualization and
site locating. Here, the tool may provide an efficient mechanism of delivering high-resolution
imagery from WMS services. Indeed, any application that requires access to shared data for
visualization and analysis could potentially be improved by the concepts presented here. The
ArcXML capabilities of MWODP provide an additional way to work with data when a given
ArcIMS website gateway does not yield itself to the task at hand, such as digitizing points from
an ArcIMS image background. The website interface may be bypassed entirely, using the
underlying data directly and thus allowing the task to be completed easily.
In summary, the primary contributions of this work include the development of a request
envelope optimizer to determine what data to download, as well as implementation of a tile-
based display approach and vector feature simplification techniques. The implementation and
comparative study presented here have demonstrated the potential for these optimizations with
respect to data analysis and display - showing that WFS, WMS and ArcXML data sources may
be effectively used within a desktop GIS platform.
24
Figures and Tables
Figure 1. The MapWindow GIS desktop platform.
25
Figure 2. Detail Square Grid (DSG). Any given grid cell may recursively contain another
instance of a DSG, to a virtually unlimited depth.
26
Figure 3. Flowchart showing the general operation of the Detail Square Grid (DSG).
27
Figure 4. Display mechanism for showing high-resolution data over low-resolution data, as new
data is downloaded. New tile is added over top right corner.
28
Figure 5. Feature simplification process. Dropping redundant vertices has no impact on visual
appearance and a negligible initial time impact.
29
Figure 6. Using the Catalog Browser to locate data.
30
Figure 7. Using the Add Layer screen to insert online data into a project.
31
Figure 8. A full project built entirely with online layers.
32
Figure 9. Times to load and display data in MapWindow with MWODP versus comparison
products.
33
Table 1. Mean initial data display times (ti) and complete data load times (tf) for selected GIS applications and data sources, in seconds.
Metric Data Type (ArcXML) MWODP ArcExplorer uDig AIMS Viewer
ti Polyline; 73291 Features 0.90 5.00 n/a4 8.25
tf Polyline; 73291 Features 170.00 68.00 n/a4 n/a
ti Point; 3128 Features 0.90 3.90 n/a4 2.00
tf Point; 3128 Features 12.40 8.21 n/a4 n/a
ti Polygon; 50 Features 0.60 0.70 n/a4 0.50
tf Polygon; 50 Features 18.00 0.70 n/a4 n/a
ti Image (30m DEM) 0.90 4.00 n/a4 3.00
tf Image (30m DEM) 107.50 n/a n/a4 n/a
Data Type (WFS/WMS) MWODP ArcExplorer uDig AIMS Viewer
ti Polyline; 49 Features 0.20 n/a4 8.00 n/a4
tf Polyline; 49 Features 0.60 n/a4 8.00 n/a4
ti Point; 3128 Features 0.40 n/a4 3.00 n/a4
tf Point; 3128 Features 9.50 n/a4 62.00 n/a4
ti Polygon; 50 Features 0.80 n/a4 7.50 n/a4
tf Polygon; 50 Features 8.60 n/a4 7.50 n/a4
ti Image (30m DEM) 4.00 n/a4 39.00 n/a4
tf Image (30m DEM) 119.60 n/a4 n/a n/a4
34
Chapter 4: Evaluation and Implementation of the OGC Web Processing Service
for Use in a Client-Side GIS
This paper has been submitted for publication to the journal GeoInformatica in March of
2007. Figures follow the full text as per submission guidelines. References indicated in text are
collected in Appendix 2: References.
Abstract
The Open Geospatial Consortium Web Processing Service (WPS) proposed specification
is intended as a solution for developing web-based geoprocessing plug-ins, and for easily sharing
algorithms and geoprocessing functionality. This paper seeks to evaluate the WPS proposal with
respect to feasibility and potential utility, and to identify areas for improvement. An
implementation approach including a client-side tool and a server-wide wrapping technique for
exposing geoprocessing functionality through WPS is presented. Challenges with the WPS
proposal are discussed together with potential solutions. Several potential enhancements to the
WPS proposal are introduced and considered, including a mechanism to guide client applications
in prompting for correct data and a means to list the data available on a server. A successful
implementation of the WPS proposal is presented as well as a list of observed enhancements that
might improve the resulting WPS protocol.
35
1. Introduction
The Open Geospatial Consortium (OGC, or OpenGIS) is a consensus standards
organization concerned primarily with the release of open (i.e., non-proprietary) specifications to
unite geographic information software, bringing the multitude of disjoint formats and
communications mechanisms together to allow interoperability (Open Geospatial Consortium,
2006). Rather than avoiding this standardization and remaining fully proprietary, many GIS
system developers “have shown extraordinary cooperation in teaming to submit OpenGIS
Specifications” (Information Today, 1997) and have actively embraced the standards, some even
participating in their development. As the OGC is composed of many professionals in multiple
fields, rather than a single committee in a single corporate environment, the standards are
typically of consistently high quality and are suitable for any number of differing scientific tasks.
On November 17, 2005, the OGC released the fourth revision of a proposal for a
specification called the Web Processing Service (WPS) (Open Geospatial Consortium, 2005).
This proposed specification describes a mechanism by which geoprocessing may be performed
on remote servers, using principally extensible markup language (XML) for communication
through the Internet. The specification is authored in such a way that it should be fully language
and platform independent. The OGC requested public comments for a time, with a cutoff date of
February 4, 2006. Although the forum for public comments has already closed, there have been,
to date, few if any real-world studies on the feasibility and utility of the proposal from the client-
side GIS point of view.
Prior to WPS, web-based geoprocessing systems and approaches similar to WPS have
been implemented by various entities. Most notably, the Environmental Systems Research
Institute (ESRI) product ArcInfo 8.3 (ESRI, 2003) contains a feature called the Geoprocessing
36
Server, which ran on large-scale UNIX servers to perform geoprocessing on behalf of ESRI
client software which submitted jobs for processing. The ESRI Geoprocessing Server protocol is
proprietary and closed such that only ESRI software is able to make use of the remote processing
capabilities. Interestingly, this feature was removed from the following version (ArcGIS 9.0). A
similar but subtly different feature was introduced in ArcGIS Server 9.2, where a “Model
Builder” tool constructed from simpler ESRI geoprocessing components may be served to
ArcGIS Desktop and ArcExplorer clients (Environmental Systems Research Institute, 2006).
Unlike WPS, the ESRI implementation is not compatible with non-ESRI products. A closed,
proprietary communications protocol prevents it from being adopted at large or studied in a non-
ESRI environment.
2. What is the Web Processing Service (WPS)?
The Web Processing Service defines a mechanism by which a client may submit a
processing task to a server to be completed. The service defines a “server instance”, or server, as
an entity which may provide one or more processes, or individual processing tasks (e.g., adding
two raster datasets together could be one process). In this manner, any given server may be able
to perform multiple different, and not necessarily related, processes.
The specification indicates that extensible markup language (XML) should be used for all
communication. Extensible markup language documents are made up of individual elements,
which are logical containers for related data. An element may contain other elements, and any
given element may contain attributes which describe that element. A simple example of an XML
document might be:
<landscape name=”Smithsonian Park”>
37
<tree type=”Elm” height=”8” />
</landscape>
This XML document describes a landscape, which is indicated by the element entitled
“landscape”. An attribute entitled “name” indicates that this is the Smithsonian Park. A sub-
element entitled “Tree” implies that the landscape contains or owns this tree, and the tree has a
further two attributes which describe the type of tree and its height. The element is closed, or
ended, by repeating the name of the element with a leading slash.
XML is designed to be “straightforwardly usable over the Internet”, “human-legible and
reasonably clear”, “formal and concise”, and “easy to create” (W3C, 2000). Using XML is
beneficial mainly due to being human-readable, which assists greatly in designing and debugging
applications using it. XML documents may be validated to ensure that they contain all needed
elements and attributes. Validation takes place against an XML schema, which is a specialized
form of XML document which describes the structure that an XML document must follow.
The main goal of the Web Processing Service is to define how to communicate to
perform remote processing. To this end, there are three key requests which may be made of a
WPS server: GetCapabilities, DescribeProcess, and Execute. The first of the requests asks the
server to list the individual processes which are available on that server, along with a short
abstract and keywords. The request does not require any parameters. Once a process has been
identified from the response, a “DescribeProcess” request may be sent, providing the process in
question as a parameter. The response to this request includes the same information as the
GetCapabilities response, plus more detailed information about any needed input parameters for
the process and whether the input is simple (e.g., a simple number like 23) or complex (e.g., a
38
data file). Complex outputs are typically encoded as XML, for instance using GML (Geographic
Markup Language, a relative of XML) for vector data.
If the DescribeProcess response indicated that this is the process the user or client wishes
to execute, the third request (Execute) may be invoked. This requests that the server actually
performs the operation. Necessary parameters include the name of the process as well as any
applicable inputs for the particular process. The response to the Execute request is an
ExecuteResponse document, another XML document which indicates a process status, indicates
the inputs that were used, and provides either simple literal value outputs or links to complex
outputs. The process status may be “ProcessAccepted”, indicating that the process was received
and is in queue to be processed; “ProcessStarted”, indicating that the process is underway;
“ProcessSucceeded”, meaning the process completed; or “ProcessFailed”, indicating that a
problem occurred. If the status is ProcessAccepted or ProcessStarted, the status is accompanied
by an attribute which indicates where the next ExecuteResponse document may be found. In this
way, the client may check on the status of the process by requesting the next ExecuteResponse
document. In the case of ProcessStarted, a status message and progress percentage may also be
provided.
If the process status is ProcessFailed, the ExecuteResponse document also contains an
error code embedded in an XML ExceptionReport element, which may be one of five error codes
(MissingParameterValue, InvalidParameterValue, NoApplicableCode, ServerBusy or
FileSizeExceeded). If the process succeeded, the response document will also include either the
outputs (in the case of simple literal values) or URL links to complex outputs (such as a file with
raster data). If a single complex output is produced, that output may be returned directly in lieu
39
of an ExecuteResponse document. Together, these three operation requests and their responses
constitute the majority of the Web Processing Service proposal.
3. Why and when should a Web Processing Service be used?
Because the geoprocessing functionality proposed is unlimited in scope or nature (Open
Geospatial Consortium, 2005), the proposal holds great promise for utilizing computational tools
without traditional concerns such as distributing bug fixes or checking for the most up-to-date
version. Although the scope of what may be accomplished is unlimited, many operations can be
completed more quickly locally (i.e., on a user’s desktop PC) than remotely (i.e., on a central
server), especially after factoring in time to upload input data and subsequently download
resulting outputs. When determining whether to use local or remote data processing, a number of
factors must be considered beyond the raw size of the datasets involved. Computational
complexity plays a large part. If the process takes several hours to complete even on a small
dataset, it can be better to process the data remotely. If the task is not complex and the bulk of
the work lies in pressing through large volumes of locally stored data, it can be more efficient to
perform the processing locally. Hence, before one chooses to use only remote data processing, an
intelligent choice ought to be made whether to proceed with processing locally or remotely. As
illustrated in the simple graph in Figure 1, remote processing has a useful place in modern
computing. Higher processing power in server farms can easily reduce the cost of time-
demanding and highly complex tasks, especially when combined with high-throughput networks
such as fibre channel or gigabit ethernet. Therefore, data should be sent to servers typically
having higher processing power, instead of using the slower local computer, when the time to
40
process the data locally would be greater than the combined time to transmit the data, process it
remotely, and download it again.
Remote processing is also an ideal choice if the algorithm is relatively new, and is under
active development. In this scenario, new version releases do not require software upgrades by
end users. Rather, only the server requires an update to reflect the new code or algorithm.
Subsequently all users automatically gain access to the most current and most accurate version of
the process simply by using the server-based processing service. This single point of control over
the process also creates the possibility of charging for the use of the process, if desired.
The traditional view of remote processing mandates that input data is uploaded, as in
Remote Procedure Calls (RPC) where input data and parameters are sent together with a function
call (Bloomer, 1992). Input data could be stored on the server as well, requiring the client only to
specify the particular input which is desired. This creates the opportunity for a processing server
to also provide data: raw data wouldn’t necessarily be provided, but processed result data could
be returned without needing to upload input data. This makes a great deal of sense particularly
for processes requiring real-time data such as weather station observations, live traffic
observations, etc. These processes could be provided by the same agency that collects the data,
allowing the processes to have access to the latest available data at all times. The motivations for
using a remote processing server are many, but ultimately the decision must lie with the user
whether remote processing is appropriate for the task.
4. WPS Implementation Considerations
The WPS proposal describes a mechanism by which a client computer may submit a job
to be processed on a server computer. This is classic client/server architecture, meaning that both
41
a client component and a server component are needed. For implementation and testing purposes
it is useful to build the client-side component on top of an existing geographic information
system to take advantage of existing visualization features for the geospatial data to be processed
and returned, however, this is not always required and initial testing may easily be performed
with command-line or spatially unaware testing tools. This client-side component is the portion
which handles XML communication through the internet with the server, ideally without the user
needing to directly see or work with the XML at all in order to discover available processes or to
make their request and retrieve results. It is desirable to build this client-side component in such
a way that it is not tied to any specific software package, proprietary or otherwise.
The server-side component which provides the client implementation (and other client
implementations) with actual services should similarly be standalone (i.e., not tied to any
particular geoprocessing algorithm or process that is to be provided). One approach to this
problem is to place an interface layer around existing or new geoprocessing routines written as
command-line Linux-based utilities, Windows services, or Windows applications. As long as the
application or algorithm implementation in question may be executed without user interaction
(e.g., through command-line arguments, TCP/IP communication, or through OLE data transfer),
this thin communications layer is a good option. It may be placed around existing geoprocessing
functionality and existing tools (or newly developed tools) to enable them to be served using
WPS, by providing XML that meets the interface requirements of the WPS communication
schema. Rather than requiring a full rewrite of existing software, the existing software will likely
only need minor modification to make it able to run in an unattended mode, ideally via
command-line arguments and generated log files. GRASS utilities (Neteler, 2006) are an
42
excellent example of existing command-line tools which may be wrapped using an approach
such as this.
This wrapper may then initiate the tool as needed, and monitor a log file or a return a
status message to indicate whether the process succeeded, is still running, failed or is in queue.
Status percentages and relevant error messages may also be retrieved from log files, to be
returned to the end user through appropriate communications in an automated fashion, with this
wrapping technique. Placing this thin wrapper around standalone tools enables them to be used
in multiple places and for multiple purposes with a minimum of effort. In essence, this wrapper
becomes the “WPS Server”, because it handles all communications needed by WPS. This
wrapper, constituting the WPS server, could be implemented as a PHP web page, as an
ASP.NET web page, as a standalone application or using any other server technology.
Many of the operations needed by a WPS server are simply metadata operations:
providing information about individual processes (i.e., required inputs) and listing processes
available on a server. The WPS server will ideally load information on available processes from
a configuration file (perhaps one per process) or from a database, thus making the code written
for the WPS server reusable simply by adding additional processes to configuration files or to the
database. These configuration files or this database may also indicate to the WPS server how to
launch the process and how to parse its output files.
An overview of the suggested communications flow between a client application and a
server application is shown in Figure 2. Initially, the client application will query the server,
providing a GetCapabilities request. The WPS server then returns an XML document matching
the WPS schema (arrow 1 in Fig. 2). The client then presents the user with a list of the processes
available on the server (arrow 2 in Fig. 2). The user then selects one of these processes, causing
43
the client to request additional information on that process (arrow 3) by sending the
DescribeProcess request. The client application helps the user to collect and enter any needed
input parameters for the process to be executed; it then initiates the process on the server (arrow
3) by sending the Execute request. The server in turn will trigger a specialized process launcher
utility (arrow 4).
Note that the WPS server should not execute the requested process directly, because this
would imply a delay: the server would need to complete the process before a reply to the client
could be sent. Instead, it is desirable to have the WPS server initiate processing in a different
thread, or in a different process, so that an initial ExecuteResponse may be immediately returned
to the client. In this manner, geoprocessing operations which are expected to take a good deal of
time will still allow the end user to use their computer. For cleanliness and safety, it is best to
start a completely new process, so that if a process terminates abnormally it won’t stop the entire
WPS server as well: hence, a specialized process launcher utility is a good solution.
As explained in section 2, this initial ExecuteResponse document informs the client
application of where future status updates (i.e., the next ExecuteResponse) on the requested
operation may be found, as well as notifying of success, failure, accepted or rejected jobs, and
providing status updates. The client application should request this next ExecuteResponse
document as often as the user wishes (arrow 6 in Fig. 2). Ideally the WPS server should be
designed such that an ExecuteResponse document may be found in a consistent location, perhaps
always using the same URL for the most recent response. A good approach to addressing
generation of response documents would be the creation of a specialized web page or server
component which simply parses a log file being written by an executing process to determine
current status or errors.
44
Having the ability to provide status updates requires that the server component is able to
get such updates from the process which is executing. As implied, a log file is an excellent
solution to this: the process should be able to write a log file or to redirect its standard output to a
text file. In this manner, the file may be automatically parsed by the WPS server, providing good
connectivity between the components of the system.
Once the ExecuteResponse document indicates that the process has completed, the server
must return any applicable error message or return information on where the generated data may
be downloaded or obtained. The client software should then allow the user to save or view the
data, thus completing the role of WPS.
5. Suggested Enhancements, Problems and Potential Solutions
While the WPS proposal is able to accomplish its stated goals in its current form, the
proposal could be enhanced by six key changes. These changes include two additional elements
in the DescribeProcess response provided by a server, which describes a given process’s inputs
and outputs, as well as a mechanism by which a client may cancel a request which is pending or
processing. Potential changes also include correcting some inconsistencies in behavior, providing
additional exception types for error handling, and having only a single entry point for each
process and perhaps a single entry point for each server.
The first suggested change is to add an element to the Extensible Markup Language
(XML) document which is returned by a DescribeProcess request. Currently, the needed inputs
are listed by this document, but no clear description of how the client should prompt the user for
this input is provided. The needed data may come in the form of selecting a shape on a map,
providing a literal value such as “23”, browsing for a file of a given type, or dozens of other
45
methods for collecting data. In our test implementation, we introduce a new XML element called
“PromptMethod” to address this problem. The element may contain the values
“browseforvector”, “browseforraster”, “getboundingbox”, or “getmatchingregex”. These will
cause the client application to prompt for a vector file, prompt for a raster file, retrieve a
bounding box (e.g., by asking the user to draw it) or collect a piece of information matching a
particular pattern, respectively. The first three require no explanation; the last, getmatchingregex,
will accept only a user-entered value which matches the provided regular expression.
A regular expression is a rule defined by special characters, such as “^[a-zA-Z][a-zA-
Z]$”. This regular expression would look for the beginning of the input (symbolized by ^),
followed by two letters, from A to Z, independent of case, followed by the end of the input
(symbolized by a dollar sign). This provides a flexible and quickly configurable input filter to
ensure that a user enters only input that is suitable. Some variations for syntax in regular
expressions exist due to differing regular expression processing engines (Goyvaerts, 2006),
meaning that care should be taken to ensure expressions are designed in such a way that they
may be interpreted in the same way on both clients and the server. An example of the suggested
addition to WPS may be seen in Figure 3, where the regular expression is defined as “^\d{8}$”.
This expression indicates that the start of the string (^) should be followed by eight digits (d{8})
and the end of the string ($). This expression assumes that Microsoft’s regular expression
processor will be utilized.
The second suggested change is another addition to the DescribeProcess response.
Currently there is no mechanism by which a server may list the data that is available on the
server for use by a given process. An excellent example of where this may be useful is in the
processes of watershed delineation - defining stream networks and watersheds based on raster
46
elevation datasets (Savant et al., 2002). Elevation raster datasets can typically be very large, so it
is undesirable and often impossible to upload the entire input file to the server. Datasets such as
elevation data typically do not change often, and may be stored on the server to save time. In our
test implantation, we address this by introducing an XML element entitled “AvailableData”, with
a child element for each data item containing a name and a brief description as shown in Figure
4. Not only does this speed up processing by removing the need to upload the input data, but it
also creates a means by which a WPS server may act as a data repository as well as processing it
and returning that processed data.
In the current WPS proposal there is an inconsistency after submitting a job to a server
with regards to what should occur next.. If the process will result in a single return value and the
Execute request was made with the “store” parameter set to false, WPS will allow the process to
immediately return the output, rather than an XML ExecuteResponse document. If there is more
than one output, or if the process has been asked to store the results, then an ExecuteResponse
document is generated. This behavior is inconsistent, since any given process might return either
multiple outputs or a single output, depending on the parameters provided to the process. Instead,
it is simpler and more straightforward to always return an ExecuteResponse document, storing
any complex output data (e.g., vector or raster files) on the server until downloaded by the client.
Simple value outputs (e.g., a single number) may be returned directly embedded in the
ExecuteResponse document, with links pointing to complex outputs. Our third suggested change
is to require always returning an ExecuteResponse document to provide greater consistency and
simplify client implementation far easier.
After submitting a job to a WPS server, it may be desirable to cancel the requested
operation; this eventuality is not planned for with the current WPS proposal. In our test
47
implementation (and as our fourth suggested change) we introduce the use of a “cancel request
URL” in the ExecuteResponse document, along with the existing URL indicating where the next
ExecuteResponse document may be found. In this manner a client wishing to cancel a process
needs only to access the URL to trigger a cancellation of the requested process, preventing
wasted server processing time on undesired processing.
Our fifth suggested change to the WPS proposal is to have a single entry point for each
possible request (GetCapabilities, DescribeProcess, and Execute) on a given process. Ideally, a
single entry point (e.g., a single PHP web page) could be used not only for every request on a
process, but also for every process available on that server. Presently, each of the requests that a
process supports may have a different URL to perform that request, as illustrated in Figure 5. In
the figure, the GetCapabilities URL is circled in blue, the DescribeProcess URL in green, and the
Execute URL in red. Here each URL is the same, making maintenance and implementation
easier, although it is acceptable to have a different access URL for each operation. Confusion or
errors can easily arise with differing URLs for these operations. This can be addressed easily by
making it required to use only one URL for all three of the requests that a process must support.
Lastly, our sixth suggested change is to implement a more highly structured exception
system. Presently there are only a few exception types (MissingParameterValue,
InvalidParameterValue, NoApplicableCode, ServerBusy and FileSizeExceeded), which are
limiting - particularly when attempting to parse the error automatically. With a small number of
exception types (exception codes), there is no generic way in which to handle errors on behalf of
the user; the only thing that can be done presently is to display the error to the user. A more
complex and structured exception hierarchy would allow client applications to understand the
nature of the error that occurred, perhaps recovering or retrying automatically as needed. The
48
ability to insulate the end user from errors and recover gracefully is an important part of any
standard design, and this ability would be made possible with a more detailed exception
hierarchy.
The above six suggested changes and enhancements have potential to enhance the WPS
specification and make it more useful and functional. In the following section, we describe a test
implementation of the WPS proposal which includes the enhancements proposed here.
6. Software Implementation of Design
As indicated, it is useful to build the client-side component on top of an existing
geographic information system to take advantage of existing visualization features for geospatial
data. MapWindow GIS (MapWindow Open Source Team, 2006) is an example of many open
source GIS applications (see osgeo.org for others) suitable for use as an application platform for
evaluating the WPS proposal. With a well-defined plug-in architecture supporting the Visual
Basic .NET and C# programming languages, MapWindow GIS was an useful environment in
which to develop a test implementation of the WPS proposed specification.
Specifically, we constructed a MapWindow plug-in called the “WPS Gateway” that
allows the end user to browse a list of available WPS servers from a simple database-driven
catalog, as well as the processes available on those servers. Any given remote process is referred
to in this system as a “WPS Online Plug-in”, which is accessed via the WPS Gateway
component. The server-side interface layer (process wrapper) described in the design is referred
to as a “WPS Online Plug-in Wrapper” in this implementation. For the purposes of this test, two
unique such wrappers were constructed, one for use with Linux using PHP and one for use with
Windows using ASP.Net.
49
The Linux implementation involved creating a PHP page to provide metadata
information in response to GetCapabilities and DescribeProcess requests and a PHP page to
provide response documents. Additionally a C++ process launcher application was created. Each
of these tools may be easily reused for other processes as well, because the same PHP files may
be reused for multiple processes. Adding a new process can be done by simply adding a new
section to each of the two PHP files which is customized to the new process. This approach can
be extended so that the utilities do not need to be modified for new processes, but instead a
configuration file is saved describing each process provided by the server (as outlined in the
suggested design above). The configuration files will then be read by the tools, making direct
editing of the source code files for each new process unnecessary. This has the benefit of keeping
WPS functionality centralized and abstracted from the actual geoprocessing tools, as well as
providing the convenience of having a single entry point for all WPS processes on a given
server. Taken together, these utilities constitute the “WPS Online Plug-in Wrapper” for Linux.
The communications and process flow in this implementation is shown in Figure 6,
which builds upon the designed communications flow shown in Figure 2. Here, MapWindow
GIS is the client application. From within MapWindow, the user enables the WPS Gateway plug-
in from a menu (arrow 1 in Fig. 6). This causes several menu items to be added to MapWindow.
The key new item of interest is “Browse Catalog”. Because there are currently no central catalog
services available online for listing available WPS processes, a simple database-driven catalog
service has been developed for use by this tool.
Upon choosing “Browse Catalog”, the gateway plug-in queries the catalog service on a
central server (arrow 2 in Fig. 6) to fill a list of available servers. If the user selects one of these
servers, the gateway queries that server with a GetCapabilities request, which returns the server
50
capabilities (listing the available processes). The gateway fills a list with these processes (arrow
3 in Fig. 6). The user may then select one of these processes, causing the gateway plug-in to
request additional information on that process via a DescribeProcess request (arrow 4). If the
user decides to execute this process, the gateway plug-in first collects any needed input data or
parameters from the user. It then initiates the process on the server (arrow 5) by sending an
Execute request. The server in turn triggers the specialized process launcher utility as designed
(arrow 6). This process launcher uses the “fork” operation to initiate the new process which is
not connected to the web page. The initially started process is then free to continue processing
while the server completes successfully to return an initial ExecuteResponse document to the
gateway plug-in, after which the user is informed that the process has been accepted by the
server. The user may continue using their computer while execution continues in the background
on the server past this point.
The newly created process resulting from the fork operation then proceeds to launch the
actual operation, which executes and writes a log file in the process (arrow 7). Periodically, the
gateway application will check on the status of the process (arrow 8). This status check operation
triggers another web page, called “GetStatusUpdate”, which parses the contents of the log file
being written for the particular process request, returning an appropriate status message and
progress percentage. This occurs numerous times until the status indicates that the process has
completed or failed; in the case of failure, the error message is displayed to the user and the
process halts. If successful, the gateway plug-in downloads any output data and causes it to be
displayed in MapWindow GIS (arrow 9).
Two WPS processes were built for this test client implementation to consume. The first
was written for Linux using C++, and performs basic raster mathematic operations (addition,
51
subtraction, multiplication and division). One useful application of such an operation might be to
subtract a raster dataset containing elevation data from a pit-filled elevation dataset of the same
area (Fig. 7). Pit filling is a technique by which depressions in an elevation dataset are filled so
that water may escape from every grid cell; this is used frequently for watershed delineation
(Planchon and Darboux, 2001).
The second online plug-in used to demonstrate and test the WPS proposal is a watershed
delineation tool (Fig. 8). This tool is based on the Automatic Watershed Delineation (AWD) tool
included in the EPA BASINS 4 watershed analysis system (http://www.hspf.com/basins4) and
uses Terrain Analysis using Digital Elevation Models (TauDEM) (Band 1986, Tarboton 1991)
code. The process accepts a raster dataset with elevations as input. Based on this, it produces
several intermediate outputs as well as a stream network shape collection and a watershed
polygon shape collection representing the likely streams and watershed boundaries for the area.
These outputs may then be used for further modeling or visualization.
The first attempt at exposing AWD functionality through the WPS proposal’s
mechanisms followed an approach very similar to the WPS Online Plug-in Wrapper for Linux.
The Automatic Watershed Delineator was written in Visual Basic .NET originally; this project
was converted to a command-line utility easily. An ASP.NET web page was created to handle
WPS requests in the same manner as with the raster mathematics plug-in, and a process launcher
technique was implemented. Initial testing of this technique worked successfully, but in practice,
the launcher was unable to access all files and ActiveX components (a type of Windows library)
needed to complete the operation. The attempt to start the command-line delineation tool would
fail with a myriad of errors: threading model compatibility problems, permissions failures, and a
mysterious “Insufficient privileges to launch COM object” error message. Even when ASP.NET
52
was configured to run with administrative access as a last resort, these permissions problems
persisted. To make matters worse, many of the files randomly had their permissions reset by
Windows, particularly when rebooting.
The implementation of the AWD online plug-in wrapper involved creating a new
Windows service called “Delineation Listener” which monitors a temporary path used to store
input files. The ASP.NET web page accepts the input files and returns an initial
ExecuteResponse document, then simply terminates (see Figure 9, from step 6 onward). When a
new input file is detected by the Windows listener service, the delineation tool begins processing
the new input files (arrow 6 in Fig. 9), writing to a log file while processing. Subsequent status
update requests from the gateway plug-in access a “GetStatusUpdate” ASP.NET web page much
like the Linux PHP equivalent. This GetStatusUpdate tool parses the log file written by the
Delineation Listener service and returns an appropriate ExecuteResponse document. If the log
file does not yet exist, it’s assumed that the Delineation Listener service has not yet begun
processing the input, so the ExecuteResponse document simply indicates that the process has
been accepted but has not yet begun being processed.
The two ASP.NET web pages (the page handling WPS GetCapabilities, DescribeProcess
and Execute requests, and the page handling status updates) along with the Delineation Listener
comprise the “WPS Online Plug-in Wrapper” for Windows. Similar to the Linux approach, the
same set of web pages can handle multiple differing processes by adding a section to the pages
for each new process. The Delineation Listener is customized tightly to the delineation process,
so with the present architecture a new Windows service needs to be authored for each new
process. Future enhancements might include using configuration files for each process as with
the Linux approach, and creating a generic Windows listener service for launching actual
53
processing tasks. A generic listener service will eliminate the need to create a completely new
listener service for each new process running on Windows.
7. Conclusion
Overall, the WPS proposal was found to be an effective way of standardizing on a
communications mechanism for client/server geoprocessing. The proposal works as currently
designed, and is indeed suitable for many GIS tasks. Implementation of the client component and
the server-based WPS processes showed that the WPS proposal is sound and effective.
Nonetheless, there are several opportunities for enhancement to the WPS proposal including the
six specific recommendations provided here. Our test implementation is a simple wrapping
approach to expose current and new geoprocessing functionality using the WPS strategy easily
and quickly on the server-side, and it provides a client implementation for an existing open-
source GIS platform, MapWindow. It is hoped that these efforts will benefit others working to
implement the WPS proposed specification on other GIS platforms, and that our specific test
implementation will also be immediately beneficial to current MapWindow users.
Any conceivable geoprocessing activity may be presented in an “online plug-in” format.
This allows the developers of the algorithm to continuously improve the algorithm while still
allowing users at any location to use the code, without needing to update to a latest version. This
also ensures that code and algorithms being used are of high quality; if a bug is detected in a
released version of an algorithm which is distributed on CD, no easy way exists to ensure that all
users successfully upgrade to the corrected version. With a web-based processing architecture,
this problem is alleviated by simply publishing the new algorithm to the processing server.
Processor intensive and time consuming geoprocessing may be performed on remote servers,
54
freeing the user’s desktop to work on other tasks. Large datasets may even be stored on the
server and processed according to the user’s particular parameters, combining data repository
and data processing aspects into one system.
The WPS proposal introduces a standard which will allow diverse developers at different
locations to produce geoprocessing offerings and provide them easily to differing client
platforms. In these tests, the WPS proposal has been shown to be practical and usable in its
current design. The additional enhancements proposed can improve WPS significantly, making it
better suited still to the task for which it was designed.
55
Figures
Figure 1. Local processing and remote processing each have their appropriate time.
56
Figure 2. Suggested communications flow between the client and the server.
57
Figure 3. Suggested PromptMethod element in DescribeProcess response.
58
Figure 4. Suggested AvailableData element in DescribeProcess response.
59
Figure 5. Ability to have a differing URL for each request on the same process can cause
confusion and unnecessary complexity.
60
Figure 6. Communication and process flow for MapWindow GIS implementation.
61
Figure 7. Sample output of a subtraction operation.
62
Figure 8. Sample outputs of the Watershed Delineation tool.
63
Figure 9. Revised approach for Windows and ASP.NET.
64
Chapter 5: Conclusions
This thesis details the evaluation and software implementation of three major Open
Geospatial Consortium specifications; two in a released state (Web Map Service and Web
Feature Service) and one in a proposal state (Web Processing Service). One of the released
specifications, WFS, requires the use and implementation of the Geographic Markup Language
(GML) as a communications mechanism, thus including a fourth specification to consider.
Implementation of the released specifications in software highlighted no major design
flaws with the specifications, and software development was straightforward without any
noteworthy complications. This is in contrast to the proposed specification, WPS, which didn’t
necessarily have flaws, but which did omit some key considerations. This difference may be
explained by the wide number of tools making use of the WMS and WFS specifications at this
point; it is likely that wide adoption causes faster feedback and improvement of the proposals. As
the WPS proposal continues to be adopted and tested, it too will evolve to the point that
developers attempting to implement it can find no flaws or areas to improve upon. As it stands,
the discussed improvements to WPS will help to bring it to the level of quality observed in WMS
and WFS; but additional work and discussion is needed to reach this end goal.
The attempt to merge the web-oriented WFS and WMS specifications into a client-side
GIS to allow end users to build GIS projects consisting of both online and offline data sources
met with success. Resulting time measurements compare well with similar solutions, often
resulting in a faster and more efficient data view. As stated, no major design problems were
encountered with WFS or WMS; so no design enhancements are proposed. Rather, a design and
implementation approach is outlined, illustrating how a software developer may make effective
use of the proposals in client-side GIS. The design is implemented as the MapWindow Online
65
Data Plug-in, which may serve as a finished software example of the outlined design approach.
Source code for this project may be found on the included CD-ROM.
WPS was implemented primarily to test its effectiveness at solving the problem of
client/server data processing. After considering the fundamental layout of the proposal and
potential communications flows, a design was proposed for adopting the specification. Because
WPS is a client/server architecture, it is irrelevant whether the “client” is itself a server, which is
passing along requests to the processing server, versus the setup of the “client” being an actual
end-user application. In this implementation, the “client” is assumed to be an end-user
application running on a local desktop. The communications framework and approach developed
may be applied to any set of client/server component pairs, whether local or server-based.
The suggested software design was then implemented successfully as the MapWindow
WPS Gateway application serving as the client-side component, and a few relatively simple
server-side processes were developed for consumption by this gateway application for testing.
Potential enhancements and a few minor problems in WPS were discussed, and some of these
enhancements were also built into the example software implementation. Source code for all
WPS components (the Windows client application as well as all server-side components) is
available on the included CD-ROM.
All Open Geospatial Consortium specifications that were tested were found to be
effective and useful from within client-side GIS, and are found to be easily useable by software
developers to aid in standardization. The more mature WMS and WFS specifications are found
to be more solid, with less possibility for confusion or missing functionality than WPS. This
discussion, and future work, will help to bring WPS into a more useful and more widely adopted
form.
66
Appendix 1: References
Alesheikh, AA., H. Helai, HA. Behroz, (2002). Web GIS: Technologies and Its Applications,
Proceedings of the 2002 Symposium on Geospatial Theory, Processing and Applications,
International Society for Photogrammetry and Remove Sensing.
Anderson, Geoffrey and Rafael Moreno-Sanchez, (2003). Building Web-Based Spatial
Information Solutions around Open Specifications and Open Source Software.
Transactions in GIS, 7(4): 447-466.
Andrew Evans, R. Kingston, S. Carver, I Turton, (1999). Web-based GIS used to enhance public
democratic involvement. Presentation given at GeoComputation ’99, Mary Washington
College, Virginia.
Anselin, Luc, Yong Wook Kim and Ibnu Syabri, (2004). Web-based analytical tools for the
exploration of spatial data. Journal of Geographic Systems. 6, 197-218.
Band, L. E., (1986), "Topographic partition of watersheds with digital elevation models," Water
Resources Research, 22(1): l5-24.
Bloomer, John. 1992. Power Programming with RPC. Cambridge, MA: O’Reilly Media.
Choi, Jin-Yong and Bernard A. Engel (2003). Real-Time Watershed Delineation System Using
Web-GIS. Journal of Computing in Civil Engineering. 17(3), 189.
Douglas, David H. and Thomas K. Peucker (1973). Algorithms for the reduction of the number
of points required to represent a digitized line or its caricature, The Canadian
Cartographer 10(2): 112-122
Environmental Systems Research Institute (ESRI). 2003. ArcGIS Desktop Products Data Sheet.
WWW document, http://www.esrichina-bj.cn/produce/esri/arcgisdesktopsheet.pdf
67
Environmental Systems Research Institute (ESRI) (2005). History of ESRI. WWW document,
http://www.esri.com/company/about/timeline/flash/index.html
Environmental Systems Research Institute (ESRI) (2006a). ArcIMS. WWW document,
http://www.esri.com/software/arcgis/arcims/index.html
Environmental Systems Research Institute (ESRI) (2006b). Geography Network. WWW
document, http://www.geographynetwork.com/
Environmental Systems Research Institute (ESRI) (2006c). ArcXML Programmer’s Reference
Guide. WWW document, http://edndoc.esri.com/arcims/9.1/
Environmental Systems Research Institute (ESRI). (2006d). ArcGIS 9.2 Webinar – ArcGIS
Server: Publishing a Geoprocessing Model. WWW document,
Galanda, Cecconi and Martin Galanda, (2002). Adaptive Zooming in Web Cartography.
Computer Graphics Forum, 21(4), 787-799.
Geotools Project (2006). GeoTools, The Open Source Java GIS Toolkit. WWW document,
http://geotools.codehaus.org/
GIS Competitors Cooperate on OpenGIS Specs. (1997). Information Today, 14(2), 15-15.
Google, (2005a). Google Earth Common Questions. WWW document,
http://earth.google.com/faq.html
Google, (2005b). Explore Google Local. WWW document, http://maps.google.com
Goyvaerts, Jan. 2006. Regular Expression Tutorial. WWW document, http://www.regular-
expressions.info/tutorial.html
Hecht, Louis, (2002). Web Services Are the Future of Geoprocessing. GeoWorld, 15, 26.
INSIDE Idaho (2006). Interactive Numeric and Spatial Information Data Engine. WWW
document, http://indideidaho.org/
68
Idaho State University 2006 Campus Map. WWW document, http://giscenter-
ims.isu.edu/website/CampusGIS/viewer.htm
Isaacs, Lindsay, (2000). GIS on the Net. American City & County, 115(15), 52.
Kraak, Menno-Jan, (2004). The role of the map in a Web-GIS environment. Journal of
Geographic Systems, 6, 83-93
Limp, W. Frederick, (2002). Web Mapping 2002. GeoWorld, 15, 30-32.
Long, Darrel, A. Muir, and R. Golding, (1995). A longitudinal survey of Internet host reliability.
Symposium on Reliable Distributed Systems
MapWindow Open Source Team. (2006). MapWindow GIS 4.0 Open Source Software. WWW
document, http://www.mapwindow.org/
Neteler, M. November 2006. The GRASS GIS software. Presented at a GIS Seminar at
Politecnico di Milano, Polo Regionale di Como.
Open Geospatial Consortium, Inc. (2004). Geography Markup Language (GML) Committee
Draft. WWW document, http://www.opengeospatial.org/
Open Geospatial Consortium, Inc. (2001a). OpenGIS® Implementation Specification: Grid
Coverage. WWW document, http://www.opengeospatial.org/
Open Geospatial Consortium, Inc. (2005a). Web Feature Service Implementation Specification.
WWW document, http://www.opengeospatial.org/
Open Geospatial Consortium, Inc. (2001b). Web Map Service Implementation Specification.
WWW document, http://www.opengeospatial.org/
Open Geospatial Consortium, Inc. (2001c). Filter Encoding Implementation Specification.
WWW document, http://www.opengeospatial.org/
69
Open Geospatial Consortium, Inc. (2005b). OpenGIS® Web Processing Service (WPS)
Discussion Paper. WWW document, http://www.opengeospatial.org/
Open Geospatial Consortium, Inc. (2006). Vision and Mission. WWW document,
http://www.opengeospatial.org/about/?page=vision
Open Geospatial Consortium, Inc. (2003). Web Map Service (WMS) Implementation
Specification. WWW document, http://www.opengeospatial.org/
Open Source Initiative OSI. (2006). The Open Source Definition. WWW document,
http://opensource.org/docs/definition.php
Peng, Zhong-Ren. (1997). An assessment of the development of Internet GIS, ESRI User’s
Conference, San Diego, CA, 1997.
Peng, Zhong-Ren and Chuanrong Zhang (2004). The roles of geography markup language
(GML), scalable vector graphics (SVG), and Web feature service (WFS) specifications in
the development of Internet geographic information systems (GIS). Journal of
Geographical Systems, 6, 95-116.
Planchon, Olivier and F. Darboux. 2001. A fast, simple and versatile algorithm to fill the
depressions of digital elevation models. Catena 46: 159-176
Tarboton, David. G., (1989), "The analysis of river basins and channel networks using digital
terrain data," Sc.D. Thesis, M.I.T., Cambridge, MA, (Also available as Tarboton D. G.,
R. L. Bras and I. Rodriguez-Iturbe, (Same title), Technical report no 326, Ralph M.
Parsons Laboratory for Water resources and Hydrodynamics, Department of Civil
Engineering, M.I.T., September 1989).
70
Savant, Gaurav, L. Wang, D. Traux. 2002. Remote Sensing and Geospatial Applications for
Watershed Delineation. Conference Proceedings: Integrated Remote Sensing at the
Global, Regional and Local Scale. IAPRS, Vol. XXXIV, Part 1, ISSN 1682-1750
United States Environmental Protection Agency (2006). BASINS, Accessed May 30, 2006 at the
EPA Website: http://www.epa.gov/OST/BASINS/
United States Geological Survey (2004). Seamless Data Distribution System. WWW document,
http://seamless.usgs.gov/
United States Geological Survey (2005). StreamStats. WWW document,
http://water.usgs.gov/osw/streamstats/index.html
University of Minnesota (Regents of) (2006). MapServer. WWW document,
http://mapserver.gis.umn.edu/
W3C, 2000. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation,
6 October 2000.
Wright, Dawn J., J. B. Cushing, J. E. Cuny, D. R. Toomey, (2003). Why Web GIS May Not Be
Enough: A Case Study with the Virtual Research Vessel. Marine Geodesy, 26, 73-86
Wuthrich, Dennis, (2005). Rethinking Web-GIS: Design and Use Considerations for GIS on the
Web. Proceedings of the May 2005 Conference of the Urban and Regional Information
Systems Association.
71
Appendix 2: CD-ROM Contents
| AutorunPro.EXE | MapWindow 4.3 Stable Release.exe | autorun.inf | index.htm | +---MapWindow 4.3 Source Code | | Contents not listed as MapWindow source code is supplementary. | +---OnlineDataPlugin 2.3 Binaries | | README.TXT | | | \---OnlineDataPlugin | AxInterop.MapWinGIS.dll | Interop.MapWinGIS.dll | ODPOptions.xml | ODPRecent.xml | OnlineDataPlugin.dll | OnlineDataPlugin.pdb | OnlineDataPlugin.xml | UpdateCheck.exe | +---OnlineDataPlugin 2.3 Source Code | | README.TXT | | | \---OnlineDataPlugin | | MPL-1.1.txt | | OnlineDataPlugin.sln | | | \---OnlineDataPlugin | | CB067352_LoRes.jpg | | Globe.ico | | MPL-1.1.html | | NoPreview.bmp | | OnlineDataPlugin.vbproj | | OnlineDataPlugin.vbproj.user | | OnlineDataPlugin.xml | | UpdateCheck.exe | | clsAXLRetrieveBoundBox.vb | | clsCommunications.vb | | clsConverters.vb | | clsDataFetcher.vb | | clsDetailTilesGrid.vb | | clsLayerCustomizationsXML.vb | | clsMergeSF.vb
72
| | clsODPMWInterface.vb | | clsODPTypes.vb | | clsSafeInvokeHandler.vb | | clsVertexSimplifier.vb | | frmAddOnlineLayer.Designer.vb | | frmAddOnlineLayer.resx | | frmAddOnlineLayer.vb | | frmBrowseCatalog.Designer.vb | | frmBrowseCatalog.resx | | frmBrowseCatalog.vb | | frmConfigOpts.Designer.vb | | frmConfigOpts.resx | | frmConfigOpts.vb | | frmOnlineDataStatus.Designer.vb | | frmOnlineDataStatus.resx | | frmOnlineDataStatus.vb | | frmPreviewGenerators.Designer.vb | | frmPreviewGenerators.resx | | frmPreviewGenerators.vb | | frmSynchronousWait.Designer.vb | | frmSynchronousWait.resx | | frmSynchronousWait.vb | | frmUnhandledEx.Designer.vb | | frmUnhandledEx.resx | | frmUnhandledEx.vb | | ico_help0012.ico | | kickbucket_small.gif | | loading.GIF | | loading.jpg | | screwdriver.gif | | | \---My Project | Application.Designer.vb | Application.myapp | AssemblyInfo.vb | Resources.Designer.vb | Resources.resx | Settings.Designer.vb | Settings.settings | +---WPS Gateway 1.0 Binaries | | README.TXT | | | \---WPSGateway | Interop.MapWinGIS.dll | UpdateCheck.exe
73
| WPSGateway.dll | WPSGateway.pdb | WPSGateway.xml | WPSSettings.xml | epsg.txt | \---WPS Gateway 1.0 and Services Source Code | MPL-1.1.txt | README-SRC.TXT | +---WPSCatalog | WPSCatalog.php | WPSConfig.php | +---WPSDelinWebSvc | | ASPError.ashx | | DelinByHUCWebSvc.ashx | | DelinWebSvc.ashx | | DelinWebSvc.sln | | GetCurrentStatus.ashx | | epsg.txt | | web.config | | | +---App_Data | +---Delineator | | | Delineator.sln | | | | | \---Delineator | | | 7za.exe | | | Delineator.vbproj | | | clsAWDDelin.vb | | | frmStartWatching.Designer.vb | | | frmStartWatching.resx | | | frmStartWatching.vb | | | ico_roadsigns0126.ico | | | modDelineator.vb | | | proj.dll | | | tdbFileTypes_v2.vb | | | | | +---My Project | | | Application.Designer.vb | | | Application.myapp | | | AssemblyInfo.vb | | | Resources.Designer.vb | | | Resources.resx | | | Settings.Designer.vb
74
| | | Settings.settings | | | | | \---bin | | \---Debug | | 7za.exe | | Delineator.exe | | Delineator.pdb | | Delineator.vshost.exe | | Delineator.xml | | Dforrt.dll | | Interop.MapWinGIS.dll | | Interop.TKTAUDEMLib.dll | | Interop.mwTauDem.dll | | MapWinGeoProc.dll | | TemplateOutput.txt | | fortcalls.dll | | mwtaudem.dll | | proj.dll | | regTaudem.cmd | | test.bgd | | tkTaudem.dll | | | \---ProcessData +---WPSGateway | | WPSGateway.sln | | | \---WPSGateway | | UpdateCheck.exe | | WPSGateway.vbproj | | clsCommunications.vb | | clsConverters.vb | | clsProcessingItem.vb | | clsSafeInvokeHandler.vb | | clsSettings.vb | | clsWPSGateway.vb | | epsg.txt | | frmBrowse.Designer.vb | | frmBrowse.resx | | frmBrowse.vb | | frmConfigOpts.designer.vb | | frmConfigOpts.resx | | frmConfigOpts.vb | | frmContactInfo.Designer.vb | | frmContactInfo.resx | | frmContactInfo.vb | | frmExecute.Designer.vb
75
| | frmExecute.resx | | frmExecute.vb | | frmInputDialog.vb | | frmSelectMWLayer.Designer.vb | | frmSelectMWLayer.resx | | frmSelectMWLayer.vb | | frmStatus.Designer.vb | | frmStatus.resx | | frmStatus.vb | | frmSubmitServer.Designer.vb | | frmSubmitServer.resx | | frmSubmitServer.vb | | frmSynchronousWait.designer.vb | | frmSynchronousWait.resx | | frmSynchronousWait.vb | | frmUnhandledEx.Designer.vb | | frmUnhandledEx.resx | | frmUnhandledEx.vb | | gears.ico | | ico_help0012.ico | | kickbucket_small.gif | | | \---My Project | Application.Designer.vb | Application.myapp | AssemblyInfo.vb | Resources.Designer.vb | Resources.resx | Settings.Designer.vb | Settings.settings | \---WPSRasterMathSvc | ExceptionReporter.php | WPSConfig.php | xml.php | \---RasterMathSvc OLog.cpp OLog.h getcurrentstatus.php libgdal.so.1.10.0 makefile rastercalculator rastercalculator.cpp rastermathsvc.php testgrid1.tif
76
testgrid2.tif
