centre for geo-information thesis report girs-2006-02
Post on 17-Jan-2022
1 Views
Preview:
TRANSCRIPT
Centre for Geo-Information Thesis Report GIRS-2006-02
Comparison of Web Mapping Services
Philipp Gaertner
Feb
ruar
y / 2
006
II
“ Comparison of Web Mapping Services ”
Philipp Gaertner
Registration number 77 11 19 250 070
Supervised by:
H.J. Stuiver and A.R. Bergsma
Wageningen University and Research Centre
Laboratory of Geo-Information Science and Remote Sensing
Thesis report number: GIRS-2006-02
Thesis code number: GRS 80424
A thesis submitted in partial fulfillment of the degree of Master of Science at
Wageningen University and Research Centre, The Netherlands.
February, 2006
Wageningen, The Netherlands
Eberswalde, Deutschland
III
Data sharing make sense for the simple reason that there is only one Earth, and we share it.
- (Buehler, 1998)
IV
Table of Contents
ACKNOWLEDGMENT.......................................................................................................................... VI
ABSTRACT .........................................................................................................................................VII
LIST OF FIGURES .............................................................................................................................. VIII
LIST OF TABLE...................................................................................................................................... IX
LIST OF ABBREVIATION......................................................................................................................X
CHAPTER 1. INTRODUCTION.............................................................................................................1
1.1 Research objectives ..................................................................................................................3
1.2 Research question.....................................................................................................................4
1.3 Set-up of the report ..................................................................................................................4
CHAPTER 2. BACKGROUND................................................................................................................5
2.1 Importance of interoperability ................................................................................................5
2.2 Protocols for the Internet.........................................................................................................6
2.3 The OpenGIS Consortium.......................................................................................................9
2.3.1 OGC Web Services .................................................................................................10
2.3.2 Web Map Services specification ............................................................................11
2.3.3 WMS Operations ....................................................................................................12
2.3.3.1 The GetCapabilities request .....................................................................14
2.3.3.2 The GetMap request..................................................................................15
2.3.3.3 The GetFeatureInfo request .....................................................................16
CHAPTER 3. SOFTWARE AND DATA..............................................................................................19
3.1 ArcIMS from ESRI ................................................................................................................19
3.2 Datasets....................................................................................................................................22
CHAPTER 4. METHODOLOGY..........................................................................................................23
4.1 Data Preparation and Processing (Phase 1) .........................................................................25
V
4.2 Determination of Web Mapping Services used in Germany (Phase2) ........................................................................................................................26
4.3 Developing of user service requirements (Phase3) ..............................................................27
4.4 Benchmark Test (Phase 4) .....................................................................................................29
4.4.1 XML validator ........................................................................................................30
CHAPTER 5. RESULTS AND DISCUSSION......................................................................................31
5.1 Intermediate Results ..............................................................................................................31
5.1.1 User service requirements......................................................................................31
5.1.2 Web Mapping Services used in Germany.............................................................32
5.2 Final Results............................................................................................................................34
5.2.1 Benchmark Test ......................................................................................................34
5.2.1.1 Capabilities Response - XML document ................................................................................................................34
5.2.1.2 GetMap Response......................................................................................43
5.2.1.3 GetFeatureInfo Response .........................................................................50
CHAPTER 6. CONCLUSSIONS AND RECOMMENDATIONS......................................................52
CHAPTER 7. REFERENCES................................................................................................................54
CHAPTER 8. APPENDIX .......................................................................................................................A
APPENDIX A - Web GIS Application ........................................................................................A
APPENDIX B - Capabilities.1.0.0.xml (Nationalpark) ..............................................................D
APPENDIX C - Capabilities.1.1.0.xml (Nationalpark) ..............................................................G
APPENDIX D - Capabilities.1.1.1.xml (Nationalpark) .............................................................. L
APPENDIX E - GetMap Requests and Response....................................................................... P
APPENDIX F - Web Application Stress Test Settings...............................................................Y
VI
Acknowledgment
I would like to express my gratitude to my supervisors Frank Torkler, John Stuiver and Aldo Bergsma for
their support and patience during my research and during the period of writing this report.
I would like to pay special thanks to Wolfgang Nueske and his colleagues of the Mueritz national park
department for being very helpful and supportive during the thesis period.
VII
Abstract
Geographical Information Systems are widely used tools for analysing, moddeling and processing of
geodatsets. GIS’s can be used as desktop applications, which refer to either stand alone programs or
networked programs. Because of the limited range, both types have a small amount of users.
The new medium of the World Wide Web provides a big platform to publish GIS maps to a large number
of users. This new application characteristic can be called web GIS. Web GIS allows the user to interact
dynamically with spatial objects and maps. To provide clients with the service of an interoperable web
GIS environment, application providers implemented Web Mapping Services, which are standards created
by the OpenGIS Consortium (OGC). They describe the possibilities how a map server should produce
maps of spatially referenced data to a client.
The OGC published since it origin four versions of Web Mapping Service specifications. The content of
the WMS specifications changed slightly over time. Towards a closer look to the WMS specification the
question arised, which WMS specification will perform best in order to fulfil certain user service
requirements? In order to answer this research question a cooperation with the Mueritz national park in
Germany as a real client was established. During the project ESRI’s ArcIMS program was used as web
GIS to perform a benchmark test. The test used two image services as data input. National park staff
member discussed their user service requirements by means of a requirements checklist which was
modified from the Geographical Information Systems International Group. The image services and the
user requirements were combined with WMS Get operations in order to get capabilites, map images and
feature infos. The comparison of the output files showed that the OGC Web Mapping Service version
1.1.1 is most suitable for a national park web GIS application. Further research should include
interoperability test, which check the performance of several server and services.
VIII
List of Figures
Figure 1 - Potential data layers within a GIS ................................................................................................................. 1
Figure 2 - Location of the national park (source: footnote) ........................................................................................... 2
Figure 3 – Overview map from the Mueritz national park in Mecklenburg Vorpommern (source:footnote)................ 3
Figure 4 - Interoperable Computing system (source: (Homoet, 2003)) ......................................................................... 6
Figure 5 - Two tier Clint/Server scheme with structure of URI (modified from (Peng & Tsou, 2003))........................ 7
Figure 6 - Structure of the OpenGIS Consortium (source: OGC).................................................................................. 9
Figure 7 - OGC Web Service Architecture Diagram (source: (Beaujardiere, 2001)) .................................................. 10
Figure 8 - Dependencies of WMS and Internet standards (source: (Donaubauer, 2004) ............................................. 11
Figure 9 - History of OGC’s WMS specifications ....................................................................................................... 12
Figure 10 - Chronological sequence of WMS operations (UML sequence diagram) (source: (Donaubauer, 2004)) .. 18
Figure 11 - ArcIMS components (source: footnote) .................................................................................................... 20
Figure 12 – Steps taken by Arc IMS to process request and response (source: footnote)............................................ 22
Figure 13 - Methodology to investigate the most suitable WMS for the national park department............................. 24
Figure 14 - ArcIMS WMS Connector Administrator Window with a Warning Message concerning SRS................. 39
Figure 15 - First map image from the map handling requirements .............................................................................. 43
Figure 16 - Second map image from the map handling requirements.......................................................................... 44
Figure 17 - Three partitions of Nationalpark map images ........................................................................................... 46
Figure 18 - Three partitions of NP_Vegetation map images........................................................................................ 46
Figure 19 - Requests under stress condiction per WMS specification ......................................................................... 47
Figure 20 - Response time under stress conditions for 4 different GetMap requests per WMS version...................... 48
Figure 21 - Map image from were GetFeatureInfos are requested............................................................................... 50
Figure 22 - WMS versions and there changes over time.............................................................................................. 52
IX
List of Table
Table 1 - A general OGC Web Service Request (source: ((OGC), 2001)) .................................................................. 13
Table 2 - The parameters of a GetCapabilities request URL (source: ((OGC), 2000; (OGC), 2001; (OGC), 2002;
(OGC), 2004)...................................................................................................................................................... 14
Table 3 - The parameters of a GetMap request URL (source:((OGC), 2000; (OGC), 2001; (OGC), 2002; (OGC),
2004)................................................................................................................................................................... 16
Table 4 - The parameters of a GetFeatureInfo request URL (source:((OGC), 2000; (OGC), 2001; (OGC), 2002;
(OGC), 2004)...................................................................................................................................................... 17
Table 5 - Used Map Services with their Attributes ...................................................................................................... 25
Table 6 - WMS used by surveying administrations of the federal states in Germany ................................................. 32
Table 7 - Web Mapping Applications with Providers, Product name and supported WMS........................................ 33
Table 8 - Difference between WMS version 1.0.0, 1.1.0 and 1.1.1 concerning the quantity of the provided metadata
............................................................................................................................................................................ 41
Table 9 - GetFeatureInfo response in INFO_FORMAT = text/html............................................................................ 51
X
List of Abbreviation
AdV Arbeitsgemeinschaft der Vermessungsverwaltungen
CGI Common Gateway Interface
DCP Distributed Computing Platform
DTD Document Type Definition
ESRI Environmental Systems Research Institute
GDZ Geodatenzentrum
GIF Graphics Interchange Format
GIS Geographical Information System
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IMS Internet Map Server
IP Internet Protocol
ISO International Standards Organization
JPEG Joint Photographic Experts Group
MIME Multipurpose Internet Mail Extensions
OGC OpenGIS Consortium (before Open Geospatial Consortium)
OWS Open GIS Consortium Web Service
PNG Portable Network Graphics
SDI Spatial Data Infrastructure
SRS Spatial Reference Systems
TC Technical Committee
TCP Transmission Control Protocol
UML Unified Modelling Language
URI Uniform Resource Identifiers
URL Uniform Resource Locator
W3C World Wide Web Consortium
WAS Web Application Stress
WMS Web Map Service
WMT Web Mapping Testbed
WWW World Wide Web
XML Extensible Markup Language
XSL Extensible Stylesheet Language
1
Chapter 1. Introduction
A map gives many people an orientation in space. A map can give the answer for questions like “Where
am I?” or “How can I go to …?”(Federal Agency for Cartography and Geodesy, 2005).
To create maps geodatasets are needed. Geodata describe our environment in objects and their spatial
reference to certain points, areas or regions (Burrough, 1998; Heywood, 2002; Sickel, 2004). Geodata can
be stored in geodatabases and visualized as maps (layers) in Geographical Information Systems (GIS) as
shown in figure 1. GIS’s are widely used tools
which support decision making in monitoring,
planning or the assessment processes.
In fact around 80 percent of all decisions in
public and private live (Federal Agency for
Cartography and Geodesy, 2005) and circa 90
percent of all information’s used by
governments are based on geo-related
characteristics (Crompvoets, 2004).
Figure 1 - Potential data layers within a GIS
(source: (Federal Agency for Cartography and Geodesy, 2005))
Many operator use GIS as desktop application. “Desktop GIS refers to either stand-alone programs with
no information exchange between computers or networked programs in which desktop GIS program share
data, applications and other resources within Local-Area Networks “(Peng & Tsou, 2003). Disadvantages
of desktop GIS are costly GIS programs (Mathiyalagan et al., 2005)and the installation on every desktop
computer. That means users have to access desktop GIS in order to be able to use it, this greatly limits the
number of users (Peng & Tsou, 2003).
The new medium Internet offers many people the possibility to access information from all over the
world. It also gives a big platform to publish GIS maps to a large number of users. This new application
characteristic can be called Internet GIS. Nevertheless, “like many other new fields, there is no general
agreement on the term to describe GIS programs based on the Internet”(Peng & Tsou, 2003). Different
2
names are used, such as Internet GIS, GIS online, Web GIS or simply web mapping1 (Peng & Tsou, 2003;
Mathiyalagan et al., 2005). The terms are similar but have a different meaning. “Internet GIS refers to the
use of the internet as a means to exchange data, perform GIS analysis, and present results, whereas Web
GIS refers to the use of the word wide web (WWW)” (Mathiyalagan et al., 2005). The WWW is a
networking application that runs on top of the Internet, which means the Internet is the infrastructure and
contains lots of applications including the WWW (Peng & Tsou, 2003). Both Web GIS and Internet GIS
utilize the client/server computing model, viz the client is asking (requesting) for a certain information and
the server is answering (responding) the request back to the client.
Web GIS can be seen as dynamic web mapping. The user interacts (zooming, panning, scrolling, measure
distances) with the spatial object and maps directly by means of extra functions on the client side.
Generally each Web GIS provider has its own way to create web maps. To provide clients with the service
of an interoperable web mapping environment, commonly accepted standards and guidelines had to be
established. This mission was realized by the OpenGIS Consortium (OGC). The OGC defined Web
Mapping Service (WMS) specifications, which describe the possibilities how a map server should produce
maps of spatially referenced data to a client (Kolodziej, 2003). Because of the WMS specifications it is
possible to combine maps from different data sources or rather map server. This multi server environment
is based on an interoperable data infrastructure. Several projects examined the interoperable access from
geodata, coming from distributed sources, in order to receive corrects maps (Teege & Seuss, 2003;
Donaubauer, 2004). Other projects tested the performance of different Web Map Server packages on the
basis of their capabilities (Forrest et al., 2000; Prastacos, 2000).
The OGC published since it origin four versions of Web Mapping Service specifications. The content of
the WMS specifications changed slightly over time because of technology developments and software
improvements. Towards a closer look to the WMS specification the
question arised, which WMS specification will perform best in order to
fulfil certain user service requirements? In order to be able to answer the
question, this research project was established. During the project a
cooperation was founded with the Mueritz national park department as a
real client and its staff members as users with certain requirements.
Figure 2 shows the location of the national park which is approximately
100 km north-west of the German capital. The study area contains the
whole national park area which is recorded with 322 km².
Figure 2 - Location of the national park (source: footnote2)
1 Wikipedia: GISwiki (last access 11.02.2006) 2 http://www.germany-tourism.de/media/map_mueritz_e.gif (last access 18.02.2006)
3
It contains more than 100 lakes, whereas the lake “Mueritz”, shown in figure 3, is with 117 km² the
biggest and most interesting. Furthermore, worth to mention are the large pine forests and swamps in the
east of the “Mueritz”, as well as the old beech forests in the hilly area around Serrahn (Landesamt fuer
Forsten und Grossschutzgebiete Mecklenburg-Vorpommern, unknown). Besides the comparison of the
Web Mapping Service specifications as the main goal, was a web GIS prototype for the Mueritz national
park constructed.
Figure 3 – Overview map from the Mueritz national park in Mecklenburg Vorpommern (source:footnote3)
1.1 Research objectives
The aim of the study is to investigate the performance differences of the current Web Mapping Service
Specifications:
• Web Mapping Service 1.0.0
• Web Mapping Service 1.1.0
• Web Mapping Service 1.1.1
• Web Mapping Service 1.3.0
To accomplish this general objective, map services will be created and user service requirements will be
defined. Within a benchmark test environment three different Web Map Service operations are
investigated (GetCapabilities, GetMap GetFeatureInfo). Finally the best performed Web Mapping Service
specification will be used to create a Web GIS application for the Mueritz national park.
3 http://www.nationalpark-mueritz.de/images/faltblatt.ru.gif (last access 18.02.2006)
4
In order to reach the aim of the study the following research objectives are defined:
1. Making the available spatial information of the Mueritz national park transparent to the
public.
2. Assess main mapping services used in Germany.
3. Determine and test requirements of an appropriate web mapping service for the national park
from a public user’s viewpoint.
4. Giving an outlook how to maintain the up-to-date ness of the information (datasets).
1.2 Research question
The investigation of the following research question is based on the four main objectives:
• Which Web Mapping Service specification is most suitable, to fulfil the requirements of public
users, for the implementation of the Web GIS application located at the Mueritz national park
department?
1.3 Set-up of the report
This document is divided into 6 chapters. The first chapter deals with a general introduction and the
presentation of the project its objectives, research questions and end with this section. Chapter two gives
information about the importance of interoperability, the main internet protocols and finally a short
description of the Open GIS Consortium and a detailed description of the Web Mapping Service
specifications. Chapter three gives information about the used Software and datasets. Chapter four
explains our used methodology in general and each particular phase specifically. Results and discussions
are combined in chapter five. And finally, chapter six summarizes conclusions and recommendations for
the presented project. Part of the appendix contains the description of the final web GIS application, with
its structure and setups.
5
Chapter 2. Background
This chapter will give a general description about the importance of interoperability between Information
Systems. Roughly are main standardization organizations and their suites of protocols for accessing
resources and exchanging data in the Internet environment mentioned. The last part covers the role and
structure of the OGC as leading organization in the scope of open standards for spatial data distribution.
Within the network of OGC web services are the Web Mapping Service specifications and their contained
operations explained more deeply.
2.1 Importance of interoperability
‘Interoperability’ or ‘being interoperable’, these words are increasingly used within social, political and
organizational perspective across the world. The Oxford Dictionary4 describes ‘interoperable’ as:
• adjective (of computer systems or software) able to operate in conjunction.
With respect to Information Systems, the term interoperability is used to describe the capability of
different types of computers, networks, operating systems, and applications to work together effectively,
without prior communication, in order to exchange information in a useful and meaningful manner, to
read and write the same file formats and use the same protocols5,6.
In a non interoperable system is it necessary to convert data formats to be able to transfer them from one
system to another one. During the conversion process inaccuracies could arise or coherences disappear
(Homoet, 2003). Missing interoperability strongly implies that the above mentioned system was not
planned with standardization in mind7.
4 http://www.askoxford.com/results/interoperable (last access 07.02.2006) 5 http://en.wikipedia.org/wiki/Interoperable (last access 07.02.2006) 6 http://www.ariadne.ac.uk/issue24/interoperability/intro.html (last access 02.02.2006) 7 See footnote 5
6
In contrast an interoperable system, shown in figure 4, has direct access to one another. There is no need
to convert datasets to be able to exchange them. Another important advantage is, the system requesting the
data doesn’t need to know the internal data organisation of the responding system (Homoet, 2003).
Figure 4 - Interoperable Computing system (source: (Homoet, 2003))
Datasets are provided by standardized interfaces and remain at the data owner. An interoperable interface
brings a big advantage, because the user can constantly access the most up to date data files, as they are
retrieved straight from the data holder. If software products are not interoperable, because of patents, trade
secrets or miscoordination8, the results are doomed to failure.
Several organisations deal with creation of interoperability standards like the Location Interoperability
Forum9 or the Web Services Interoperability Organization10.
2.2 Protocols for the Internet
There are two main organizations with the focus to improve the performance and the potentials of the
web. One of them is the Internet Engineering Task Force (IETF) which develops and promotes web
standards, in particular those of the Internet Protocol Suite. The Internet Protocol Suite is a set of
communication protocols that implement the protocol stack11 on which the internet is based on (Peng,
2003). The two most important protocols inside are the Transmission Control Protocol (TCP) and the
8 See footnote 5 9 http://www.openmobilealliance.org/tech/affiliates/lif/lifindex.html (last access 07.02.2006) 10 http://www.ws-i.org/ (last access 07.02.2006) 11 “A protocol stack is a combination of multiple protocols that work together enabling communication on a network.” (source:
Peng & Tsou, 2003)
7
Internet Protocol (IP), that’s why it is sometimes called the TCP/IP protocol suite12. One of the most
important characteristics of the TCP/IP is its support “of interoperability among many different types of
computers in the network environment” (Peng & Tsou, 2003). TCP provides the mechanism for
transferring information packages across networks and the IP is the mailing address system for the Internet
machines. On top of the protocol stack is the HyperText Transfer Protocol (HTTP) which is a request /
response protocol between clients and servers. The resources to be addressed by HTTP are identified by
means of Uniform Resource Identifiers (URI) (Peng & Tsou, 2003). “The URI provides a global naming
scheme to identify the names and locations of resources on the web. A characteristic URI is made up of
four parts: the protocol scheme, the server name or domain name, the port number, and the location of
target resources. A general overview of the protocol stack components gives figure 5, modified from Peng
& Tsou, 2003.
Figure 5 - Two tier Clint/Server scheme with structure of URI (modified from (Peng & Tsou, 2003))
The second important organization is the World Wide Web Consortium (W3C), which is an international
consortium with the main focus to develop web standards and guidelines. Since 1994, W3C has published
more than ninety such standards, called W3C recommendations13. One important and wide spread
standard, which is maintained by the W3C, is the HyperText Markup Language (HTML). This markup
language was originally defined by Tim Berners-Lee and further developed by IETF14. HTML is the
lingua franca for publishing web pages with hypertext on the WWW.
Another fundamental standard is the Extensible Markup Language (XML), which is a simple, very
flexible text format derived from the Standard Generalized Markup Language (SGML) (Donaubauer,
2004). Originally designed to meet the challenges of large-scale electronic publishing, its primary purpose
12 http://en.wikipedia.org/wiki/Internet_protocol_suite (last access 02.02.2006) 13 http://www.w3.org/ (last access at 01.02.2006) 14 http://en.wikipedia.org/wiki/HTML (last access at 02.02.2006)
8
now is to facilitate the exchanging and sharing of data across systems connected via the internet. A XML
document can be considered as correct, if it is well formed and valid15. A well formed document conforms
to all XML’s syntax rules. A valid document has data that conforms to content rules or XML schemas.
The oldest schema format for XML is the Document Type Definition (DTD). DTD defines a grammar and
a logical structure to the xml document. If a certain xml document is associated to a DTD, it is possible to
validate it. Validation means to check if the structure and grammar is legal (Donaubauer, 2004).
Next to the W3C and IETF are other organizations busy with the creation of specifications, guidelines and
standards. Further information can be found under International Organization for Standardization16,
American National Standards Institute17 and European Committee for Standardization18.
15 http://en.wikipedia.org/wiki/XML#Correctness_in_an_XML_document (last access at 02.02.2006) 16 http://www.iso.org/iso/en/ISOOnline.frontpage (last access at 02.02.2006) 17 http://ansi.org/ (last access 13.01.2006) 18 http://www.cenorm.be/cenorm/index.htm (last access 18.02.2006)
9
2.3 The OpenGIS Consortium
“The OpenGIS Consortium, Inc. (OGC) is a non-profit, international, voluntary consensus standards
organization that is leading the development of standards for geospatial and location based services” 19.
The OGC’s mission is “to lead the global development, promotion and harmonization of open standards
and architectures that enables the integration of geospatial data and services into user applications and
advance the formation of related market opportunities”20. The term OPENGIS® is a registered trademark
and stands for specifications and documents published from the OGC(Homoet, 2003). The specifications
define a comprehensive software framework for distributed access to geodata and geoprocessing resources
(Peng & Tsou, 2003). The OGC is based on three branches shown in figure 6.
Figure 6 - Structure of the OpenGIS Consortium (source: OGC21)
The design of the specifications is based on a member driven consensus process (Reed, 2005). The
development itself takes place in the Special Interest Groups and Working Groups, which merges to the
Specification Program. During the process works the OGC as a connector between the geoinformatics
19 http://www.opengeospatial.org/ (last access at 12.01.2006) 20 http://www.opengeospatial.org/about/?page=vision (last access at 12.01.2006) 21 http://www.opengeospatial.org/about/?page=programs (last access at 12.01.2006)
10
specific norms from the ISO / TC 211 committee and the standards of the general informatics developed
by the W3C (Donaubauer, 2004).
Another branch of the OGC is the Interoperability Program. The goal of this program is to check
prototypes and scenarios in test beds and pilot projects22. The results of the Interoperability Program can
help to improve the design and development within the Specification Program.
2.3.1 OGC Web Services
The OGC Web Service (OWS) suite includes three principal types of georeferenced information access
services (Kolodziej, 2003):
• the Web Map Service (WMS),
• the Web Coverage Service (WCS) and
• the Web Feature Service (WFS).
Figure 7 is an architecture diagram showing conceptually how OWS components are related, and naming
some (not all) of the interfaces between them (Beaujardiere, 2001). The standards are independent of each
other and a free combination of the individual components can multiply the possibilities of their use
(Homoet, 2003). The following chapters focus on Web Map Services and their operations.
Figure 7 - OGC Web Service Architecture Diagram (source: (Beaujardiere, 2001))
22 http://www.opengeospatial.org/about/?page=ip (last access at 12.01.2006)
11
2.3.2 Web Map Services specification
The Web Map Service standard specifies the behaviour of a service that produces georeferenced maps. In
this context is “map” defined as a visual representation of geodata and not the data itself ((OGC), 2002). It
standardizes the way in which maps are requested (Peng & Tsou, 2003) and how server describe their data
holdings ((OGC), 2002). Figure 8 from Donaubauer shows the dependencies between the WMS
specification and the above described protocols for the Internet (Donaubauer, 2004).
Figure 8 - Dependencies of WMS and Internet standards (source: (Donaubauer, 2004)
The evolutionary history of OGC’s web mapping activities is illustrated in figure 9. It started with the
“WWW Mapping Framework” by Doyle23 in 1997 (Peng & Tsou, 2003). Based on this idea, the OGC
build up an initiative, known as the Web Mapping Testbed (WMT) - phase 1 ((OGC), 2000), here GIS
software vendors as well as governmental agencies got the possibility to design pilot web mapping
systems to test-implement the ideas in the WWW mapping framework (Peng & Tsou, 2003). The WMT -
phase 1 process culminated in the OpenGIS WMS interface implementation specification version 1.0.0,
hereinafter "WMS 1.0.0." ((OGC), 2001).
Phase 2 of the WMT was made to rapidly develop interface specifications. That led “to Standards-based
Commercial-Off-The-Shelf implementations of software that support use and exploitation of geospatial
data and images over the WWW” (Peng & Tsou, 2003). WMS 1.1.0 is a result of WMT - phase 2. The
WMS 1.1.1 and WMS 1.3.0 are rectified versions of WMS 1.1.0.
23 Doyle, A. (1997) WWW Mapping Framework. Open GIS Project Document 97-007. OpenGIS Consortium
12
Figure 9 - History of OGC’s WMS specifications
2.3.3 WMS Operations
One purpose of all WMS specifications is to standardize three main operations ((OGC), 2000; (OGC),
2001; (OGC), 2002; Kolodziej, 2003; (OGC), 2004) or moreover to define a syntax for the WWW Unified
Resource Locator (URL) that invokes (request) each of these operations, known as:
• GetCapabilities (returns service metadata, which is a description of the service information
content and acceptable request parameters);
• GetMap (returns a map image whose geospatial and dimensional parameters are well defined);
• GetFeatureInfo (returns information about particular features shown on the map) ((OGC), 2002).
A Web Map Server should be able to react on these requests with:
• Producing a map (as picture, as a series of graphical elements, or as a packaged set of geographic
feature data),
• Answering basic queries about the content of the map, and
• Telling other programs what maps it can produce and which of those can be queried further
(Kolodziej, 2003).
13
A WMS client (e.g. a standard web browser) can ask a WMS compliant server to respond just by
submitting requests in the form of URL24 (as mentioned above). The request (message transmission), is
done by the HTTP GET method. Other optional operations like GetStyles and PutStyles can be called by
the HTTP POST method (Donaubauer, 2004). As seen in the table 1 summary, the URL prefix includes
the host, port, path and a question mark ‘?’, plus optional server specific query parameters (name/value
pairs) ending in an ampersand ‘&’.
Table 1 - A general OGC Web Service Request (source: ((OGC), 2001))
The order of the individual query parameter isn’t relevant (Kolodziej, 2003)). Finally “the resulting URL
must be valid according to the HTTP Common Gateway Interface25 (CGI) standard, which mandates the
presence of ‘?’ before the sequence of query parameters and the ‘&’ between each parameter” ((OGC),
2001). An incorrect request to the Map Server must give an exception from the server ((OGC), 2001).
All WMS versions are able to handle the GetCapabilities, GetMap, GetFeatureInfo request. Due to the
development and expansion of the specifications version the request commands and response differ
slightly. All changes on a specification to the previous versions are listed in the new specification under
“Version Changes” ((OGC), 2001; (OGC), 2002; (OGC), 2004). The following chapter will describe the
GetCapabilities, GetMap and GetFeatureInfo more precisely and will call more attention to main changes
between the WMS specification versions.
24 “A Uniform Resource Locator (URL) or web address, is a sequence of characters, conforming to a standardized format, that is
used for referring to resources, such as documents and images on the internet, by their location.” (source:
http://en.wikipedia.org/wiki/Url (last access 18.02.2006)) 25 “The Common Gateway Interface (CGI) is an important World Wide Web technology that enables a client web browser to
request data from a program executed on the Web server. CGI specifies a standard for passing request data between a web server
and the program used to service that request.” (source: http://en.wikipedia.org/wiki/Common_Gateway_Interface(last access
18.02.2006)
14
2.3.3.1 The GetCapabilities request
The principle of the GetCapabilities procedure is to get service metadata, which is a machine-readable
report of the map server’s information content and tolerable request parameter values ((OGC), 2004).
Capabilities request
In order to find out what layer a WMS server supplies or what data format it supports, a WMS client
makes a “Capabilities request”. The example shows a request to a WMS in the version 1.1.0:
http://server_adress/path/script?REQUEST=GETCapabilities&VERSION=1.1.0&SERVICE
=WMS&
The table 2 gives all required parameter and some optional parameters which could be used for a
GetCapabilities request.
Table 2 - The parameters of a GetCapabilities request URL (source: ((OGC), 2000; (OGC), 2001; (OGC),
2002; (OGC), 2004)
Version parameter name and value Required /Optional Description
1.0.0 WMTVER = 1.0.0 R Request version
REQUEST = capabilities R Request name
Vendor-specific parameters O
1.1.0 VERSION = 1.1.026 O Request version
SERVICE = WMS27 R Service type
REQUEST = GetCapabilities28 R Request name
UPDATESEQUENCE = number O Sequence number for cache control
1.1.1 VERSION = 1.1.1 O Request version
SERVICE = WMS R Service type
REQUEST = GetCapabilities R Request name
UPDATESEQUENCE = string O Sequence number or string for cache control
1.3.0 VERSION = 1.3.0 O Request version
SERVICE = WMS R Service type
REQUEST = GetCapabilities R Request name
FORMAT = MIME_type O Output format of service metadata
UPDATESEQUENCE = string O Sequence number or string for cache control
26 Several request parameters have been modified or added. The "VERSION" parameter was previously "WMTVER". 27 The "SERVICE" parameter did not exist in version 1.0.0! 28 The "GetCapabilities" request type was previously "capabilities"
15
Capabilities response
The response to a GetCapabilities request is an xml document for each WMS version. Each xml file must
be valid according to the xml DTD29 which is described in each version in Annex A. The DTD specifies
the required and optional content of the response and how the content is “formatted” ((OGC), 2001). The
purpose of the GetCapabilities operation is to obtain service metadata, which is a machine-readable
description of the server’s information content and acceptable request parameter values ((OGC), 2004).
2.3.3.2 The GetMap request
The GetMap process is designed to create a map, which is defined to be either a pictorial image or a set of
graphical elements ((OGC), 2001). The GetMap request allows the WMS client to indicate distinct layers,
the geographic area, the spatial reference system, the desired output format etc. (Kolodziej, 2003).
The example shows a request to WMS version 1.1.0:
• http://www.Airesip.org/wms/process/cgi?REQUEST=GetMap&FORMAT=image/gif
&WIDTH=640&HEIGHT=480&LAYERS=temperature&SRS=EPSG:4326&BBOX=-
110.,40.,-80.,30.&&VERSION=1.1.0
The table 3 gives all required parameter and some optional parameters which have to be or can be used for
a GetMap request. The differences between 1.0.0 and the other 3 specifications are only in the description
of the request version and the request name.
29 For further information is http://www.w3.org/TR/REC-xml/ and http://www.digitalearth.gov/wmt/xml/ recommended (last
access at 13.01.2006)
16
Table 3 - The parameters of a GetMap request URL (source:((OGC), 2000; (OGC), 2001; (OGC),
2002; (OGC), 2004)
Version parameter name and value Required /Optional Description
1.0.0 WMTVER = 1.0.0 R Request version
REQUEST = map R Request name
LAYERS = layer_list R list of one or more map layers
STYLES = style_list R list of one rendering style per requested layer
SRS = srs_indentifier R Spatial Reference System
BBOX = xmin,ymin,xmax,ymax R Bounding box corners in SRS units
WIDTH = output_width R Width in pixels of map picture
HEIGTH = output_height R Height in pixels of map picture
FORMAT = output_format R Output format of map
TRANSPARENT = true_or_false O If TRUE then the background color will be Transparent,
BGCOLOR = color_value O A hexadecimal red-green-blue color value for the background
EXCEPTIONS = exceptions_format O Format in which exceptions are reported by the map server
Vendor-specific parameters
1.1.0./ VERSION = version R Request version
1.1.1/ REQUEST = GetMap R Request name
1.3.0 : : :
: : :
Map response
The output of a GetMap request is a single map whose type corresponds to the FORMAT parameter in the
request. In case of the example the HTTP request included an image/gif format of 640x480 pixels. The
returned object must be a GIF image with a MIME30 type of image/gif, with an extend of 640 times 480
pixel.
2.3.3.3 The GetFeatureInfo request
The optional GetFeatureInfo operation is only supported for those layers which are defined as queryable =
“1” (true) ((OGC), 2000). The GetFeatureInfo operation was made to provide clients with more
information about points in map images (picture case) that were returned by previous map requests
((OGC), 2001). That’s why the request has to include most of the previous (original) GetMap request
parameters like STYLES, BBOX, SRS, WIDTH and HEIGHT. The additional information is only for a
specific point, defined by X and Y positions (map coordinates) from the original map image.
30 MIME (Multipurpose Internet Mail Extensions) is a description scheme for documenttyps. For example is raster image with the
GIF format described as image/gif, a text in html format as text/html (source: Donaubauer, 2004)
17
The example shows a GetFeatureInfo request with WMS version 1.1.0:
• http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Fe
ature_Info&STYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WI
DTH=900&HEIGHT=600&INFO_FORMAT=text/xml&SERVICENAME=Nationalpark&
QUERY_LAYERS=2&X=86&Y=268
The table 4 gives all required / optional parameters for the GetFeatureInfo request. Differences between
1.0.0 and the other 3 specifications are the description of the request version and the request name.
Furthermore is in the WMS 1.3 the INFO_FORMAT required.
Table 4 - The parameters of a GetFeatureInfo request URL (source:((OGC), 2000; (OGC), 2001; (OGC),
2002; (OGC), 2004).
Version parameter name and value Required /Optional Description
1.0.0 WMTVER = 1.0.0 R Request version
REQUEST = feature_info R Request name
<map request copy> R Copy of the map request parameters that generated the map for
which information is desired
QUERY_LAYERS = layer_list R list of one or more layers to be queried
INFO_FORMAT = output_format O return format of feature information
FEATURE_COUNT = number O how many features to return information
X = pixel_column R X coordinates in pixels of feature (from upper left corner)
Y = pixel_row R Y coordinates in pixels of feature (from upper left corner)
Vendor-specific parameters O
1.1.0./ VERSION = version R Request version
1.1.1/ REQUEST = GetFeatureInfo R Request name
EXCEPTIONS = exceptions_format O Format in which exceptions are reported by the WMS
: : :
1.3.0 INFO_FORMAT = output_format R return format of feature information (MIME type)
: : :
18
FeatureInfo response
The response format for WMS 1.0.0 can only be in MIME type or in GML format. Whereas in the newer
versions WMS 1.1.0, 1.1.1 and 1.3.0 is the GML format part of the MIME types ((OGC), 2000; (OGC),
2002). These are listed in the <Format> elements in side the <Request><FeatureInfo> element of its
Capabilities xml ((OGC), 2001; (OGC), 2002).
The whole chronological sequence for the WMS operations is shown in figure 10:
Figure 10 - Chronological sequence of WMS operations (UML sequence diagram) (source: (Donaubauer,
2004))
19
Chapter 3. Software and Data
The implementation of the testbed for a WMS was done by means of the Internet Map Server (ArcIMS)
from the software vendor “Environmental Systems Research Institute” (ESRI). The choice for ArcIMS
was based on the implementation of the WMS specifications (1.0.0, 1.1.0 and 1.1.1), an uncomplicated
handling of the software and its components as well on the sufficient help function in case of
troubleshooting. The following chapter will focus on the architecture, major components and
communication mechanism of ArcIMS. Finally the used datasets provided by the national park department
are described.
3.1 ArcIMS from ESRI
ArcIMS from ESRI is a web mapping package, with “the functionality to distribute maps, data and
metadata via the world wide web” (Environmental Systems Research Institute (ESRI), 2004 a). To
establish a running ArcIMS site, supporting components are needed which include a web server, a Java
virtual machine and a servlet engine. The web server executes requests and responses from and to the
client. Whereas the Java virtual machine provides a basic application programming interface, which is
needed because many of the ArcIMS components are Java based. The servlet engine plugs into the web
server and supplies the connection between the Java virual machine and the web server (Environmental
Systems Research Institute (ESRI), 2004 a).
ArcIMS has its own mapping engine (Peng & Tsou, 2003) and is structured in multi-tier architecture
consisting of presentation tier, business logic tier and data tier (East et al., 2001). A usual partition of this
multi-tier architecture is, that the presentation tier is placed at the client site with a web browser and the
business logic and data storage tiers are found at the server side as shown in figure 11 (Peng & Tsou,
2003).
The presentation tier includes ArcIMS client viewers for accessing, viewing and analyzing spatial data. It
consists of:
• preprepared standard viewers (HTML viewer, Java viewer),
• modifiable costumer viewers (Active X viewer, Cold Fusion viewer) and a
• non-web standard viewer (ArcExplorer).
20
Figure 11 - ArcIMS components (source: footnote31)
The business logic tier handles user requests from the client viewers, produces maps and manages the site.
The components include:
• ArcIMS application server connectors,
• ArcIMS application server,
• Tasker and Monitor
• ArcIMS spatial server.
The external web server handles the request from the client using HTTP, forwards it to the application
server and sends a response back to the client. But the web server cannot directly communicate with the
application server, because the web server forwards requests in HTML and the ArcIMS application server
expects incoming requests in ArcXML32. They need an application server connector, which provides a
communication channel. ArcIMS supplies several connection possibilities, whereas this project used the
WMS Connector. The connector translates OGC-standard WMS requests into ArcXML format before
forwarding it to the application server and translates the ArcIMS spatial server response back into HTML
before returning it back to the web server (Environmental Systems Research Institute (ESRI), 2004 b;
Environmental Systems Research Institute (ESRI), 2004 c).
The purpose of the application server is to handle the load distribution of incoming requests
(Environmental Systems Research Institute (ESRI), 2004 a). It catalogs which map service is running on
31 http://map.sdsu.edu/geo596/lecture/week8.htm (last access 11.02.2006) 32 ArcXML is the ArcIMS version of xml and is used to create map service configuration files (Peng & Tsou, 2003). For more
information on ArcXML and map configuration files, see the ArcXML Programmers Reference Guide available at
http://support.esri.com. (last access 11.02.2006)
21
which ArcIMS spatial server and allocates an incoming request the appropriate spatial server (Peng &
Tsou, 2003).
Additionally has the business logic tier a Tasker and Monitor. The Tasker deletes the images generated by
Image Server after a predefined time interval, to make sure that the web site does not run out of disk space
(East et al., 2001). The Monitor starts Spatial Servers and makes checks that Spatial Servers are always
running.
The last part of the business logic tier is the spatial server. The spatial server can produce maps and
bundles these maps into the appropriate format based on the user requests (Environmental Systems
Research Institute (ESRI), 2004 a). The spatial sever supports several functionalities by means of special
components. Each component makes up an own server, shown is figure 11. The Query Server, Geocode
Server and Extract Server have a private status (without interface) and will be managed automatically by
the spatial server when needed. The Image, Feature, Metadata and ArcMap Server have a public status and
can be accessed through the ArcIMS interface.
Each of the component severs is assigned to one or more instances. A spatial server instance is a thread
that can handle one user request at a time. On spatial server instances are map services running. A map
service is a set of spatial data that provides instructions to the spatial server on how to draw a map when a
request is received (Peng & Tsou, 2003). Each public component server has its own service – ArcIMS
Image Service, Feature Service, Metadata Service, ArcMap Image Service.
It is possible to have more spatial servers running on one or multiple machines. That means a mechanism
is needed to manage these spatial servers and their services. Therefore ESRI created virtual server. The
concept of a virtual server is that it groups one or more spatial server instances. If an ArcIMS spatial
server goes down, incoming requests can still be handled by the other spatial servers assigned to the same
virtual server.
The data tier consists of data sources available for use with ArcIMS. The data access manager provides a
link between the spatial server and data source.
In addition, ArcIMS provides management tools within the business logic tier. The ArcIMS Manager
gives access for authoring maps, administering ArcIMS services and designing web sites.
One whole request cycle is presented in the homepage of the GIS Center Kings County33 and shown in
figure 12. The client sends a request to an ArcIMS side (1), the web server receives the request and passes
it to the connector (2). The connector opens a path for the application server and hand the request through
(3). The application server sends the request to an available spatial server within a virtual server group (4).
33 http://www.metrokc.gov/gis/kb/Content/ArcIMS.htm (last access 19.02.2006)
22
The spatial server generates the response (5) and returns the response in the reverse order of the initial
request (6).
Figure 12 – Steps taken by Arc IMS to process request and response (source: footnote34)
3.2 Datasets
The datasets which were used for the analysis and implementation of the web GIS application are owned
by the national park department. All shapefiles were with an undefined (unknown) coordinates system and
projection. Theses datasets were in form of:
- Raster - topographical map 1:10.000 (TIFF),
- Shapefiles - vegetation map,
- tourist information (camping grounds, swimming areas, hiking trails, biking routes
and animal viewing platforms),
- infrastructure information (road network, parking areas, railway stations and railway
lines),
- national park borders (protection zones),
- land use information (urban areas, lakes).
34 http://www.metrokc.gov/gis/kb/Content/ArcIMS.htm (last access 19.02.2006)
23
Chapter 4. Methodology
The general methodology, shown in figure 13, is divided into four phases:
1. data preparation and processing
2. determination of Web Mapping Services used in Germany
3. development of user service requirements and
4. benchmark testing.
Within the data preparation and processing phase, all necessary input data were defined and prepared. The
phase to determine which WMS will be used needs collaboration with surveying administrations and to
search within existing web GIS applications. The phase to develop user service requirements is realised by
working groups, consisting of national park staff members. The project’s main focus is at the benchmark
testing phase. The benchmark testing phase involves map services coming from the data preparation, three
OGC Web Mapping Services specifications and user service requirements. Three request blocks are
executed in this phase: GetCapabilities, GetMap and GetFeatureInfo. The final comparison of all output
files coming from the Get operations, will allow a conclusion of the most suitable WMS specification
version according to the user requirements. This WMS version is used for the implementation of the web
GIS application for the Mueritz national park.
The web GIS application for the Mueritz national park is a spin-off product of this thesis work. Its
construction phase, content and maintenance explanations are excluded from the main methodology and
will be explained in the ‘Web GIS Application’ part within the Appendix.
24
Figure 13 - Methodology to investigate the most suitable WMS for the national park department
WMS used in Germany : WMS 1.0.0 (1) WMS 1.1.0 (2) WMS 1.1.1 (3)
2. Determination of Web Mapping Services used in Germany
Arc IMS Image Service
Arc Map Image Service
Get Map (1), (2), (3)
Get FeatureInfo (1), (2), (3)
Get Capability (1), (2), (3)
Xml Validator
ArcXML map configuration file
.mxd file
Creating (layout) file in Arc IMS Author
Creating (layout) file
in Arc Map
Creating Services in ArcIMS Administrator
National park data: .shp file
Request to surveying
administrations responsible for Deutschland
Viewer
Deutschl and Viewer
other web mapping
applications
Investigation of existing
web mapping applications
BEST- GIS – Consortium Requirement Checklist for
GIS
Modification to User Service Requirement
Checklist for Web GIS
User service Requirement
Checklist Web GIS
National park working group: Discussion on user service
requirements by means of checklist
User Service requirements
Get operation (request) (1), (2), (3)
Xml files Xml fi les Map images
Comparison of (1), (2), (3)
Most suitable WMS
Input data
Action
Intermediate results
Final results
1. Data Preparation and Processing
4. Benchmark Test
3. Developing of user service requirements
web mapping
application
25
4.1 Data Preparation and Processing (Phase 1)
To realize a benchmark test, map services are needed. A map
service is a set of spatial data and is described more specific in
the software chapter. Four types of map services exist:
1. ArcIMS image service,
2. ArcMap image service,
3. Feature service,
4. Metadata service.
In this case study, the first two types of map services are used:
“The ArcIMS image service uses the image server component of
the spatial server to generate a map image (JPEG, PNG, and
GIF)” (Peng & Tsou, 2003). The input to the ArcIMS image
service is an ArcXML map configuration file. The map
configuration file was created from shapefiles using the ArcIMS
Author.
The ArcMap image service is comparable to an ArcIMS image service. It generates also a map image and
sends it back to the client in a graphic format. The “difference is that the ArcMap image service uses the
ArcMap server while the ArcIMS image service uses the image server” (Peng & Tsou, 2003). The input to
the ArcIMS image service is an .mxd document from ArcMap. Both image services were created and
started within the administrator of ArcIMS. Table 5 shows the tested image services and their layer
configuration.
Table 5 - Used Map Services with their Attributes
Image service Name Created with Layers
ArcIMS image service Nationalpark ArcIMS author,
ArcIMS
Administrator
3 polygon
7 line
2 point
ArcMap image service NP_Vegetation ArcMap,
ArcIMS
Administrator
1 polygon
1 line
26
4.2 Determination of Web Mapping Services used in Germany
(Phase2)
The main WMS used in Germany are studied to determine
which WMS options exist. Firstly, WMS’s are obtained by
requests to surveying administrations of the states. Hereafter,
investigating these WMS’s is done by means of internet
literature studies.
Request to surveying administrations of the states
In the Federal Republic of Germany, all surveying and
cadastrall administrations of the states are combined into a
consortium called „Arbeitsgemeinschaft der
Vermessungsverwaltungen35 (AdV). This working committee
developed two viewers in a pilot project: the “Deutschland
Viewer36“ and the “Deutschland Viewer – Bayern37” (Working
Committee of the Surveying Authorities, 2005). Both Viewer
access the original datasets of the surveying administrations by
means of standardized WMS interfaces. To know which versions of the WMS the different state surveying
administrations support, email correspondence with all contact persons of the participating administrations
is made. The contact persons are known at AdV (Working Committee of the Surveying Authorities, 2005)
and in the “Deutschland Viewer-Bayern”.
Investigation of existing web mapping applications
By means of internet literature studies existing web mapping applications are investigated. Due to the
amount of existing applications is the list of the reviewed applications by far not complete. If the WMS
version is not mentioned in the literature or application itself, the administrator or contact person is
consulted by means of email to clarify the version.
35 In English “Working Committee of the Surveying Authorities“http://www.adv-online.de/extdeu/index.jsp (last access
11.02.2006) 36 http://www.geodatenzentrum.de/geodaten/gdz_rahmen (last access 11.02.2006) 37 http://deutschlandviewer.bayern.de/deutschlandviewer/GermanyViewer.html (last access 11.02.2006)
27
4.3 Developing of user service requirements (Phase3)
To determine the service requirements from a public user’s
viewpoint means to identify different application users and take into
account each user viewpoint on the functions of the services
available. One alternative way is to organize a working group, where
all members are aware of the application’s common interest and
objectives (Geographical Information Systems International Group,
unknown)38. This working group was set up by staff members of the
national park department. They organised meetings to discuss the
requirement checklist point by point. The outcome of this work is
automatically the final requirements specification document. The
checklist, developed by (Ravden & Johnson, 1989), is chosen as a
appropriate method to gather the opinions of GIS end-users
(Geographical Information Systems International Group, unknown).
The checklist for the GIS domain was adapted to Web GIS services
and contains the following parts:
Map handling requirements
Main aspects are correct retrieving and organising output maps itself. The maps are retrieved from one
map server, which means there is no multiple server interaction.
1.1 Is the delivered map the correct map and properly retrieved in terms of its features (point, line, and
polygon)?
1.2 Does the desired map contain the correct scale and spatial extent?
1.3 While using the pan function, does the scale remain the same proportion?
1.4 When displaying overlapping maps, are the layers in the right (requested) order?
1.5 For each layer, is the rendered style (colour, line width) consistent?
38 http://www.gisig.it/best-gis/ (last access 11.02.2006)
28
Response speed
This section deals with the response speed, which is a factor to measure the efficiency of an application or
a program. The response time is the elapsed time from when a client viewer sends a request because an
event has occurred, until it receives a response and a new map is displayed (ESRI – virtual campus
training - Learning ArcIMS). For simulating a multi-user request and measuring response time the Web
Application Stress (WAS) from Microsoft39 is used. This web stress tool is designed to realistically imitate
multiple browsers requesting pages from a web site.
2.1 How long does the response time take?
2.1 How does a multi-user request effect the response time from a single server application?
Export spatial data
This section deals with the export of spatial data.
3.1 Which image format does the web mapping service support to exporting a map presentation?
Query handling
This section deals with the request of queries that allows end-users to ask questions and get information
about the features on the map.
4.1 How should results of a performed query be shown? Showing it in a table with hyperlinks to the
feature in the map or showing the result directly in a highlighted feature (one or more)?
39 http://www.microsoft.com/downloads/details.aspx?FamilyID=E2C0585A-062A-439E-A67D-75A89AA36495&displaylang=en (last access 04.02.2006)
29
4.4 Benchmark Test (Phase 4)
The goal of the benchmark test is to compare the performance of three different WMS specifications by
means of the ArcIMS Web GIS program. Each WMS specification contains three main Get operations
(GetCapabilities, GetMap and GetFeatureInfo). The performance is to ask the map server to give
capabilities, map image and feature information of each WMS for two created image services
(Nationalpark - ArcIMS image service and NP_Vegetation - ArcMap image service).
The GetCapabilities performance is done with the aid of the WMS Connector (9.1). When a
GetCapability request is made, a set of xml files are stored in a Capabilities directory. Each Capabilities
directory contains three capabilities files.
<Capabilities Directory>
|__wms
|__<hostname>-<port>
|__<service>
|__capabilities_1_0_0.xml
|__capabilities_1_1_0.xml
|__capabilities_1_1_1.xml
30
4.4.1 XML validator
The validation of the Capability xml files is done via the Brown University’s XML validator40. The xml
validator offers full xml 1.0 validation facilities with Unicode Transformation Format41 (UTF) – 8
encoding standards for local or fire walled xml files.
The performance of the GetMap and GetFeatureInfo is dependent upon user service requirements. To
illustrate the co-operation between the GetMap operations, the pan function as described in 1.3 concerning
map handling requirements is used. The performance of the pan function is a moving BBOX. If a first
GetMap operation asked for a Bounding Box of 4541402,5929360,4548946,5934282 while the second
Get Map operations asked for 4541402,5929360,4548946,5934282 the BBOX moves 2000 unit (meter)
on the x axis and 1000 units (meter) on the y axis.
All GetMap operations are done with OGC-standard WMS requests within the Microsoft Internet Explorer
URL address bar. The request is transferred via HTTP and TCP/IP until the Image and ArcMap server,
which processes the requests and produced map images which are sent back to the client (Browser).
The GetFeatureInfo request uses the same infrastructure as the GetMap operations. The request is
transferred to the spatial server that forwards the request automatically to the query server (for the ArcIMS
image service). Meanwhile, the ArcMap server has the equivalent of the query server already built-in
(Peng & Tsou, 2003) and responses by itself (from the ArcMap image service). The WMS specification
does not indicate an output format for a response. ESRI has provided four XSL stylesheets
(Environmental Systems Research Institute (ESRI), 2004 b). The ‘Text/xml’ stylesheet is used in this case
study.
The final comparison is based on all output files. The xml files are compared on complexity and volume
of the provided service metadata. The map image is compared to the original map. Here correctness is the
main criterion. The WMS specification version with the best performance in terms of accuracy and
completeness is advised to be used for the Mueritz National Park internet-GIS application.
40 http://www.stg.brown.edu/service/xmlvalid/ (last access 11.02.2006) 41 Unicode Transformation Format is a encoding standard which is able to represent any universal character in the unicode
standard. (source: http://en.wikipedia.org/wiki/Unicode_Transformation_Format last access 18.02.2006)
31
Chapter 5. Results and Discussion
This chapter describes intermediate results and final results. Intermediate results are user service
requirements from the national park and web mapping services currently used in Germany. These findings
were input parameters for the benchmark test environment. The outcomes of the benchmark test
environment were the final results.
5.1 Intermediate Results
5.1.1 User service requirements
The working group, consisting of national park staff members, discussed the web GIS checklist by means
of their common interests and objectives. The conclusion from the group discussion is the below presented
service requirement list.
Map handling requirements
1.1 The delivered map has to be the correct map and has to be properly retrieved in terms of its
features type (point, line, polygon)!
1.2 The desired map has to contain the correct scale and spatial extent!
1.3 While using the pan function, the scale has to remain the same proportion!
1.4 When overlapped layers are displayed, the order of the layers must be right (as requested)!
1.5 For each layer the rendered style must (colour, line width) be consistent!
Response speed
2 The response time from a multi user request should be as short as possible!
Export spatial data
3 The WMS should support as many picture formats as possible!
Query handling
4 The correct result of a performed spatial/tabular query should be shown in a table with hyperlinks
to the requested features in the map!
32
The obtained user service paragraphs looked very similar to the user service web GIS checklist. This does
not indicate that the paragraphs are wrong or not useable. The reasons for their similarity might be:
• that the checklist itself is already too specific, and does not allow the national park staff members
to define their point of view about service requirements within web mapping applications,
• that the staff members are not aware of neither the need nor the performance of a Web Mapping
Service, even though the context were illustrated.
• or, that the task to describe their own user service requirements was too complex because of
missing experience and expertise or simply the imagination of requirements of the user.
However, we implemented the determined user service requirements within the Get operations of GetMap
and GetFeatureInfo respectively in the benchmark test environment.
5.1.2 Web Mapping Services used in Germany
All surveying and cadastral administrations, which are involved in the viewer project, replied to the
inquiries. The Federal Agency for Cartography and Geodesy and the federal state of Sachsen abet all
implemented WMS specifications. Two federal states support WMS 1.1.0 while six support WMS 1.1.1
(upper Austria included). Two surveying administrations gave particulars that they use WMS, but did not
specify which version. No administration provides WMS’s of version 1.3.0. Table 6 shows the current use
of WMS specifications within the viewer projects.
Table 6 - WMS used by surveying administrations of the federal states in Germany
Surveying department WMS 1.0.0 WMS 1.1.0 WMS 1.1.1 not known
Baden-Würtemberg X
Brandenburg X X
Bayern X
Hessen X
Niedersachsen X
Nordrhein-Westfalen X
Rheinland-Pfalz X
Sachsen X X X
Thüringen X
Fed. Agency f. Cart./Geodesy X X X
Upper Austria X
Total 2 4 8 2
33
The investigation of web GIS applications resulted in six reviewed products, shown in table 7. The
Landesamt for Geosciences and Resources in Brandenburg supports WMS 1.1.0 whereas all other
applications abet WMS 1.1.1. Two applications did not provide information about the used versions of
WMS.
Table 7 - Web Mapping Applications with Providers, Product name and supported WMS
State Provider Product name WMS not known
Bayern Bayerische Vermessungsverwaltung BayernViewer 1.1.1
Brandenburg Landesamt für Geowissenschft. u. Rohstoffe Brdbg. Produktkatalog 1.1
Hamburg Landesbetrieb Geoinformation und Vermessung GeoNord X
Niedersachsen Landesvermessung + Geobasisinformation Niedersachsen VKV-Mapservice 1.1.1
Nordrhein-Wes. Landesvermessungsamt Nordrhein Westpfahlen „TIM-online“ 1.1.1
Nordrhein-Wes. Cross-Border Geodata Infrastructure X-Border Project X
These intermediate results provide an indication of the current used WMS specifications in Germany. A
tendency towards the WMS specification 1.1.1 is recognizable for the surveying administrations as well
within the environment of the web GIS applications. Nevertheless the earlier versions of the WMS
specifications are still in use. WMS version 1.3.0 is so far not supported due to the missing map server
implementation of this WMS specification version42.
Because of the fact, that WMS versions 1.0.0 to 1.1.1 are nationwide implemented, it was decided to
include these WMS specification in our benchmark test environment to analyze which WMS specification
performs best concerning the user service requirements.
The surveying administration of Mecklenburg-Western Pomerania, where the Mueritz national park is
located, does not participate or rather support the Viewer project. However, the surveying administration
establishes at the moment their own Spatial Data Infrastructure (SDI) for Mecklenburg-Western
Pomerania. It provides, within the first implementation phase, state authorities access to geobasisdata.
This application is based on the WMS version 1.1.1. It is designated to set the WMS version 1.1.1 as a
minimum standard. This decision should be kept in mind for the implementation of the web GIS
application of the national park.
42 As stated by the OpenGIS Consortium only the company ‘Manifold System’ located in the United States implemented the
WMS 1.3.0.
34
5.2 Final Results
5.2.1 Benchmark Test
5.2.1.1 Capabilities Response - XML document
The GetCapabilities request was done for the ‘Nationalpark’ and the ‘NP_Vegetation’ image services via
WMS Connector. WMS version 1.3.0 is not supported by ArcIMS thus the results cannot be presented for
this version. The GetCapability request delivers a xml document that indicates no differences of WMS
1.0.0, 1.1.0 and 1.1.1 between ArcIMS image service and the ArcMap image service concerning their
structure.
They do show differences concerning their content and elements as well as the quantity of metadata. The
whole xml file for each WMS version (Nationalpark image service) can be found in the appendix of this
document.
The following part describes the structure and element differences in addition to the quoted43 metadata of
the WMS versions 1.0.0, 1.1.0 and 1.1.1 of the Nationalpark ArcIMS image service.
Any Capability xml document has two main elements the:
o Service element (general information about the service), and the
o Capability element (specific information about the kinds of functionality offered by the
server).
The general service metadata, provides metadata for the service as a whole ((OGC), 2001). It contained in
the first WMS version elements for the Name, Title, Abstract, Keywords, OnlineResource, Fees and
AccessConstraints. The following WMS specifications were extended with ContactInformation which
contains elements of ContactPerson and ContactAddress.
43 Only the filled elements will be shown, to arise the recognisability of the data itself.
35
The coloured sections are differences between the individual WMS:
o Is the difference from WMS 1.0.0 to WMS 1.1.0
o Is the difference from WMS 1.1.0 to WMS 1.1.1
The metadata itself given for the WMS 1.0.0 contains:
<WMT_MS_Capabilities version="1.0.0">
<Service>
<Name>WMS</Name>
<Title>Web Map Service Nationalpark</Title>
<Abstract>ArcIMS 9.1.0 Nationalpark Web Map Service</Abstract>
<Keywords>ArcIMS</Keywords>
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
The service metadata for the WMS 1.1.0 and WMS 1.1.1 are identical (the abridgement shows version
1.1.1) and give the following information:
<WMT_MS_Capabilities version="1.1.0">
<Service>
<Name>OGC:WMS</Name>
<Title>Web Map Service Nationalpark</Title>
<Abstract>ArcIMS 9.1.0Nationalpark Web Map Service</Abstract>
<KeywordList><Keyword>ArcIMS</Keyword>
</KeywordList>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
<ContactInformation>
<ContactAddress><AddressType>postal</AddressType></ContactAddress>
</ContactInformation>
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
36
The Capability element is divided into three elements ((OGC), 2000; (OGC), 2001; (OGC), 2002),
containing:
• Request (informs about available request types),
• Exception (informs how exceptions may be reported) and
• Layer (list of map layers available from this server).
The request element lists available request types (Get44) Map, (Get)Capabilities and (Get)FeatureInfo.
Each request type offered by the server, list the available output formats and the supported distributed
computing platforms (DCPs). At present, only HTTP is defined for DCP ((OGC), 2000; (OGC), 2001;
(OGC), 2002). The WMS 1.0.0 describes the “Get onlineResource” together, whereas the versions 1.1.0
and 1.1.1 describe the Get and onlineResource in separated elements. The Capability element with the
Request element (Map, Capabilities, FeatureInfo) gives only information about online Resouce. The xml
response for WMS version 1.0.0 looks like the following:
<WMT_MS_Capabilities version="1.0.0">
<Capability>
<Request>
<Map>
<DCPType>
<HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap
/Nationalpark?" />
</HTTP>
</DCPType>
</Map>
<Capabilities>
<DCPType>
<HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap
/Nationalpark?" />
</HTTP>
</DCPType>
</Capabilities>
<FeatureInfo>
<DCPType>
44 Version 1.0.0 calls the request “Map”, all following version call the request “GetMap”. Please have a look to footnote 25.
37
<HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap
/Nationalpark?" />
</HTTP>
</DCPType>
</FeatureInfo>
</Request>
The Capability element with the Request element for the WMS 1.1.0 and WMS 1.1.1 are identical (the
shortened version below shows WMS 1.1.1) and give the following information:
<WMT_MS_Capabilities version="1.1.0">
<Capability>
<Request>
<GetCapabilities>
<Format>application/vnd.ogc.wms_xml</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetCapabilities>
<GetMap>
<Format>image/png</Format>
<Format>image/jpeg</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetMap>
38
<GetFeatureInfo>
<Format>application/vnd.ogc.wms_xml</Format>
<Format>text/xml</Format>
<Format>text/html</Format>
<Format>text/plain</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetFeatureInfo>
</Request>
The Exception element indicates which output formats are supported for reporting problems encountered
when executing a request ((OGC), 2000). The Exception element for the WMS version 1.0.0 is empty.
WMS version 1.1.0 and 1.1.1 support the following formats:
<WMT_MS_Capabilities version="1.1.0">
<Service>
<Capability>
<Exception>
<Format>application/vnd.ogc.se_xml</Format>
<Format>application/vnd.ogc.se_inimage</Format>
<Format>application/vnd.ogc.se_blank</Format>
</Exception>
The Layer element has two functions: “it either refers to a map layer which can be requested by Name in
the LAYERS parameter of the GetMap request, or it is a category Title for all the layers nested within
((OGC), 2000). For the Nationalpark image service the first function is the case.
The shapefiles which were used to create the image service had no projection information, therefore the
Spatial Reference Systems (SRS) value for the service and the layer is set to NONE. That means
automatically the Latitude/Longitude Bounding Box covers the whole world with -180, -90, 180, 90
degree. Figure 14 shows the corresponding warning message.
39
Figure 14 - ArcIMS WMS Connector Administrator Window with a Warning Message concerning SRS
All WMS versions describe their services with a Title and a Spatial Reference System (SRS).
Additionally, the SRS is described in WMS 1.1.0 and 1.1.1 as Latitude and Longitude of the Bounding
Box and Layer queryable45, Layer opaque46, respectively Layer noSubsets47.
The individual layers have in all WMS’s, information about – Layer queryable, Name48, Title and
LatLongBoundingBox. WMS 1.1.0 and 1.1.1 specify supplementary SRS and ScaleHint49 (min, max) for
each Layer. Only WMS 1.1.1 gives extra information when each layer supports Layer opaque and Layer
noSubsets.
45 Layer queryable: 0 = not queryable, 1 = queryable 46 Layer opque: 0 = map data represents vector features that probably do not completely fill space, 1 = map data are mostly or
completely opque 47 Layer noSubsets: 0 = WMS can map a subset of the full bounding box, 1 = WMS can only map the entire bounding box 48 Name: The name is a single word used for machine-to-machine communication while the Title is for the benefit of humans. For
example, a dataset might have a Title “Minimum Ground Water Level”and be requested using the Name “GWLMIN” (source:
(OGC) (2001). "OpenGIS Web Map Server Interface Implementation Specification." Version: 1.1.0. Project Document 01-047r2;
Wayland, Massachusetts: Open GIS Consortium. 49 ScaleHint: This element suggests minimum and maximum scales for which it is appropriate to display this layer.
40
The Layer element from the WMS 1.0.0 is shortened, and represents a polygon (MV_Aemter), line
(Mueritzrundweg) and point (Bahnhof) layer.
<WMT_MS_Capabilities version="1.0.0">
<Capability>
<Layer>
<Title>Nationalpark</Title>
<SRS>EPSG:NONE</SRS>
<Layer queryable="1">
<Name>0</Name>
<Title>MV_Aemter</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
<Layer queryable="1">
<Name>5</Name>
<Title>Mueritzrundweg</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
<Layer queryable="1">
<Name>10</Name>
<Title>Bahnhof</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
The Layer element from the WMS 1.1.0 and WMS 1.1.1 is shortened to the same layers (polygon
(MV_Aemter), line (Mueritzrundweg) and point (Bahnhof) layer).
<WMT_MS_Capabilities version="1.1.0">
<Capability>
<Layer queryable="0" opaque="0" noSubsets="0">
<Title>Nationalpark</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<Layer queryable="1"(>) opaque="0" noSubsets="0">
<Name>0</Name>
<Title>MV_Aemter</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
41
<ScaleHint min="NaN" max="9999999" />
</Layer>
<Layer queryable="1"(>) opaque="0" noSubsets="0">
<Name>5</Name>
<Title>Mueritzrundweg</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
<Layer queryable="1"(>) opaque="0" noSubsets="0">
<Name>10</Name>
<Title>Bahnhof</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
The summary of this study shown in table 8, gives the identified differences between: WMS 1.0.0 and
WMS 1.1.0 as well as WMS 1.1.0 and WMS 1.1.1. The main differences between WMS 1.0.0 and WMS
1.1.0 are onlineResource information as well as output format types. Differences between WMS 1.1.0 and
WMS 1.1.1 is only in one element of Layer description.
Table 8 - Difference between WMS version 1.0.0, 1.1.0 and 1.1.1 concerning the quantity of the provided
metadata
Main Element Sub Element WMS 1.0.0 – WMS 1.1.0 WMS 1.1.0 – WMS 1.1.1
Service Element OnlineResource xmlns:xlink, xlink:href, xlink:type
AddressType
Capability Element Request - GetCapabilities Format
OnlineResource xmlns:xlink, xlink:type
Request - GetMap Format
OnlineResource xmlns:xlink, xlink:type
Request - GetFeatureInfo Format
OnlineResource xmlns:xlink, xlink:type
Exception Format
Layer - Category Layer Layer queryable, opaque, noSubsets
LatLonBoundingBox minx, miny, maxx, maxy
Layer SRS Layer opaque, noSubsets
ScaleHint min, max
42
XML Validation
Validation concerning the locally stored Capabilities xml files was done using the Brown University’s
XML validator. No modification with styles sheets was made. The availability to suppress warning
messages and relax namespace checks was used. The results for the Nationalpark and NP_Vegetation
image services were identical.
• Capabilities.xml / WMS 1.0.0 status = 4 actual errors are detected
• Capabilities.xml / WMS 1.1.0 status = 4 actual errors are detected
• Capabilities.xml / WMS 1.1.1 status = 0 no validation errors (document validates OK)
The error types for WMS 1.0.0 and WMS 1.1.0 were:
• error (1102): tag uses GI for an undeclared element
• error (1103): end tag uses GI for an undeclared element
• error (1150): enclosing tag undefined or lacks content model; can't check child
• error (1203): attribute can't be checked because element is not defined.
In general, each WMS version presents the same basic metadata. The basic metadata is inflated
respectively per service in WMS 1.1.0 and WMS 1.1.1. However, the automatically created xml
documents show differences between the WMS specifications. WMS version 1.0.0 gave no information
about online resources or output format description for the request operations or other exceptions. The xml
files from WMS 1.1.0 and 1.1.1 declared output formats additional to the new implemented layer
descriptions. This extra server information makes the last two WMS specification versions more attractive
then the incomplete described WMS 1.0.0.
Besides the WMS specification comparison, astonishment arose concerning the presented error message.
Due to the missing projection is the SRS set to NONE and the lat/lon Bounding Box to degree. In the
following chapter the map requests were done in meters instead of degree. This should have entitled an
error message.
The validator concluded that only the xml document from the WMS version 1.1.1 is well formed. The
other xml files were invalid because of undeclared elements and tags. The validator follows the xml 1.0
specification rather close and flags error that may pose problems later on.
43
5.2.1.2 GetMap Response
The first part of the GetMap series was carried out by means of the map handling requirements. The
request asked for
• a map from the Nationalpark ArcIMS image service via WMS 1.0.0,
• with the layers 2,3,1,8,4,10,11, no style,
• a BoundingBox of 4543594,5904292,4589152,5934759 which means a spatial extent of 45558
meter on the x axis and 30467 meter on the y axis,
• a map image as png (Portable Network Graphics) and a width of 900 pixels and a height of 600
pixels.
The complete GetMap command as well as corresponding png is shown in figure 15 below.
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11
&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=i
mage/png&SERVICENAME=Nationalpark&
Figure 15 - First map image from the map handling requirements
44
Concerning the pan function and the required stable scale factor a map was panned 5000 m to the east and
4000 meter to the south. The new map remained at the same scale. The complete command and the
responded png are shown in figure 16.
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&
STYLES=&SRS=EPSG:NONE&BBOX=4548594,5900292,4594152,5930759&WIDTH=900&HEIGHT=600&FORMAT=im
age/png&SERVICENAME=Nationalpark&
Figure 16 - Second map image from the map handling requirements
The previous requests were executed using WMS 1.1.0 and WMS 1.1.1. Instead of WMTVER=1.0.0 and
REQUEST=Map (WMS 1.0.0), we had to use
SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap. The following command is a copy of the first
GetMap request, but with WMS 1.1.1 parameters.
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.1&R
EQUEST=GetMap&LAYERS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4543594,59
04292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/png&&SERVICENAM
E=Nationalpark&
Surprisingly, a request in WMS 1.1.0 and 1.1.1 could be executed with WMTVER and REQUEST=Map
from WMS 1.0.0. On the other hand, a request in WMS 1.0.0 was accepted with
SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap from WMS 1.1.0. and WMS 1.1.1 as shown
below:
45
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.1.1&REQUEST=Map&L
AYERS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759
&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.0.0&R
EQUEST=GetMap&LAYERS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4543594,59
04292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&
The parameters themselves can appear in any order and parameter names are not case sensitive. Another
interesting point was the difference between ArcIMS image service and ArcMap image service requests.
When a request was made using the ArcIMS image service (Nationalpark) for a certain layer, it could be
done by means of name or title. The server accepted for the ArcMap image service (NP_Vegetation) only
the appropriate name, not the title. The first command below contains a name within the request. The
output is a map image. The second command requests the same but with a title instead of the name and
should therefore give an error message.
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LA
YERS=1,0&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=9
00&HEIGHT=600&FORMAT=image/jpeg&SERVICENAME=NP_Vegetation&
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LA
YERS=Nationalparkgrenze,Vegetationstypen1,0&STYLES=&SRS=EPSG:NONE&BBOX=454359
4,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&SERVICENA
ME=NP_Vegetation&
The following figure 17 and 18 show map images from the Nationalpark and NP_Vegetation image
services which were requested in three partitions for each WMS version. Each partition had a smaller area:
• Bounding Box : 4543594,5904292,4589152,5934759 and an area of 1388.015 km²
• Bounding Box : 4558965,5918732,4566123,5923475 and an area of 33.950 km²
• Bounding Box: 4562987,5920876,4564602,5922637 and an area of 2.844 km².
46
Figure 17 - Three partitions of Nationalpark map images
Figure 18 - Three partitions of NP_Vegetation map images
47
The responded map images were properly retrieved in terms of their features, for each partition and WMS
version. All WMS versions responded to the correct scale and spatial extent as well as the right order of
the layers. The rendered styles for the features were consistent in all cases.
Finally, no differences were detected between the responded map images supported by WMS 1.0.0, 1.1.0
and 1.1.1. Nevertheless differences were detected in the sense of, how the client was allowed to ask the
server to perform a certain task. All WMS versions allowed for example the use of REQUEST=Map and
REQUEST=GetMap command whereas no WMS specification defined not to do so.
Response speed
During the single stress simulation 5 clients requested constantly 4 different GetMap operations over 15
minutes. In this time period, the WMS 1.1.0 served 367 requests with an average speed of 24 requests per
minute. Whereupon the WMS 1.1.1 requested 255 times which means less than 17 requests per minute.
Nevertheless, not all requests were successful because of temporary overloading when the server
frequently was unable to handle the request (code 503: service unavailable50). This situation happened
most often with WMS 1.1.0, 222 unavailable services. The WMS 1.1.1 had the most successful and the
least number of unsuccessful request. Figure 19 presents the number requests per WMS under stress
conditions.
050
100150200250300350400
Number of hits
1.0.0 1.1.0 1.1.1
Web Mapping Services
Server requests under stress condictions
service unavailable
succesfully
Figure 19 - Requests under stress condiction per WMS specification
50 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html (last access 06.02.2006)
48
Analysis of the response time for the GetMap requests shows that requests using WMS 1.1.0 responds
fastest. The average response speed of WMS 1.1.0 was 3 seconds faster than WMS 1.0.0 and 5 seconds
quicker than WMS 1.1.1. Remarkable is the response speed for the second GetMap command. All three
WMS version completed this request approximately 7 seconds sooner than the other GetMap commands.
The response time for each WMS version is illustrated in figure 20.
0
4000
8000
12000
16000
20000
response time in
milliseconds
1 2 3 4
GetMap requests
Response times under stress conditions
WMS 1.0.0
WMS 1.1.0
WMS 1.1.1
Figure 20 - Response time under stress conditions for 4 different GetMap requests per WMS version
Export spatial data
As mentioned before, the WMS specification presents only pictures of maps to the web client, which
means the export of spatial data is restricted to this fact. The Image Server and ArcMap Image Server are
able to send map images in graphical formats as JPEG, PNG or GIF. All WMS versions supported these
three graphical formats with responsed map images. Notable is that none of the WMS version gave the
capability in the xml document to support the GIF file. WMS version 1.0.0 stated no graphical format at
all within the GetMap part of the capability xml file.
It was expected that the derived map images from the three different WMS specification are identical,
because the WMS specifications are complementary to each other. By reason of the successive
construction is the progression to generate a map image by the first WMS version equally to the latest
WMS version. Each WMS accepted the modified parameter names of the newer and older version
respectively. The mentioned differences in a request on an ArcIMS-or ArcMap image services, concerning
the ‘title’ or the ‘name’ are not a difference of the WMS versions itself. It is rather a distinction or
limitation for requesting ArcIMS image services or ArcMap image services.
49
The WAS tool provided by Microsoft gave the possibility to simulate a large number of users against a
web application. But how accurate is the measured response time and does it really shows differences in
the performance of the WMS specification? Scepticism came up in both issues. First of all, the
performance of the server might have been affected because the WAS tool was installed on the windows
XP platform were the web server is located as well. This could have had an impact on the request
generator, which is fairly resource intensive while generating the web requests51. However, it is possible to
run WMS on the same machine as a web server, but 100% accurate results were not expected. The other
doubtful point is the real influence of the WMS version on the response speed. Because of these unknown
factors, doubts about the significance between response time related to the WMS version arised.
Nevertheless there are differences noticeable between the GetMap commands and the WMS version itself.
It is assumed that the high number of unavailable services at the WMS version 1.1.0 has an influence of its
fast response speed. If the service was not available the test tool went quickly on to ask the next request.
This took less time then the whole request -response cycle. WMS 1.1.1 with less unavailable services
needed therefore more time to finish the request-response cycle. That’s why the WMS 1.1.1 has the most
successful finished requests next to WMS 1.0.0.
One user service requirement was the support of many picture formats as possible. The source images
referenced in a map configuration file can be stored in many different formats. But the map image itself
must be in one of only three formats: JPEG, GIF, or PNG. All WMS versions support this formats. But no
WMS version mentioned the GIF formats in the Capabilities xml file. GIF files use the Lempel-Ziv-Welch
compression technology, which is patented by Unisys Corporation. The patent expired in all countries on
July 7, 2004 (ESRI – virtual campus training - Learning ArcIMS). At the time when the WMS versions
were published the patent of the GIF file format were still current. The patent might be the possible reason
why no xml Capability document mentioned this picture format.
51 http://www.west-wind.com/presentations/webstress/webstress.htm (last access 06.02.2006)
50
5.2.1.3 GetFeatureInfo Response Within the GetFeatureInfo request it is specified at which pixel and layer the interest is. The following
GetMap statement was used to create a map image. The GetFeatureInfo operation investigated one pixel
in the center of the national park and is expressed in the following command and the corresponding map
image (figure 21).
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LA
YERS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&
WIDTH=900&HEIGHT=600&FORMAT=image/gif&SERVICENAME=Nationalpark&
Figure 21 - Map image from were GetFeatureInfos are requested
The yellow arrow in the picture above indicates the pixel of interest. Within the statement for the
GetFeatureInfo below information to pixel 86 on the x axis, 418 on the y axis at the layer number 2
(lakes) is requested:
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Feature_I
nfo&STYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&H
EIGHT=600&INFO_FORMAT=text/xml&SERVICENAME=Nationalpark&QUERY_LAYERS=2
&X=86&Y=268
51
The following lines are the XML response:
<?xml version="1.0" encoding="UTF-8" ?>
<FeatureInfoResponse>
<FIELDS AREA="2614600,75" EIGENTUMSV="" MV="1"
NAME_DES_S="Käbelicksee" PERIMETER="9396,651764" _ID_="45"
_LAYERID_="2" _SHAPE_="[Geometry]" />
</FeatureInfoResponse>
Additionally an inquiry was made for an ÍNFO_FORMAT=text/html instead of xml. The xml file is
converted into html, using a predefined stylesheet. The output looked like the following table 9:
Table 9 - GetFeatureInfo response in INFO_FORMAT = text/html
All WMS versions responded with the same results. But it was not possible to get results for line or point
features. The GetFeatureInfo request doesn’t include query builder performances with SQL statements
and logical expressions. Neither is the result (presented in a table) connected via hyperlink to the
interested feature in the map as it was required from the users.
52
Chapter 6. Conclussions and Recommendations
After taking into account the intermediate results and the final results it is possible to answer the research
question. The Web Mapping Service specification 1.1.1 is most suitable, concerning the requirements of
public user’s, for the implementation of the web GIS application for the Mueritz national park. The
answer to the research question is based on the facts that:
• most of the surveying administrations within the ‘Deutschland Viewer’ project support
the WMS 1.1.1
• the surveying administration of Mecklenburg-Western Pomerania plans to establish an SDI in
their state, based on the WMS 1.1.1 as a minimum standard and the national park as state
department has access to geospatial data through this WMS version
• the Capability xml files of WMS 1.1.1 and WMS 1.1.0 provided the highest quantity of service
metadata but only the xml files from the WMS 1.1.1 were validated as well formed (valid),
• the WMS 1.1.1 had the most successful and the least unavailable service results during the Web
Application Stress performance, whereas it is fact that these results might not represent the
impact of the WMS itself.
During the benchmark test it was actualized, that the different WMS specifications retrieve the map
images in the exact same way (pictured in the dark grey fields, figure 22) because the specifications are
complementary to each other. The OGC Consortium extended each new WMS version concerning service
metadata and added attributes for better
layers description. This enlarged the
possibilities for service and capability
descriptions (in the light grey fields, figure
22). Finally these changes let perform the
WMS version 1.1.1 in a better way then the
older versions.
Figure 22 - WMS versions and there changes over time
53
During the project were user service requirements obtained which looked very similar to the created web
GIS checklist. To prevent a very specific checklist an administrative workshop could create over long
term a checklist for selecting and defining user service requirements within specific web GIS applications.
To avoid that users are unaware of service requirements, a closer co-operation with the staff members of
the national park could help. On the spot support might increase the communication about the use and
need of WMS and the resulting user service requirements.
Within the research it was concluded, that the WMS version 1.1.1 is be the best option for the web GIS
application of the national park department. To be more interoperable the application should support all
OGC compliant WMS specifications. In that way the client would be able to include as many datasets as
needed from distributed map sever.
The comparison of the current WMS specification, excluded the last published WMS version 1.3.0
because it is implemented just once and is therefore not used widely. When the WMS version 1.3.0 is
wide spread within spatial services, additional comparisons between the WMS versions could be useful.
Also a multi server analysis is recommended, because a multi server analysis might detect differences in
the content of the xml documents. The WMS specification only suggests the possible use of the
GetCapabilites interface and leaves the detailed design of the interfaces to software companies (Peng &
Tsou, 2003). The software companies can influence the xml content because of the mentioned vendor
specific parameters.
Further test performances should include interoperability analysis. The advantage of interoperability in
case of the national park could be, to use third party datasets (for example topographical or land use maps)
via map services. On the other hand could the SDI for Mecklenburg-Western Pomerania create a map
service to use flora and fauna distribution maps from the national park. An archetype could be the
‘Conformance and Interoperability Test and Evaluation52 of the OGC consortium.
During this thesis project started also the analysis of how the WMS versions operate within open source
UMN Map Server environment. A similar test environment with the same dataset inputs were set up. Due
to the time limitations the tests couldn’t finish successfully and give assured facts. But it is strongly
recommend that the interoperability performances are continued within further projects. The output could
give information whether the WMS as well as the map server work in an interoperable way. But the
interoperability tests are not limited to the open source products. Commercial packages like Autodesk
Map guide, Geo Media WMS or MapInfo MapXtreme are from the same interest.
52 http://www.opengeospatial.org/initiatives/?iid=65 (last access 07.02.2006)
54
Chapter 7. References (OGC) (2000). "OpenGIS Web Map Server Interface Implementation Specification." Version:
1.0.0. Project Document 00-028; Wayland, Massachusetts: Open GIS Consortium. (OGC) (2001). "OpenGIS Web Map Server Interface Implementation Specification." Version:
1.1.0. Project Document 01-047r2; Wayland, Massachusetts: Open GIS Consortium.
(OGC) (2002). "OpenGIS Web Map Server Interface Implementation Specification." Version: 1.1.1 Project Document 01-068r3; Wayland, Massachusetts: Open GIS Consortium.
(OGC) (2004). "OpenGIS Web Map Server Interface Implementation Specification." Version: 1.3.0 Project Document 03-109r1; Wayland, Massachusetts: Open GIS Consortium.
Beaujardiere, J. d. (2001). "Basic Services Model Draft Candidate Implementation Specification." Version 0.0.8 Paper Number 01-022r1; Wayland, Massachusetts: Open GIS Consortium.
Buehler, K., McKee, L. (1998). "The OpenGIS Guide: Introduction to Interoperable
Geoprocessing and the OpenGIS Specification." 3rd ed. Wayland, Massachusetts: OpenGIS Consortium
Burrough, P. A., McDonnell, R. A. (1998). "Principles of Geographical Information Systems."
New York, Oxford University Press. Crompvoets, J. (2004). "Lecture of: "Spatial Data Infrastructure", Wageningen University. Donaubauer, A. J. (2004). "Interoperable Nutzung verteilter Geodatenbanken mittels
standardisierter Geo Web Services." Institut fuer Geodaesie, GIS und Landmanagement, Technische Universitaet Muenchen.
East, R., et al. (2001). "The Architecture of ArcIMS, a Distributed Internet Map Server." Redlands, California
Environmental Systems Research Institute (ESRI). (2004 a). "ArcIMS 9 Architecture and Functionality." Redlands, California
Environmental Systems Research Institute (ESRI). (2004 b). "ArcIMS Help - WMS Connector." Redlands, California
Environmental Systems Research Institute (ESRI). (2004 c). "WMS Connector for ArcIMS 9.0 SP2." Redlands, California
Federal Agency for Cartography and Geodesy (2005). "Geoinformation und moderner Staat,
Innenministerieller Ausschuss fuer Geoinformationswesen (IMAGI). Forrest, D., et al. (2000). "A comparison of three web map servers." Bulletin of the Society of
University Cartographers 34(2): 13-27.
Geographical Information Systems International Group. (unknown). "Guidelines for Best Practice in User Interface for GIS." Section 4 "Analysis of GIS users, taks and workflows",
Geographical Information Systems International Group. (unknown). "Guidelines for Best Practice in User Interface for GIS, ." Section 5 "Checklist for selecting and defining user
requirements for specific GIS applications”, Heywood, I., Cornelius, S., Carver, S. (2002). "An Introduction to Geographical Information
Systems." Pearson Education Limited.
Homoet, M. (2003). "Entwicklung eines kooperativen Web-Clients für interoperable Internetkarten."
Kolodziej, K. (2003). "OGC's WMS Cookbook: Recipes for Web Mapping." GeoSpatial Solutions 13(10): 42-44.
Landesamt fuer Forsten und Grossschutzgebiete Mecklenburg-Vorpommern. (unknown). "Nationalparkplan, Leitbild und Ziele."
55
Mathiyalagan, V., et al. (2005). "A WebGIS and geodatabase for Florida's wetlands." Computers and Electronics in Agriculture 47(1): 69-75.
Peng, Z. R., Tsou, M.H. (2003). "Internet GIS – Distributed Geographic Information Services for
the Internet and Wireless Networks. ." Prastacos, P. (2000). "Putting GIS on the web internet solutions of GIS-providers in
comparison." Geo-Informations-Systeme 13(1): 13-16. Ravden, S. J., et al. (1989). "Evaluating Usability of Human-Computer Interfaces: A Practical
Method." Chichester: Ellis Horwood Limited. Reed, C. (2005). "Technical Committee Policies and Procedures." Sickel, J. V. (2004). "Basic GIS Coordinates." Taylor & Francis.
Teege, G., et al. (2003). "Pilotierung von OGC-Spezifikationen in Prjekten des Runden Tisch GIS e.V." 8. Muenchener Fortbildungsseminar Geoinformationssysteme, TU Muenchen.
Working Committee of the Surveying Authorities. (2005). "OGC Web Map Services in der deutschen Landesvermessung."
A
Chapter 8. Appendix
APPENDIX A - Web GIS Application
The web GIS application is a prototype for the Mueritz national park department and is today locally
accessible under http://esg1136/website/webGIS/viewer.htm from the computer ESG1136 (room A206) in
Alterra, Wageningen. The application is going to be included at the Mueritz national park homepage.
The prototype is a HTML viewer which incorporates an ArcMap Image Service. These Service contains
of 27 layers (12 point, 11 line and 4 polygon layers) with general infrastructure and several tourist
information. The HTML viewer is a thin client without plug-ins or applets. The advantage is that the client
computer doesn’t need to be very powerful. Most of the computing / processing are done at the server
side. However the generalized GIS functionality is sufficient for the tourist needs and was required from
the national park department.
The prototype construction followed roughly the MoSCoW method. During the first meeting at the
national park department it was discussed, what the web GIS application
• MUST have,
• SHOULD have,
• COULD have and
• WON’T have.
After a short period for getting to know the program a first prefiguration was created. Changes within the
prefiguration were undertaken after each reviewing session and telephone conference with the staff
members. Step by step were the prototype improved to the current layout and functionality.
B
Screenshot from the web GIS application prototype from the Mueritz national park
The current version of the web GIS contains of 8 frames:
• Top Frame,
• TOC Frame (Table of content),
• Tool Frame,
• Map Frame,
• Text Frame,
• Mode Frame,
• Bottom Frame and
• Post Frame.
The layout of the map cannot be changed by the user. The legend is dynamically rendered and gives after
each map manipulating a new legend image. The amount of visible layers is dependent at the zoom factor,
because of the utilization of scale ranges. The overview map gives the client an understanding where he is
located at the map. The north arrow and the scale bar allow users to orientate and to get a feeling for
distances.
Additionally is a copyright text from the surveying administration of Mecklenburg-Western
Pomerania included (“Copyright © Landesvermessungsamt Mecklenburg – Vorpommern”). The
C
copyright text is always visible in the map and is also included in the print out. The help function explains
the context of the web GIS prototype itself and explains all tools and their functionality.
The prototype includes basic GIS functions like zooming, panning and identification of points within the
maps. These functions present the tested WMS Get operations (GetMap, GetFeatureInfo). The tested Get
operations from the WMS’s aren’t built-in in the HTML viewer. This could be possible with the custom-
build viewer (Active X or Cold Fusion Viewer).
When the necessity occurs to update the datasets of the application, two steps are required:
• changing the .mxd file in ArcMap and
• refreshing the ArcMap image service in ArcIMS administrator.
The updating process can be done at the University for Applied Science in Eberswalde where the
application will be located. A second option would be to set up a remotely access from the national park
department by means of a password registration. This option has to be build up in the near future. If the
SDI of the state Mecklenburg-Western Pomerania is operating it would be a great opportunity to
connect via map service to their available up to date datasets. This could be done in a new thesis project.
D
APPENDIX B - Capabilities.1.0.0.xml (Nationalpark)
<?xml version="1.0" encoding="UTF-8" ?>
- <WMT_MS_Capabilities version="1.0.0">
- <Service>
<Name>WMS</Name>
<Title>Web Map Service Nationalpark</Title>
<Abstract>ArcIMS 9.1.0 Nationalpark Web Map Service</Abstract>
<Keywords>ArcIMS</Keywords>
<OnlineResource />
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
- <Capability>
- <Request>
- <Map>
- <Format>
<PNG />
<JPEG />
</Format>
- <DCPType>
- <HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?" />
</HTTP>
</DCPType>
</Map>
- <Capabilities>
- <Format>
<WMS_XML />
</Format>
- <DCPType>
- <HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?" />
</HTTP>
</DCPType>
</Capabilities>
- <FeatureInfo>
- <Format>
<XML />
<MIME />
E
</Format>
- <DCPType>
- <HTTP>
<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?" />
</HTTP>
</DCPType>
</FeatureInfo>
</Request>
- <Exception>
- <Format>
<WMS_XML />
<INIMAGE />
<BLANK />
</Format>
</Exception>
- <Layer>
<Title>Nationalpark</Title>
<SRS>EPSG:NONE</SRS>
- <Layer queryable="1">
<Name>0</Name>
<Title>MV_Aemter</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>1</Name>
<Title>Nationalparkgrenze</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>2</Name>
<Title>Seen</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>3</Name>
<Title>Ortschaften</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>5</Name>
<Title>Mueritzrundweg</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
F
</Layer>
- <Layer queryable="1">
<Name>6</Name>
<Title>Naturerlebnispfad</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>4</Name>
<Title>Radwanderwege</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>7</Name>
<Title>Mueritz-Nationalpark-Rundweg</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>8</Name>
<Title>Strassen</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>9</Name>
<Title>Bahnlinie</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>10</Name>
<Title>Bahnhof</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>11</Name>
<Title>Zeltplatz</Title>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities>
G
APPENDIX C - Capabilities.1.1.0.xml (Nationalpark)
<?xml version="1.0" encoding="UTF-8" ?>
- <WMT_MS_Capabilities version="1.1.0">
- <Service>
<Name>OGC:WMS</Name>
<Title>Web Map Service Nationalpark</Title>
<Abstract>ArcIMS 9.1.0 Nationalpark Web Map Service</Abstract>
- <KeywordList>
<Keyword>ArcIMS</Keyword>
</KeywordList>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
- <ContactInformation>
- <ContactPersonPrimary>
<ContactPerson />
<ContactOrganization />
</ContactPersonPrimary>
<ContactPosition />
- <ContactAddress>
<AddressType>postal</AddressType>
<Address />
<City />
<StateOrProvince />
<PostCode />
<Country />
</ContactAddress>
<ContactVoiceTelephone />
<ContactFacsimileTelephone />
<ContactElectronicMailAddress />
</ContactInformation>
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
- <Capability>
- <Request>
- <GetCapabilities>
<Format>application/vnd.ogc.wms_xml</Format>
- <DCPType>
- <HTTP>
H
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetCapabilities>
- <GetMap>
<Format>image/png</Format>
<Format>image/jpeg</Format>
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetMap>
- <GetFeatureInfo>
<Format>application/vnd.ogc.wms_xml</Format>
<Format>text/xml</Format>
<Format>text/html</Format>
<Format>text/plain</Format>
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetFeatureInfo>
</Request>
- <Exception>
<Format>application/vnd.ogc.se_xml</Format>
<Format>application/vnd.ogc.se_inimage</Format>
<Format>application/vnd.ogc.se_blank</Format>
</Exception>
- <Layer queryable="0" opaque="0" noSubsets="0">
I
<Title>Nationalpark</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
- <Layer queryable="1">
<Name>0</Name>
<Title>MV_Aemter</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="NaN" max="9999999" />
</Layer>
- <Layer queryable="1">
<Name>1</Name>
<Title>Nationalparkgrenze</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>2</Name>
<Title>Seen</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>3</Name>
<Title>Ortschaften</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1">
<Name>5</Name>
<Title>Mueritzrundweg</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>6</Name>
<Title>Naturerlebnispfad</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
J
</Layer>
- <Layer queryable="1">
<Name>4</Name>
<Title>Radwanderwege</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>7</Name>
<Title>Mueritz-Nationalpark-Rundweg</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>8</Name>
<Title>Strassen</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>9</Name>
<Title>Bahnlinie</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>10</Name>
<Title>Bahnhof</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1">
<Name>11</Name>
<Title>Zeltplatz</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
L
APPENDIX D - Capabilities.1.1.1.xml (Nationalpark)
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE WMT_MS_Capabilities (View Source for full doctype...)>
- <WMT_MS_Capabilities version="1.1.1">
- <Service>
<Name>OGC:WMS</Name>
<Title>Web Map Service Nationalpark</Title>
<Abstract>ArcIMS 9.1.0Nationalpark Web Map Service</Abstract>
- <KeywordList>
<Keyword>ArcIMS</Keyword>
</KeywordList>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
- <ContactInformation>
- <ContactPersonPrimary>
<ContactPerson />
<ContactOrganization />
</ContactPersonPrimary>
<ContactPosition />
- <ContactAddress>
<AddressType>postal</AddressType>
<Address />
<City />
<StateOrProvince />
<PostCode />
<Country />
</ContactAddress>
<ContactVoiceTelephone />
<ContactFacsimileTelephone />
<ContactElectronicMailAddress />
</ContactInformation>
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
- <Capability>
- <Request>
- <GetCapabilities>
<Format>application/vnd.ogc.wms_xml</Format>
M
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetCapabilities>
- <GetMap>
<Format>image/png</Format>
<Format>image/jpeg</Format>
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetMap>
- <GetFeatureInfo>
<Format>application/vnd.ogc.wms_xml</Format>
<Format>text/xml</Format>
<Format>text/html</Format>
<Format>text/plain</Format>
- <DCPType>
- <HTTP>
- <Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap/Nationalpark?"
xlink:type="simple" />
</Get>
</HTTP>
</DCPType>
</GetFeatureInfo>
</Request>
- <Exception>
<Format>application/vnd.ogc.se_xml</Format>
<Format>application/vnd.ogc.se_inimage</Format>
<Format>application/vnd.ogc.se_blank</Format>
N
</Exception>
- <Layer queryable="0" opaque="0" noSubsets="0">
<Title>Nationalpark</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>0</Name>
<Title>MV_Aemter</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="NaN" max="99999999" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>1</Name>
<Title>Nationalparkgrenze</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>2</Name>
<Title>Seen</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>3</Name>
<Title>Ortschaften</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>5</Name>
<Title>Mueritzrundweg</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>6</Name>
<Title>Naturerlebnispfad</Title>
<SRS>EPSG:NONE</SRS>
O
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>4</Name>
<Title>Radwanderwege</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>7</Name>
<Title>Mueritz-Nationalpark-Rundweg</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>8</Name>
<Title>Strassen</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>9</Name>
<Title>Bahnlinie</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>10</Name>
<Title>Bahnhof</Title>
<SRS>EPSG:NONE</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
- <Layer queryable="1" opaque="0" noSubsets="0">
<Name>11</Name>
<Title>Zeltplatz</Title>
<SRS>EPSG:NONE</SRS>
P
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90" />
<ScaleHint min="0" max="NaN" />
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities>
APPENDIX E - GetMap Requests and Response
WMS 1.0.0
For the Nationalpark ArcIMS Image Service were the following requests accomplished.
Starting map image with name
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&S
TYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image
/png&SERVICENAME=Nationalpark&
Q
Panned map image
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&S
TYLES=&SRS=EPSG:NONE&BBOX=4548594,5900292,4594152,5930759&WIDTH=900&HEIGHT=600&FORMAT=image
/png&SERVICENAME=Nationalpark&
map image with title as PNG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.0.0&REQUEST=GetMap&LAYE
RS=Seen,Ortschaften,Nationalparkgrenze,Strassen,Radwanderwege,Bahnhof,Zeltplatz&STYLES=&SRS=EPSG:NONE&
BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/png&&SERVICENAME=Na
tionalpark&
R
First zoom of map image as JPEG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&S
TYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=900&HEIGHT=600&FORMAT=image
/jpeg&SERVICENAME=Nationalpark&
Second zoom of map image as GIF
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&S
TYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&HEIGHT=600&FORMAT=image
/gif&SERVICENAME=Nationalpark&
S
For the NP_Vegetation ArcMap Image Service were the following requests accomplished.
map image with name as PNG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=1,0&STYLES=&S
RS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/png&SER
VICENAME=NP_Vegetation&
First zoom of map image as JPEG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=1,0&STYLES=&S
RS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&SER
VICENAME=NP_Vegetation&
T
Second zoom of map image as GIF
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.0.0&REQUEST=Map&LAYERS=1,0&STYLES=&S
RS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&HEIGHT=600&FORMAT=image/gif&SER
VICENAME=NP_Vegetation&
WMS 1.1.0
For the Nationalpark ArcIMS Image Service were the following requests accomplished.
Starting map image with name
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=6
00&FORMAT=image/png&SERVICENAME=Nationalpark&
U
Starting map image with name and WMS 1.0.0 structur e
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.1.0&REQUEST=Map&LAYERS=2,3,1,8,4,10,11&S
TYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image
/png&SERVICENAME=Nationalpark&
Panned map image
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4548594,5900292,4594152,5930759&WIDTH=900&HEIGHT=6
00&FORMAT=image/png&SERVICENAME=Nationalpark&
V
map image with title as PNG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=Seen,Ortschaften,Nationalparkgrenze,Strassen,Radwanderwege,Bahnhof,Zeltplatz&STYLES=&SRS=EPSG:NONE&
BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORMAT=image/png&&SERVICENAME=Na
tionalpark&
First zoom of map image as JPEG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=900&HEIGHT=6
00&FORMAT=image/jpeg&SERVICENAME=Nationalpark&
W
Second zoom of map image as GIF
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&HEIGHT=6
00&FORMAT=image/gif&SERVICENAME=Nationalpark&
For the NP_Vegetation ArcMap Image Service were the following requests accomplished.
map image with name as PNG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=1,0&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORM
AT=image/png&SERVICENAME=NP_Vegetation&
X
First zoom of map image as JPEG
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=1,0&STYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=900&HEIGHT=600&FORM
AT=image/jpeg&SERVICENAME=NP_Vegetation&
Second zoom of map image as GIF
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYE
RS=1,0&STYLES=&SRS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&HEIGHT=600&FORM
AT=image/gif&SERVICENAME=NP_Vegetation&
Y
APPENDIX F - Web Application Stress Test Settings
1.Get Map
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.1&REQUEST=
GetMap&LAYERS=2,3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,45661
23,5923475&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&SERVICENAME=Nationalpark&
2.GetMap
http://esg1136/wmsconnector/com.esri.wms.Esrimap?SERVICE=WMS&VERSION=1.1.1&REQUEST=
GetMap&LAYERS=Seen,Ortschaften,Nationalparkgrenze,Strassen,Radwanderwege,Bahnhof,Zeltplatz&
STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT
=600&FORMAT=image/png&&SERVICENAME=Nationalpark&
3.GetMap
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.1.1&REQUEST=Map&LAYERS=2,
3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=
900&HEIGHT=600&FORMAT=image/jpeg&SERVICENAME=Nationalpark&
4.GetMap
http://esg1136/wmsconnector/com.esri.wms.Esrimap?WMTVER=1.1.1&REQUEST=Map&LAYERS=2,
3,1,8,4,10,11&STYLES=&SRS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=
900&HEIGHT=600&FORMAT=image/jpeg&SERVICENAME=Nationalpark&
top related