%Der Hauptteil der Arbeit
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\chapter{Introduction}
The use of web-based maps has seen a tremendous increase over the last few years. In 1999 approximately 40 million maps per day were accessed over the Internet. Two years later this number had increased to 200 million maps per day, and it is reasonable to expect that this number has multiplied several times since then. This development also shows the growing significance of the presentation of spatial information on the Internet \texorhtml{\citep}{\cite}{peterson2003,dickmann2004}.

The release of \textit{Google Maps} in February 2005 caused a sensation in the web mapping industry. \textit{Google Maps} presented a novel web-based mapping application which garnered the world's attention with its high speed and high degree of interactive mapping capability, as well as features including high-resolution satellite images and an attractive map design \texorhtml{\citep}{\cite}{ramsey2006}.
\textit{Google Maps} was able to revolutionize the usability of web mapping applications through its implementation of a pure, client-side JavaScript - an aspect which until then had been neglected by many existing applications even though usability clearly influences user satisfaction and greatly contributes to the success of an application.

A search of existing literature shows very little research focusing on the usability of web mapping applications. Analyses or empirical research on the usability of web mapping applications have not been published to date.\\ This thesis will examine the usability of web mapping applications by using the term 
\textit{Smart Map Browsing} as an indicator of usability.  This expression does not exist in current literature and will therefore be developed and further defined as part of the work presented herein, more specifically in Chapter~\ref{smartmapbrowsing}.  As a result, this thesis intends to contribute to the further technical development of the usability of web mapping applications.





\newpage
\section{Objectives}
The section below outlines the research objectives formulated at the start of this thesis. 

One objective of this thesis is to investigate the current state of client-side web mapping technology, with an emphasis on the different \textit{Smart Map Browsing} characteristics of free Internet map applications.  The term  \textit{Smart Map Browsing} will be defined as a result of this investigation.  

For the practical part of this thesis, a \textit{Smart Map Browsing} feature will be selected and applied to pure JavaScript web mapping applications.  The objective of this extension is to increase the usability of such applications in web browsers. It is also hoped that a resulting solution will be widely applicable so that it can be easily integrated into existing free web mapping applications.



\section{Thesis Outline}
\begin{description}
    \item[Chapter 2 (Background)] gives an overview of the main background materials for this thesis.  It will present and discuss terms such as \textit{Free
        Software}, \textit{Usability}, \textit{WebMapping} and \textit{Open Geospatial Consortium}, and explain the basic principles of \textit{Web Map Services}.
    \item[Chapter 3 (Analysis)] commences with a current state analysis of selected web mapping applications. The results of this analysis are used to assist in defining the term \textit{Smart Map Browsing}. This will be followed by a requirements analysis for the \textit{animated zooming} feature. The chapter concludes with a technical analysis of \textit{OpenLayers}.
    \item[Chapter 4 (Concept)] provides the concept behind the implementation of the planned \textit{OpenLayers} extension. It will discuss the technical details as well as the development guidelines of the \textit{OpenLayers} project, all of which are important criteria to consider for the implementation process.
    \item[Chapter 5 (Implementation)] illustrates the steps required for the implementation of the \textit{animated zooming} features, as well as the testing procedure and potential difficulties.   
    \item[Chapter 6 (Conclusion)] summarizes the results of this thesis, discusses some of the open issues and concludes with a look to the future.\\

    \item[Appendix A (Current State Analysis)] contains the detailed results of the analysis conducted on the twelve web mapping applications from Chapter 3.
    \item[Appendix B (Classification Diagram)] shows a complete classification diagram of \textit{OpenLayers}. All functions and classifications which were changed during the implementation process are highlighted.
    \item[Appendix C (Test Plan)] comprises the test plan for the integration testing done in Chapter 5.
    \item[Appendix F (CD-ROM)] is comprised of a CD-ROM which contains the \textit{animated zooming} and \textit{panning} extension, integrated into         \textit{OpenLayers}, Version 2.4 RC5 (as of May 25, 2007).
               
\end{description}








%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%   *** GRUNDLAGEN ***
%   #2
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Background}
This chapter discusses relevant background material required for a proper understanding of this thesis. 

\section{Free Software}
\T\enlargethispage{1\baselineskip}
\subsection{Term}
\label{freeSoftware}
The word 'free' in the term \textit{Free Software (FS)} is not related to the concept of monetary value ie. price, but derives its meaning from the idea of >>freedom<<.

Seen as thus, the term \textit{Free Software} is defined by the following four freedoms \texorhtml{\citep}{\cite}{FSFE}:
\begin{enumerate}
    \item The freedom to run the program, for any purpose.
    \item The freedom to study how the program works, and adapt it to your needs.
    \item The freedom to redistribute copies so you can help your neighbor.
    \item The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.
\end{enumerate}
A program is defined as Free Software only when it provides the user with these four freedoms, otherwise it is defined as not free or proprietary.  In this thesis, the use of the word >>Free<< in capital letters denotes software with the above-mentioned four characteristics ie. freedoms.  

In 1985 Richard Stallman founded the \textit{Free Software Foundation
(FSF)} with the goal of advancing the concept of Free Software \texorhtml{\citep}{\cite}{grassmuck2004}.
Free Software does not prohibit the commercial use of programs (as per Freedom 1). Actually, a market study conducted by the EU Commission in 2007 showed the economic significance of business models based on Free Software ie. Open Source \texorhtml{\citep}{\cite}{heise}:

\begin{quote}
    >>\textit{EU researchers predict that open-source related services will comprise 32 percent of IT services in 2010. Furthermore, the contribution of the open-source sector to the GDP could reach 4 percent by that year. Currently, the total IT infrastructure share of the European GDP is at 10 percent.}<<
\end{quote}



\subsection{Free Software versus Open Source}
Free Software is not the same as \textit{Open
Source}.

Background: The term \textit{Free Software} is often misinterpreted because >>Free<< is understood in terms of price, not freedom (as per the FSF definition). 
This confusion was \textit{one} of the reasons why the \textit{Open Source Initiative
(OSI)}\footnote{\url{http://www.opensource.org} \checkURL} started to use the term \textit{Open Source} instead (1998). The main objective of this marketing campaign was to promote the commercialization and acceptance of Free software in the business sector. This development also resulted in a move away from focusing on the philosophical and ethical ideas behind Free software, and instead only emphasized the technical advantages of open source. \texorhtml{\citep}{\cite}{FSFE}. Seen this way, Open Source refers only to open source access, which is a decidedly weaker criteria compared to the concepts underlying Free Software \texorhtml{\citep}{\cite}{GNU_os}.

\subsection{Licensing Categories}
\T\enlargethispage{\baselineskip}
Software licenses outline a user's rights to using a software. A Free software license is one which expressly bestows upon the user the four freedoms outlined in Section 2.1.1. They are however just as binding as licenses for proprietary software. 

The licensing conditions apply when a software is distributed (with or without changes).
Figure~\ref{img:fskategorien} classifies a number of Free software licenses (based on their strength of protection) into four categories \texorhtml{\citep}{\cite}{reiter2004}:


    \begin{enumerate}
        \item \textit{Strong Protection}\\
            e.g. GNU General Public License (GPL): A license who modifies a GNU
            GPL software agrees to distribute it under the same licensing 
            conditions along with the corresponding source code.
        \item \textit{Weak Protection}\\
            e.g. GNU Lesser General Public License (LGPL): GNU LGPL
            The software can be used in proprietary software, however the GNU
            LPGL source code must remain free.            
        \item \textit{No Protection}\\
            e.g. X11 (modified BSD): The software can be distributed without 
            preserving the source code or Free Software freedoms; furthermore
            it can be used in proprietary software.
        \item \textit{GPL Non-Compatible or Imbalanced}\\
            Includes all other Free Software licenses, ie. do not fit criteria
            outlined in (1) to (3); e.g. Netscape Public License
    \end{enumerate}

\begin{figure}[htbp] \begin{center}
    \T\includegraphics[width=8cm]{images/fs-kategorien_en.ps}
    \W\htmlimage{images/fs-kategorien_en.png}
    \caption{FS Licensing Categories (as per \texorhtml{\citep}{\cite}{reiter2004})}
    \label{img:fskategorien} \end{center} \end{figure}


Software with numerous different licenses under (1) to (3) are protected by the strongest license \texorhtml{\citep}{\cite}{reiter2004}.  Free Software licenses with protection are also referred to as \textit{Copyleft}. Copyleft means that anyone distributing software (with or without modifications) confers to other users the right to further distribute or modify the softwre. Copyleft therefore guarantees this right for all users.
The GNU project describes and compares the difference between Copyleft and Copyright in the following terms \texorhtml{\citep}{\cite}{GNU_copyleft}:

\begin{quote}
    \frz{\textit{Developers of proprietary software use copyrights to limit the freedom of users whereas we guarantee it. As a result, we have changed the name 'Copyright' into 'Copyleft' to illustrate this difference.}}
\end{quote}


\newpage

\section{Usability}
\subsection{Terms}
\label{usability_begriffe}

The German language contains a number of words which are used synonymously with the term \textit{Usability}, such as: Bedienbarkeit, Bedienerfreundlichkeit, Benutzbarkeit, Benutzerfreundlichkeit, Ergonomie, Gebrauchstauglichkeit,
Handhabbarkeit, Nutzungsqualität, Software-Ergonomie, User
Experience etc.  However, the term \textit{Gebrauchstauglichkeit} has established itself as the widely accepted translation of the term \textit{Usability}.
In this sense, the word \frz{Gebrauch} refers to the context in which a product is used. In contrast to some of the above-mentioned terms (e.g. \textit{Benutzerfreundlichkeit}) this term takes into account not only the user, but also the task to be completed.  If the product does not support the user in completing a task, it is considered ineffective 
\texorhtml{\citep}{\cite}{fit_begriffe,usability_da}.

The term \textit{Usability} was initially defined in 1998 as part of the international standard ISO 9241-11; one year later it was translated into German \texorhtml{\citep}{\cite}{fit_begriffe}:
    
\begin{description}
\item[English: \frz{Usability}] (ISO 9241-11:1998)
\begin{quote}
    \textit{\frz{Extent to which a
    product can be used by specified users to achieve specified goals
    with effectiveness, efficiency and satisfaction in a specified
    context of use.}}
\end{quote}

\item[German: \frz{Gebrauchstauglichkeit}] (DIN EN ISO 9241-11:1999;
    German Translation)
    \begin{quote} \textit{\frz{Das Ausmaß
    in dem ein Produkt durch bestimmte Benutzer in einem bestimmten
    Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv,
    effizient und zufriedenstellend zu erreichen.}}
\end{quote}
\end{description}

Jakob Nielsen, who is considered one of the leading authorities in the software and web design usability field, describes usability as the \frz{degree of quality with which a user experiences an interaction} \texorhtml{\citep}{\cite}{usabilityhandbuch}.

In this thesis the term \textit{Usability} will be used synonymously with the German terms \textit{Gebrauchstauglichkeit} and 
\textit{Benutzbarkeit}.

\newpage
\subsection{Measurability}
\label{usability_messbarkeit}
The usability of a product can be measured using the ISO attributes of Effectiveness, Efficiency and Satisfaction. At the same time, these characteristics are unlikely to serve as a consistent standard as their significance will greatly depend on the user context and ultimate use objective.
As a result usability should always be viewed in the context of its objectives. \texorhtml{\citep}{\cite}{usability_da}.  Given a user's different needs along with his/her subjective impressions, a purely objective assessment of usability is almost impossible.

Jakob Nielsen divides the concept of usability into five measurable factors, and also illustrates the diverse nature of the term usability with an interactive application system \texorhtml{\citep}{\cite}{usability_da, trends_in_webmapping}:

\begin{itemize}
    \item \textbf{Learnability:}
        The user should be able to learn the system easily in order to complete   
        his/her tasks.
    \item \textbf{Efficiency:} 
        The user should be able to perform tasks quickly, thereby increasing productivity.
    \item \textbf{Memorability:} 
        The user should be able to quickly re-establish proficiency in the operation of the system after a (prolonged) absence.
    \item \textbf{Errors:} 
        The system should enable the user to have a very low error rate.
    \item \textbf{Satisfaction:} 
        The operation of the system should be pleasant for the user.
\end{itemize}

Along these lines usability is seen as a measure of the quality of user-system interaction. It greatly influences the user's acceptance and accordingly, the success of a system. 


\newpage
\T\enlargethispage{3\baselineskip}
\section{Web Mapping}

\subsection{Terms}
\label{webmapping_begriffe}
There are a number of terms which describe the electronic illustration of maps on the Internet - among the more commonly used are: \textit{Internet Map},
\textit{Web Map}, \textit{net-based e-map}, \textit{Cyber Map} etc. 

Jens Fitzke also defined three general terms to be used for these types of maps~\texorhtml{\citep}{\cite}{fitzke1999}:\\
\textit{GIS online} is used as a collective term for all types of GIS applications which are available through a network.
\textit{Internet-GIS} narrows this focus to network technology based on specific protocols.
In most cases the term can be even further defined by assuming the existence of a specific client (the web browser), leading to the term \textit{WebGIS}.

On the other hand, Frank Dickmann uses the terms \textit{WebMapping} und
\textit{WebGIS} to classify the electronic illustration of maps on the Internet. \\
\textit{Web Mapping} is derived from the term \textit{Web Map} although it is more strongly associated with the map production process. \textit{Web Mapping} includes not only the visual presentation of maps on the Internet, but also simple viewing features such as Zooming, Panning as well as Layering.  However, these features are not yet considered \frz{GIS adequate}~\texorhtml{\citep}{\cite}{dickmann2004}.\\
The term \textit{WebGIS} is used to indicate a user's ability to modify attributes beyond the usual \textit{Web Mapping} functions, as well as to perform additional GIS operations (such as keyword searches, search functions, area and distance measurements).

However, since basic GIS analysis functions such as attribute searches are also associated with \textit{Web Mapping}, it becomes clear that a clear demarcation line between \textit{Web Mapping} and
\textit{WebGIS} does not exist \texorhtml{\citep}{\cite}{dickmann2004}.

This thesis will use the term \textit{Web Mapping} as described by Frank Dickmann, which also includes the simple analytical functions found in a GIS system.



\subsection{Classification}
Web mapping applications are classified into \textit{static} and \textit{interactive} maps, depending on their degree of interactivity \texorhtml{\citep}{\cite}{mitchell2005}.

\textit{Static maps} or \textit{view-only maps} are ready-made maps which are integrated into the website as a stand-alone picture.\\
In the early stages of web mapping development paper copies of maps were scanned and subsequently shown on the Internet in bitmap format.

This resulted in a considerable on-line collection of static maps, which is still widely in use today \texorhtml{\citep}{\cite}{dickmann2004, mitchell2005}.

The introduction of interactive maps provided users with the option to adjust map sections to suit their individual needs, as well as to obtain additional information by panning images, zooming in, activating other map layers or requesting map-related information. At each change the map section is redrawn and displayed with the new information \texorhtml{\citep}{\cite}{dickmann2004}.

From a technical view the distinction between static and interactive mapping illustrations is not an easy one to make. For example, a map which has been altered by \textit{panning} and/or \textit{zooming} would still be considered a static map
\texorhtml{\citep}{\cite}{dickmann2004} if the zooming function merely changed the scale of the map without revealing any new detail ie. information. 

\T\enlargethispage{3\baselineskip}
\subsection{Architecture}
The client-side server model forms the basis of Web Mapping and WebGIS applications, whereby a web browser becomes the client communicating with the web server. Figure~\ref{img:clientServer} illustrates this process:
The client requests a map by sending an inquiry to the web server. The web server directs the inquiry to the map server which evaluates the inquiry, searches for the relevant geographical data and generates the corresponding map.  The map is then sent to the web server, where it is integrated into a HTML page and sent back to the client browser \texorhtml{\citep}{\cite}{klauer2002,mitchell2005}.

\begin{figure}[htbp] \begin{center} \begin{Label}{img:clientServer}
    \T\includegraphics[width=13cm]{images/webMappingArchitecture.eps}
    \W\htmlimage{images/webMappingArchitecture.png}
    \caption{Client-Server Architecture (as per \texorhtml{\citep}{\cite}{mitchell2005})}
\end{Label} \end{center} \end{figure}


\newpage
\subsubsection*{Client Technology}
On the client side, the existence of a web browser is the only prerequisite for using a web mapping application. A standard browser will usually be able to illustrate raster data in GIF, JPG and PNG format.\\ 

However, vector data ara not yet supported by all browsers. One example is Mozilla
Firefox\footnote{\url{http://www.mozilla-europe.org} \checkURL} (Version 2.0) which supports the SVG 1.1 specification\footnote{\url{http://www.w3.org/TR/SVG11} \checkURL}.  Because this type of SVG standard is not yet widely supported by web browsers, vector data does not figure significantly in current web mapping applications. The topic of web mapping in conjunction with vector data will not be discussed in further detail at this point, as it is not relevant to the work presented herein (see \texorhtml{\citep}{\cite}{svgWebMapping_kunze, svgWebMapping_langfeld} for more information).


\subsubsection*{Server Technology}
On the server side, a web server (e.g. 
\textit{Apache}\footnote{\url{http://www.apache.org} \checkURL}) along with a specific map server is required, whereby the latter does not have to be installed on the same computer (same applies to the geodata base) \texorhtml{\citep}{\cite}{klauer2002}.
The \textit{UMN MapServer}\footnote{\url{http://mapserver.gis.umn.edu} 
\checkURL} is a free and very popular map server which communicates with the web server via a \textit{Common Gateway Interface (CGI)}. Many web mapping applications are based on the \textit{UMN MapServer} (see Chapter~\ref{bestandsaufnahme}). Two other significant map servers are \textit{Geoserver}\footnote{\url{http://docs.codehaus.org/display/GEOS/Home}
\checkURL} and \textit{deegree}\footnote{\url{http://deegree.org}
\checkURL}.\\



\subsection{Characteristics}
What are the main characteristics of a web mapping application? This section provides a \textit{general} introduction to the main components and interactive potentials of a web mapping application.  Section 3.1 provides a detailed analysis of selected web mapping applications. 

\subsubsection*{Components}
Generally speaking, the user interface of web mapping applications consists of the following components (Figure~\ref{img:webmappingComponents} shows several of these using the example of \textit{OpenLayers}):

\newpage
\T\enlargethispage{3\baselineskip}
\begin{itemize}
    \item \textit{Main Map}\\
        The basic component of every application. It contains one or more layered raster or vector graphics as well as additional components placed into the map.
    \item \textit{Overview Map}\\
        Displays the main map (usually showing the full geographic dimensions) in the form of a smaller navigable reference map and highlights the current view portion of the main map. The purpose of this map is to assist the user's orientation, allowing for a good overview of the maps at hand.
    \item \textit{Pan/Zoom Bar}\\
        Includes panning arrows as well as a zoom tool with a slider for changing zoom levels.
    \item \textit{Layer Overview}\\
        Lists all available map layers along with an option to turn layers on or off.
    \item \textit{Toolbar}\\
        Contains buttons and menu options for activating various (GIS) functions 
        (e.g. Navigation, Analysis, Queries and Printing).
    \item \textit{Scale Bar}\\
        Shows the current scale in form of a bar, description field or check box.
    \item \textit{Legend}\\
        Explains the colors and symbols used in the map, often in conjunction with the layer overview. 
\end{itemize}
\begin{figure}[htbp] \begin{center}\begin{Label}{img:webmappingComponents}
    \T\includegraphics[width=13cm]{images/webMappingComponents_en.eps}
    \W\htmlimage{images/webMappingComponents_en.png}
    \caption{Components of Web Mapping Application \textit{OpenLayers}}
\end{Label} \end{center} \end{figure}

\newpage
\subsubsection*{Interaction Possibilities}
With the growth of the Internet and the growing popularity of web mapping applications the concept of interactivity has become a fundamental component in the development and usability of mapping applications \texorhtml{\citep}{\cite}{kn2007}.

Critical to this development is the ability to navigate around a map, allowing the user to adjust the map by using Drag\&Drop per mouse click. By clicking on the panning arrows the map can also be panned in predefined increments.\\

Changing the zoom level of a map can be done in a variety of ways: clicking on the + or -- button, double-clicking on the map, using the mouse to open a zoom box, moving of zoom slider or mouse wheel.\\

Some web mapping applications also offer panning and zoom navigation options using the keyboard (see Chapter \ref{bestandsaufnahme}).

Often the user can also change the view of the currently selected map portion in the overview map (by mouse click or Drag\&Drop), which will also change the main map accordingly. In the same vein, the overview map is updated along with changes made to the main map.

In the layer overview, interactivity includes the ability to turn layers on and off by means of check boxes or buttons, and to combine layers into one main layer.

Toolbar functions represent varying degrees of interactivity, including the already mentioned pan/zoom functions as well as options related to printing, querying, object selection, distance measurements and getting directions.

Two additional interactive features in web mapping applications are represented by cursors showing the current ground location, and individually adjusted map sizing. Some web mapping applications also offer users the ability to make queries about geographically referenced objects or obtain more information on other items, thereby creating a highly interactive environment.

All of the above-mentioned features contribute to the interactive nature of a web mapping application. The increasing trend towards Web 2.0 and AJAX has also resulted in noticeable interactivity improvements in the web mapping area. One of the highlights in this area is the asynchroneous data transfer through the \textit{XMLHttpRequest} object, as it allows websites to be refreshed in the background instead of having to be re-loaded after every modification.  Because of this technology, a web mapping application is able to execute a user's command in a fairly short time period, as the necessary steps can be completed in the background. As a result, the usability of interactive web mapping applications is approaching the features of classic Desktop(GIS) applications 
\texorhtml{\citep}{\cite}{dickmann2001,svgWebMapping_kunze}. 



\subsection{Tiling}
\label{webmapping_tiling}
Tiling is a fairly new development - it involves the division of maps into smaller tiles in order to increase the usability of web mapping applications.

The following section provides a general discussion of the tiling method, using Figure \ref{img:tiling}
 \texorhtml{\citep}{\cite}{svgWebMapping_langfeld,svgWebMapping_kunze}:

In order to create an optimum web mapping environment (ie. not burdening the application with extraneous data), the application's maps are initially divided into tiles
(a). In effect, each tile is a small map on its own, however, in combination with the other tiles it forms one complete map and is not visually distinguishable as a separate unit. Once a specific map area is selected (b), all tiles which are completely or partially visible in this area must be loaded (c). In addition, all tiles which border the selected area but are not visible are also loaded (d). If the user moves or adjusts the map, the tiles loaded in (d) are now shown without delay.  At the same time, all remaining tiles which now border the new selected area (but are not yet visible) are also loaded for future use, while the tiles no longer bordering on the new area are removed.


\begin{figure}[htb] \begin{center} \begin{Label}{img:tiling}
			\T\includegraphics[width=9cm]{images/tiling_en.eps}
            \W\htmlimage{images/tiling_en.png}
			\caption{Determination of Tiles to be Loaded (as per \texorhtml{\citep}{\cite}{svgWebMapping_langfeld,svgWebMapping_kunze})}
            \end{Label} \end{center} \end{figure}
			
Tiling can be done in two ways: client-side or server-side. In client-side tiling the web mapping client defines the tiling boundaries and requests each tile from the map server.  In server-side tiling the server divides the map into smaller tiles and sends these to the web browser which then displays the data on the computer.

Generally the web mapping application performs a client-side management of the loaded tiles, whereby the tiles are stored in a DOM tree that represents the current HTML website.  As soon as the selected map area is changed, the program calculates the new tiling arrangements, removes the now extraneous tiles and adds the tiles required for the new selection.

Even though this \frz{tile preloading process} involves a higher amount of data transfer, it significantly increases the speed of web mapping operations, particularly the navigation within maps (\textit{Map Browsing}).

Each zoom level has its own \frz{tile grid}, with uniform tile sizes for each zoom level (usually 256 pixels). During a zoom-in function the height and width of each tile are doubled, \mbox{that is}, each tile is divided into four new tiles, each containing more detailed information.  During zoom-out the process is reversed: four tiles are combined into one tile.


\section{Open Geospatial Consortium}
\label{OGC}

The \textit{Open Geospatial Consortium
(OGC)}\footnote{\url{http://www.opengeospatial.org} \checkURL} was formed out of the \textit{Open GRASS Foundation (OGF)} in 1994 (known as \textit{OpenGIS Consortium until 2004}).  It is an international non-profit industry association consisting of businesses, government organizations and universities with a current (May 2007) membership base of over 340 members \texorhtml{\citep}{\cite}{OGC,joos2003}. 

The OGC's objective is to define open standards in the form of interfaces and protocols for standard access to spatial information, as well as to provide public access to these specifications for the purpose of interoperability \texorhtml{\citep}{\cite}{pichlerKlopfer2005}. All specifications are arrived at by consensus \texorhtml{\citep}{\cite}{joos2003}. \textit{OpenGIS\texorhtml{\textsuperscript{\textregistered}}{\htmlsym{reg}}}
is the registered trademark of the Open Geospatial Consortium
\texorhtml{\citep}{\cite}{OGC}.

Products and services conforming to OGC specifications allow for a smooth exchange and/or use of spatially referenced data between different systems. This interoperability, even within competing applications, also enables users to select an application that best suits their needs and requirements
\texorhtml{\citep}{\cite}{pichlerKlopfer2005}.


\newpage
\T\enlargethispage{3\baselineskip}
\section{Web Map Service}

\textit{Web Service} is a service available over the Internet, which uses a standardized XML-based messaging system.  Web Services are integral to the interoperability of software applications, that is to say, Web Services support the exchange of otherwise independent web applications by way of a standardized interface. Web Services operate independent of existing programming languages and operating systems \texorhtml{\citep}{\cite}{mitchell2005}.

Web Services are becoming very popular in web mapping applications, where they have been described as the \frz{future of web mapping} \texorhtml{\citep}{\cite}{mitchell2005}.
The so-called \textit{Web Map Services (WMS)} allow for a smooth integration of different (raster or vector) maps in web mapping applications over the Internet. In this process, the role of displaying the map is performed by a  
\textit{Web Map Server} (WMS Server) \texorhtml{\citep}{\cite}{wms2005}.\\


\subsection{Web Map Client}
A \textit{Web Map Client} is the system which integrates the WMS, either server-side (e.g. in a map server) or client-side (e.g. in a web mapping application).

In a \textbf{server-side} WMS integration individual Web Map Services are cascaded, ie. several Web Map Services are integrated into one. The resulting linkages (or chain) act as a single WMS, ie. the chain is not visible to the user. The disadvantage of this arrangment is that the speed of map display in the browser will be determined by the slowest WMS in the chain. Another problem area: if one WMS in the chain is disabled, the web map client does not receive a response and the map area remains empty \texorhtml{\citep}{\cite}{wms2005}.  Here the map server takes on the role of the web map client.

During a \textbf{client-side} WMS integration the web mapping application requests the maps directly from the web map server and then displays these in the browser. When using several Web Map Services, each WMS can be displayed as a layer in the application. In this case the browser, ie. the web mapping application, acts as the web map client.

If only external Web Map Servers are used, the web mapping application does not really require its \frz{own} map server since the extensive map generation process is shifted to the WMS server. Still, quite a few (Free) web mapping applications are designed to include their own map server (more on this in Chapter~\ref{bestandsaufnahme}).


\newpage
\subsection{OGC conforming WMS}
When a Web Map Service fulfills the WMS specifications\footnote{\url{http://www.opengeospatial.org/standards/wms}
\checkURL}  of the OGC, it is referred to as a OGC conforming WMS. This means that requests to and responses from the WMS must be done according to a specific standard. The following three queries fall under current OGC specifications (with the third being optional)\texorhtml{\citep}{\cite}{wms2005,simonisMerten2004}:
\begin{enumerate}
    \item \textit{GetCapabilities}\\
        queries the WMS' capabilities.
    \item \textit{GetMap}\\
        requests a specific map.
    \item \textit{GetFeatureInfo}\\
        requests information on individual map objects.
\end{enumerate}

\T\enlargethispage{3\baselineskip}
Figure \ref{img:webServicesArchitectur} illustrates the relationships between some OGC web services, as well as the main operators (as defined by the OGC web services).

\begin{figure}[htbp] \begin{center} \begin{Label}{img:webServicesArchitectur}
    \T\includegraphics[width=14cm]{images/OGCwebservices.eps}
    \W\htmlimage{images/OGCwebservices.png}
    \caption{OGC Web Services Architecture 
        (as per \texorhtml{\citep}{\cite}{OGC_webservices})}
    \end{Label} \end{center} \end{figure}










%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%   *** ANALYSE ***
%   #3
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



\chapter{Analysis}

This chapter begins with a current state analysis of the usability features in Free web mapping applications. Based on the results of this analysis, the term  \textit{Smart Map Browsing} will be defined and its characteristics and potential will be derived. A selected feature will be the subject of a requirements analysis which forms the basis for a subsequent implementation. The web mapping application chosen for this process will be analyzed in more detail towards the end of this chapter.


\section{Current State Analysis}
\label{bestandsaufnahme}

\subsection{Objective}
The objective of this analysis is to provide a general overview of the main Free web mapping applications and to discern specific user-friendly navigation features. Based on the results of the overview it should be possible to derive the characteristics and potential of \textit{Smart Map Browsing}.

\subsection{Method}
\subsubsection*{Criteria}
Before conducting the analysis, standardized criteria are defined and divided into the following eight categories:

\begin{enumerate}
    \item \textit{General}\\
        name, URLs (home, documentation, download, live demo), 
        current version, last update, license,
        businesses/organizations (which have/had a major role in the
        development), short description 
    \item \textit{System}\\
        architecture (client-side or client-serverside), 
        programming language, \mbox{prerequisites}, supported browser;
        where applicable, integration with other Free software
    \item \textit{Community}\\
        URL of mailing lists (ML), developer and user ML's 
        (categorized by month and totals of active developers/users within a
        fixed time period), 
        revision administration, commercial support
    \item \textit{Documentation}\\
        for installation/development/operation 
        (notes/instructions, tutorials, URLs)

    \item \textit{Usability}\\
        general impression, main map, overview map, layer overview, legend,
scale bar, toolbar, zoom bar, pan navigation panel, zoom, zoom
        with double-click/mouse wheel/ zoom box, panning, zooming and panning with 
        keyboard, tiling

    \item \textit{Additional Features}\\
        analysis, search, help and print functions

    \item \textit{Notes}

    \item \textit{Screenshot}\\
        of analyzed demo
\end{enumerate}

Category 1 and 2 provide general information about the web mapping application while category 3 takes a closer look at the corresponding community and its activities. Category 4 contains instructions, brief evaluations and further information on the available documentation.
The usability analysis of the application forms the main part of the investigation (category 5). It tests and evaluates different GUI components for their usability and interactivity based on a pre-selected demo. Category 6 investigates additional interactive (GIS) functions that do not play a major role in an application's usability. Category 7 lists relevant notes and special remarks. The screenshot shown in Category 8 serves as an illustration of the demo testing.

Please note that the analysis will \textit{not} provide a complete list of features for each application. Specific technical details (for example, the support of WMS or WFS) are not relevant to this analysis and will not be investigated further. The key focus of this analysis is the usability of the application.

\newpage
\T\enlargethispage{\baselineskip}
\subsubsection*{Mailing List Analysis}
The activity of a particular FS community is reflected in its mailing lists (MLs), which are generally divided into developer and user mailing lists (Free web mapping applications).  In order to compare the activity on the lists, two numbers are used as indicators:
\begin{itemize}
    \item Average number of mails per month.
    \item Total number of developers/users who have contributed within a certain time period. Note: Developers in this context also includes individuals who express an interest in development but do not actively contribute to the development of the application.
\end{itemize}
Because ML archives are also divided by month, a six-month time period (October 2006 - March 2007) was selected for the purposes of this investigation.

For an automatic determination of the requested numbers, a script written in Python\footnote{\url{http://www.python.org} \checkURL} performs the count function (see Listing 3.1), provided that that the monthly ML archives are located (unzipped) in a separate directory and the mails from a particular month are in \textit{one} file (unformatted text format). Otherwise an automatic analysis cannot be correctly carried out. \\
In this analysis two popular types of ML archives (including their different syntax for sender information) are used: 
the very popular  
\textit{GNU
Mailman}\footnote{\url{http://www.gnu.org/software/mailman} \checkURL} archive
(zipped txt files; 
Syntax \frz{\texttt{From [name] at [domain]}}) and the ML archive of 
\textit{SourceForge}\footnote{\url{http://sourceforge.net} 
\checkURL} (HTML format; Syntax \frz{\texttt{From: [real name]
<name@do...>}}).


The script is applied to the directories containing the different archive data. Below are the main steps of this operation:
\begin{enumerate}
    \item Open file (Line 11)
    \item Find line containing string \frz{\texttt{From }} or \frz{\texttt{From: }}
(13; 23)
    \item Read sender's mail address (14-17; 24-27)
    \item Increase mail count variable (18; 28)
    \item Increase user count variable if address not available (19-20; 29-30)
    \item Repeat steps 2 - 5 for remaining file lines
    \item Analogous read-out of remaining files as per steps 1-6
    \item Final output of calculated values (34-38)\\
\end{enumerate}

\newpage
\T\lstinputlisting[caption=Python script for analysis of ML archives; \textit{MLanalyse.py},
\T label=lst:mlanalyse,language=Python]{listings/MLanalyse.py}
\W ~\\Listing: Python script for analysis of ML archives; \textit{MLanalyse.py}
\W \label{lst:mlanalyse}
\W\begin{example}
\W\input{listings/MLanalyse.py}
\W\end{example}
    
Example using analysis of developer ML of \textit{OpenLayers}:

\begin{ifhtml}
\begin{example}
2006-December.txt: 36 mails
2006-November.txt: 131 mails
2006-October.txt: 196 mails
2007-January.txt: 262 mails
2007-February.txt: 342 mails
2007-March.txt: 510 mails
---
months     : 6
mails total: 510
mails/month: 85
users total: 72 
\end{example}
\end{ifhtml}

\begin{latexonly}
\begin{lstlisting}[numbers=none,frame=none,backgroundcolor=\color{white}]
2006-December.txt: 36 mails
2006-November.txt: 131 mails
2006-October.txt: 196 mails
2007-January.txt: 262 mails
2007-February.txt: 342 mails
2007-March.txt: 510 mails
---
months     : 6
mails total: 510
mails/month: 85
users total: 72 
\end{lstlisting}
\end{latexonly}


\newpage
\subsubsection*{Live Demo}
Using the sample demo, the listed usability criteria (Category 5) and other defined features (Category 6) are analyzed. It should be possible to use the demo in Firefox browser without installation of the application and pre-installed plug-ins (JavaScript activation is assumed). Generally such demos are available on the home page of the respective web mapping applications.

It is important to bear in mind that a demo will not necessarily include all the functions available in the actual application. Even the user interface of a demo may only represent a \textit{likely} GUI configuration of the application. For this reason it is important to note that this analysis will focus solely on demos used for this purpose.

Another item worthy of mention is the objective nature of a usability analysis. When evaluating the usability and design of an application the line between objective judgement and subjective impression is not always clearly defined
(see Section \ref{usability_messbarkeit}).\\
Many of the interactive features of web applications have become standard, and for the most part meet user expectations, such as the Drag\&Drop functions used for moving map areas or the icons used for zooming and panning functions. Usability criteria such as these can fairly easily be evaluated on an objective basis.\\
However, factors related to the design of applications, such as the use of colors or the configuration of different components, invariably involve some range or leeway in making usability judgements. In the following analysis the subjective evaluation part will be kept to a minimum.

\subsection{Selection}
\label{analyse_auswahl}
The Internet portal \textit{FreeGIS}\footnote{\url{http://freegis.org} 
\checkURL} will be used for the selection of the Free web mapping applications to be analyzed. A search using the key word \frz{Web Mapping} lists more than 50 software tools in the \frz{Software} category (as of April 10, 2007).  Because the number is quite large, some restrictions were applied to achieve a suitable number for the purpose of this thesis.

Based on the definitions of terms related to web mapping (see Chapter \ref{webmapping_begriffe}) several entries were removed - for example, \textit{MapServer}, \textit{Geoserver} and
\textit{deegree} do not fit the criteria for required web mapping clients.

Following an evaluation of the remaining entries eleven of the most promising and significant (as shown by being mentioned on other GIS portals such as \textit{OSGeo}\footnote{\url{http://www.osgeo.org} \checkURL}
or \textit{MapTools}\footnote{\url{http://www.maptools.org} \checkURL}) Free web mapping client applications were selected. 

In this vein the current state analysis does not purport to present an exchaustive analysis of available applications.  It is rather intended as an overview of the variety found in Free web mapping applications and their usability-related functions.

Owing to the great significance and popularity of \textit{Google Maps} \texorhtml{\citep}{\cite}{ramsey2006}, this proprietary software will also be compared to the eleven Free software applications.

Below is a list of all twelve selected web mapping applications (in alphabetical order):
\begin{itemize}
    \item CartoWeb
    \item Chameleon
    \item Google Maps
    \item iGeoPortal 
    \item ka-Map
    \item Mapbender
    \item Mapbuilder
    \item MapGuide Open Source
    \item MappingWidgets
    \item OpenLayers
    \item p.mapper
    \item WMS Mapper
\end{itemize}

\newpage
\subsection{Result}
\label{analyse_ergebnis}
Complete analysis results of the twelve analyzed web mapping applications can be found in Appendix
\ref{anhang:bestandsanalyse}\texonly{ (pg. \pageref{anhang:bestandsanalyse} and following) -- two pages per tool}. 

Applications can be classified into the following three types:

\begin{latexonly}
\begin{itemize}
    \item [\hspace{0.6cm}\textbf{Type 1:}] Free, 100\% client-side
    \item [\hspace{0.6cm}\textbf{Type 2:}] Free, client-serverside
    \item [\hspace{0.6cm}\textbf{Type 3:}] Proprietary, 100\% client-side
\end{itemize}
\end{latexonly}

\begin{ifhtml}
\begin{itemize}
    \item \textbf{Type 1:} Free, 100\% client-side
    \item \textbf{Type 2:} Free, client-serverside
    \item \textbf{Type 3:}
        Proprietary, 100\% client-side
\end{itemize}
\end{ifhtml}

Two of the twelve applications are Free Software and \textit{pure} 
JavaScript applications, which run exclusively on the client (Type 1), that is to say, they only contact an external map server for the purpose of requesting the map whereas all functions of the application are implemented on the client. A map server (e.g. WMS server) is still required but in this case does not form an actual part of the web mapping application.  In the thesis the term  \textit{client-side} is used when these criteria are fulfilled.

Nine of the twelve analyzed applications are Free software client-serverside applications (Type 2), ie. the application implies or assumes the existence of a proper map server. Client-server mixed applications, on the other hand, require an installation. The term \textit{client-serverside} will be used for this type of web mapping application.

\textit{Google Maps} is a Type 1 application (pure JavaScript), and the only proprietary application used in the testing procedure. As mentioned in Section
\ref{analyse_auswahl}, the analysis' main focus is on \textit{Free} web mapping solutions, but given the significance of \textit{Google Maps} the latter was also included in the analysis for comparison purposes. Proprietary client-server solutions were not considered as part of this analysis.

Table \ref{tab:maptools} shows the most significant results of the analysis along with an opportunity to compare the selected applications.


\setlength{\textheight}{47\baselineskip}

\input{maptools/maptools_en.tex}


\clearpage
\setlength{\textheight}{42\baselineskip}

\subsection{Evaluation}
\label{analyse_auswertung}
The results obtained in Section \ref{analyse_ergebnis} are now compared and evaluated according to usability. This evaluation offers a first thorough overview of exemplary \textit{Smart Map Browsing} capabilities in web mapping applications and forms the basis for a subsequent definition of \textit{Smart Map Browsing} in Section \ref{smartmapbrowsing}.

The evaluation is classified into three categories:
GUI Components, Pan/Zoom Characteristics, and Community.

\subsubsection*{A) GUI Components}

\begin{description}
    \item[Overview Map] 
        Eight out of twelve applications feature an overview map which can be
        manipulated (per mouse click or double-click) to move the main map.  
        \textit{Mapbender} has an optional pull-out area which allows a
        combination of zoom and pan functions.  \textit{Google Maps} offers 
        animated panning of the main and overview maps with double-click or 
        Drag\&Drop of the viewed section. \textit{Ka-Map} shows signs of similar 
        animation features.\\
        Once a user zooms the map, the selected section moves in sync with the 
        overview map. \textit{Google Maps} and \textit{OpenLayers}, for example,  
        feature a dynamic overview map which is automatically zoomed along with 
        the main map (whereas it remains fixed during other functions). However, 
        the centering of a map section after manual repositioning is only
        possible with \textit{Google Maps}.\\
        \textit{Google Maps} displays the reference map in the same 
        style as the main map. On the other hand, in \textit{OpenLayers} the 
        style is defined only by the active base layer, and overlays are not 
        displayed. Similarly, only \textit{Google Maps} and \textit{OpenLayers} 
        offer a minimizable overview map display.


        Conclusion: A close-to perfect rendition in \textit{Google Maps}; a good 
        approach and similar potential in \textit{OpenLayers}. Static overview 
        maps of other tools are not very helpful at high zoom levels.

    \item[Layer Overview]
        Nine of twelve applications feature a layer overview. Three of those 
        use a layer overview in conjunction with a legend.         
        \textit{OpenLayers} und \textit{Mapbender} are able to completely 
        minimize the control.  Other applications offer collapsable 
        (sub-)layers although this carries with it the risk of interleaving 
        (see \textit{CartoWeb}, \textit{ka-Map}).
        
        If the layers list is too long, there is a risk of the user losing track 
        of the layers (see \textit{Chameleon}). Similarly, usability is less 
        than optimal when the user has to confirm a layer selection with an 
        additional click to update the selection (see \textit{CartoWeb}, 
        extit{Chameleon}, and \textit{iGeoPortal}). In \textit{Ka-Map} and 
        \textit{iGeoPortal} it is possible to select and change the sequence of 
        different layers. \textit{Google Maps} displays only three types of 
        layers options, namely Map, Satellite, and Hybrid.

        Conclusion: Good combination possibilities involving the legend, some 
        risk with interleaving, disadvantage with manual update requirements, 
        convincing simplicity in \textit{Google Maps} and \textit{OpenLayers}.

\newpage
    \item[Scale]
        Scale display in web mapping application is quite variable, 
        including the use of scale bars (such as  
        \textit{ka-Map}), simple numerical scale indicators 
        (\textit{OpenLayers}), a pre-defined menu box(\textit{CartoWeb}, \textit{Mapbender}) or an editable scale 
        text field (\textit{Mapbuilder}, \textit{p.mapper}).

        Conclusion: Selection boxes and text fields look more complex than bars 
        or simple scale indicators.  A semi-transparent bar fits in nicely 
        with the map. 

    \item[Toolbar]
        All applications investigated for this thesis contain a tool bar, ranging 
        from the very minimalistic (\textit{OpenLayers}, \textit{WMS Mapper}) to 
        the very elaborate (as seen in \textit{ka-Map}, \textit{Mapbender}). 
        However, the differences in their functional ranges are quite small.  
        Noticeable features are the Zoom History buttons (as found in 
        \textit{Mapbender} and \textit{MapGuide Open Source}). Most applications 
        however do not automatically adapt the mouse cursor to the selected tool 
        function.

        Conclusion: Generally speaking, featured tool bars show only small 
        differences, with the \frz{usual} range of tool functions. Applications 
        which are 100\% client-side are limited to the more basic functions.     


    \item[Zoom Bar]
        Four out of twelve applications feature a zoom bar (\textit{OpenLayers},
        \textit{MapGuide Open Source}, \textit{p.mapper} and
        \textit{Google Maps}). In \textit{MapGuide Open Source} the zoom bar can 
        be placed anywhere on the map. \textit{P.mapper} offers a remarkable 
        \textit{continuous zooming} feature: when the zoom slider is moved, the
        map is simultaneously scaled, then redrawn. However, the  
        non-functioning + and -- \frz{buttons} are rather annoying.
        
        Conclusion: Zoom bars offer a good selection of zooming levels. All four 
        applications offer a remarkably high degree of usability.
        
    \item[Pan Navigation Panel]
        Four applications feature panning buttons at the edge of the 
        map. On the other hand, three applications offer a navigation panel as 
        part of a combined pan-zoom bar navigation feature (see 
        \textit{OpenLayers}, \textit{MapGuide Open Source} and \textit{Google 
        Maps}). 
        In the remaining five applications the map can be panned only by way of  
        Drag\&Drop.

        Conclusion: Panning controls are very useful. However, having to      
        navigate through a map using features located at the edge of the map 
        impairs the visual integration of the map into a website. A PanZoom bar
        shortens and thus considerably facilitates the navigation process.

\end{description}

\newpage
\subsubsection*{B) Pan/Zoom Characteristics}

\begin{description}
    \item[Zooming with double-click]
        Only \textit{OpenLayers} and \textit{Google Maps} have an automatic   
        zoom-in option by virtue of double-clicking on the mouse. Applications 
        which require the user to switch to the \textit{ZoomIn} tool before 
        being able to click for zoom-in are not considered here. 

      
        Conclusion: The usability feature shows that a smooth transition between 
        panning and zooming is possible \textit{without} having to first select 
        a specific tool for this purpose. This results in very smooth 
        \textit{map browsing}.

    \item[Zooming with mouse wheel]
        Three applications permit a zoom level change by using the mouse wheel
        (\textit{OpenLayers}, \textit{Google Maps}, \textit{p.mapper}). Only 
        \textit{Google Maps} continues to show the exact location pointed to by
        the mouse cursor after the zooming feature has been activated. In 
        comparison, \textit{OpenLayers} centres the map according to the 
        location of the cursor;  \textit{p.mapper} zooms in and out regardless 
        of the location of the mouse cursor.

        
        Conclusion: Similar to the double-click feature, mouse wheel zooming 
        allows for a smooth transition between panning and zooming. Only 
        \textit{Google Maps} offers the expected characteristics by 
        adjusting the map in sync with the cursor location.


    \item[Zooming per zoom box]
        Ten of twelve applications offer a pull-out box (per mouse) which allows the user to perform zoom functions for selected areas. Only \textit{WMS Mapper} und \textit{Google Maps} do not offer this feature. The color highlighting of the zoom area is considered a positive feature (inc. \textit{OpenLayers},
        \textit{ka-Map}). In five applications it is also possible to access the zoom box via the Shift-key (inc. \textit{OpenLayers},
        \textit{mapbuilder}).

        Conclusion: This is a \frz{basic} feature found in most applications (so
        it is somewhat surprising not to find it in \textit{Google Maps}); it is 
        very useful for direct zooming of a particular area, whereby the use of 
        Shift-key command is also widespread.

    \item[Zooming/Panning with keyboard]
        \textit{OpenLayers}, \textit{p.mapper} and \textit{Google
        Maps} allow Zoom/Pan navigation using the keyboard. 
        \textit{Google Maps'} panning key configuration is very extensive and intuitive.

        Conclusion: Only a few applications provide navigation options using the 
        keyboard. Expanded key configuration offers a good level of convenience.

    \item[Zoom Level]
        The ability to see the current zoom level is an important factor in the
        usability of an application.\\
        Four application feature an unlimited number of minimum and maximum zoom 
        levels, ie. no limitation on zoom level intervals (see 
        \textit{Chameleon}, \textit{iGeoPortal}, \textit{Mapbuilder} and 
        \textit{MappingWidgets}).
        Two applications, (\textit{WMS Mapper} and \textit{CartoWeb}), define a 
        minimum and maximum zoom depth, but still enable \frz{on-the-spot} 
        zooming.  The remaining six applications feature well coordinated        
        minimum/maximum zooming properties.
        Applications using a zoom bar offer a particularly good 
        indication of zoom levels.

        Conclusion: Good zoom level indicators have a positive effect on 
        usability, unlimited zoom levels to a lesser degree.

    \item[Zoom Reset]
        With the exception of \textit{WMS Mapper} all applications have the 
        option of reverting a map to its maximum dimension (usually as a button 
        on the tool bar). \textit{Google Maps} does a good job of integrating 
        this function into the pan/zoom bar.  \textit{OpenLayers} 
        does not generally offer the possiblity of combining the zoom reset 
        function with the expanded zoom bar.

        Conclusion: An expected standard feature which should be included in 
        every application.

    \item[Tiling]
        Map tiling is supported by five applications (\textit{OpenLayers}, \textit{WMS Mapper}, \textit{ka-Map}, \textit{MapGuide Open Source} and
        \textit{Google Maps}). A noticeably quick (ie. without delay) panning 
        process is offered only by \textit{OpenLayers} and \textit{Google Maps}. 
        Other applications feature rather sluggish panning properties.

        Conclusion: Noticeably good pan/zoom characteristics in tiling-based 
        applications. Superior panning characteristics in \textit{OpenLayers} 
        and \textit{Google Maps}. 

    \item[Load Time]
        The load time required for panning and zooming are critical factors in evaluating the usability of a web application.\\ 
        Tiling-based applications have a clear speed advantage compared to conventional web applications.\\
        In zooming three different forms of map construction are observed: 
        \texorhtml{\begin{compactitem}}{\begin{itemize}}
        \item map is constructed by sequentially ordered tiles
        (\textit{OpenLayers}, \textit{ka-Map}, 
        \textit{MapGuide Open Source},
        \textit{Google Maps})
        \item new map is displayed as a complete unit 
        (inc. \textit{Mapbender}, \textit{Mapbuilder})
        \item new map is displayed as a complete unit after a certain load time (\frz{loading} indicator) (\textit{iGeoPortal},
        \textit{p.mapper}, \textit{CartoWeb})
        \texorhtml{\end{compactitem}}{\end{itemize}}

        Conclusion: Load times can be lengthy and somewhat disruptive during 
        the panning process. Zoom changes sometimes result in an empty map 
        background. A gradual tile assembly ensures a dynamic and visible 
        loading process.
        



\end{description}


\newpage
\subsubsection*{C) Community}
\begin{description}
    \item[Revision Administration]
        Seven applications offer source code administration with 
        SVN\footnote{\url{http://subversion.tigris.org} \checkURL}, three 
        provide this by way of CVS\footnote{\url{http://www.nongnu.org/cvs} 
\checkURL}. 
        \textit{WMS Mapper} und \textit{Google Maps} do not provide source code 
        administration features.
        
        Conclusion: A revision administration is a standard feature in every FS 
        project. The trend towards the more modern SVN is not surprising.

    \item[Developer Mailing List (ML)]
        Seven of twelve applications provide a developer mailing list. Looking at the monthly number of mails, applications such as \textit{MapGuide Open Source} (168), \textit{Mapbuilder} (120)
        and \textit{OpenLayers} (85) are noted for their activity.  The remaining applications show between 10 and 50 mails per month.\\
        Leading the number of active developers (using the six month defined time period) is \textit{iGeoPortal} with 101 developerss (note that \textit{iGeoPortal} uses the \textit{deegree} ML).
        \textit{OpenLayers} follows with 72 different developers, whereas the remaining applications range between 10 and 50 developers.
    
        Conclusion: \textit{MapGuide Open Source} has a surprisingly high mail activity with relatively few developers. \textit{OpenLayers} shows above-average mail activity and the highest number of active developers in a single project.

    \item[User Mailing List (ML)]
        Ten of twelve application have a user mailing list. 
        \textit{MapGuide Open Source} is the most prominent with 527 mails per 
        month. The high number is likely a result of the application's 
        widespread use due to the earlier proprietary background of Autodesk.
        At 197 mails per month, \textit{OpenLayers} is also counted among the 
        leading applications. The majority of the applications have mailing 
        lists ranging from 50-100 mails per month.\\
        Among active users \textit{MapGuideOpen Source} is the clear front runner 
        with 297 mails per month, followed by \textit{OpenLayers} at 150. The 
        remaining mailing lists range from 60 to 120 active users in the six 
        month time period.
        
        Conclusion: Noticeably high monthly mail volume at \textit{MapGuide Open 
        Source}, which also has the highest number of active users. In the same 
        vein, the number of users and mails at\textit{OpenLayers} is also above 
        average (as is its developer mailing list).
        

\end{description}




\newpage
\section{\textit{Smart Map Browsing}}
\label{smartmapbrowsing}

Using the foregoing analysis results as a base, the objective of the following section is to: a) devise a definion of the term \textit{Smart Map Browsing}, b) derive its properties, and c) outline its potential.

The expression \textit{Smart Map Browsing} is not used in current literature and will be further defined and elaborated in this thesis.

\subsection{Term}
\label{smb_begriff}
The definition for the term \textit{Smart Map Browsing} is based on the ISO standard for usability (see Section \ref{usability_begriffe}):

\begin{quote}
\textit{Smart Map Browsing describes a web mapping application's usability in terms of its effectiveness, efficiency and satisfaction for the user.}

\textit{The characteristics of Smart Map Browsing are defined by a variety of self-explanatory, interactive elements and functions which display the expected interactive properties - they define the ideal, user-friendly web mapping application, taking into account the most current technology available.}
\end{quote}


\subsection{Characteristics}
\label{smb_eigenschaften}
The current state of technology related to \textit{Smart Map Browsing} can be described in more detail using two categories -- \textit{GUI components} 
and \textit{Pan/Zoom properties}. It should be noted that because these characteristics are based on the \textit{current} state of technology (effectively a \textit{Smart Map Browsing 1.0}), medium-term modifications will be required as newer technology becomes avaialble.

\subsubsection*{A) GUI Components}
\label{smb_guikomponenten}

\begin{description}
    \item[Main Map]
        In web applications where the map forms the main part of the application 
        (as opposed to applications where maps are merely useful \frz{additions} 
        to other functions), the map should occupy the main part of the 
        application's interface. A seamless change in map size (e.g. 
        by moving map edges) allows the user to set a map according to his/her 
        individual requirements. The ability to adjust the map to the current 
        browser size is is also considered a positive \textit{Smart Map 
        Browsing} feature.\\
        One usability aspect in web mapping applications that should not be 
        overlooked is map design. An attractive map layout, easy-to-read 
        signatures, symbols and lettering, intuitive colors in 
        attractive combinations and a well-selected graphic picture 
        density - they all have a positive influence on the attractiveness 
        of a web map  \texorhtml{\citep}{\cite}{raeberJenny2003}.

    \item[Overview Map] 
        The ability to navigate in the overview map is an important criteria in
        \textit{Smart Map Browsing}. The click/double-click along with 
        Drag\&Drop drags the selected section in the reference map. 
        Following the intereaction with the overview map the selected section is 
        always re-centered. This is an important feature for maintaing the 
        interactive relationship with the user, as well as to ensure his/her  
        orientation during this process.\\ 
        By panning the main map, the overview map is also immediately adjusted to the new location. In this case, a simultaneous panning action (\textit{animated panning}) involving the main and overview map is considered ideal as the user is provided with the new map position but does not lose track of the overall position.\\
        The overview map is also adjusted according to the zoom level in the main map. In this case the scale used is always larger than the one used in the main map (by a defined factor) so that the overview map retains its ability to serve as an \frz{overview} for the user.\\
        The feature allowing the minimization of the overview map is considered useful. Placing it within the main map means more available space for the main map; at the same time this location of the overview map places it within the user's center of attention.\\
        A further improvement to usability would be to also display the active layers in the main map in the overview map.

    \item[Layer Control]
        When a layer is turned on/off, the map is automatically updated (no confirmation required). This feature is an important characteristic of \textit{Smart Map Browsing}.
        The ability to minimize the overview enables the user to turn his/her full attention to the map at hand. In addition, the ability to change the layer sequence and to integrate a legend into the layer control are also considered useful (depending on the application).

       
    \item[Legends]
        Legends should be as succinct as possible and directly related to the map contents. The components of a legend should be ordered according to their significance, grouped with similar elements and displayed accordingly  \texorhtml{\citep}{\cite}{raeberJenny2003}. Again, the ability to minimize the legend enables the user to get a better view of the map at hand.

    \item[Scale]
        Scale indicators or bars are only useful if they are recalculated for each zoom level \texorhtml{\citep}{\cite}{raeberJenny2003}. A scale bar should be available during \textit{Map
        Browsing} so that estimates of distances can be done with the naked eye. The use of bars is recommended (particularly for web applications with \frz{inexperienced} map users) and is preferred over the use of scale indicators. Ideally, the bar is displayed semi-transparently within the map.


    \item[Toolbar]
        Overly extensive toolbars can have a negative effect on the usability of 
        an application. Limiting the toolbar to the advanced query and 
        analysis functions is advisable as it would result in \frz{smart} 
        \textit{Map Browsing}. Simple zooming and panning functions are ideally 
        done with a pan/zoom bar or similar 'intuitive' pan/zoom 
        features (such as mouse wheel, double-click). Another important factor in 
        smooth \textit{Map Browsing} is the ability to switch between panning 
        and zooming  \textit{without} having to first activate the respective
        tool.\\
        In so far that it is considered useful, a mouse cursor should visually 
        reflect the user's tool choice (by changing the cursor image) so as to confirm the selection.\\
        In this respect the zoom history feature is a useful \textit{Smart Map Browsing} feature. This feature allows a user to un/redo recently-made panning or zooming activities.

    \item[Zoom Bar]
        One of the most significant \textit{Smart Map Browsing} feature is the zoom bar. It offers a high degree of interactivity and a good visual indicator of the current zoom level relative to available zoom levels. \\
The term \textit{continuous zooming} denotes the ability to scale a map 'on the fly' by moving the zoom slider. The map is only loaded to the selected scale when the slider is released. This feature increases the user's navigational ability and serves as a good example of \textit{Smart Map Browsing}.
                
    \item[Pan Navigation Panel]
        The pan navigation panel offers intuitive and precise panning. Integrating the panel into a Pan/Zoom bar is preferable to locating it on the map edge because navigation  \frz{by mouse} is made simpler and quicker. 
        
\end{description}

According to \texorhtml{\citep}{\cite}{raeberJenny2003} navigation and control elements in web mapping applications should be self-explanatory and efficient. They should also be logically grouped to facilitate the use of the web mapping program. The user should be able to quickly find the required function instead of being overwhelmed by the available functions. The navigation of a map containing many different elements is quite complicated and requires a fairly steep learning curve. As a result, a map navigation control pad which is intuitive should be the main focus, while the more demanding functions should be simplified as much as possible or at least reduced to a minimum \texorhtml{\citep}{\cite}{raeberJenny2003}.

It it not imperative to place navigation components outside the map view. The advantage of placing the controls inside the map is that the user is always aware of the available options, as they are in plain view (and easily noticed) rather than being relegated to the side. Having a correspondingly attractive representation of the controls is also beneficial \texorhtml{\citep}{\cite}{raeberJenny2003}.


\newpage
\subsubsection*{B) Pan/Zoom Characteristics}

\begin{description}
    \item[Zooming with double-click]
        Zooming with double-clicking on the map enables a smooth transition between panning and zooming without having to separately switch to the corresponding controls. This feature increases the intuitive nature of the application and is therefore defined as a characteristic of \textit{Smart Map Browsing}.

    \item[Zooming with mouse wheel]
        Similar to double-click zooming, zooming via mouse wheel also increases the usability of the application by ensuring a smooth transition into zoom mode. \\
Accordingly, we speak of a  \textit{Smart Map Browsing} feature when the geographic position shown by the mouse wheel during the zoom process is at the same pixel position after the zoom is completed. On the other hand, zooming that centres the map according to the position of the mouse cursor, or does not take into account the actual cursor position, is not along expected lines and therefore not considered part of a \textit{Smart Map Browsing} definition.


    \item[Zooming with zoom box]
        The ability to zoom with a pull-out zoom box has become a standard feature in most web mapping application - a feature most users would now expect to see. Along with a zoom box button on the toolbar it should also be possible to draw the zoom box by pressing the Shift-key. In addition, a unicolour, semi-transparent shading of the zoomed area provides the user with a visual confirmation of his choice.\\
        This useful feature is considered a critical element of \textit{Smart Map
        Browsing}.
        
    \item[Zooming/Panning with keyboard]
        Simple navigation manouveurs should be executable with the plus, minus or arrow keys. An extended, intuitive keypad for the pan function is considered beneficial to usability (some of the more obvious choices for rudimentary map re-positioning are Home, End, Page $\uparrow$, Page $\downarrow$).  
        
    \item[Zoom Levels]
        Zoom level intervals should be clearly delineated. The zooming function is deactivated once the maximum or minimum zoom level is reached, with the corresponding buttons showing that the zooming function is no longer active. Displaying the potential zoom depth on a zoom bar is also helpful to the user's orientation while viewing the map.

    \item[Zoom Reset]
        A user would expect to be able to reset the map to its maximum dimensions by using a zoom reset function. Following the principles of usability, whereby similar elements are grouped logically, a similar integration of the zoom reset buttons into the pan/zoom bar is recommended. This means that all zoom and pan functions can be located outside of the toolbar
        (see also \textit{(A) GUI Components}).

        \newpage
    \item[Animation]
        Animation in web maps is done for several reasons: To increase the user's attention level, to direct attention to specific objects, to increase the user's orientation during the navigation process or to lead him/her through a specific topic. There are two different types of animation: temporal and non-temporal 
        \texorhtml{\citep}{\cite}{dickmann2004,raeberJenny2003}.

        Temporal animation displays spatial changes which occured in a specific period of time
        \texorhtml{\citep}{\cite}{dickmann2004,raeberJenny2003}. An example of temporal animation is the display of population growth of a city in, say, the last century. The user should be able to interact with the animation by using self-explanatory navigation elements. It is easier to display complex data with time flow. These types of animations should take place within the confines of the main map and not replace a web mapping application's interactive \textit{Map Browsing}.
        
        Non-temporal animation displays spatial data of 
        \textit{one} concrete point in time with different illustrations \texorhtml{\citep}{\cite}{dickmann2004,raeberJenny2003}. 
        An example of non-temporal animation would be an automatic \frz{ZoomTo} feature, whereby the user is led to a specific location through the use of non-temporal animation. This in combination with map navigation controls results in very dynamic pan and zoom properties, which are described as \textit{animated panning} and
        \textit{animated zooming} in \texorhtml{\citep}{\cite}{OLtrac}. The user's orientation and ability to judge distances ie. scale is not hindered.
        
        Cartographic animations increase the user's attention and add considerable value to the map. Animations (within a reasonable range) are an important characteristic of \textit{Smart Map Browsing}.

    \item[Tiling]
        One of the most fundamental characteristics of \textit{Smart Map
        Browsing} is the tiling of maps. To reduce the cumbersome computing time
associated with servers, a client-side tiling is to be preferred over server-side processes (see Section \ref{webmapping_tiling}). Provable measurements were not carried out.  Ideally, tiling results in an absolutey smooth (ie. without delay) map movement. During zooming the tiles are assembled in a spiral or star-like manner, beginning from the middle of the map. This dynamic loading process provides the user with a visible confirmation of the map loading process.


    \T\enlargethispage{\baselineskip}
    \item[Load Time]
        The most important criteria of a web page is its load time \texorhtml{\citep}{\cite}{nielsen2000}. Here a distinction between objective and subjective load time needs to be made. The former is the time actually required to load a page; the latter refers to the user's personal impression of time while the page is loading. According to Jakob Nielsen the objective load time should not exceed eight seconds.  Anything above this value negatively affects the usability of a web application.\\
        In the context of web mapping applications, the most important issue is the time required for a user to be able to view a map. The load time required for the complete page, including all details and if applicable, pre-loaded tiles for the non-visible area, is less significant in this case \texorhtml{\citep}{\cite}{nielsen2000}.
        \newpage
        Ideally there is no time delay during a drag procedure (see \textit{Tiling}).
        A map constructed with sequentially appearing tiles appears to take less time (ie. has a faster subjective load time) than an untiled map which is shown only when the process is completed. \textit{Tile Caches} can be used to increase the objective load time during tiling. A more detailed discussion follows in the next section.  


\end{description}


Inherent in the definition of \textit{Smart Map Browsing} is the user's ability to interact with a web mapping application in a variety of ways. At the same time, the usability of each interaction is of paramount importance, that is, the performance of the component(s) should always conform to expectations.



\subsection{Potential}
\label{smb_potenziale}

The main characteristics of \textit{Smart Map Browsing} along with their potential in the web mapping area are featured below:



\textbf{Tiling} (\textit{client-side} tiling only) is without doubt one of the most significant characteristics of \textit{Smart Map Browsing}, with great potential for user-friendly web mapping applications.  However, tiling on its own (see Chapter
\ref{webmapping_tiling}) does not guarantee good \textit{Smart Map Browsing}. Even the highest-performance application cannot offer good usability if the response time of the map server is very long. Tiling does not predict the objective load times of tiles.  In the spirit of the \textit{Smart Map Browsing} definition, the goal should be to reduce objective load times as much as possible.


One solution is server-side \textbf{\textit{Tile
Caching}} (client-side caching will not be discussed). Here the tiles are kept on the server in the form of readily rendered graphics, thereby reducing the response time of the map server: When a client requests a map, the server does not have to generate the map, instead it accesses the finished tiles (usually stored in the file system) and sends them to the client in a considerably shorter time frame.  For this purpose, the tiles must be of uniform size and available in a pre-defined tile grid.\\ 
\textit{WMS Tile Caching}\footnote{
\url{http://wiki.osgeo.org/index.php/WMS_Tile_Caching} \checkURL} 
or \textit{WMS-Cached} -- in short, WMS-C -- is representative of an initial recommendation on how such a standard could look based on the OGC WMS specifications. A more detailed suggestion for a standardized solution is described in the \textit{WMS Tiling Client Recommendation}\footnote{
\url{http://wiki.osgeo.org/index.php/WMS_Tiling_Client_Recommendation}
\checkURL}, a result of the Tiling Discussion Group at the \textit{FOSS4G} Conference 2006\footnote{
\url{http://www.foss4g2006.org} \checkURL} in Lausanne.
Based on this recommendation the US company \textit{MetaCarta}\footnote{\url{http://www.metacarta.com} \checkURL} has developed the implementation of \textit{TileCache}\footnote{\url{http://www.tilecache.org} \checkURL} --
a WMS-C compliant server, available under the BSD license. \textit{TileCache} is a Python-based 
WMS/TMS\footnote{\url{http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification}
\checkURL} server containing mechanisms for the rendering and caching of tiles. In the most simple scenario, \textit{TileCache} can create its own local cache of (all) tiles on the hard drive. It accomplishes this by means of write access to the hard drive, the ability to execute Python CGI scripts and the designation of a chosen WMS server. The tiles are subsequently requested by a WMS-C or TMS-supporting client (such as \textit{OpenLayers}). 
\textit{TileCache} is said to speed up WMS requests by a factor of 10 to 100. The use of \textit{TileCache} under
\textit{mod\_python}\footnote{\url{http://www.modpython.org} \checkURL} supports more than 300 requests per second
\texorhtml{\citep}{\cite}{tilecache}.\\
Server-side tile caching offers significant potential for the further development of \textit{Smart Map Browsing} in web mapping applications. Despite the short history and still outstanding OGC standardization of WMS-C, noticeable progress in the load times of WMS maps has been made. Accordingly, tile caching promises to become a fundamental feature of \textit{Smart Map Browsing}.

By turning the focus to the navigational elements of web mapping applications the \textit{Smart Map Browsing} ability of the \textbf{Zoom Bar} is noteworthy. The analysis (see Section  \ref{bestandsaufnahme}) shows a noticeably improved usability in the four applications which feature this type of component. The zoom bar in combination with a pan navigation panel and a zoom reset button enables an implementation of the above-mentioned usability guidelines. The defined aspects of the zoom depth orientation (see Section \ref{smb_eigenschaften}) offer additional opportunities to influence the concept of usability.\\
In conclusion, the use of a zoom bar offers great future potential.

\T\enlargethispage{\baselineskip}
Closely connected to this development are the very recent and innovative attempts at animating different navigational features. 
\textbf{\textit{Animated panning} and
\textit{animated zooming}} are \textit{Smart Map Browsing} 
features which are currently implemented in only three of the analyzed applications.\\
\textit{Animated panning}, in conjunction with tiling, offers a good method of assisting users to go from point A to B by way of an animated and no-delay process. Similar to Drag\&Drop panning, this process demonstrates to the user that the viewed map selection is only a part of a whole, seamlessly connected map - a clear advantage in preserving the user's orientation in the viewing process.\\
Essentially, the \textit{animated zooming} feature is an automatic zooming process that animates the transition from zoom level A to level B. During the zooming process the map is scaled and redrawn once zooming level B is reached. This type of animation permits the zooming in and out of the map at one or more zoom levels. 
\textit{animated panning} and \textit{zooming} is also a possibility.\\
Furthermore, the \textit{animated zooming} feature implies an additional function: Moving the slider of a zoom bar results in a seamless rescaling (up or down) of the current map. This is an example of \textit{manual} non-temporal animation.\\
An accepted glossary term for zooming animations in web mapping applications does not yet exist. Given the similarity to 
\textit{animated panning} characteristics the term \textit{animated zooming} seems a plausible choice. On the other hand, \textit{Google Maps}, uses the term  \textit{continuous zooming} to denote zooming animation per mouse wheel (currently only in 
\textit{Windows} operating systems).  In this discussion the term \textit{animated zooming} is used to denote \textit{automatic} zoom processes (initiated by e.g. click, double-click, mouse wheel or zoom box).   Furthermore, \textit{animated zooming} is used as a collective term describing all animation-supporting zoom processes in web mapping applications, including \textit{continuous zooming} (used interchangeably with \textit{seamless
zooming}).\\
It stands to reason that these two recent features (\textit{animated
panning} und \textit{zooming}) will play a signficant role in the further development of \textit{Smart Map Browsing}. Currently, some performance problems   (caused by limited band width or client hardware) can occur with extensive animation, which could negatively influence usability.  At the same time, the future potential of these extensions is clearly recognized, and it is conceivable that they will soon become an intrinsic part of any web mapping application. 


\newpage
\section{Requirements Analysis}
\label{anforderungsanalyse}

One of the more surprising observations in Section \ref{analyse_ergebnis} is the extraordinary  \textit{continuous zooming} feature of \textit{p.mapper}.
\textit{OpenLayers} on the other hand is convincing in almost all other areas, and in addition has one of the most active communities in the Free web mapping area. Furthermore, using the new term \textit{Smart Map Browsing} (see Section
\ref{smartmapbrowsing}) as a guide, there is great development potential for \textit{OpenLayers} and animated zoom processes. A zoom feature similar to the one featured in \textit{p.mapper} would be an ideal addition to \textit{OpenLayers}.

Based on the reasons stated above, the Free web mapping application \textit{OpenLayers} supplemented with a novel add-on \textit{animated zooming} feature was selected for the practical part of this thesis. This section details the exact requirements for this type of add-on feature.

\subsection{Purpose}
The purpose of the practical thesis portion is to implement the \textit{Smart Map Browsing} feature \textit{animated zooming} into the Free mapping application  \textit{OpenLayers}.

The main purpose of the extension is to assist during navigation, so as to ensure the user's orientation during the zoom process.\\
Note: Empirical measurements will not be conducted, therefore a \textit{measureable} enhancement is not possible. However, the definition of \textit{Smart Map Browsing} implies that this extension would have a positive effect on usability. In comparison to non-animated zoom processes (whereby the map \frz{jumps} into the desired zoom level), an animated continuous zoom process would noticeably improve the user's orientation, which would likely also lead to greater acceptance by the community.  A general consensus regarding the attractivness of this extension is evidenced by the mailing list discussions on \textit{animated zooming}.



\newpage
\T\enlargethispage{2\baselineskip}
\subsection{Must-Have Criteria}
\label{musskriterien}
The functionality of an application (as seen from the user's point of view) is described by the following \textit{Must-Have} requirements:

\begin{enumerate} 
	\item It should be possible to freely move the zoom slider on the zoom bar by holding down the left mouse key. This means implementing the following application scenarios:
		
		\begin{itemize} 
		\texorhtml{\item[a)]}{\item a)}
		The selected view of the main map is scaled on-the-fly by moving the zoom slider.
		\texorhtml{\item[b)]}{\item b)} During \textbf{ZoomIn} the map is scaled by an enlargement of visible tiles. Depending on the difference in zoom levels, the tile bitmap graphics will be somewhat or significantly more pixelated. 
		\texorhtml{\item [c)]}{\item c)} During \textbf{ZoomOut} the main map is initially scaled by decreasing the size of visible tiles. The resulting white border (around the smaller map) should be filled in such a way that the user is always viewing a completely filled-in map surface.

The redrawn map surface is scaled relative to the tiles of the original map selection. 
		\texorhtml{\item [d)]}{\item d)} If \textbf{several overlays} are activated, they are scaled together with the selected base layer.
			Note that items such as symbols and letters will also be scaled up or down as part of this process. 
		\texorhtml{\item [e)]}{\item e)} The \textbf{overview map} contains a marker, whose size adjusts along with the zoom process (simultaneously with the modifications to the main map). The marker always shows the current area of the main map.
	\end{itemize} 
		
	\item As soon as the user selects the desired zoom level (by releasing the left mouse key), the hitherto scaled bitmap tiles (along with all activated overlays) are redrawn.  
\end{enumerate}

\subsection{Should-Have Criteria}
\label{anforderungsanalyse_wunsch}
The \textit{should-have} criteria for the \textit{animated zooming} feature are defined as follows:  
\begin{enumerate} 
    \item Full \textit{animated zooming} support for all layer types available in \textit{OpenLayers}.
    \item Zoom Animation with Zoom Bar (buttons)
        \begin{itemize}
        \texorhtml{\item [a)]}{\item a)} On clicking the + or  -- button at the end of the zoom bar, the map is zoomed in or out by one level. 
        \texorhtml{\item [b)]}{\item b)} On clicking at a specific point on the zoom bar, the map is zoomed to the level indicated by the pointer.           
    \end{itemize}
    
    \newpage
    \item Double-click Zoom Animation
        \begin{itemize}
        \texorhtml{\item [a)]}{\item a)} When a user double-clicks on the map, the map will be zoomed in by one zoom level. The geographic position of where the double-click ocurred is now the new centre of the scaled map view.
        \texorhtml{\item [b)]}{\item b)} With double-click animation the zoom and pan processes are combined. This requires only an animation of the zoom process; the panning occurs before zooming without animation. 
        \end{itemize}

	\item Zoom Animation with Mousewheel
        \begin{itemize}
        \texorhtml{\item [a)]}{\item a)} By turning the mouse wheel up (ie. away from the user) or down (ie. towards the user), the user is able to zoom into/out of the map by exactly one zoom level.
        \texorhtml{\item [b)]}{\item b)} As per the \textit{Smart Map Browsing} definition of mouse wheel zooming properties (see Section \ref{smb_eigenschaften}), zooming per mouse wheel is described as follows:            
            \textit{\frz{The geographic position below the cursor at the time of mouse wheel operation remains at the same pixel position after the zoom has been completed.}}
        \end{itemize}

	\item Zoom Animation with Zoom Box
        \begin{itemize}
        \texorhtml{\item [a)]}{\item a)}Once the user has pulled up a map area and released the left mouse key, the map is zoomed to a level that displays this selected area.
        \texorhtml{\item [b)]}{\item b)} Using the zoom box tool to click on the map (without pulling the zoom box into the map) results in a zoom action equal to one zoom level. The geographic position of where the click occured now becomes the new center point of the map.
        \texorhtml{\item [c)]}{\item c)} In zoom box animation zooming and panning processes are combined. Only an animation of zoom processes is required however; panning occurs before zooming without animation.
        \end{itemize}

	\item Zoom Animation with Keyboard
        \begin{itemize}
        \texorhtml{\item [a)]}{\item a)} Pressing the + or -- key results in a one level zoom increase/decrease. 
        \end{itemize}
\end{enumerate}

\T\enlargethispage{2\baselineskip}
The following is valid for each zoom animation:\\
The animated zoom process occurs automatically within a defined time period. The zoom slider moves in sync with the animation until the desired position (up or down) is reached. Once the map is at its highest/lowest zoom level, no additional zoom-out or zoom-in animation is possible. During the zoom animation the marker in the overview map adjusts itself continuously to the section of the main map. As long as the zooming animation is active, no additional zoom processes can be activated.


\newpage
\T\enlargethispage{3\baselineskip}
\section{Technical Analysis of \textit{OpenLayers}}
\label{analyse_OL}	
At this point the functionality of \textit{OpenLayers} will be examined in more detail. The purpose of this analysis is to increase the understanding of the application as well as to serve as a premise for the subsequent conceptualization and implementation.


\subsection{General}
\label{OL_allgemein}
\textit{OpenLayers} is a pure JavaScript API for the creation of web mapping applications; it also offers support for the use of numerous (standardized) formats (OGC WMS, OGC WFS, GeoRSS, ka-Map, WorldWind and many more) which are integrated as layers into \textit{OpenLayers}. 

In addition, \textit{OpenLayers} features panning and zooming of maps, client-side tiling, markers, \frz{popup windows}, various adjustable navigation components, keyboard commands, a robust event handling mechanism and more. Each part of \textit{OpenLayers} is configurable \texorhtml{\citep}{\cite}{OLosgeo}.

A Python/Shell-based script enables the automatic creation of a  \textit{lite} version of \textit{OpenLayers}, whereby selected classes can be integrated into one single JavaScript file \texorhtml{\citep}{\cite}{OLprofiles}.
This is a result of a discussion that took place in September 2006 at the FOSS4G Conference, where such a solution called \textit{webmap.js} was requested \texorhtml{\citep}{\cite}{webmap.js, webmap.js-discuss}.

The target group for \textit{OpenLayers} includes all users or developers who wish to display a map on the Internet, or build a map-based Internet application \texorhtml{\citep}{\cite}{OLosgeo}.


\subsubsection*{History}
The February 2005 release of \textit{Google Maps} drew a lot of attention. As a result of numerous \textit{reverse engineerings} of \textit{Google Maps} codes 
(by Phil Lindsay, among others\footnote{\url{http://stuff.rancidbacon.com/gmaps-standalone}
\checkURL}) Google responded with its first \textit{Google Maps}
API\footnote{\url{http://www.google.com/apis/maps} \checkURL} in June 2005. However, the possibility for commercial implementation did not exist 
\texorhtml{\citep}{\cite}{ramsey2006,OLbusiness}.

Recognizing this deficiency, the US company \textit{MetaCarta}, in cooperation with Phil Lindsay, developed a first prototype of the eventual \textit{OpenLayers} which was presented in late June 2005 at the \textit{Where 2.0} Conference in San Francisco\footnote{\url{http://conferences.oreillynet.com/cs/where2006/view/e_sess/9310}
\checkURL}. One year later, shortly after the June 2006 \textit{Where 2.0} in San Jose, the team headed by developers Schuyler Erle, Chrisopher Schmidt and Erik Uzureau released the first official version (1.0) of \textit{OpenLayers}  on July 5, 2006. Not long after, in August 2006, Version 2.0 of the project was released\texorhtml{\citep}{\cite}{OLosgeo,OLbusiness}.

At present \textit{OpenLayers} is undergoing the incubation process at the independent \textit{Open Source 
Geospatial Foundation (OSGeo)}, with the goal of being accepted as a software project by the summer of 2007.  Parallel to this process, serious efforts are being made to integrate key functions of  \textit{OpenLayers} into other Free web mapping applications \texorhtml{\citep}{\cite}{OLosgeo} -- with ongoing discussions at \textit{ka-Map}\footnote{
\url{http://lists.maptools.org/pipermail/ka-map-users/2006-June/001729.html}
\checkURL}$^,$\footnote{\url{http://ka-map.ominiverdi.org/wiki/index.php/OpenLayers_ka-Map_Merge}
\checkURL},
\textit{Mapbuilder}\footnote{
\url{http://geoservices.cgdi.ca/mapbuilder/demo/openlayers/index.html}
\checkURL} and 
\textit{Mapbender}\footnote{\url{http://www.mapbender.org/index.php/Open_layers}
\checkURL}. 




\subsection{Class Overview}
\label{klassenuebersicht}
\T\enlargethispage{3\baselineskip}
Because of its object-oriented programming, the API of \textit{OpenLayers} is divided into a multitude of classes, of which the main ones are briefly described below. The remaining classes are not discussed in any further detail, as they are not a requirement for a basic understanding of API. More detailed information can be found in the 
\textit{JSDoc} documentation\footnote{
\url{http://dev.openlayers.org/docs/overview-tree.html} \checkURL}. A complete classification diagram of \textit{OpenLayers}
(Version 2.4 RC5; as of May 25, 2007) can be found in Appendix~\ref{anhang:klassendiagramm}\texonly{ on page
\pageref{anhang:klassendiagramm}}.


\begin{description}
        
     
    \item[OpenLayers.Map] is the main class of the \textit{OpenLayers} API. It
        compiles the application's main map and provides numerous methods for 
        the administration of the map display, including the display of layers 
        and operating components, zooming and panning. In addition, this class 
        allows for queries of current map status through numerous 'get' methods. 

   \item[OpenLayers.Layer:] Layers represent the most significant component of 
 \textit{OpenLayers}. All map displays are based on the \textit{Layer} class. 
        \textit{Layer.js} produces individual layers, sets the transparency and 
        resolution of each, and provides the basic 'get' methods.\\
        \textit{OpenLayers.Layer} serves as the primary class for a number of 
        special subclasses. 
        Version 2.4 RC5 of \textit{OpenLayers} supports the following layer 
        types:
        Free tile-based layers (\textit{WMS, MapServer, KaMap,
        TMS, WorldWind}), Free untiled layers (\textit{WMSUntiled,
        MapServerUntiled}), proprietary third-party layers 
        (\textit{Google, VirtualEarth, Yahoo, MultiMap}) as well as the layers
        \textit{Image} (for displaying raster graphics) and \textit{Canvas} (for 
        drawing of colored lines, only Overlay display is possible). 
        
        Below four layer classes are described in more detail:

        \textit{OpenLayers.Layer.Grid}\\
        Derived from the \textit{HTTPRequest} class, \textit{Grid} serves as one 
        of the important primary classes for the above-mentioned Free 
        tile-based layers.  \textit{Grid.js} divides the layers into tiles, 
        holds them in an array, and loads them as a spiral-like sequence 
        beginning from the middle.

        \textit{OpenLayers.Layer.WMS}\\
        As a subclass of \textit{Grid}, \textit{WMS} receives the URL of the 
        WMS servers and is responsible for generating the individual tile WMS
        URL's based on the desired tile boundaries (\textit{bounds}).

        \textit{OpenLayers.Layer.WMS.Untiled}\\
        The \textit{Untiled} class displays the complete map section in a WMS
        tile URL. Note that many WMS servers will have a pre-defined maximum 
        tile size of 2048 pixels; if  \textit{OpenLayers} requests a larger map 
        section, the WMS server will send an error message and the map view 
        will remain empty.

   
        \textit{OpenLayers.Layer.Image}\\
        Derived from \textit{Layer}, the \textit{Image} class permits the 
        display of individual bitmap graphics as map layers. Besides a URL, the 
        pixel size as well as the geographic dimension of the requested picture 
        are also required.
        \T\enlargethispage{\baselineskip}

    \item[OpenLayers.Control:] Operating elements in \textit{OpenLayers}
        are elements related to map navi\-gation as well the display of map 
        information (e.g. scale). The \textit{Control} class serves as a base 
        class for all operating elements, among them: 

        \textit{OpenLayers.Control.PanZoom}\\
        generates pan/zoom navigation with a panning pad (4 arrow buttons), as
        well as a ZoomIn, ZoomOut, and ZoomReset button. The 
        \textit{slideFactor} parameter defines the number of pixels used 
        during the panning processes.

		\textit{OpenLayers.Control.PanZoomBar}\\ 
		generates a pan/zoom bar with a pan navigation panel as well 
		as a zoombar with a zoom slider containing a ZoomIn and ZoomOut button 
		at each end. (see Section~\ref{img:webmappingComponents}\texonly{ on page 
		\pageref{img:webmappingComponents}}).\\
		The zoom bar is integral to the development of \textit{animated 
		zooming} features. For this reason its functionality is described in 
		more detail.\\ There are three ways to use the zoom bar: 
        \begin{enumerate} 
            \item Click on the + or -- button located at each end of the zoom
		 		bar.\\This results in an increase/decrease of the map view by one
		 		zoom level.
				\item Click anywhere on the zoom bar.\\ 
                The slider moves to the nearest predefined zoom level. The map 
				is redrawn to the corresponding zoom level.  
            \item Use Drag\&Drop to move zoom slider smoothly over the zoom
				 bar.\\
				Upon releasing the left mouse key, the slider positions itself on 
				the next available zoom level, and the selected map view is redrawn 
				to the corresponding zoom level.
        \end{enumerate}
				

		\textit{OpenLayers.Control.OverviewMap}\\ 
        generates a small overview map 
        (see Section~\ref{img:webmappingComponents}\texonly{; pg. 
        \pageref{img:webmappingComponents}}). This map shows the current view of 
		the main map and serves as a positioning and navigational tool. The 
		overview map is usually located in the lower right hand side of the map 
		and can be minimized by pressing a button on the map edge. This class 
		provides the functions needed for querying and setting of the selection 
		rectangle, which can be moved by way of defined mouse events.

        \textit{OpenLayers.Control.KeyboardDefaults}\\
        defines type and activities of (keyboard) key commands.
        
        \textit{OpenLayers.Control.MouseDefaults}\\
        defines map activity during mouse events. 
        This includes click, double-click, mouse wheel and mouse movement events.
        \T\enlargethispage{2\baselineskip}
        
    \item[OpenLayers.Tile:] When a map is tiled, each tile is defined by a 
    \textit{Tile} object. To generate a tile, the corresponding layer, pixel 
        position, geographic tile dimensions, the URL and pixel size of the tile 
        are required. The standard tile size is 256 pixels. An option available 
        during map initialization allows for a change of the standard size.

              
        \textit{OpenLayers.Tile.Image}\\
        Derived from the \textit{Tile} class, the \textit{Tile.Image} object 
        presents the proper tile graphic and creates an img-Div-HTML element for 
        each tile during the drawing of the map.
        
    \item[OpenLayers.Events] 
        takes over the event handling from \textit{OpenLayers}.        
    
    \item[OpenLayers.Pixel]	
        displays monitor coordinates in n x- and
        y- pixel values.

    \item[OpenLayers.Size]	
        displays a pixel size value pair in width and height.

    \item[OpenLayers.LonLat]
        displays geographic coordinates in \textit{longitude} and \textit{latitude}.
    
    \item[OpenLayers.Bounds]	
        displays a rectangular area (\textit{bounding box}) whose four sides (left, below, right, above) are indicated with geographic coordinates in \textit{float} format. The \textit{Bounds} class provides different get-functions (e.g. center and pixel dimensions of the \textit{bounding box}) as well as comparative functions (e.g. whether a pixel is located within the defined \textit{bounding box}).

    \item[OpenLayers.Util]
        contains the different functions and settings which cannot be assigned to any of the other\textit{OpenLayers} classes.

\end{description}



\newpage
\subsection{Unit Tests}
\label{OL_unittests}
\textit{OpenLayers} uses the  \textit{Test.AnotherWay}\footnote{\url{http://straytree.com/TestAnotherWay/doc}
\checkURL} framework for unit tests. Version 2.4 RC5 of \textit{OpenLayers}
(as of May 25, 2007) supplies almost 1500 unit tests, which are controlled over a central web interface\footnote{
\url{http://openlayers.org/dev/tests/run-tests.html} \checkURL}.
The framework offers the ability to test HTML and
JavaScript source codes, and also provides the test results.

Each HTML test page contains one or more JavaScript test functions which start with \texttt{test\_}; they must also define a test object \texttt{t} as the transfer parameter \texorhtml{\citep}{\cite}{TestAnotherWayDoc,OLunittests}.\\

\begin{latexonly}
\begin{lstlisting}[caption=A sample of a simple test page with a test function, label=lst:testfunction, firstnumber=11]
<html>
<head>
    <script src = "../lib/OpenLayers.js"></script>
    <script type = "text/javascript">  
        function test_Map_Zoom(t) {
            t.plan(1);
            var map = new OpenLayers.Map("map");
            var layer = new OpenLayers.Layer.WMS("ABC", 
                                                 "http://example.com/123", 
                                                 {'layers':'test'});
            map.addLayer(layer);
            map.zoomTo(0);
            t.eq(map.zoom, 0, "Map zoomed to level 0 correctly.");
        }
    </script>
</head>
<body>
    <div id="map" style="width: 512px; height: 512px;"/>
</body>
</html>
\end{lstlisting}
\end{latexonly}

\begin{ifhtml}
\label{lst:testfunction}    
Listing: A sample of a simple test page with the a function
\begin{example}
<html>
<head>
    <script src = "../lib/OpenLayers.js"></script>
    <script type = "text/javascript">  
        function test_Map_Zoom(t) {
            t.plan(1);
            var map = new OpenLayers.Map("map");
            var layer = new OpenLayers.Layer.WMS("ABC", 
                                                 "http://example.com/123", 
                                                 {'layers':'test'});
            map.addLayer(layer);
            map.zoomTo(0);
            t.eq(map.zoom, 0, "Map zoomed to level 0 correctly.");
        }
    </script>
</head>
<body>
    <div id="map" style="width: 512px; height: 512px;"/>
</body>
</html> 
\end{example}
\end{ifhtml}


Listing \ref{lst:testfunction} shows a sample test page which can be used for a simple testing of an \textit{OpenLayers} function.
On line 6 the test function defines the number of planned tests (here: one), with the expectation that they will be completed correctly. If the number does not match the number of actual tests, the test function is not successful.  Lines 7 to 12 produce a map with a WMS layer, at zoom level 0. Line 13 tests the assertion that the map is actually at zoom level 0.

\newpage
The testing framework provides five methods for the testing of self-defined assertions:

\begin{itemize}
    \item \texttt{t.ok(boolean, ``String for output'')}\\
        The test is successful if the assertion 
        \texttt{boolean} is true.
    \item \texttt{t.eq(value1, value2, ``String for output'')}\\
        The test is successful if the \texttt{value1} value corresponds with the 
        expected \texttt{value2} value.
    \item \texttt{t.like(string, regEx, ``String for output'')}\\
        The test is successful if \texttt{string} corresponds with the regular
        term \texttt{regEx}.
    \item \texttt{t.html\_eq(HTML1, HTML2, ``String for
        output'')}\\
        The test is successful if \texttt{HTML1} corresponds with the expected 
        value \texttt{HTML2}; each HTML can be stated as 
        DOM Element or HTML string.
    \item \texttt{t.fail(``String for output'')}\\
        Used for a deliberate test failure; expects only output string.
\end{itemize}
Examples and additional information on the functionality of the framework can be found in the \texorhtml{\citep}{\cite}{TestAnotherWayDoc} documentation.










%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%   *** KONZEPT ***
%   #4
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Concept}
The previous sections of this thesis provided a current state analysis as well as an overview of the functionality of \textit{OpenLayers}. The purpose of this chapter is to draft an implementation concept for the \textit{animated zooming} feature.

\section{Objectives}
The objective of the practical part of this thesis is to implement a new \textit{Smart Map Browsing} extension for the Free JavaScript web mapping application \textit{OpenLayers}.

The new \textit{animated zooming} feature is intended to expand the functionality of \textit{OpenLayers} with a user-friendly zooming extension:
On moving the zoom slider, the scale of the main map is simultaneously and smoothly adjusted to the most current slider position, thereby re-scaling the map by enlarging or reducing it. Once the slider is released, the map is redrawn at the new zoom level. An improvement in the user's orientation during zooming is an important objective for this extension.

Cooperation with the developers of \textit{OpenLayers} is desired to achieve an optimal benefit level for this feature. In this process suggestions made by the developers would also be taken into account. The goal is the adaption of the \textit{animated zooming} features into the current SVN developer's version, with the eventual objective of making it a part of the next official version of \textit{OpenLayers}.


\section{Functionality}
\label{funktionsweise}
At this point the conceptualized \textit{animated zooming} scale model is introduced in detail.
The discussion starts with a description of the full zooming process using a zoom slider, followed by a description of the special features of the ZoomOut process.\\

\newpage
Suppose $Z_n$ is the current zoom level of the main map, \math[Z_{max}]{Z_{\rm{max}}} the maximum ZoomIn level, 
and \math[Z_{min} = 0]{Z_{\rm{min}} = 0} as the minimum ZoomOutlevel, for which the following applies:\\
\math[Z \htmlsym{isin} N]{Z \in \mathbb N} and
\math[Z_{min} \htmlsym{le} Z_{n} \htmlsym{le} Z_{max}]{Z_{\rm{min}} \le Z_{n} \le Z_{\rm{max}}}

The following steps describe the developed scaling model as well as the exact process involved in using the zoom slider. A state diagram (Figure \ref{img:statediagram}\texonly{; pg.
\pageref{img:statediagram}}) and an activity diagram (Figure \ref{img:activitydiagram}\texonly{; pg.
\pageref{img:activitydiagram}}) illustrate this model. The individual steps involved are referenced by the numbers contained in the processes of the activity diagram: 

\T\enlargethispage{2\baselineskip}
\begin{enumerate}
	\item The user points the mouse on the zoom slider, presses and holds down 
		the left mouse key. As soon as he/she releases the key, the process is 
		stopped and completed with Step 8.
	\item The current zoom level $Z_n$ is determined.
	\item All tiles $k$ within zoom level $Z_n$, which are fully or partially 
		located in the visible area, as well as all pre-loaded tiles which border 
		on this area, are determined.
	\item The user decides on a zoom direction (ZoomIn
		or ZoomOut).
	\item At this point the compatibility of the decision made in (4) with the 
		current zoom level $Z_i$ (in the first round $Z_i = Z_n$) is verified, ie. if
        \math[Z_i = Z_{min}]{Z_i = Z_{\rm{min}}}, respectively
        \math[Z_i = Z_{max}]{Z_i = Z_{\rm{max}}}, then ZoomOut or ZoomIn
		is not possible. In this case, a new zoom direction must be selected (Step 4). Otherwise the process continues with step (6).
	\item The corresponding zoom-scale process occurs in tandem with the zoom slider operation (in the direction chosen in (4)):
		\begin{itemize}
            	\texorhtml{\item [a)]}{\item a)} New zoom slider position $P_i$ is determined.
		\texorhtml{\item [b)]}{\item b)} New zoom level $Z_i = Z(P_i)$ is calculated.
		\texorhtml{\item [c)]}{\item c)} New (scaled) tile size $K(Z_i)$ of the current zoom level $Z_i$ is calculated on the basis of $Z_n$. The following rules apply:
                \begin{latexonly}
                \begin{eqnarray}
                    K(Z_i) & = & 2^{Z_i - Z_n} * K(Z_n)  \qquad
                    \rm{f"ur} \ \it Z_n < Z_i \\
					K(Z_i) & = & K(Z_n)  \qquad	\qquad \qquad \! 
                    \rm f"ur \it \ Z_n = Z_i \\
                    K(Z_i) & = & \frac{1}{2^{Z_n - Z_i}} * K(Z_n)
                    \qquad \! \rm f"ur \it \ Z_n > Z_i
					\label{eq:kachelgroesse}
				\end{eqnarray}
                \end{latexonly}

                \begin{ifhtml}
                    ~\\
                    $K(Z_i) = 2^{Z_i - Z_n} * K(Z_n)$ für 
                    $Z_n < Z_i$\\

                    $K(Z_i) = K(Z_n)$ für $Z_n = Z_i$\\

                    $K(Z_i)  = 1 / (2^{(Z_n - Z_i)} * K(Z_n))$ für  
                    $Z_n > Z_i$\\
                \end{ifhtml}

				Starting with zoom level $Z_n$ the tile size $K(Z_n)$ is doubled 
				with every new zoom level (for $Z_n<Z_i$; see equation 4.1) or 
				halved (for $Z_n>Z_i$; see equation 4.3) so as to obtain the new 
				tile size $K(Z_i)$ for the currently active zoom level $Z_i$. At 
				equal zoom levels ($Z_n=Z_i$) the tile sizes are of equal size (see 
				equation 4.2).

				Note: The individual zoom levels serve only as defined interim 
				values. The actual scaling process occurs continuously.
		\texorhtml{\item [d)]}{\item d)} During the ZoomIn or ZoomOut process 
				all currently loaded (visible and non-visible) tiles are scaled to 
				the calculated tile size $K(Z_i)$ (more accurately: expanded or 
				shrunk).
		\texorhtml{\item [e)]}{\item e)} \textbf{Only for ZoomOut:} 
				As soon as all tiles $k$ (as defined in (3)) are sized to a 
				level where all are part of the visible area, additional tiles must 
				be loaded in the background to avoid the creation of a white border
				during ZoomOut. 
				A more detailed discussion on tile preloading in ZoomOut processes 
				is provided in the following paragraph \frz{Special Features of
		 		ZoomOut}.
              
		\end{itemize}
	\item As long as the left mouse key is held down (see Step 1), the user can 
		change the zoom direction at any time, which brings the process back to (4).
		Once the mouse key is released, the zoom process is completed with (8).
	\item The visible area is redrawn in the new zoom level $Z_i$ including all 
		required tiles (using standard tile size $K(Z_n)$). In addition (according 
		to the principles outlined in the tiling method; see Section 
		\ref{webmapping_tiling}), all adjacent non-visible tiles are preloaded at 
		the same size. This completes the zoom process.
\end{enumerate}
\T\enlargethispage{2\baselineskip}
\begin{figure}[htbp] \begin{center}
			\T\includegraphics[width=13cm]{images/uml/statediagram_en.eps}
            \W\htmlimage{images/uml/statediagram_en.png}
			\caption{State Diagram of Zoom Process Using Slider}
			\label{img:statediagram} \end{center} \end{figure}
\W ~\\\\
\begin{figure}[htbp] \begin{center}
			\T\includegraphics[width=15.4cm]{images/uml/activitydiagram_en.eps}
            \W\htmlimage{images/uml/activitydiagram_en.png}
			\caption{Activity Diagram of Zoom Process Using Slider}
			\label{img:activitydiagram} \end{center} \end{figure}

\newpage
\subsubsection*{Special Considerations for ZoomOut}
Two solutions regarding the preloading of tiles in Steps 6e of the zoom process are introduced. The objective is to ensure quick tile loading (ie. without delay) and thereby eliminate the creation of a white border around a now smaller map. 
\begin{itemize}
    	\texorhtml{\item [A)]}{\item A)} As soon as a previously non-visible tile of $k$ 
		becomes part of the visible area, all non-visible tiles are newly 
		defined and preloaded in the background at zoom level $Z_n$. 
		They are stored as new, non-visible tiles in the DOM tree. All 
		loaded tiles are immediately adjusted to thr current scale, ie. 
		they are simultaneously adjusted to the same scale as the remaining tiles 
		(where the calculated tile size is $K(Z_i)$).



		The disadvantage: the zooming process requires a continuous loading of a 
		large number of tiles which also have to be scaled in accordance with the 
		remaining tiles. Therefore it is likely that performance is negatively 
		impacted by an increased number of tiles.
	\texorhtml{\item [B)]}{\item B)} A special feature of the second solution is a 
		newly defined \frz{ZoomOut tile}. In addition to the tiles $k$ described 
		in Step 3, during initialization of the application \textit{one} 
		additional tile $k_*$ is loaded for the purpose of executing the Zoom Out 
		process.
        $k_*$ shows the geographic dimension of the complete map on one tile.
        The pre-defined tile pixel size $K_*$ of $k_*$ is to be larger than the pr-edefined tile size $K_k$ of all tiles $k$ by a factor of $x$:
		$K_* = x * K_k$, whereby 
        \math[x \htmlsym{ge} 1]{x \ge 1}
        and 
        \math[x \htmlsym{isin} R]{x \in \mathbb R}. A suitable value for $x$ is dependent on the size of the whole map as well as the number of possible zoom levels; it is determined in the implementation (see Section~\ref{zoomOut-Kachel}).
		The center of the whole map is the geographic center of $k_*$. 
		
		The objective of this approach is to reduce the time-consuming reloading
 		of tiles during a on-the-fly zoom-out procedure (featured in Solution (A)). 
		Instead, $k_*$ is used as a kind of base tile, with which the majority of 
		the scale processes can be executed. This way, it is no longer necessary 
		to keep loading and scaling new tiles in order to  \frz{fill in} the white 
		area that would otherwise appear, especially since the high level of 
		detail on these tiles is not even required for ZoomOut scaling.

        At a certain level of magnification, however, the extensive 
        \frz{pixelation} of $k_*$ will be a disadvantage. Depending on the zoom 
        level intervals this can lead to an inability to identify map sections 
        during high-scale processes.
\end{itemize}



\newpage			
\section{Technical Framework Requirements}
\label{technischeRahmenbedingungen}
The \textit{OpenLayers} demo 
\textit{controls.html}\footnote{\url{http://www.openlayers.org/dev/examples/controls.html}
\checkURL} serves as the basis for the implemention of the \textit{animated zooming} feature. Adaptations are possible.
The following layers (along with their map sources) are used:
\begin{itemize}
    \item \textbf{WMS-BaseLayer} (default):
        \url{http://labs.metacarta.com/wms/vmap0}
    \item \textbf{WMS Untiled-BaseLayer}:
        \url{http://labs.metacarta.com/wms/vmap0}
    \item \textbf{Image-BaseLayer}:
        \url{http://earthtrends.wri.org/images/maps/4_m_citylights_lg.gif}
    \item \textbf{WMS-Overlay}:
        \url{http://www2.dmsolutions.ca/cgi-bin/mswms_gmap}
\end{itemize}

\subsubsection*{Expandability}
\label{erweiterbarkeit}
The implementation takes into account a possible expandability of the application at a later date. In particular, the should-have criteria outlined in Section \ref{anforderungsanalyse_wunsch} are to be integrated into the conceptualized \textit{animated zooming} feature with as little effort as possible. 
The \textit{animated
panning} feature\footnote{\url{http://trac.openlayers.org/ticket/110}
\checkURL} developed by \textit{OpenLayers} (currently still in review stage) serves as a component for the implementation of the automatic zoom animation. The algorithm for the time-dependent calculation of force movement curves (rapid start, damped finish) is to be extended in such a way that it can used for the zoom animation process. A combination of pan and zoom animation processes should also be possible.

Because of the different types of layers (see Section \ref{klassenuebersicht}) supported by \textit{OpenLayers} an individual treatment of each different scale action is required.  Identical source code can be stored in the base class \textit{Layer.js}. Layer-specific zoom activity can be treated with individual (overwritten) methods so that only the new layer class has to be adapted during the integration of new layer types. Changes in the key functions is not required, ensuring a fairly easy expandability of the \textit{animated zooming} feature.





\newpage
\T\enlargethispage{2\baselineskip}
\section{Development Guidelines in \textit{OpenLayers}}

The development guidelines of the \textit{OpenLayers} project are clearly defined:

By following specific rules \footnote{\url{http://trac.openlayers.org/wiki/FilingTickets}
\checkURL} anyone can use the Ticket System\footnote{\url{http://trac.openlayers.org/query}
\checkURL} of \textit{OpenLayers} to advise of bugs or suggestions for new features. 
A finished patch file \footnote{\url{http://trac.openlayers.org/wiki/CreatingPatches}
\checkURL} correcting the bug or implementing the feature is attached to the generated ticket; the ticket status is set to \textit{review}. A summary of implemented changes should then be circulated through the developers' mailing list, where they can be discussed and if need be, further modified. If no modifications are required, the patch is tested (and changed, if required) by one or more authorized \textit{project committers} and subsequently integrated into the most current SVN developer's version, the \textit{Trunk} \texorhtml{\citep}{\cite}{OLcontribute}.

Registered developers can set up their own SVN sandbox for testing and demonstration purposes. Each sandbox is independent of the Trunk. Within the confines of the sandbox developers have unlimited room for action and are not required to follow any guidelines.

Presently, the \textit{Project Steering Committee (PSC)} of \textit{OpenLayers} consists of seven members\footnote{\url{http://trac.openlayers.org/wiki/SteeringCommitteeMembers}
\checkURL}. They supervise the project process and implement decision making processes that reflect the spirit of the community.  Major decisions, such as substantial source code changes, changes to backward compatibility, dates of new releases, or the clarification of procedural questions are subject to a vote by the committee members. Each person in the \textit{OpenLayers} community can use the developer's mailing list to submit or comment on proposals, however, only committee members are allowed to vote. The voting process is subject to clearly defined rules, with the possible voting values listed below \texorhtml{\citep}{\cite}{OLcommittee}:
\begin{description}
    \item[\texttt{+1}] Fully support for the proposal, willingness for active collaberation
    \item[\texttt{+0}] Support for the proposal, but no willingness for active collaberation
    \item[\texttt{~0}] No opinion
    \item[\texttt{-0}] Mild disagreement of proposal, but will not block
    \item[\texttt{-1}] Veto;  refusal of proposal
\end{description}

A proposal is accepted if the total sum of voting results totals is at least +2 and there are no veto votes (ie.\texttt{-1}). When submitting a veto, the voter has to provide a clear reason for the veto and, within two days, an alternative for the solution to the problem. In cases of considerable debate, the decision rests with the committee chairman\texorhtml{\citep}{\cite}{OLcommittee}.

The implementation of the \textit{animated zooming} features is carried out on the basis of the above-mentioned developer's guidelines. Regular communication on available interim versions through the developer's mailing list is meant to ensure that the  \textit{OpenLayers} community is part of the development process. It also ensures that suggested changes or suggestions made by developers can be taken into account as quickly as possible. Furthermore, the transparency of this process results in the best possible acceptance of the feature. At this stage it is important to note that the \textit{animated zooming} feature is merely intended to extend the existing API, therefore fundamental changes in the key components of \textit{OpenLayers} will not be required. At the same time, the analysis of the source codes by other developers also servers as a quality assurance system.



\section{Test Methods}


\subsection{Component Tests}
\label{konzept_komponententests}
Component tests support the development process of the planned extension. 
For this purpose, the \textit{Test.AnotherWay} framework used by \textit{OpenLayers} will be applied (see Section \ref{OL_unittests}). The purpose of the unit tests is to verify the soundness of all functions and classes, and to serve as part of the quality assurance process. The intention is a \textit{test first development}, with the component tests created alongside the actual source text.

During the compilation of unit tests for the \textit{animated zooming} feature the special nature of the automatic zoom animation needs to be taken into account: in order to achieve automatic animation, a time-dependent component which directs this process is required in the API source code.
The JavaScript function \textit{window.setInterval} ensures a constantly recurring infinite cyclical execution of a particular function along with interconnected breaks. This function can be interrupted with \textit{window.clearInterval}. To test these asynchronous function commands in the source code with component tests, \textit{Test.AnotherWay} offers the method  
\textit{delay\_call} which supports two arguments: the waiting period between function commands in seconds, and the executable function. If a time is not indicated, a time delay of .2 seconds applies. For a successful testing procedure, the sample test function of Listing \ref{lst:testfunction} has to be modified for the zoom animation as follows:\\
\T\enlargethispage{\baselineskip}

\begin{latexonly}
\begin{lstlisting}[caption=Sample test taking into account asynchronous function commands, label=lst:testfunctionDelay, firstnumber=11]
    ...
            map.zoomTo(0);
            /*t.delay_call(1, function() {*/
                t.eq( map.getZoom(), 5, "map.zoom is correct after calling zoomTo" );
            /*});*/
    ...
\end{lstlisting}
\end{latexonly}
\begin{ifhtml}
\label{lst:testfunctionDelay}    
Listing: Sample test function taking into account asynchronous function commands
\begin{example}
    ...
        map.zoomTo(0);
            t.delay_call(1, function() {
            t.eq( map.getZoom(), 5, "map.zoom is correct after calling zoomTo" );
        });
    ...    
\end{example}
\end{ifhtml}

\newpage
\subsection{Integration Tests}
\label{testplan}
After the component tests are complete, as a quality assurance measure integration tests are used to check the interaction of numerous (tested) unit components. A test plan describes the action of selected test cases, which are carried out after the implementation has been completed. The plan is divided into different test suites to achieve a logical division of the functions to be tested. Each test suite can be carried out separately. It is divided into different working steps (test cases) and expected results, which are checked during the implementation of the test cases. If a result deviates from an expected performance, the test suite will fail.

A test plan for the \textit{animated zooming} extension is developed on the basis of the requirements analysis (see Section \ref{anforderungsanalyse}). A complete listing of all \textit{possible} scenarios which could apply for the use of the feature would be too extensive for the purposes of this thesis. Accordingly, the test plan focuses on the typical and extreme cases of zoom performance. Application functionalities which are independent of the implemented feature are not considered in the test plan. They are verified as part of the component tests and ideally should not be impaired by the implementation. To ensure comparability of the tests, they are carried out with the  \textit{OpenLayers} demo \textit{controls.html}. For each test the tester documents the date, operating system, browser, name of tester, test duration and applicable comments.

The complete test plan for the \textit{animated zooming} and \textit{panning} extensions can be found in Appendix \ref{anhang:testplan} \texonly{(pg. \pageref{anhang:testplan}
and following)}. The \textit{animated panning} was included in the tesplan because at the time of conceptualization and implementation the review process by the \textit{OpenLayers} developers had not yet been completed. For this reason, a separate quality assurance process was carried out to verify the correctness of the extension.

Note: Once the implemention was complete, the plan was updated in view of actually implemented criteria, which led to an expanded version of the test plan. A more detailed discussion of the implementation and the associated updates to the test plan follows in the next chapter.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%   *** REALISIERUNG ***
%   #5
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Realization}
\label{realisierung}


This chapter addresses the implementation of the concept described in the previous chapter. The realization process is divided into preparation, implementation, testing, and problems. 


\section{Preparation}
To start, a new  \textit{OpenLayers} user account and SVN sandbox are created\footnote{\url{http://trac.openlayers.org/wiki/FrequentlyAskedQuestions} \checkURL}.The sandbox is freely accessible at \url{http://svn.openlayers.org/sandbox/emanuel/}.
A current version of the trunk is copied into the sandbox and serves as the basis for further development. The sandbox allows for its own source code administration and executes an automatic checkout into the public directory\url{http://dev.openlayers.org/sandbox/emanuel/}. This enables other developers to test the source code directly in the webbrowser without having to first perform a svn checkout. 

The actual implementation is carried out in a checked-out sandbox version on a Debian GNU/Linux system. No installation is required;  \textit{OpenLayers} runs without a web server in any local directory. An internet connection is required to work with the map layers described in Section~\ref{technischeRahmenbedingungen}. Firefox web broser is used for testing during the development phase. In addition, the Firefox plugin \textit{Firebug}\footnote{\url{http://www.getfirebug.com}
\checkURL} is used to debug JavaScript code, visualize individual HTML-Div elements, and to test the DOM tree. The \textit{OpenLayers} sample demo is adapted to the selected layers (see Section~\ref{technischeRahmenbedingungen}).


\section{Implementation}
\label{implementierung}


The ensuing description is based on the utilization of a tiled WMS layer, and is divided into implementation steps that build on each other. The steps will be described in separate sections. 

The developed \textit{animated zoom\-ing} und \textit{panning} extension was updated to the \textit{OpenLayers} Version 2.4 RC5 
(as of May 25, 2007); it is available through:
\begin{itemize}
     \item the above-mentioned SVN sandbox (Revision 3197 of May 28, 2007);\\
either by checkout:  
\texorhtml{\scriptsize}{\normalsize} svn co -r3197 http://svn.openlayers.org/sandbox/emanuel/animatedZooming/\\
\normalsize or online per TracBrowser: 
\texorhtml{\scriptsize}{\normalsize} \url{http://trac.openlayers.org/browser/sandbox/emanuel/animatedZooming}, and


   \item \normalsize the attached CD-ROM in Appendix \ref{anhang:cd}, which is a copy of the sandbox revision 3197.
\end{itemize}



All subsequently indicated source code references refer to Revision No. 3197. The sample demo \textit{demo.html} contained in the root directly was updated according to Section~\ref{technischeRahmenbedingungen} and can be run directly off the CD or the current sandbox version
(\url{http://dev.openlayers.org/sandbox/emanuel/animatedZooming/demo.html}).

The classification diagram in Appendix \ref{anhang:klassendiagramm} highlights in color all classes that have been changed for the purposes of implementing the \textit{animated zooming} and
\textit{panning} extensions. In addition, all edited methods are listed. The diagram is also based on Version 2.4 RC5 of \textit{OpenLayers} (as of May 25, 2007).




\T\lstset{columns=flexible}
\T\lstset{language=JavaScript}

\subsection{Zoom Slider Events}
\label{zoomsliderevents}

The three event steps necessary for the use of the zoom slider in the \textit{PanZoomBar.js} are as follows: 
\textit{MouseDown} -- \textit{MouseMove} -- \textit{MouseUp}.

In the \textit{MouseDown} event the current zoom level (before zooming) is stored in the \textit{Map} object property
\texorhtml{\lstinline{zoomlevel_startScale}}{\code{zoomlevel_startScale}}. This value forms the basis calculation for the scaling process.

If the \textit{MouseMove} event is activated through a movement of the slider, the following three values are re-calculated with every change in movement:
\begin{enumerate}
    \item \textbf{Slider position}:\\
        The currently active mouse position forms a pixel value pair whose 
        y-value indicates the slider position. Values located outside of the 
        zoom bar are intercepted (see \textit{zoomBarDrag()}; \textit{PanZoomBar.js}).
       	\html{br}
	
    \item \textbf{Zoom Level}:\\
        The difference between slider start position and current slider position 
        divided by the indicated slide raster gives the new zoom level 
        deviation. Added to the starting value of the zoom level this 
        results in the new zoom level 
        \texorhtml{\lstinline{zoomlevel_scale}}{\code{zoomlevel_scale}}
        (see \textit{calculateNewZoomlevel()}; \textit{Map.js}):
\begin{ifhtml}
\code{      
    var deltaY_zoomlevel = this.zoomStart.y - sliderPosition.y;\html{br}
    this.zoomlevel_scale = this.zoomlevel_startScale + deltaY_zoomlevel/zoomStopHeight;
}    
\end{ifhtml}

\begin{latexonly}    
\begin{lstlisting}[numbers=none, frame=none, backgroundcolor=\color{white}]
    var deltaY_zoomlevel = this.zoomStart.y - sliderPosition.y;
    this.zoomlevel_scale = this.zoomlevel_startScale + deltaY_zoomlevel/zoomStopHeight;
\end{lstlisting}
\end{latexonly}
    
    \item \textbf{Tile Size}:\\
        During scaling the tile size is doubled (or halved) with every change in zoom level (see Section~\ref{funktionsweise} and \textit{calculateNewTileSize()}; \textit{Map.js}). For the zoom-in process the following applies for the tile width: 
\begin{ifhtml}
\code{   
this.tileSize_scale.w = 
      Math.pow(2, (this.zoomlevel_scale - this.zoomlevel_startScale)) * this.tileSize_startScale.w;
}    
\end{ifhtml}

\begin{latexonly}    
	\begin{lstlisting}[numbers=none, frame=none, backgroundcolor=\color{white}]
    this.tileSize_scale.w = 
      Math.pow(2, (this.zoomlevel_scale - this.zoomlevel_startScale)) * this.tileSize_startScale.w;
	\end{lstlisting}
\end{latexonly}	


        Similarly, for the zoom-out process:
\begin{ifhtml}
\code{   
this.tileSize_scale.w = 
      1 / (Math.pow(2, (this.zoomlevel_startScale - this.zoomlevel_scale))) * this.tileSize_startScale.w; 
}    
\end{ifhtml}

\begin{latexonly}          
\begin{lstlisting}[numbers=none, frame=none, backgroundcolor=\color{white}] 
    this.tileSize_scale.w = 
      1 / (Math.pow(2, (this.zoomlevel_startScale - this.zoomlevel_scale))) * this.tileSize_startScale.w;  
\end{lstlisting}
\end{latexonly}	

\end{enumerate}

Once the three values have been calculated, each tile is scaled to the newly determined tile size (a detailed description follows in the next section).

Once the mouse key has been released (\textit{MouseUp} event) the slider stops on the next adjacent zoom level value, and all visible tiles are redrawn. 

\subsection{Scaling}
\label{realisierung_skalierung}
Scaling is used only for the active base layer; other active layers are hidden during the scaling process (see \textit{prepareZoomAnimation()}; \textit{Map.js}). This measure became necessary when a noticeable decrease in performance was observed with just two active layers. Detailed measurements were not taken. As a result, the decision was made not to continue scaling more layers in order to obtain a faster (and more user-friendly) zoom-scaling process.

At the beginning of the zooming process the tile containing the centre of the visible area must be determined. If the center is located on the edge of several tiles, the first tile located is defined as the \texorhtml{\lstinline{centerTile}}{\code{centerTile}} (see \textit{getCenterTile()};\textit{Grid.js}).

By moving the zoom slider the values defined in Section
\ref{zoomsliderevents} are initially used to scale and position the center tile (see \textit{scaleTileTo()}; \textit{Grid.js}). 
The new tile size is used to set the \textit{width} and \textit{height} style parameter of the HTML-imgDiv element of the tile.
The positioning algorithm is based on the theorem on intersecting lines. Through the elementary geometric line relationship between the tile center and the corner points of the original and scaled tiles the new top and left pixel positions of the tile graphic can be determined. 

The remaining (visible) tiles are scaled and repositioned based on the scaled center tile.

During the scaling process the overview map is simultaneously updated (see \textit{updateOverview()}; \textit{OverviewMap.js}). The red border which highlights the selected area is increased/decreased during the zoom process and always indicates the exact section of the main map.
During slider movement, the zoom level of the overview map adjusts to the current main map. New tiles for the reference map are loaded. This does not impair the zooming process.


\subsection{ZoomOut Tiles}
\label{zoomOut-Kachel}
During intitialization of the current base layer a basis tile (larger by a factor of $x$) is loaded to prevent the formation of a white border around a shrinking map during the zoom-out process (see Section~\ref{funktionsweise}). 
A tile whose borders contain the full dimension of the map (\textit{maxExtent}) is determined, ie. the map must be displayable on one single tile. Beginning with zoom level 0 the resolution is doubled (and the map shrunk accordingly) until the whole map fits on one tile (see \textit{setZoomOutTile\_share}; \textit{Layer.js}).

After several days of testing, an optimal tile size factor $x$ of 4 emerged. The standard tile size in \textit{OpenLayers} is 256 pixels (px). This means that the zoom-out tile would be loaded with 1024 px. Background: Generally, many WMS servers (including MapServer) pre-define 2048 px as the maximum map size which should not be exceeded. Larger tiles result in better quality during scaling. However, taking into account load time it is better to choose a smaller tile with a smaller factor $x$. With a standard tile size of 512 px, a factor of 4 is still within the permitted size range (2048 px); at 1024 it also has a justifiable load time (in normal conditions). At smaller zoom level changes the quality at 1024 px is also considered acceptable. However, definite  \frz{pixelation} occurs during large zoom changes, which cannot be completed avoided even with a higher factor. 

To request the ZoomOut tile in the defined size from the WMS server, the 
\textit{getURL} method in \textit{WMS.js} was expanded by one parameter \textit{tileSize}.


\T\enlargethispage{\baselineskip}
\subsection{Automatic Zoom Animation}
\label{automatischeZoomanimation}
All requirements described in Section~\ref{musskriterien} are taken into account and implemented accordingly (with the exception of overlay scaling). The 
\textit{animated zooming} feature in the zoom bar is expanded with the mentioned should-have criteria (see Section~\ref{anforderungsanalyse_wunsch}).

After discussions with the PSC members of \textit{OpenLayers} the \textit{animated panning} patch which is currently in \textit{Review} stage is used as the basis for the time-dependent calculation of the zoom animation steps. The \textit{easeInOutZoom} method in \textit{Util.js} is the result of the adaption of the analogously compiled \textit{animated panning} function (see
listing~\ref{lst:easeInOutZoom}).
Thereby \texorhtml{\lstinline}{\code}{delta} is the difference between the zoom levels before and after animation, \texorhtml{\lstinline}{\code}{totalsteps} is
the pre-defined number of animation steps,
\texorhtml{\lstinline}{\code}{step} is the current \frz{step counter}, and \texorhtml{\lstinline}{\code}{power} is the pre-defined power factor for the acceleration curve override.\\
\T\enlargethispage{2\baselineskip}

\begin{ifhtml}
\label{lst:easeInOutZoom}
~\\Listing: Power Movement Curve Algorithm for Zoom Animations; \textit{Util.js}
\begin{example}
OpenLayers.Util.easeInOutZoom = function(delta, totalSteps, step, power) \{
    var stepVal = Math.pow(((1 / totalSteps) * step), power) * delta;
    return stepVal; 
\}
\end{example}
\end{ifhtml}

\begin{latexonly}
\begin{lstlisting}[caption=Force Movement Curve Algorithm for Zoom Animations; \textit{Util.js}, label=lst:easeInOutZoom, backgroundcolor=\color{lightgray}]
OpenLayers.Util.easeInOutZoom = function(delta, totalSteps, step, power) {
    var stepVal = Math.pow(((1 / totalSteps) * step), power) * delta;
    return stepVal; 
};
\end{lstlisting}
\end{latexonly}

After extensive testing with different values for the above-mentioned variables 
\texorhtml{\lstinline}{\code}{totalsteps = 4} and 
\texorhtml{\lstinline}{\code}{power = 0.7} were considered ideal values for the zooming process. Particular attention was paid to the speed of the animation, which should not exceed two seconds. For this reason a smaller step quantity was selected. For the power factor a value that would quickly accelerate the zoom movement in the beginning and gradually slow it down at the end was desired. The delay between user action and the first \textit{visible} zoom movement is thus very small.

The \textit{window.setInterval} method described in Section~\ref{konzept_komponententests} is used as a \frz{metronome} for the gradually proceeding animation; in the \textit{zoom\-Slide} method it is retrieved from the \textit{Map.js}.
Clicking on the zoom bar (buttons), double-clicking on the map, moving the mouse wheel, pulling out the zoom box or pressing the +/-- key starts the automatic zoom animation using the \textit{zoomTo} method. An optional function parameter can be used to deactivate the animation and to perform a more {jump-like} zooming process.

Starting or repeating a new animation using the above-mentioned interactions is not possible while zoom animation is in process. Turning the mouse wheel numerous time will still only result in a one-level zoom change. An extension of this function is conceivable. 

Zooming with double-click, mouse wheel and zoom box simultaneously adjusts the map to the new center (also with animation). Combining \textit{animated zooming} 
and \textit{panning} means that two \mbox{\textit{window.setInterval}} methods are running independently of each other -- one for zooming and one for panning.


\subsection{Tile Configuration with \textit{smooth tile update}}
In \textit{OpenLayers} the old map is deleted (white background appears) and subsquently re-assembled through a gradual reloading of tiles (default setting).
This effect would greatly impair the forecasted improvement in user orientation during \textit{animated zooming}. For this reason a solution whereby the scaled background layer stays visible until until the new tiles (in the layer above it) are completely loaded into the visible area is implemented.
In this thesis, this effect is described as \textit{smooth tile
update}; in line with its definition it is also considered as a characteristic of \textit{Smart Map Browsing}.


The actual implementation (see \textit{cloneBaseLayerDiv\_share()};
\textit{Layer.js}):\\
First, the active base layer along with all its tiles is cloned 
(\texorhtml{\lstinline}{\code}{baseLayerDivClone}) and added to the layer container.
The z-index of \texorhtml{\lstinline}{\code}{baseLayerDivClone} is decreased by one so that the layer lies directly under the original layer.
Subsequently the ZoomOut tile of the original layer must be switched invisibly (hidden) so that it does not cover the underlying cloned layer during the tile assembly. 

A \textit{loadend} event in the \textit{Layer.js} results when all tiles of the original layer are loaded into the visible area (see \textit{spiralTileLoad()}; \textit{Grid.js}). After the cloned layer is deleted, a new zoom animation may be started (see \textit{setLoadendVisibility()}; \textit{Layer.js}).


\subsection{Supported Layers}
\label{unterstuetzteEbenen}
After implementation, the \textit{animated zooming} feature supports the layers \textit{Image}, \textit{WMS Untiled} as well as all derived layer classes of \textit{Grid}, namely (\textit{WMS}, \textit{MapServer}, \textit{KaMap}, \textit{TMS} and \textit{WorldWind}; compare also classification diagram in Appendix \ref{anhang:klassendiagramm}). 
On the other hand, \textit{TMS} and \textit{WorldWind} do not offer ZoomOut tile support, this requires a layer-specific adjustment of the \textit{getURL} method (similar to \textit{WMS.js}).

Applications currently unsuited for \textit{animated zooming} include \textit{MapServer Untiled} as well as layers of third-party providers 
(\textit{Google}, \textit{VirtualEarth}, \textit{Yahoo} and
\textit{MultiMap}). 
\textit{Canvas} serves only as an overlay and is therefore also not supported. 


The possible expansion of new layer types described in Section~\ref{erweiterbarkeit} is provided for by the 
\textit{Layer} base class. As conceptualized, new layer types do not by default support zoom animation. Through the implementation of layer-specific methods (\textit{getTileSize()}, \textit{getCenterTile()} and if applicable, \textit{cloneBaseLayerDiv()}), the default properties of \textit{Layer.js} are overwritten.


\subsection{Animated Panning}
The \textit{animated panning} feature is used for combined zoom/pan operations (see Section~\ref{automatischeZoomanimation}). Other than correcting a rounding error in the \textit{getLonLatFromViewPortPx} method (\textit{Layer.js}) and supplementing the unit tests, the existing \textit{animated panning} was not altered.

Panning control using arrow keys was expanded based on the 
\textit{Smart Map Browsing} characteristics (see Section~\ref{smb_eigenschaften}; heading \textit{Zooming/Panning with Keyboard}). Accordingly, it is possible to reposition the map by 75\% of the current map width/height at any one time, using the keys Home, End, Page $\uparrow$ or Page $\downarrow$.

\newpage
\subsection{Source Code Structure}
As the central object in \textit{OpenLayers}, the \textit{Map} class assumes the zoom animation control. The \textit{animated zooming} source code is essentially divided into the functions 
\textit{prepare\-ZoomAnimation()}, \textit{runZoomAnimation()} and
\textit{finishZoomAnimation()}. 

All zoom changes are done with the \textit{zoomTo} method, from where the three above-mentioned animation functions are retrieved.


At the end of the implementation the complete written (respectively: modified) source code was divided into logically grouped patches. Table \ref{tab:patches} shows the eight generated patch files with the corresponding number of total lines as well as the added and deleted source code lines.
Listing \ref{lst:patchfile} illustrates the principle of added and deleted files using as an example an excerpt of the patch file \textit{final\_animatedZooming\_PanZoomBar.patch}. For space reasons the associated unit test changes (Line 1 - 53) are not illustrated here.

\W\xmlattributes*{table}{class=myTable}
\begin{table}[htbp]
\T\scriptsize
\begin{center}  
\begin{Label}{tab:patches}    
\begin{tabular}{rlrrr}    
\T\toprule
&&\multicolumn{3}{c}{\bf Lines}\\
\T\cmidrule(l){3-5}
\bf Nr.& \bf Patch File& \bf total&\bf added& \bf deleted\\
\T\midrule
1&final\_animatedZooming\_Core.patch&1883&1293&105\\
2&final\_animatedZooming\_LayerImage.patch&154&115&4\\
3&final\_animatedZooming\_LayerWMSUntiled.patch&339&1293&105\\
4&final\_animatedZooming\_Mouse.patch&325&220&34\\
5&final\_animatedZooming\_OverviewMap.patch&329&136&54\\
6&final\_animatedZooming\_PanZoomBar.patch&140&77&8\\
\T\addlinespace
7&animatedPanning\#2.patch&384&207&45\\
8&keyboardDefaults.patch&183&139&10\\
\T\midrule
&\bf Total&\bf 3737&\bf 2480&\bf 269\T\\
\T\bottomrule
\end{tabular}
\texorhtml{\caption}{\htmlcaption}{Generated Patch Files for \textit{animated zooming} und
\textit{panning}}
\end{Label}\end{center}
\end{table}




The eight patch files are found on the attached CD; they are also available online at \textit{OpenLayers} under the following three tickets:
\texorhtml{\begin{compactitem}}{\begin{itemize}}
    \item \frz{animated zooming}
        (Ticket 442)\footnote{\url{http://trac.openlayers.org/ticket/442}
        \checkURL}
    \item \frz{animated panning}
        (Ticket 110)\footnote{\url{http://trac.openlayers.org/ticket/110}
        \checkURL}

    \item \frz{new keys for better panning}
        (Ticket 580)\footnote{\url{http://trac.openlayers.org/ticket/580}
        \checkURL}
\texorhtml{\end{compactitem}}{\end{itemize}}


\newpage
\T\lstinputlisting[caption=Patch File \textit{final\_animatedZooming\_PanZoomBar.patch} (excerpt), label=lst:patchfile, firstline=54]{listings/final_animatedZooming_PanZoomBar.patch}
\W \label{lst:patchfile}
\W ~\\Listing: \xlink{final\_animatedZooming\_PanZoomBar.patch}{listings/final_animatedZooming_PanZoomBar.patch}



\section{Tests}

\subsection{Component Tests}
\label{tests_komponententests}
Component tests were set up at the beginning of the implementation, taking into account the distinctiveness of asynchronous function commands in automatic zoom animations (see Section~\ref{konzept_komponententests}). 
The following two notable characteristics were observed during the use of the \textit{delay\_call} method: 
\begin{enumerate}
    \item According to the \textit{delay\_call} method, no additional test
     assertion which builds upon assertions and instructions of the 
     \textit{delay\_call} method can follow within a test function. Otherwise
     the test function will fail.\\
        Background: Because of the determined delay time, instructions that 
        follow the \textit{delay\_call} method are preferred and therefore 
        processed before \textit{delay\_call()} is carried out. As a result, the 
        generated component tests always set \textit{delay\_call()} as the last 
        instruction in test functions (see Listing~\ref{lst:delayCall}; line 
        33/34).
    \item Test functions involving several automatic zoom animations require a  
        corresponding number of \textit{delay\_call} commands. According to (1) 
        these cannot be listed in consecutive order. One solution would be to 
        interleave them; ie. to executive a command within an existing command. 
        However, a more elegant solution is to list the individual functions and 
        their delay times in the parameter list of \textit{one} 
        \textit{delay\_call} method (see Listing~\ref{lst:delayCall}).

\end{enumerate}

Appropriate component tests were developed for almost all newly implemented (modified) functions of \textit{OpenLayers} (see Classification Diagram in Appendix~\ref{anhang:klassendiagramm}). In doing so, three new test pages were created:
\textit{test\_WMS\_Untiled.html}, \textit{test\_Mouse\-Defaults.html} and
\textit{test\_KeyboardDefaults.html}. The remaining test files were expanded with new methods.
The implementation of \textit{animated zooming} resulted in a further required adjustment and expansion (with \textit{delay\_call} methods) of test functions which test zoom performance.

Towards the end of the implementation all tests were carried out successfully. The component tests provided a quality assurance aspect and thus ensured the correctness of the \textit{animated zooming} und \textit{panning} features for future extensions.\\


\begin{latexonly}
\lstset{moredelim=[is][\color{red}]{/*}{*/}}
\begin{lstlisting}[caption={Multiple
    \textit{delay\_call} commands in a test function; \textit{test\_Map.html}},
    label=lst:delayCall]
function test_05_Map_center(t) {
    t.plan(6);
    map = new OpenLayers.Map('map');
    var baseLayer = new OpenLayers.Layer.WMS("Test Layer", "http://octo.metacarta.com/cgi-bin/mapserv?",
        {map: "/mapdata/vmap_wms.map", layers: "basic"} );
    map.addLayer(baseLayer);
    var ll = new OpenLayers.LonLat(2,1);
    map.setCenter(ll, 0);
    map.zoomIn();
    /*t.delay_call( 
        1, function() {*/
            t.eq( map.getZoom(), 1, "map.zoom is correct after calling setCenter,zoom in");     
            t.ok( map.getCenter().equals(ll), "map center is correct after calling setCenter, zoom in");
            // set zoomanimation flag manually,
            // reason: loadend event in layers.js will not achieved in unittests
            map.zoomanimationActive = false;
            map.zoomOut();
        /*},
        1, function() {*/
            t.eq( map.getZoom(), 0, "map.zoom is correct after calling setCenter,zoom in, zoom out");
            map.zoomTo(5);
        /*},    
        1, function() {*/
            t.eq( map.getZoom(), 5, "map.zoom is correct after calling zoomTo" );
            map.zoomToMaxExtent();
        /*},
        1, function() {*/
            t.eq( map.getZoom(), 2, "map.zoom is correct after calling zoomToMaxExtent" );
            var lonlat = map.getCenter();
            var zero = new OpenLayers.LonLat(0, 0);
            t.ok( lonlat.equals(zero), "map center is correct after calling zoomToFullExtent" );
        /*}
    );*/   
}
\end{lstlisting}
\end{latexonly}

\begin{ifhtml}
\label{lst:delayCall}
~\\Listing: multiple \textit{delay\_call} commands in a test function; \textit{test\_Map.html}
\begin{example}
function test_05_Map_center(t) \{
    t.plan(6);
    map = new OpenLayers.Map('map');
    var baseLayer = new OpenLayers.Layer.WMS("Test Layer", "http://octo.metacarta.com/cgi-bin/mapserv?",
        \{map: "/mapdata/vmap_wms.map", layers: "basic"\} );
    map.addLayer(baseLayer);
    var ll = new OpenLayers.LonLat(2,1);
    map.setCenter(ll, 0);
    map.zoomIn();
    t.delay_call( 
        1, function() \{
            t.eq( map.getZoom(), 1, "map.zoom is correct after calling setCenter,zoom in");     
            t.ok( map.getCenter().equals(ll), "map center is correct after calling setCenter, zoom in");
            // set zoomanimation flag manually,
            // reason: loadend event in layers.js will not achieved in unittests
            map.zoomanimationActive = false;
            map.zoomOut();
        \},
        1, function() \{
            t.eq( map.getZoom(), 0, "map.zoom is correct after calling setCenter,zoom in, zoom out");
            map.zoomTo(5);
        \},    
        1, function() \{
            t.eq( map.getZoom(), 5, "map.zoom is correct after calling zoomTo" );
            map.zoomToMaxExtent();
        \},
        1, function() \{
            t.eq( map.getZoom(), 2, "map.zoom is correct after calling zoomToMaxExtent" );
            var lonlat = map.getCenter();
            var zero = new OpenLayers.LonLat(0, 0);
            t.ok( lonlat.equals(zero), "map center is correct after calling zoomToFullExtent" );
        \}
    );   
\}    
\end{example}   
\end{ifhtml}



\subsection{Integration Tests}
\label{testprotokoll}
After completion of the implementation the initial test plan was adapted to the actually implemented functions. The final test plan is divided into seven test suites (see Appendix~\ref{anhang:testplan}\texonly{, pg. \pageref{anhang:testplan}
and following}).

The complete test was carried out in seven different browsers, and a test log for each was compiled. Table \ref{tab:browserversionen} illustrates the tested browser version, divided by operating systems used.

\xmlattributes*{table}{class=myTable} 
\begin{table}[htbp]
\scriptsize
\begin{center}
\T\begin{threeparttable}
\begin{tabular}{lll}
\T\toprule
\bf Debian GNU/Linux 3.1 & \bf Mac OS 10.4 & \bf Windows XP\\
\T\cmidrule(r){1-1}\cmidrule(lr){2-2}\cmidrule(l){3-3}
Firefox 1.5.0.7&Safari 2.0.4&Internet Explorer 7.0\\
Bon Echo
2.0.0.1\T{\tnote{1}}
&Firefox 2.0.0.2&Firefox 2.0.0.3\\
&Opera 9.10&\T\\
\T\bottomrule
\end{tabular}
\T\begin{tablenotes}\tiny
    \T\item[1] self-compiled version of Firefox 2.0.0.1 
\T\end{tablenotes}    
\T\end{threeparttable}
\W\normalsize
\texorhtml{\caption}{\htmlcaption}{Tested Browser Versions}
\label{tab:browserversionen}
\end{center}
\end{table}

\textit{KDE Konqueror}\footnote{\url{http://www.konqueror.org}
\checkURL} (Version 3.5.5 and 3.3.2) is not supposed to be supported by \textit{OpenLayers} - this was also checked as part of the testing process (see also \texorhtml{pg. 
\pageref{maptool:openlayers}}{\link{OpenLayers}{maptool:openlayers}}). During an attempt to run the demo the map was not loaded (ie. the map window remained empty). Even after posting a question on the \textit{OpenLayers} developer's mailing list the reason for this could not be found.

The test run using \textit{Internet Explorer (IE)} 7 uncovered three problem areas:
\texorhtml{\begin{compactenum}}{\begin{enumerate}}
    \item The following test plan question was always checked with a 
    \textit{No}:\\
    \textit{\frz{Does the status bar of the browser show the completion of the 
    map loading process (e.g. confirm that it is \textit{done})?}}

    \item Zooming using the keyboard did not work in IE. 
    \item PNG tile graphics became invisible once they exceeded 32768 pixels during the scaling process. CPU load also jumped considerably. Sometimes IE did not respond temporarily or it crashed completely.


\texorhtml{\end{compactenum}}{\end{enumerate}}
Item (1) can be neglected, as it does not impair the functional performance of the application. A search for a solution to this browser-specific problem was not carried out.\\
Problem (2) also only occured in IE. With the addition of two IE-specific keycodes for the + and -- key the problem was solved (see \textit{KeyboardDefaults.js}).\\
The basic problem of item (3), that tile graphics above 32768 pixels are no longer shown, was also observed in the three browsers tested in Mac OS X and Firefox in Windows. It stands to reason that graphics in these browsers are only displayed at maximum 16 bits, ie. 1 bit for pre-drawing and 15 for the size number, hence $2^{15}=32768$ px. 
The above-mentioned performance problems observed in IE are serious enough that they warrant an urgent solution to ensure the reliability of the application. 

Since IE does not seem to capture pixels exceeding $2^{15}$, the application needs to compensate for this problem. Prior to scaling a tile, \textit{OpenLayers} now checks in the methods \textit{scaleTileTo()}, \textit{scaleTilesOfGrid()} and
\textit{scaleZoomOutTile\_share()} (in \textit{Layer.js}) whether the above-mentioned value has been exceeded. If that is the case, no further scaling takes place and the tiles stay at their most recent tile size. This has no real significance for the user, since at 32768 pixels the map is already highly pixelated. However, the fact that after a certain zoom level the map does not continue to adjust in line with the movement on the zoom slider can be somewhat irritating for the user, with a corresponding negative effect on \textit{Smart Map Browsing}.

The implemented integration tests form the concluding part of the implementation and test phase. They also highlight the importance of test logs for quality assurance purposes, as shown by the discovery of new problem areas.


\section{Problems}
\label{schwierigkeiten}

\subsection{Performance}
\label{performance}
The biggest problem with the implementation of the \textit{animated
zooming} feature was and is the issue of performance, because as more tiles are scaled, the scaling process slows down accordingly.  Because of this issue, the simultaneous scaling of all active overlays was not considered in the early development stages (see Section~\ref{realisierung_skalierung}). Even with a base layer the zoom process can be noticeably slower when the view area is large as opposed to a smaller map view of, say, \mbox{512 x 512} pixels.

In the search for a solution the following approach for performance optimization was developed: during scaling a change in the position and size of tiles is carried out on the basis of central CSS classes which are assigned to the tiles line-by-line (column-by-column), rather than using a CSS-style parameter for each graphic.
Accordingly, one CSS class per tile column or line would determine the \textit{left} or \textit{top} position of the tile. The tile width and height would be the same for all classes. For scaling a tile grid of \mbox{4 x 4}, a modification to 8 CSS classes would be required, as compared to 16 CSS style characteristics in each tile.\\
This concept had been implemented on a test basis, but was later abandoned when  the hoped-for improvement in speed did not occur. Detailed measurements were not carried out. 


A second optimization solution was more successful and became a part of the developed extension: only the tiles that are completely or partially located in the visible area are scaled. All other tiles (ie. outside the visible area) are not included in the scale process (see \textit{setTilesOutsideInvisible};
\textit{Grid.js}). For example: Given a map window of \mbox{512 x 512 px} and a tile size of 256 px, \textit{Grid.js} by default creates a \mbox{7 x 6} tile grid. Accordingly, a maximum of nine tiles can be found in the visible area at the same time.
The number of tiles which have to be scaled can therefore be reduced from 42 to a maximum of nine. 

An additional performance problem was discovered during the implementation of the test plan. \textit{Internet Explorer} slows down noticeably with tiles of over 32768 pixels, which in some cases resulted in a crash of the browser. A solution to this problem is described in Section \ref{testprotokoll}.


\subsection{Layer Types}
The desired implementation of the \textit{animated zooming}
features for all layers supported by \textit{OpenLayers} (as outlined in the should-have list) could not be fully realized (see Section \ref{unterstuetzteEbenen}). The difficulty (and associated effort) with implementing the layer-specific special characteristics were underestimated during the conceptualization phase. As a result, the effort was limited to the layer types \textit{Image}, \textit{WMS Untiled} and \textit{Grid} (inc. sub layers). 



\subsection{Component Tests}
Difficulties were encountered during the creation of the unit test components in which asynchronous code was supposed to be tested. The two characteristic of  \textit{delay\_call()} as described in Section~\ref{tests_komponententests} are not documented in \texorhtml{\citep}{\cite}{TestAnotherWayDoc}. Extensive research and an inquiry over the \textit{OpenLayers} developer's mailing list did not yield an answer. The solution was discovered only towards the end of the implemention. Therefore the component tests were not developed in immediately parallel with the implemention, as was planned.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%
%   *** FAZIT ***
%   #6
%
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Conclusion}
\T\enlargethispage{\baselineskip}
\section{Summary of Results}
\label{zusammenfassung}
The central focus of this thesis is represented by the following three steps: a current state analysis of Free web mapping applications, which leads to the definition of the term \textit{Smart Map Browsing}, as well as the implementation of a selected \textit{Smart Map Browsing} feature.

The \textbf{current state analysis} investigated the usability of twelve selected web mapping applications. As expected, \textit{Google Maps} (the lone proprietary representative) proved to be a cutting-edge application. The analysis also revealed an impressive performance by \textit{OpenLayers}\\
As a general summary it can be said that in terms of usability, the tile-based applications convince with their no-delay map panning and dynamic tile assembly.
Combined with a zoom bar these applications have an already large lead in terms of usability compared to conventional web mapping applications.\\
An innovative and so far novel interactive extension was provided by \textit{p.mapper}'s \textit{continuous zooming} feature, which shows great potential for the further development of web mapping applications.\\
The majority of analyzed applications showed definite weaknesses because of missing zoom options with mouse wheel, double-click or keyboard commands.
In addition, the static zoom performance seen in many overview maps left a decidedly negative impression with regards to usability.\\
Before submission, all analysis results of this thesis were re-checked and updated if required.

This thesis also developed and defined the term \textbf{\textit{Smart Map Browsing}}. A definition was developed on the basis of the ISO usability standards. 
The characteristics of \textit{Smart Map Browsing} were derived from the results of the current state analysis; they outline the current state of the technology of \textit{Smart Map Browsing}.
The characteristics serve as guidelines on how web mapping applications could be conceptualized and developed for a high level of usability. This includes intuitive, self-explanatory GUI components as well as pan/zoom that performs to expectations after interacting with these elements. \textit{Smart Map Browsing} intensity describes the degree of usability. When a web mapping application displays all of the listed properties, it is considered a high-grade \textit{Smart Map Browsing} application. On the other hand, if the application features fewer of these properties, it has a lower \textit{Smart Map Browsing} quality.\\

The thesis highlighted the most significant features of \textit{Smart Map Browsing} as well as their future potential. The result: the performance of (client-side) tiling can be significantly improved by (server-side) tile caching, as shown by the implementation of \textit{TileCache}. 
An important factor for zoom depth orientation is the zoom bar. The use of  \textit{animated zooming} und \textit{panning} shows great potential, as it creates an entirely new \frz{navigation experience} for the user. These characteristics along with their potentials are continuously updated and developed through new technology, and they will further shape the development of \textit{Smart Map Browsing}.


The third phase of this thesis consisted of the implementation of the \textit{Smart Map Browsing} feature \textbf{\textit{animated zooming}} into \textit{OpenLayers}.
Summarizing, almost all stated Must-Have and Should-Have requirements were implemented, with the exception of active overlay scaling and achieving full support for all layer types. Performance issues were the main problem encountered during implementation - the next section discusses the resulting open issues.\\ 
The developed feature expands the current \textit{OpenLayers}-API. Through the
\textit{Build Profile} of \textit{OpenLayers} it is possible to combine selected API classes into a single JavaScript file. This file can then be integrated into any web mapping application. As a result, this thesis was successful in achieving its original objective of finding a universally valid solution.\\
The implementation results are summarized in eight patches and are currently undergoing the review process by 
\textit{OpenLayers} developers. The patch for the improvement of the panning keyboard control has already been accepted without modifications and has been released as part of \textit{OpenLayers} Version 2.4 RC2 in April 2007. The integration of \textit{animated zooming} and \textit{panning}
is planned for Version 2.5 which is scheduled to be released in the fall of 2007.



\section{Open Issues}
\T\enlargethispage{\baselineskip}

A basic problem in the use of tiling in web mapping applications is the WMS server's ability to automatically place a scale bar, pre-defined logo,  watermark or signature on every requested map. 
Figure~\ref{img:tilingWatermark} illustrates the potentially unaesthetic tile effects in \textit{OpenLayers} using the examples of two WMS services. Maps that are supplemented with externally-generated and repetitive details divert the user's attention from the map content and therefore have a negative effect on \textit{Smart Map Browsing}.\\
\textit{TileCache} offers a technical approach to dealing with display issues such as these:
with the \textit{Metatile} option the WMS server loads a large tile, which is subsequently provided to the web mapping application in the form of numerous smaller, subdivided tiles. By default a \textit{Metatile} is divided into 5x5 tiles. Taking into account the recommended maximum tile size of 2048px by WMS servers, the complete display of large maps with only one meta tile would generally not be possible. Therefore this solution could still result in a recurrence of this undesired element.

A second tiling problem is the positioning of labels which extend beyond tile borders. In Figure~\ref{img:tilingWatermark} (left picture) these labels are simply cut off, which clearly impairs the readability of the map. A discussion of potential problem solving approaches would go beyond the confines of this thesis, therefore this issue is merely pointed out.


\begin{figure}[htb] 
    \begin{center}
    \T\includegraphics[width=7cm]{images/tiling_wms_grass.eps}
    \W\htmlimage{images/tiling_wms_grass.png}
    \hspace{0.4cm}
    \T\includegraphics[width=7cm]{images/tiling_wms_bavaria.eps}
    \W\htmlimage{images/tiling_wms_bavaria.png}
    \texorhtml{\caption[Tiling Problems with Scale Bar, Logos and
    Labels]}{\caption}
    {Tiling Problems with Scale Bar, Logos and Labels in WMS services \texorhtml{\citep}{\cite}{grass} and \texorhtml{\citep}{\cite}{gdiBavaria}}
    
    \label{img:tilingWatermark} 
\end{center}
\end{figure}



Furthermore two open issues are observed in the developed \textit{OpenLayers} extension \textit{animated zooming}:

\begin{enumerate}
    \item Map scaling can at times result in a significant loss of quality. As the zoom level increases the tiles display an increasing coarsening of the pixel structure, which can result in a near illegibility of the map content. This is particularly evident during zoom-out from a high zoom level, where the ZoomOut tile intially provides barely usable information. The only zoom-interaction confirmation the user receives is the pixel movement itself.\\
A possible solution would be to use several ZoomOut tiles (based on different zoom levels). As soon as the map exceeds a certain zoom level, an additional ZoomOut tile could be loaded. However, this alternative requires additional load and processing time which could negatively impact performance.

\newpage
\item Because of the performance problems touched upon earlier, overlay scaling was abandoned - an aspect that has negative effects on \textit{Smart Map Browsing}.
Moreover, compared to \textit{animated panning} the automatic zoom animation process is still very sluggish. For purposes of usability, a seamless and quick zoom animation is highly desirable. The mentioned performance problems show clearly that because of the large processing requirements, scaling processes in browsers are still very limited by current technology. Ideal \textit{animated zooming} without noticable delays does not seem to be feasible with current client-hardware. However, given future technological developments this problem is likely to be solved in the next few years.
\end{enumerate}



\T\enlargethispage{2\baselineskip}
\section{Outlook}

This thesis proposes that \textit{Smart Map Browsing} leads to improved user acceptance. Approaches of the heuristic evalution method were used to prove this thesis by way of a usability analysis. Empirical confirmation was not carried out, as this would have been beyond the scope of this thesis. 


As a result, extensive usability tests using scientific methods are recommended for further research work, as they serve to substantiate usability improvements in web mapping applications through the hereby defined characteristics of \textit{Smart Map Browsing}.

There is a need for further research in the implementation of \textit{Smart Map Browsing} characteristics. Given the current state of technology, the defined characteristics have only limited value. As the technology develops, additional analysis and definitions will be required.

For the \textit{animated zooming} feature in \textit{OpenLayers} the following extensions are conceivable for the future:
\begin{itemize}
    \item All layer types are fully \textit{animated
        zooming} compatible.
    \item An \frz{add-up} of several zoom interactions   
        \textit{during} an automatic zoom animation results in a recalculation
        of the maximum zoom level. Using the 
        example of mouse wheel movement this means that the number of wheel turns 
        would be taken into account.
    \item To optimize the tile load time, background loading of the tiles for
        the maximum zoom level is carried while the automatic zoom animation is 
        still in process. If the maximum zoom level is changed, the loaded tiles 
        are discarded.
    \item The ZoomReset globe from the simplified zoom bar is integrated into 
        the center of the pan navigation panel, enabling ZoomReset in 
        combination with the expanded zoom bar of the PanZoom bar.
        Note: The zoom bar is considered fundamental for manual  
        \textit{animated zooming} and it, rather than the mini zoom bar, should 
        be included in standard versions of \textit{OpenLayers}.

\end{itemize}


\newpage
Looking at the discussions on the future of Free web mapping applications, it seems likely that \textit{OpenLayers} will one day form the functional core for some map applications -- current discussions revolve around \textit{ka-map}, \textit{Mapbuilder} and \textit{Mapbender}.
\textit{OpenLayers} already offers an adaptable \textit{lite} version, which swaps out selected \textit{OpenLayers} classes into one JavaScript file
(see Section \ref{OL_allgemein} and \ref{zusammenfassung}).
This would provide for a trouble-free integration into other applications.

The \textit{lite} version is a first step towards linking the multitude of Free web mapping projects and effectively utilizing their specific potentials. The \textit{Smart Map Browsing} properties of \textit{OpenLayers} which were investigated in this thesis could also be used to develop lasting and effective usability improvements for other web mapping applications.

