centre for geo-information thesis report girs-2006-02

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




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


SERVICE = WMS R Service type

REQUEST = GetCapabilities R Request name

UPDATESEQUENCE = string O Sequence number or string for cache control


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)



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).



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



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:


<Service>

<Name>OGC:WMS</Name>


<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>


</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:


<Capability>

<Request>

<Map>

<DCPType>

<HTTP>

<Get onlineResource="http://esg1136:80/wmsconnector/com.esri.wms.Esrimap

/Nationalpark?" />

</HTTP>

</DCPType>

</Map>

<Capabilities>

<DCPType>

<HTTP>


/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>


/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:


<Capability>

<Request>

<GetCapabilities>

<Format>application/vnd.ogc.wms_xml</Format>

<DCPType>

<HTTP>

<Get>




</Get>

</HTTP>

</DCPType>

</GetCapabilities>

<GetMap>

<Format>image/png</Format>

<Format>image/jpeg</Format>

<DCPType>

<HTTP>

<Get>




</Get>

</HTTP>

</DCPType>

</GetMap>

38

<GetFeatureInfo>


<Format>text/xml</Format>

<Format>text/html</Format>

<Format>text/plain</Format>

<DCPType>

<HTTP>

<Get>




</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:


<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.


<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>


<Name>5</Name>

<Title>Mueritzrundweg</Title>


</Layer>


<Name>10</Name>

<Title>Bahnhof</Title>


</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).


<Capability>

<Layer queryable="0" opaque="0" noSubsets="0">




<Layer queryable="1"(>) opaque="0" noSubsets="0">

<Name>0</Name>




41

<ScaleHint min="NaN" max="9999999" />

</Layer>


<Name>5</Name>




<ScaleHint min="0" max="NaN" />

</Layer>


<Name>10</Name>





</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


Request - GetFeatureInfo Format


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&


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).


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)


- <WMT_MS_Capabilities version="1.0.0">

- <Service>

<Name>WMS</Name>



<Keywords>ArcIMS</Keywords>

<OnlineResource />

<Fees>none</Fees>


</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>


</HTTP>

</DCPType>

</Capabilities>

- <FeatureInfo>

- <Format>

<XML />

<MIME />

E

</Format>

- <DCPType>

- <HTTP>


</HTTP>

</DCPType>

</FeatureInfo>

</Request>

- <Exception>

- <Format>

<WMS_XML />

<INIMAGE />

<BLANK />

</Format>

</Exception>

- <Layer>



- <Layer queryable="1">

<Name>0</Name>



</Layer>


<Name>1</Name>

<Title>Nationalparkgrenze</Title>


</Layer>


<Name>2</Name>

<Title>Seen</Title>


</Layer>


<Name>3</Name>

<Title>Ortschaften</Title>


</Layer>


<Name>5</Name>



F

</Layer>


<Name>6</Name>

<Title>Naturerlebnispfad</Title>


</Layer>


<Name>4</Name>

<Title>Radwanderwege</Title>


</Layer>


<Name>7</Name>

<Title>Mueritz-Nationalpark-Rundweg</Title>


</Layer>


<Name>8</Name>

<Title>Strassen</Title>


</Layer>


<Name>9</Name>

<Title>Bahnlinie</Title>


</Layer>


<Name>10</Name>



</Layer>


<Name>11</Name>

<Title>Zeltplatz</Title>


</Layer>

</Layer>

</Capability>

</WMT_MS_Capabilities>

G

APPENDIX C - Capabilities.1.1.0.xml (Nationalpark)



- <Service>




- <KeywordList>

<Keyword>ArcIMS</Keyword>

</KeywordList>




- <ContactInformation>

- <ContactPersonPrimary>

<ContactPerson />

<ContactOrganization />

</ContactPersonPrimary>

<ContactPosition />

- <ContactAddress>

<AddressType>postal</AddressType>

<Address />

<City />

<StateOrProvince />

<PostCode />

<Country />

</ContactAddress>

<ContactVoiceTelephone />

<ContactFacsimileTelephone />

<ContactElectronicMailAddress />


<Fees>none</Fees>


</Service>

- <Capability>

- <Request>

- <GetCapabilities>


- <DCPType>

- <HTTP>

H

- <Get>




</Get>

</HTTP>

</DCPType>

</GetCapabilities>

- <GetMap>



- <DCPType>

- <HTTP>

- <Get>




</Get>

</HTTP>

</DCPType>

</GetMap>

- <GetFeatureInfo>





- <DCPType>

- <HTTP>

- <Get>




</Get>

</HTTP>

</DCPType>

</GetFeatureInfo>

</Request>

- <Exception>




</Exception>

- <Layer queryable="0" opaque="0" noSubsets="0">

I





<Name>0</Name>





</Layer>


<Name>1</Name>




</Layer>


<Name>2</Name>

<Title>Seen</Title>




</Layer>


<Name>3</Name>




</Layer>


<Name>5</Name>





</Layer>


<Name>6</Name>





J

</Layer>


<Name>4</Name>





</Layer>


<Name>7</Name>





</Layer>


<Name>8</Name>





</Layer>


<Name>9</Name>





</Layer>


<Name>10</Name>





</Layer>


<Name>11</Name>





K

</Layer>

</Layer>

</Capability>


L

APPENDIX D - Capabilities.1.1.1.xml (Nationalpark)


<!DOCTYPE WMT_MS_Capabilities (View Source for full doctype...)>


- <Service>



<Abstract>ArcIMS 9.1.0Nationalpark Web Map Service</Abstract>

- <KeywordList>

<Keyword>ArcIMS</Keyword>

</KeywordList>




- <ContactInformation>

- <ContactPersonPrimary>

<ContactPerson />

<ContactOrganization />

</ContactPersonPrimary>

<ContactPosition />

- <ContactAddress>

<AddressType>postal</AddressType>

<Address />

<City />

<StateOrProvince />

<PostCode />

<Country />

</ContactAddress>

<ContactVoiceTelephone />

<ContactFacsimileTelephone />

<ContactElectronicMailAddress />


<Fees>none</Fees>


</Service>

- <Capability>

- <Request>

- <GetCapabilities>


M

- <DCPType>

- <HTTP>

- <Get>




</Get>

</HTTP>

</DCPType>

</GetCapabilities>

- <GetMap>



- <DCPType>

- <HTTP>

- <Get>




</Get>

</HTTP>

</DCPType>

</GetMap>

- <GetFeatureInfo>





- <DCPType>

- <HTTP>

- <Get>




</Get>

</HTTP>

</DCPType>

</GetFeatureInfo>

</Request>

- <Exception>




N

</Exception>






<Name>0</Name>





</Layer>


<Name>1</Name>




</Layer>


<Name>2</Name>

<Title>Seen</Title>




</Layer>


<Name>3</Name>




</Layer>


<Name>5</Name>





</Layer>


<Name>6</Name>



O



</Layer>


<Name>4</Name>





</Layer>


<Name>7</Name>





</Layer>


<Name>8</Name>





</Layer>


<Name>9</Name>





</Layer>


<Name>10</Name>





</Layer>


<Name>11</Name>



P



</Layer>

</Layer>

</Capability>


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




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



/jpeg&SERVICENAME=Nationalpark&

Second zoom of map image as GIF



/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&



RS=EPSG:NONE&BBOX=4558965,5918732,4566123,5923475&WIDTH=900&HEIGHT=600&FORMAT=image/jpeg&SER


T



RS=EPSG:NONE&BBOX=4562987,5920876,4564602,5922637&WIDTH=900&HEIGHT=600&FORMAT=image/gif&SER


WMS 1.1.0

For the Nationalpark ArcIMS Image Service were the following requests accomplished.

Starting map image with name


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




Panned map image



00&FORMAT=image/png&SERVICENAME=Nationalpark&

V

map image with title as PNG


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&




00&FORMAT=image/jpeg&SERVICENAME=Nationalpark&

W




00&FORMAT=image/gif&SERVICENAME=Nationalpark&

For the NP_Vegetation ArcMap Image Service were the following requests accomplished.

map image with name as PNG


RS=1,0&STYLES=&SRS=EPSG:NONE&BBOX=4543594,5904292,4589152,5934759&WIDTH=900&HEIGHT=600&FORM

AT=image/png&SERVICENAME=NP_Vegetation&

X




AT=image/jpeg&SERVICENAME=NP_Vegetation&




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&

centre for geo-information thesis report girs-2006-02

Documents