Eidgenossische Technische Hochschule ZurichInstitute of Cartography and Geoinformation

Master Thesis

Service-oriented Architecture for ThematicCartography on the Web

Author:Andreas Krimbacherandreas.krimbacher@gmail.com

Supervisor:Prof. Dr. Lorenz Hurni

Advisors:Dr. Hans-Rudolf Bar

Dr. Ionut Iosifescu EnescuFlorian Straub

January 30, 2014

Geomatic Engineering and Planning MscDepartment of Civil, Environmental and Geomatic Engineering

I

Preface

This project is motivated by my fascination for the opportunities for map produc-tion in the field of Web cartography, arising form the fast development of Webtechnologies. The large amount of data and services available on the Web, whichcan be utilized for the creation of thematic maps and the possibilities for decen-tralized and automated map creation, inspired me to work on this project for thelast four months.

I would like to thank the Department of Cartography and Geoinformation at ETHZurich for giving me the opportunity to deepen my knowledge in the field of Webcartography with this project.Furthermore, I would like to express my special appreciation and thanks to myadvisors, Dr. Hans-Rudolf Bar, Dr. Ionut Iosifescu Enescu, and Florian Straub,who gave me constructive comments and warm encouragement.Also, I would like to thank Axel and Alice for correcting the language of thisthesis.

Zurich, January 27, 2014Krimbacher Andreas

II

Abstract

This thesis develops a conceptual model for the production of thematic mapswhich utilizes the Web infrastructure. The derivation of the model is performedin two steps. In the first, we develop a workflow model, which covers the stepsfrom data import to publishing and is based on the creation process of standardthematic map representations. For the modeling we focus on two-dimensional maprepresentations and processing techniques for vector data. Based on the workflow,the second step derives a conceptual model which is designed as a service-orientedarchitecture and can be implemented with decentralized Web services. An exam-ination of the model with respect to important concepts of thematic Web cartog-raphy and a prototypical application show that service-oriented architectures aresuitable for thematic map production. The main benefits are thereby the directintegration in the Web infrastructure and the possibilities for automated map cre-ation. The main limitations with respect to realization are the lack of standardsand specifications for a comprehensive description of the map symbology and themap creation process. For the advancement of service-driven map creation on theWeb, this work contributes an elementary model, which assists the developmentsin automated mapping and can increase the networking between cartographerswith respect to map production and the development of mapping techniques.

III

Table of Contents

List of Abbreviations VI

List of Figures VII

List of Tables VIII

1. Introduction 11.1. Research Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Statement of Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Research Questions and Objectives . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5. Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Methodology 52.1. A Generic Workflow for Thematic Cartography on the Web . . . . . . . . . . 52.2. A Service-oriented Architecture for Thematic Cartography . . . . . . . . . . . 62.3. Proof-of-Concept and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 62.4. Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Fundamentals 83.1. Thematic Cartography and Geovisualization . . . . . . . . . . . . . . . . . . . 8

3.1.1. Definition and Cartographic Map Production . . . . . . . . . . . . . . 83.1.2. Standard Thematic Map Representations . . . . . . . . . . . . . . . . 11

3.2. The Internet and Web Cartography . . . . . . . . . . . . . . . . . . . . . . . . 123.2.1. The Modern Web and the GeoWeb . . . . . . . . . . . . . . . . . . . . 123.2.2. Service-oriented Architectures and Web Services . . . . . . . . . . . . 133.2.3. Web Cartography with SOA . . . . . . . . . . . . . . . . . . . . . . . 15

3.3. Concepts for Thematic Web Cartography . . . . . . . . . . . . . . . . . . . . 173.3.1. Interactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2. Collaboration and Neogeography . . . . . . . . . . . . . . . . . . . . . 193.3.3. Linking of Documents, Data and Services . . . . . . . . . . . . . . . . 213.3.4. Searchability and Findability . . . . . . . . . . . . . . . . . . . . . . . 22

4. Modeling 234.1. Requirements for the Conceptual Model . . . . . . . . . . . . . . . . . . . . . 234.2. Derivation of the Generic Workflow . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1. Definition of the Scope of Thematic Cartography . . . . . . . . . . . . 244.2.2. A Generic Workflow for Thematic Cartography on the Web . . . . . . 25

IV

Table of Contents

4.3. The Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.1. A Service-oriented Architecture for Thematic Cartography on the Web 284.3.2. The Map Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.3. Different Implementations of the Conceptual Model . . . . . . . . . . 384.3.4. OGC Web Standards and Specifications for the Conceptual Model . . 40

5. Implementation 425.1. Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1. Client-side Implementation . . . . . . . . . . . . . . . . . . . . . . . . 425.1.2. Server-side Implementation . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2. Map Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.1. Choropleth Maps with Standardized Data . . . . . . . . . . . . . . . . 465.2.2. Proportional Symbol Maps and Diagrams . . . . . . . . . . . . . . . . 485.2.3. The Cartographic Procedure Service and Dot Maps . . . . . . . . . . 49

6. Evaluation and Discussion 516.1. Standard Thematic Map Representations and the Generic Workflow . . . . . 516.2. Implementation of the Concepts for Thematic Web Cartography . . . . . . . 536.3. Discussion of Research Findings . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7. Conclusions and Outlook 587.1. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.2. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliography 60

A. Appendices 64A.1. Third-party Libraries and Software . . . . . . . . . . . . . . . . . . . . . . . . 64A.2. Server-side API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.3. Service Chain Objects and Map Description . . . . . . . . . . . . . . . . . . . 67A.4. Symbology Descriptions for Example Maps . . . . . . . . . . . . . . . . . . . 73

B. Declaration of Originality 77

V

List of Abbreviations

AJAX Asynchronous JavaScript and XML

AMS Analysis and Manipulation Services

BPEL Business Process Execution Language

BPMN Business Process Model and Notation

CPS Cartographic Procedure Service

DCS Data Conversion Service

DTM Desktop Mapping System

FGDC Federal Geographic Data Committee

GML Geography Markup Language

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

ISO International Organization for Standardization

JSON JavaScript Object Notation

OGC Open Geospatial Consortium

OWL Web Ontology Language

RDF Resource Description Framework

REST Representational State Transfer

SLD/SE Styled Layer Descriptor/Symbology Encoding

SOA Service-oriented Architecture

SOAP Simple Object Access Protocol

SQL Structured Query Language

SR Symbology Repository

TMS Thematic Map Service

URI Uniform Resource Identifier

WADL Web Application Description Language

WFS Web Feature Service

WMS Web Map Service

WSDL Web Services Description Language

XML Extensible Markup Language

VI

List of Figures

3.1. Communication Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2. Cartography Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. GIS-VIS Approach for Map Production . . . . . . . . . . . . . . . . . . . . . 103.4. Technologies for Service-oriented Architectures . . . . . . . . . . . . . . . . . 143.5. Architecture of the CartoService Concept . . . . . . . . . . . . . . . . . . . . 163.6. Stages of Action for Map Interaction . . . . . . . . . . . . . . . . . . . . . . . 183.7. RDF Triple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1. Generic Workflow for Thematic Map Production on the Web . . . . . . . . . 264.2. Data Conversion Service Interface . . . . . . . . . . . . . . . . . . . . . . . . . 294.3. Interfaces of Analysis and Manipulation Services . . . . . . . . . . . . . . . . 314.4. Cartographic Procedure Service Interface . . . . . . . . . . . . . . . . . . . . 324.5. Thematic Map Service Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 334.6. Symbology Repository Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 344.7. Service-oriented Architecture for Thematic Map Production on the Web . . . 354.8. Elements of Map Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.9. Database-Centered Implementation of the SOA . . . . . . . . . . . . . . . . . 384.10. Map-Description-Centered Implementation of the SOA . . . . . . . . . . . . . 39

5.1. AngularJS Modules for the Client-side Application . . . . . . . . . . . . . . . 435.2. Editor in the Client-side Application . . . . . . . . . . . . . . . . . . . . . . . 445.3. Sequence Diagram Choropleth Map . . . . . . . . . . . . . . . . . . . . . . . . 475.4. Example Choropleth Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.5. Sequence Diagram Proportional Symbol Map . . . . . . . . . . . . . . . . . . 485.6. Example Proportional Symbol Map . . . . . . . . . . . . . . . . . . . . . . . . 495.7. Sequence Diagram Dot Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.8. Example Dot Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

VII

List of Tables

3.1. Taxonomy of Interaction Types . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Requirements for Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . 24

6.1. Evaluation of Standard Mapping Techniques . . . . . . . . . . . . . . . . . . . 516.2. Evaluation of Requirements for Thematic Web Cartography . . . . . . . . . . 53

A.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.2. Server-side Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64A.3. Client-side Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A.4. REST Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

VIII

1. Introduction

The evolution of Web mapping and the rise of the GeoWeb provide increasing possibilitiesto produce and distribute geographic products. Furthermore, 95% of all data contain geo-graphical references and can be visualized with a map (Perkins, 2010). This thesis focuseson thematic maps for the Web which are used to communicate information about a specifictheme and geographical reference.

The quality of thematic maps on the Web is based primarily on the representation quality andthe capabilities of interaction. Despite the well-known design principles for thematic maps,which have evolved from the research on analog and digital map production, a great number ofthematic maps have inadequate cartographic quality (Engemaier and Asche, 2011). Besides,most of the maps do hardly utilize the possibilities of interaction that the digital outputdevices provide.

For the production of thematic maps for the Web offline and online tools as well as softwarepackages are available. The offline production of thematic maps is often based on differentsoftware packages such as ArcGIS, MapPublisher, Adobe Illustrator, and Adobe Photoshopwhich are used for different purposes. In addition, plug-ins such as the Illustrator Plug-insfor Cartography developed at ETH Zurich are used to extend the functionalities (Hurni andHutzler, 2008). For online production of thematic maps, closed and centralized systems suchas CartoDB1 or Indiemapper2change, which that often lack sufficient functionality to analyseand visualize data can be used. Another approach involves using the ArcGIS Server3 oraddthe QGIS Server4 which provide selected functionalities of the desktop version through aserver interface.

The emergence and success of technologies under the paradigm of software as a service opensup new ways of providing functionality and raises new questions about how to produce the-matic maps in the future (Spence et al., 2009).

The thesis takes its motivation from the current lack of efficient production systems that utilizethe benefits of service-oriented architectures (SOA) and state-of-the-art Web technologies forthe production of thematic maps for the Web.

1https://cartodb.com/2http://indiemapper.com3http://www.esri.com/software/arcgis/arcgisserver4http://live.osgeo.org/de/overview/qgis_mapserver_overview.html

1

Introduction

1.1. Research Area

For the production and supply of thematic maps on the Web a long tradition of researchon thematic mapping from analog to digital production techniques can be utilized. Thetechniques for thematic cartography for this thesis are mainly based on the textbooks fromSlocum et al. (2008) and Dent et al. (2008).

Displaying thematic maps on a digital medium also is about interaction. Research was mainlydone in the area of geovisualization. A broad perspective on interaction theories can be foundin Roth (2012), where a a basic taxonomy for cartographic interaction is provided by reviewingthe major contributions in the field.

The final major research area for thematic cartography on the Web covers the infrastructureimplications of production and distribution . In this thesis, the focus is thereby on service-oriented architectures. SOA for the distribution of thematic maps on the Web is mainlybased on OGC Web services. Additions to the OGC standards were proposed in Iosifescu-Enescu (2011) and Rautenbach et al. (2013). Former developed an extended WMS to provideadditional capabilities for cartographic diagrams and legends. The work of Rautenbach et al.(2013) proposes a framework for orchestrating OGC services to produce thematic maps. Afirst approach to develop a concept for modelling and visualization of quality maps with aservice-oriented approach can be found in Asche and Engemaier (2012).

1.2. Statement of Problem

To provide and create thematic maps for the Internet, we are restricted to closed and central-ized systems. The extension of the Internet and the emerging field of technologies under theparadigm of software as a service leads to a re-evaluation of the questions: How do we pro-duce thematic maps? How do we implement production functionalities? How do we distributethematic maps?

Most studies on thematic cartography for the Web are based on OGC Web services and focuson the distribution of thematic maps. To enhance the quality of thematic maps on the Web,we also need to consider the production process with respect to the Web infrastructure.

The research in this thesis will focus on the production process of thematic maps on theWeb with respect to a service-oriented architecture. The production process will be modelledby analyzing and adopting standard work flows and processing techniques for thematic Webcartography.

2

Introduction

1.3. Research Questions and Objectives

The structure of the thesis is given be three research questions (Q) and two objectives (O):

Q1: Can the elements and the sequences of thematic map production for the Webbe modeled in one workflow?

Q2: Can the thematic map production workflow be modeled with a service-orientedarchitecture?

Q3: Are the existing standards and technologies sufficient for the implementationof the service-oriented architecture?

O1: To develop a conceptual service-oriented architecture for thematic map pro-duction on the Web which considers important concepts for Web cartography.

O2: To deliver a proof-of-concept by implementing selected functionalities of theservice-oriented architecture.

The first two questions concern the development of a conceptual model for map productionon the Web. Therefore, the thesis develops a generic workflow, that later on is transformedinto a service-oriented architecture. The third question looks at standards and technologiesto implement this conceptual model, which will be used in the proof-of-concept.

1.4. Motivation

The motivation for this thesis arises from the benefits of a service-oriented production process.The main advantages are in the field of Web cartography, for neogeographers and for richInternet applications.

For the field of Web cartography a service-oriented production process provides a betterintegration of different information, enhanced capabilities for collaborative map creation anda better integration of interactivity and searchability. The benefit in data integration isespecially the better combination of data from WebGIS with other spatial information onthe Web. For collaborative mapping, a SOA allows to share and combine not only the endproduct, but also intermediate products, production techniques and the cartographic process.Dynamic linking of different layers of thematic maps, as well as the input data, can providereal-time capabilities and enhance collaborative mapping. An additional benefit, which couldincrease the quality of the created maps, is the combination of creating and presenting mapsutilizing only one architecture.

With a browser-based user-interface the functionalities of the services can be made accessibleto neogeographers. The benefits are: easier combination of different sources of information,the creation of thematic maps without the need of specialized software, and enhanced capa-bilities for collaborative map production and sharing cartographic products.

3

Introduction

The benefits of the decentralized approach for map production, can also be utilized for richInternet applications that implement functionalities of thematic cartography. Benefits areespecially the scalability and flexibility of the functionalities provided as services. Withrespect to platform-independence the SOA allows the use of various input and output deviceswith different characteristics such as screen size or the type of interaction.

1.5. Structure of the Report

The introductory chapter 1 provides an overview of the research area, states the researchquestions and objectives, and describes the motivation for this thesis. Chapter 2 describesthe methodology of the approach. Chapter 3 summarizes the fundamentals for the fieldof thematic Web cartography and the Web infrastructure. In addition, common standardsand technologies for thematic Web cartography are introduced. In chapter 4 the develop-ment of the conceptual model is presented. In a first step, a generic workflow is proposedand evaluated with standard techniques for thematic cartography. The second step trans-forms the generic workflow into a service-oriented architecture and discusses different waysto implement the architecture. In addition, the service-oriented model is compared to OGCWeb services and other specifications. After the modeling chapter, the implementation ofthe functionalities to create the example maps is covered in chapter 5. The evaluation anddiscussion of the work is presented in chapter 6 by verifying the capabilities of the service-oriented model with respect to important concepts for thematic Web cartography and theWeb infrastructure. Furthermore, the research questions are reviewed with respect to thedeveloped workflow and service-oriented architecture as well as the availability of standardsand technologies. The thesis concludes with chapter 7, which also gives an outlook to furtherwork and opportunities.

4

2. Methodology

The aim of this thesis is to develop a conceptual model based on a service-oriented architecturefor thematic map creation on the Web. The derivation of the conceptual model is thereforeperformed in a sequential manner in three major steps. Preceding to the modeling process, theliterature review identifies important concepts with respect to Web cartography and the Webinfrastructure. Subsequently, the first step of the modeling process, derives the requirementsfrom the discussed concepts and formulates a generic workflow for the production of thematicmaps on the Web. In the second step, a service-oriented architecture is derived by specifyingservices and additional components to perform the steps of the generic workflow. In thelast step, selected functionalities for the creation of three example maps are implemented todemonstrate the operability of the conceptual model. In addition, the model is evaluated bydiscussing it with respect to the requirements.

The different steps to derive the conceptual model and to evaluate the result are outlinedblow. The last section will discuss restrictions and limitations of the approach.

2.1. A Generic Workflow for Thematic Cartography on the Web

The modeling of the workflow for thematic Web cartography is divided in three steps: Thedefinition of requirements, the restriction of the scope of thematic cartography, and the mod-eling process.

The first step, the specification of the requirements, is based on the literature review, whichidentifies important concepts for thematic Web cartography. For the specification of the re-quirements, the functionalities for the implementation of the different concepts are identified.

In addition to the requirements, the second step restricts the field of thematic cartographyto attain a practicable scope for the limited time frame of this thesis. The restrictions arethereby to two-dimensional map representations based on vector features for the map creationprocess.

For the modeling of the generic workflow for thematic map production, the steps and sequencesto create the map representation have to be identified. The derivation of this elements is basedon the production process of standard map representations for two-dimensional thematiccartography, which are presented in the well-known textbooks of Slocum et al. (2008) andDent et al. (2008).

5

Methodology

2.2. A Service-oriented Architecture for Thematic Cartography

Service-oriented architectures (SOA) are an established design pattern on the Web, whichenable a decentralized implementation of functionalities. The aim in this thesis is to utilizethe benefits of SOA for thematic map production. Therefore, the second step of the modelingprocess, derives a conceptual model from the generic workflow developed in the preceding step.The conceptual model develops specific Web services for the functionalities of the workflowand includes additional components to perform the map creation process.

In addition to the modeling, the concept of service chaining and the description of the maprepresentation is discussed to demonstrate the capabilities for an automated creation process.Furthermore, we will validate different implementations of the conceptual model to obtain abasis for the proof-of-concept and the evaluation.

2.3. Proof-of-Concept and Evaluation

The derivation of the conceptual model is based on standard map representations of thematiccartography and important concepts for Web cartography. To verify the results of the mod-eling process we will test the operability of the model in a proof-of-concept and evaluate themodel with respect to the requirements.

The proof-of-concept will implement selected functionalities for the creation of three examplemaps. The aim of the implementation is thereby to test the practicability of the conceptualmodel and to verify the applicability of the SOA for automated thematic map creation. Inaddition, the proof-of-concept should investigate the capabilities of current standards andtechnologies for the implementation of the conceptual model.

In addition to the implementation, the conceptual model is evaluated with an argumentativeapproach. Doing so, the model is discussed with respect to the support of the functionalitiesspecified in the requirements.

2.4. Criticism

The purpose of this research is to develop and examine a concept for thematic map productionon the Web. To interpret the results of this thesis for the field of Web cartography, we haveto consider the restrictions and limitations of the approach presented in the previous sections.

The main restrictions in the modeling process are with respect to the scope of thematic cartog-raphy and the architecture of the conceptual model. The derivation of the generic workflow isthereby restricted to two-dimensional map representations and to the analysis of the produc-tion process of standard map representations. For the specification of the conceptual modelthe approach is restricted to a SOA.

6

Methodology

The limitations of the approach are mainly with respect to the verification of the derivedmodel. Hence, the scope of this thesis does not allow to demonstrate the operability of allcomponents in the conceptual model. In addition, an quantitative evaluation is not possibleby the reason of the conceptual nature of the derived model. The evaluation is thereforelimited to an argumentative approach. Another limitation concerns the derivation of therequirements. These are based on the concepts for Web cartography derived in the literaturereview and therefore depend on a selective approach.

7

3. Fundamentals

The following chapter will discuss the fundamentals of thematic cartography with respect tothe Web infrastructure to provide a basis for the modeling task. In the first section, a shortoverview of thematic cartography and map production is given. The following section, showthe development of the Web and cartography on the Web with focus on service-oriented archi-tectures (SOA). In addition to SOA, section three discusses important concepts for thematicWeb cartography.

3.1. Thematic Cartography and Geovisualization

This section on thematic cartography and geovisualization is divided into two subsections.The first gives and overview of thematic cartography and map production. The seconddescribes standard thematic map representations.

3.1.1. Definition and Cartographic Map Production

The definition in Slocum et al. (2008, P. 1) describes thematic maps, in contrast to general-reference maps, as maps which are “used to display the spatial pattern of a particular themeor attribute”. A similar definition is given in Dent et al. (2008, P. 2), which divides mapsinto general purpose (reference) maps and thematic maps. The later is thereby defined as amap “which show the spatial distribution of a particular geographical phenomena”.

For the description of the production process of thematic maps the communication model forgeographical information is used. A general model is thereby introduced in Hake et al. (2002,P. 22). The authors identify a primary, a secondary, and a tertiary model. The primary modelis created by collecting data from the real world. In a second stage the secondary model, thecartographic representation, is generated from the data of the primary model. The tertiarymodel is formed in the last stage when the user interprets the map.

Another map communication model (Figure 3.1) is given in Slocum et al. (2008), whichidentifies five basic steps for thematic map production. In the first step, the map makerhas to determine the purpose of the map. In the second and third step, the user collectsappropriate data and defines the map parameters. In the fourth step the map is constructedfrom the collected data. In the last step, the result is evaluated and published according tothe map media. If the map has been regarded unsatisfactory in the evaluation step, the mapcreation process starts again with step three, by redefining the map parameters.

8

Fundamentals

Figure 3.1.: Communication Model(Slocum et al., 2008, P. 11)

Figure 3.2.: Cartography Cube(MacEachren and Taylor, 1994, P. 6)

When it comes to cartographic communication we also have to think about the term visual-ization, which is tightly connected with digital production and publishing systems as well asGIS systems. The relation between communication and visualization is best described withthe cartography cube presented in Figure 3.2 (MacEachren and Taylor, 1994). Communicationis thereby a public task which presents knowns and is characterized by low interactivity. Vi-sualization, on the opposite site of the cube, is a private task which involves high interactivityand reveals unknowns.

The differentiation between communication and visualization can also be used to show twogeneral approaches of map production. Traditional maps with focus on communication areproduced on Desktop Mapping (DTM) systems, which generates map representations froma cartographic model by using cartographic representation methods. For the creation ofinteractive maps with focus on visualization, map makers often make use of GIS, whichprovides a variety of analysis functionalities. The map representation is thereby createdby a data-to-vector-geometry transformation, which often lack cartographic representationprinciples. (Asche et al., 2013)

To overcome the limitations of DTM systems and GIS for map production, different conceptsproposed to combine the two approaches. Hardy and Kressmann (2005) propose an extensionof GIS with cartographic representations. According to the authors, the approach enableshigh-quality cartography within a database-centered environment by providing a symboliza-tion pipeline.

Another concept, with focus on atlas systems, is proposed in Bar and Sieber (1999). Theworkflow for the GIS and Multimedia Cartography approach consists of a GIS followed by agraphics application and a multimedia authoring system. The graphics application therebytransforms the GIS objects into cartographic objects while preserving GIS attributes. The

9

Fundamentals

publishing of the map, based on the representations from the graphics application, is per-formed in the authoring system. The maintained GIS attributes enables the provision ofanalysis functions in the authoring system and therefore highly interactive maps.

A similar approach to the previous concept is developed in Asche et al. (2013). The authorsdistinguish the approaches of GIS and VIS (visualization systems) for map production. Itmust be noted that VIS refers to graphic-oriented software and should not be confused with theapproach of visualization mentioned before. With VIS the study instead identifies the previousmentioned Desktop Mapping systems. The proposed approach enables the production ofmap representations out of geodatabases by coupling the GIS and VIS approach as shown inFigure 3.3. Through the coupling, geo data as well as cartographic models are combined inone concept for the creation of quality maps.

Figure 3.3.: GIS-VIS Approach for Map Production(Asche et al., 2013, P. 226)

The section reveals different approaches to thematic cartography. The definite solution comesneither from a map communication nor a visualization approach. The right position in thecartography cube has to be determined for each application individually. In addition, theproduction environment has to be chosen according to the requirements of the map repre-sentation. The discussed studies show that the combination of GIS and DTM systems canenhance cartographic quality and interactivity.

10

Fundamentals

3.1.2. Standard Thematic Map Representations

This section gives an overview of standard techniques for two-dimensional thematic mapping.The review is thereby based on the well-known textbooks of Slocum et al. (2008) and Dent etal. (2008) including the following techniques: Choropleth Map, Dasymetric Map, IsarithmicMap, Cartogram, Proportional Symbol Map, Dot Map, and Flow map.

For the choropleth map, derived data (ratio or rate with respect to the area) of enumerationunits, such as countries or states, is mapped by coloring or shading the corresponding areas.Choropleth representations can be divided into classed and unclassed maps. For the formerthe data has to be classified according to the characteristics of the data and the use case. Inunclassed maps data values are directly mapped to unique symbols and are often used fordata exploration tasks.

The dasymetric map is similar to the choropleth map, whereby the mapped areas are calcu-lated from the enumeration units and additional information, such as data for ancillary zonesor raster data for land use or other attributes. The benefit of dasymetric mapping comparedto choropleth mapping is that density variations within enumeration units can be mapped.

An isarithmic map displays three-dimensional geographical data. The visualization can beperformed with isolines and coloring or shading areas between isolines, with continuous-tone,and with wire-frame representations. To derive the data for the mapping an interpolationof the initial data has to be performed. Thereby, isometric mapping, with data occurring atpoints, and isoplethic mapping, with data occurring over geographical areas, is distinguished.

Another area based mapping technique are cartograms. The mapping of the data is thereforeperformed through scaling the areas of the enumeration units proportional to the correspond-ing attribute values. In contiguous cartograms boundaries between enumeration units arepreserved in contrast to non-contiguous cartograms, where the mapped areas float in themapped space. Specialized forms of contiguous cartograms are circle and rectangular car-tograms, where the mapped areas are generalized to circles and rectangular figures.

In the proportional symbol map point data is mapped with geometric (circles, squares, spheres,cubes . . . ) or pictorial symbols. The point location can thereby be measured directly (truepoint data) or can be derived from other representations (conceptual point data), for exampleby calculating the centroid of an enumeration unit. The size of the symbols is calculated fromthe corresponding attribute values, whereby different scaling and classification approachesare used. In addition to the location and size, the map maker has to consider the overlap ofsymbols to provide an efficient map representation.

Dot maps are used to communicate variations in spatial density by placing dots inside enu-meration units, whereby the amount of dots depends on the unit value (the count representedby each dot) and the corresponding attribute value of the area. To determine the size and unitvalue for a dot map a graphical device called nomograph can be used. The placement of thedots is either performed manually or based on algorithms, whereby additional information,such as data for ancillary zones, raster images, or digital elevation models can be utilized.

11

Fundamentals

The flow map show the movement between (geographic) locations and can be divided intofive sub-types. Distributive flow maps show movements between points, whereby true pointand conceptual data can be used. Network flow maps reveal movements in networks such asa road systems. The mapping of the data is thereby commonly performed by varying linewidth or line color. Another form are radial flow maps, which instead of mapping actualroutes only visualizes the direction of the flow with respect to a reference point. Continuousflow maps are used to map phenomenas, such as wind speed, which can be described witha vector field. The last type are telecommunication flow maps, which map Web traffic andother telecommunication data and often have no geographical space.

3.2. The Internet and Web Cartography

The Web and cartography on the Web are under rapid development. To give an overview ofthe current state, the first subsections of this section cover recent developments of the Weband the GeoWeb. The following two sections describe SOA on the Web and approaches toservice-oriented cartography.

3.2.1. The Modern Web and the GeoWeb

The expansion of the Internet connects more and more people around the world. From 2005to 2011 the number of individuals who are using the Internet increased from 1.024 billion to2.273 billion. In addition, the access to the Internet is shifting to mobile subscriptions. In theyear 2011, active mobile-broadband subscriptions reached an amount of 1.155 billion. (ITU,2013)

With the rise of the Internet the keywords Web 2.0 and Semantic Web are closely connected.In contrary to the static Web of the early years of th Internet, the Web 2.0 is characterizedby community based websites. This pages allow to collaboratively generate information aswell as sharing the information. Another concept of the Web 2.0 are Mashups, which combinedifferent information sources to generate new values. On the technological site, AJAX enhancethe creation of Web pages for the Web 2.0 by enabling the creation of highly interactive userinterfaces. The main goal of the Semantic Web is to extend the data description to createmachine readable information. This goal is achieved by complex and comprehensive modelingwith standards such as the Web Ontology Language (OWL) or the Resource DescriptionFramework (RDF). The complexity of the modeling process often implies heavy-weight toolsand sophisticated reasoning. (Berners-Lee et al., 2001),(Ankolekar et al., 2008)

In contrary to see the Semantic Web and the Web 2.0 as competing visions, there are moreand more opinions that the two ideas complement each other. The Semantic Web can benefitfrom an collaborative approach to solve the complexity of the semantic modeling process. Inaddition, Web 2.0 applications can benefit from the Semantic Web through benefits for theexchange and reuse of the created information. (Ankolekar et al., 2008)

12

Fundamentals

The developments of Web cartography are best described by the change in map distribution.The first static Web mapping site, which provided raster images as GIF format, dates to1993 and was the Xerox PARC Map Viewer. The first major distributor of Web maps wasMapQuest, which started the service in 1996 and provide user-defined street maps. The rapiddissemination of Web maps at this time is best shown by the downloads from MapQuest ona daily basis, which increased from 700,000 in 1997 to 20,000,000 in 2001. (Peterson, 2003)

The next important year for Web mapping is 2005 in which Google Earth and Google Mapsare introduced. The increased awareness of geospatial products and data combined withtechnologies of the Web 2.0 brought a new generation of mapping products and applications.The distribution of maps changed thereby from the provision of simple raster images tomore interactive representations utilizing vector data and relying on AJAX for better userexperience. (Crampton, 2009),(Haklay et al., 2008)

The rise of geographic information and products on the Web is identified with the termgeospatial Web or GeoWeb. The most important factors of the GeoWeb in the recent yearsare the development of Mapping APIs, which provide geo data and services, and the avail-ability of standards. Especially, the OGC Web Service specifications are important since therelease of the Web Map Service (WMS) standard in the year 2000. Additional advantagesof the GeoWeb are open source tools and crowd-sourced data, most notably therefore is theOpenStreetMap project. (Haklay et al., 2008),(Crampton, 2009)

Summarizing, Web cartography shifted from static maps to interactive and dynamic maps.From raster images to a wider use of vector graphic formats. The distribution is changing todistributed and service-oriented approaches and serves more and more individual and singlepurpose maps. Another development is just at the beginning with the expansion of themobile Web. New applications will therefore have to consider different screen sizes and inputmethods. In addition, more and more devices with GPS capabilities enhance the developmentof location based applications. (Peterson, 2008),(Schnabel and Hurni, 2009)

3.2.2. Service-oriented Architectures and Web Services

A service-oriented architecture (SOA) is a paradigm to arrange and utilize different function-alities and resources that may be distributed over different domains. The term Web servicerefers to the realization of the SOA paradigm in the Web infrastructure. The Web serviceinterface which is exposed to the Web is called application programming interface (API). Toprovide interoperability, SOA and Web services are standardized for the Web by the WorldWide Web Consortium (W3C), the Organization for the Advancement of Structured Infor-mation Standards (OASIS), the Object Management Group (OMG) and The Open Group.(Kohlborn and Rosa, 2012)

The main standards for Web Services, categorized by their abstraction level, are shown inFigure 3.4. In the following, we will discuss the main specifications with respect to messagingand description of services and service orchestration to provide the basics for this thesis.

13

Fundamentals

Figure 3.4.: Technologies for Service-oriented Architectures(Kohlborn and Rosa, 2012, P. 113)

On the messaging and description level two architectural styles can be distinguished, namelyWS-* and Representational State Transfer (REST). Services defined with the standards ofWS-* can use different messaging protocols, where the most common is SOAP. REST servicesare identified by URI and use HTTP actions (i.e., HTTP PUT, GET, POST and DELETE)to manipulate the state of the resource. RESTful Web services are simple and lightweight,but lack of methods to describe service contracts and miss other specifications such as WS-Security to handle security issues. To describe Web services, WSDL (Web Services DescriptionLanguage) can be used with the architectural style of WS-* specifications. For the descriptionof RESTful Web services, WADL (Web Application Description Language) or WSDL 2.0 isused. (Kohlborn and Rosa, 2012)

For the orchestration and choreography of Web services two major standards are available.WS-BPEL (Web Services Business Process Execution Language), or short BPEL, is a XML-based language for the definition of orchestration models, which represent the order of ser-vice operations. BPEL descriptions can be automatically executed by a BPEL engine. Theconnection between BPEL and Web services is managed by three communication activities(Invoke, Receive and Reply), which can be directly mapped to Web service operations definedin a WSDL document. Similar to BPEL, standardized by OASIS, the Object ManagementGroup (OMG) specified the Business Process Model and Notation (BPMN) language, whichis also directed to a non-technical audience by providing a standardized graphical notation.(Kohlborn and Rosa, 2012)

14

Fundamentals

Standardization with focus to geospatial data are mainly introduced by the Open GeospatialConsortium (OGC). The OGC is an international industry consortium of 473 companies, gov-ernment agencies and universities. The most common implementation to provide maps overthe Web is given by the specification of the Web Map Service (WMS). Similar to the WMS,the Web Map Tile Service (WMTS) specification defines a standard to distribute maps withan approach based on map tiles. In addition to WMS and WMTS, which commonly pro-vide maps as raster images, the Web Feature Service (WFS) specification is used to providevector data. Another important specification for geospatial Web Services is WPS (Web Pro-cessing Service), which defines a generic interface to implement functionalities for processinggeospatial data.

3.2.3. Web Cartography with SOA

In the literature different approaches to Web cartography with service-oriented architecturesare presented. In the following, the major contributions of the recent years to service-orientedWeb cartography beyond the scope of OGC Web services are described. In the end of thissection a short overview of OGC Web service orchestration is given.

In the dissertation of Iosifescu-Enescu (2011) a Web service to automatically generation mapsfrom GIS data is developed. The definition of the symbolization is based on the Styled LayerDescriptor (SLD) and the Symbology Encoding (SE) specifications, which are standardized bythe OGC and are used with WMS implementations. To achieve an appropriate symbolizationfor topographic and thematic maps SLD and SE are extended for cartographic needs.

To provide cartographic maps with a Web service, Iosifescu-Enescu (2011) defines the Mapand Diagram Service Interface (MDSI), which can be seen as an enhanced Web Map Service.Additional functionalities to the WMS interface are functionalities to generate diagrams forgiven tabular data, to request a legend graphic for a specific layer, to get the style descriptionfor a specific layer, and to get a layer description containing the schema information of alayer.

A service-oriented approach to create choropleth and proportional symbol maps is proposedin Rautenbach et al. (2013). The input of data is thereby implemented with a Web FeatureService. To statistically analyze the data and prepare a SLD style sheet for the renderingprocess the WPS interface is used. Rendering and distribution of the map is implementedwith a WMS, which renders the data according to the SLD style sheet. The study proposesthat a automated thematic map production is possible, but involves the risk of producingmaps that are misinterpreted by the user.

Asche and Engemaier (2012) developed the concept CartoService (Figure 3.5), which proposesa service-oriented architecture for the creation of cartographic maps. The model distinguishesthe application layer for the user interface, the processing layer for the combination of differentservices, and the data layer for data storage and management. To identify different internaland external services a service repository is used. For data preparation the concept suggeststhe following services: data import, analysis, filter, harmonization, and generalization. Tovisualize the data a symbolization service and a rendering service are defined.

15

Fundamentals

Figure 3.5.: Architecture of the CartoService Concept(Asche and Engemaier, 2012, P. 418)

Additional to the definition of the components of the service-oriented architecture, also the or-chestration of different services is important to enable an automated or semi-automated mapcreation process. Web service orchestration is mostly described with the Business Process Ex-ecution Language (BPEL), which utilize SOAP and WSDL. To enable WPS implementationsfor the use with BPEL, Sancho-Jimenez et al. (2008) proposes a proxy to provide the SOAPand WSDL interface for any WPS implementation. An extension of this concept proposesFleuren and Muller (2008) by suggesting an intermediary SOAP proxy also for other OGCWeb services such as WMS and WFS. In addition the study demonstrates the possibilitiesfor a stateful Web Map Service by using a PostGIS database which is directly connected tothe proxy.

Beside orchestration with BPEL, Supavetch and Chunithipaisan (2011) proposes an interfaceindependent orchestration language, which is executed by an execution engine implementedwith a WPS. The results of the study show that the approach allows a flexible combinationof different service types, but it also emphasizes that more complex components has to beincluded in the orchestration of services. Examples therefore are the process status, processmonitoring, asynchronous orchestration, and notification model.

Another difficulty, with regard to automated service matching, is mentioned in Kiehle et al.(2006), which states that a spontaneous linkage of services is only possible if the executionengine has sufficient semantic information about the Web services.

16

Fundamentals

3.3. Concepts for Thematic Web Cartography

In addition to service-oriented architectures discussed in the previous sections, this sectionwill focus on four important concepts for thematic cartography on the Web. The first isthereby interactivity which is an important aspect of digital map products. The secondconcept, collaboration, is an element of the Web 2.0 and the GeoWeb as for example theOpenStreetMap project shows. The last two concepts cover linking of information and servicesas well as searchability and findability. These concepts are inherent to the Web infrastructuresince the beginning and are also important for the semantic Web.

3.3.1. Interactivity

For the conception and production of digital cartographic products interaction is very impor-tant. Digital technologies not only gives us the possibility to display different cartographicrepresentations for low cost, but also gives us the possibility to provide interactive tasks withthe map and the underlying data.

The main benefits which can be achieved with vector graphic formats for interactive mappingare mentioned in Lienert et al. (2012, P. 24) as following: (a) [vector graphics] are scalablewithout loss of information or graphical artifacts; (b) the symbolization is adjustable on-the-fly (e.g., line width, transparency, fill color); (c) the geometry and symbolization can beanimated; (d) map features can be shown and hidden without regenerating and reloading theentire map; (e) attributes can be attached to each individual map feature; (f) map features,such as diagrams, can be generated on-the-fly; and (g) the geometry can be changed, allowingfor lossless projection to other coordinate systems.

When it comes to interaction we also have to think about user-centered design, which can beseen in the approaches of high-quality digital map products, such as the Atlas of Switzerland(Sieber et al., 2009) and the Atlas of Canada (Kramers, 2008).

For a comprehensive model of a user-centered design for digital cartographic representationswe will use the approach of Roth (2012), which is based on the stages of action model proposedin Norman (2002). The adoption for cartographic interaction of Norman’s interaction modelis shown in Figure 3.6 and can be divided into an execution and an evaluation phase.

In the execution phase, Roth (2012, P. 381) classifies interaction taxonomies into objective-based, operator-based, and operand-based approaches, which are named the three O’s ofcartographic interaction. The objective-based approach describes interaction at the stage offorming an intention to interact. This stage emphasizes the task the user may wish to com-plete. In the operator-based approach, taxonomies are covered that deal with specifying theaction for interacting with the computing device. In the last group, the operand-based tax-onomies, approaches are covered which specify the implementation at the computing device.

For this thesis the implementation of interaction at the computing device is important. There-fore, we will focus on the operand-based approaches of interaction. The literature review inRoth (2012) reveals two types of interaction taxonomies for operand-based interactions: type-

17

Fundamentals

Figure 3.6.: Stages of Action for Map Interaction(Roth, 2012, P. 379)

centric and state-centric. Approaches that discriminate primitives according to the character-istics of the presented information are type-centric taxonomies. State-centric taxonomies areoriented to the production process of cartographic maps from raw data to the presentationof the map. In this thesis we want to model the production of thematic maps on the Web.Therefore, we will focus on state-centric interaction theories from the field of cartography andGIS, which are presented in Persson et al. (2006) and Crampton (2002).

Persson et al. (2006) develops a comprehensive typology of around 70 interactivity functions,which are organized in 8 different interaction types. The typology is based on a literaturereview of existing divisions and categorizations of interactions. The first three types of inter-activity functions concern the map creation process. Thereby functions are identified withrespect to the model of the cartographic communication process. The identified types are theinteraction with the cartographic representation (T1), the interaction with the algorithms forthe creation of the representation (T2), and the interaction with the primary model (T3).The fourth and fifth interactivity types covers interaction with multiple views. Furthermore,the study distinguishes between the arranging of multiple views (T4) and the dynamic linkingof different display types (T5, Brushing). The sixth and seventh type of interactive functionsinclude functions related to the third and fourth dimensions, which are the change of thetemporal dimension (T6) and the interaction with 3D visualizations (T7). The eight and lasttype covers basic functions for system interaction (T8) such as panning or scrolling.

18

Fundamentals

The state-centric approach in Crampton (2002) distinguishes between contextualizing inter-action, interaction with the representation, interaction with the data and interaction withthe temporal dimension. A comparison with the previous mentioned interaction types (Ta-ble 3.1) show that the taxonomy in Crampton (2002) can be seen as a generalization of theinteractivity types proposed in Persson et al. (2006).

Table 3.1.: Taxonomy of Interaction Types

Interaction with the DataInteraction with theData Representation

• Interaction with the Primary Model/Database Query (T3)

• Dynamic Linking with further DisplayTypes (T5, Brushing)

• Interaction with the RepresentationModel (T1)

• Interaction with the Algorithms for theCreation of a Representation (T2)

• Interaction with the (Pseudo-) 3D Vi-sualization (T7)

• System Interaction (T8)

Interacting with the TemporalDimension

Contextualizing Interaction

• Interaction with the Temporal Dimen-sion (T6)

• Arranging Many Simultaneous Views(T4)

For the scope of this thesis, the four interaction types proposed in Crampton (2002) aresufficient to consider interactive functions in the production process of thematic maps. Withrespect to the stages of the action model for user-centered design the work therefore focuseson operand-based interactivity. Nevertheless, it should be noted that all stages of the modelshould be considered when the findings of this thesis are implemented in a productive mappingapplication.

3.3.2. Collaboration and Neogeography

The main advantages of the Geospatial Web or GeoWeb are identified in Crampton (2009)as crowd-sourced data, open source tools and services, and participation and syndication.Tightly coupled with the developments of the GeoWeb in the recent years are the change ofthe Web infrastructure to a collaborative and interactive platform, known as the Web 2.0.With respect to the GeoWeb the recent developments can be summarized with the term WebMapping 2.0.

The key Web Mapping 2.0 technologies mentioned in a study by Haklay et al. (2008) arethe availability of affordable GPS devices for positioning and data collection, the Web 2.0technology AJAX for interactive applications, and the development of mapping APIs for the

19

Fundamentals

provision of mapping functionalities and data. Beside the technologies, the authors discussdifferent concepts for collaboration, which are inherent to Web Mapping 2.0. For the scope ofthis thesis the concepts of knowledge collectives and peer production networks are important.

The concept of knowledge collectives describes the sharing and managing of information andcommon resources. An example for a knowledge collective is the Open Street Map (OSM)project, which provides crow-sourced geodata. In addition, the OSM project is an examplefor a peer production network, which enables people to work together for solving problemsand producing goods. With respect to OSM, this means distributed data collection andcommunity based development of mapping tools. (Haklay et al., 2008)

Another concept of Web Mapping 2.0 are mash-ups, which are used since 2000 by utilizing theOGC standards (Haklay et al., 2008). Map mash-ups are the combination of datasets fromdifferent resources and can be easily created by non-expert users on platforms like MapTube1.Another example for a mash-up is the London Profiler2 project, which is mentioned in Hudson-Smith et al. (2009) as a low cost and easy to use solution for the communication of spatialinformation between stakeholders and the government.

With the rise of the GeoWeb and Web Mapping 2.0 another important development is con-nected: Neogeography. The essence of neogeography is best described by the definition inTurner (2006, P. 2-3):

Neogeography means ”new geography” and consists of a set of techniques and toolsthat fall outside the realm of traditional GIS, Geographic Information Systems.Where historically a professional cartographer might use ArcGIS, talk of Mercatorversus Mollweide projections, and resolve land area disputes, a neogeographer usesa mapping API like Google Maps, talks about GPX versus KML, and geotags hisphotos to make a map of his summer vacation.

Essentially, Neogeography is about people using and creating their own maps, ontheir own terms and by combining elements of an existing toolset. Neogeography isabout sharing location information with friends and visitors, helping shape context,and conveying understanding through knowledge of place.

The definition shows a rather unconventional approach to cartography and GI science, withrespect to professional techniques. In the literature this issue is discussed under the headings”deprofessionalization or reprofessionalization?” (Crampton, 2009) or ”cult of the amateuror mass collaboration?” (Haklay et al., 2008). The answers to the questions mostly remainsopen or ideologically biased. For the scope of this thesis we will use the pragmatic approachof Haklay et al. (2008, P. 2034), who proposes: ”It is not either one or the other, and thereis clearly a space for both, so a synergistic approach is required.”

Web Mapping 2.0 also involves a change in the provision of data and how we evaluate data.Haklay et al. (2008) proclaims a change from a linear, publishing ”push” model, with centraldata collection and distribution, to an inter-networked, participatory model where information

1http://www.maptube.org/2http://www.londonprofiler.org/

20

Fundamentals

is collected collaboratively and can be accessed through many channels. With respect to dataquality, solutions have to be found to ensure accuracy (including metadata), coverage andresolution as well as privacy and copyright (Hudson-Smith et al., 2009).

The discussed concepts shows collaborative approaches for cartography and GIS on the Web,but also in other areas of cartography an adoption of collaborative concepts is taking place.An example is the open atlas platform concept proposed in Sieber et al. (2011). Thereby,capabilities are provided to extend the core atlas application with third party modules. Inaddition, the concept enhances collaboration by enabling the contribution of statistical andgraphical geodata.

3.3.3. Linking of Documents, Data and Services

The principle of linking documents, the concept of Hyperlinks, is inherent to the Web sincethe beginning. With the development of the Semantic Web and the adoption of linked dataprinciples, like RDF, new ways for publishing and searching data on the Web are emerged(Bizer et al., 2009). In the following we will shortly discuss the linkage of documents and datain the Web infrastructure. For the linking of services see section 3.2.2 about service-orientedarchitectures and Web services.

With respect to linkage of information on the Web two concepts can be distinguished: Linkingof documents and linking of data. The first concept is the basic structure of the Web. URLs,a subset of URIs, are used to identify different HTML documents, which are transmitted overthe HTTP (or HTTPs) protocol. With the concept of Hyperlinks Web pages can referenceto other HTML documents and can therefore establish a one way link. The concept oflinking data on the Web is an approach of the Semantic Web. Thereby, URIs and HTTP aresupplemented by RDF, which links data objects and includes a description of the connection.The link is thereby defined by a subject, predicate, object triple, whereby the subject andobject are both data resources identified with URIs. The predicate describes the relationshipof the subject and the object and is as well represented by a URI. (Bizer et al., 2009)

An example for a RDF triple is given in Figure 3.7, which states that the resource http://

www.w3.org/People/Berners-Lee/card#i is a member of the resource http://dig.csail.

mit.edu/data#DIG. The URI http://xmlns.com/foaf/0.1/member defines the relationshipof the type member in RDF.

Figure 3.7.: RDF Triple(Bizer et al., 2009, P. 4)

21

Fundamentals

3.3.4. Searchability and Findability

Since the beginning of the Web, approaches for information retrieval are important to dealwith the large amount of data. The terms searchability and findability are best described withthe taxonomy in Broder (2002), who distinguishes informational and navigational queries.Navigational (searchability) queries deal with the purpose of searching information which isassumed to be available on the Web. In contrast, navigational (findability) queries, or knownitem searches, are used to find a concrete piece of information.

A comprehensive discussion of the field of information retrieval on the Web with respectto cartographic applications would be beyond the scope of this thesis. In the following thediscussion is limited to two important aspects of mapping applications on the Web withrespect to searchability and findability.

The first aspect is the way in which the data is published on the Web. To enable the accessto data for other participants, especially search engines such as Google, four concepts can bedistinguished (Ceri et al., 2013). The first concept identifies all approaches where informationin a database can only be accessed by query forms. The information which is hidden in thedatabases is thereby known as the Deep Web. The access of the data by query forms can notbe utilized by search engines. Therefore, it is the least accessible method for data provision.The second concept to provide data is over Web application program interfaces (API). WebAPIs provide better access to data compared to query forms, but mostly are not accessible forsearch engines. The third concept are microfromats, which used to add metadata directly intoHTML pages. This additional descriptions can be automatically extracted by search enginesand should therefore be preferred to the previous concepts. The last and most preferableconcept is linked data, which was already discussed in the previous section. A specific wayfor publishing RDF triples in Web pages is RDFa, thereby the subject, predicate and objectcan be directly defined in the HTML Web page.

The discussion show different approaches for publishing data on the Web ordered by theaccessibility for search engines. It should be noted that for the development of an applicationalso other aspects such as development costs and data security have to be considered.

Beside the aspect of how the data is published, it has also be considered which data ispublished to enhance searchability and findability. Thereby, an important aspect is the dataabout the data: metadata. To describe geographical data the most important standards arethe ISO standard 19115 and the FGDC Content Standard for Digital Geospatial Metadata. Inaddition to metadata standards, the concepts of tagging and ontologies are important. Withrespect to tagging the approach of social tagging, where metadata is created in a crowd-sourced manner, is more and more utilized with the development of the Web 2.0 (Csaba,2013). Ontologies can provide a more flexible access to the information as shown in Faraziet al. (2013) with the Semantic Geo-Catalogue project.

In conclusion, the aspects of how we publish data and how we describe the data are importantto provide searchability and findability. Publishing information in a machine readable waywill enable functionalities for searching and finding information inside the application andimprove the accessibility of the application for search engines.

22

4. Modeling

In this chapter a conceptual model based on a service-oriented architecture for the productionof thematic map representations on the Web is derived. Therefore, the first section formulatesthe requirements for the modeling process. The following two sections present the modelingprocess in two steps. In the first, a generic workflow is presented, which is based on theproduction of standard cartographic map representations. In the second step, the tasks ofthe generic workflow are modeled with a service-oriented architecture by defining specific Webservices and additional components for the map creation process.

4.1. Requirements for the Conceptual Model

The requirements for the conceptual model are derived from the aspects of Web cartographyand the modern Web infrastructure as stated in the previous chapter. The specifications,presented in Table 4.1 are thereby structured into five groups: One group with requirementsfrom the field of digital map production and fours groups of requirements which are based onthe concepts for thematic Web cartography.

The first group contains requirements which arise from the production process. The literatureshows, that an efficient concept for cartographic map production considers GIS functionalitiesand DTM (Desktop Mapping) functionalities. With respect to thematic map production themodel should support the standard thematic map representations discussed in section 3.1.2.

The second group considers the implementation and provision of interaction functionalities.The requirements are thereby based on the study of Crampton (2002), which distinguishesbetween interaction with the data, the data representation, the temporal dimension, andcontextualizing interaction.

The third group aggregates specifications which consider collaborative aspects. The discussionon collaboration and neogeography shows that the concepts of peer production and knowledgecollectives are important for Web cartography. Therefore, the conceptual model should enablecollaborative map production and the sharing of intermediate and end products as well asfunctionalities.

The fourth group is based on the concept of linking documents, data and services. In therequirements the linking of documents is supplemented by the linking of maps as a specialform of a document. With respect to linking data the model should consider approaches ofthe semantic Web such as RDF triples.

23

Modeling

Table 4.1.: Requirements for Conceptual Model

Map Production I Support GIS functionalitiesI Support DTM functionalitiesI Support of standard thematic map representations

Interaction I Enable interaction with the dataI Enable interaction with the data representationI Enable interaction with the temporal dimensionI Enable contextualizing interaction

Collaboration I Enable collaborative map productionI Enable sharing of intermediate and end productsI Enable sharing of functionalities

Linking I Enable the linking of documents and mapsI Enable the linking of dataI Enable the linking of services

Searchability/Findability I Enable different publishing conceptsI Enable the generation of metadata

In the last group requirements which enhance searchability and findability are regarded. Tooptimize maps for search engines, the conceptual model should allow for different publishingconcepts. In addition, the generation of metadata has to be considered to support searchingand finding of information.

4.2. Derivation of the Generic Workflow

After the direction of the modeling process was set in the previous section with the require-ments, a generic workflow for thematic cartography will be developed in this section. Aworkflow for the whole realm of thematic cartography would be an endless task. Therefore,in the first section the field of thematic cartography is restricted to a scope which is applicablefor Web cartography. In the second section, the generic workflow is presented, which is basedon the production process of standard thematic map representations.

4.2.1. Definition of the Scope of Thematic Cartography

To limit the scope for the modeling process in this thesis, the realm of thematic cartography isrestricted with respect to the map representation and the functionalities for data processing.The modeling process will consider the production of two-dimensional map representations.The mapping of the data is thereby restricted to coordinate reference systems based on

24

Modeling

cartographic projections, which allows to maintain the coordinate reference of all input data.The second restriction concerns the processing of data. The processing of raster data isin comparison to point, line and area data difficult to automate and will therefore not beconsidered in the workflow. It should be noted, that this restriction does not exclude theusage of raster data. Raster images can be implemented in a map as a separate layer, suchas a base map. In addition, the rendering of the vector data to publish the map as a rasterimage is possible.

4.2.2. A Generic Workflow for Thematic Cartography on the Web

In this section a generic workflow for thematic cartography is presented. The modeling isbased on the production of standard thematic map representations introduced in section 3.1.2and focuses on the essential steps to produce thematic maps on the Web.

The purpose of the workflow in this section is to provide a basis for the implementation ofthe service-oriented architecture. Therefore, the workflow is restricted to tasks which involvesoftware functionalities. To clarify the scope of the workflow, we can compare it to thecommunication model in Slocum et al. (2008), which was introduced in section 3.1.1. Theapproach in this thesis considers the constructive tasks of selecting data, constructing themap, and publishing the map. The conceptual tasks of defining the purpose of the map,defining the parameters of the map, and evaluating the map are independent of the softwareand therefore not considered in the workflow.

The tasks of the generic workflow model, which is shown in Figure 4.1, can be generalizedinto four stages, which will be discussed in the following.

Data Preparation

The data preparation includes the selection, the preparation and the integration of the datafor the map. For the data selection we assume that the map creator selects a subset of datafrom a data source on the Internet or a local storage. The workflow thereby distinguishesbetween spatial and attributive data. After the selection step, the data is analyzed andmanipulated to get the data basis for the further process. This step includes tasks such asverifying the data quality, checking the topology of spatial data sets or combining differentdata sets. In the data integration task, the attributive data is combined with the spatial datato get a uniform vector data set for the further mapping process.

Data Generation

The data generation is used to derive specialized mapping data from the data basis whichwas prepared in the preceding step. Examples for this stage of the workflow are the creationof point data for a dot map, the calculation of areas for a cartogram, or the interpolation ofdata for an isarithmic map.

Mapping

The mapping includes an analysis and manipulation step and a symbolization step. Themapping is thereby performed in an iterative manner, called the mapping loop. In the first stepthe vector data set is adjusted for symbolization. This for example implies the classification

25

Modeling

of the data set, the calculation of the size for proportional symbols, or the adjustment ofpoint features for symbol placement. In the second step the map representation is created bycombining the vector data with point, line and area symbolizers. In addition to the renderingof the map symbology, the placement of labels has to be performed in the mapping loop.

Presentation

The presentation stage contains the map composition and the map publishing. The formerincludes the combination of different map layers, the creation of a legend for the map dataand the placement of additional map elements such as map title, scale bar, and imprint. Thelast step of the workflow considers the publishing of the map on the Web.

Figure 4.1.: Generic Workflow for Thematic Map Production on the Web

26

Modeling

In addition to the iterative procedure in the mapping stage, the workflow is repeated at thedata generation step or from the beginning, if the result from the map generation loop is notsufficient.

The presented workflow follows a strict layer-based approach for map creation, whereby onelayer is created by performing the tasks from selecting the data to symbolizing the data.The workflow implies that one layer represents a two-dimensional data table correspondingto a specific standard map representation and to one scale. Multivariate maps are therebyconstructed with separate layers for each map representation. In addition, multi-dimensionaldata sets, for example, with values for different time periods or different scales, are mappedby generating multiple layers.

Beside the representation of the data by point, line and area symbols, labels can be added withtwo approaches. In the first approach the anchor point of a label is defined by the mappedpoint, line, and area data. The second approach is a separate label layer which defines theanchor point of a label combined with the label text.

The combination of different layers to construct the final map representation is performed inthe map composition step. Thereby, the map creator has to select the appropriate layers forthe map and has to define the layer properties, such as transparency or masking of labels. Ithas to be noted, that the combination of layers has to be already considered in the mappingstage to provide a well designed map representation. For example, other layers have to beconsidered in the placement of labels to provide good readability of the map.

To produce effective thematic maps the knowledge of visual variables, knowledge about thesymbology, is important. In the workflow this is implied in the mapping stage and the mapcomposition. For the mapping, the map creator has to derive parameters for the symboliza-tion. This for example implies the calculation of classes, which has to consider the symbologyas well as the characteristics of the used data. In the map composition, knowledge about thesymbology is needed to generate the legend corresponding to the theme of the map.

In addition to the steps for map creation, the workflow in Figure 4.1 is extended with theinteraction tasks mentioned in Crampton (2002), which where discussed in section 3.3.1.

For the interaction with the data, functionalities have to be provided which allow to queryand analyze the underlying data of the map representation. With respect to the workflow,these functionalities can be provided in the steps ranging from the data selection to dataanalysis and manipulation in the mapping stage.

Interaction with the data representation involves the data and parameters for the symbol-ization, the symbology, and the map representation. The data for the mapping is derivedin the data generation step. An interactive task can be the changing of the dot placementalgorithm for a dot map. Parameters for the symbolization are derived in the mapping stagewith the analysis and manipulation step. An example for interaction is the reclassification ofdata for a choropleth map. Interaction with the symbolization, such as changing the colorscheme, involves tasks affecting the selected point, line, or area symbolizer. With respect tothe map representation, interactive functions are affecting the map view, for instance panningor zooming, and have to be provided in the publishing step.

27

Modeling

Contextualizing interactions involve the combination of different layers and the arranging ofmultiple views, which can be performed with the functionalities included in the map compo-sition.

The last interactive task summarizes interactions with the temporal dimension, which con-siders dynamic mapping techniques such as fly-bys and fly-throughs or navigation. Theimplementation of these tasks is performed in the publishing step.

4.3. The Conceptual Model

In this section we will present and discuss a conceptual model for thematic cartography onthe Web. The conceptual model is thereby modeled as a service-oriented architecture (SOA)and is based on the generic workflow from the previous section.

The content of this section is structured into four subsections. In the first the componentsof the SOA are introduced and an implementation of the generic workflow is presented todemonstrate the fundamental functioning of the model. The second subsection discussesthe description of the map creation process with respect to service orchestration. In thethird, different implementations of the conceptual model are presented to demonstrate thepossibilities of the approach. The last subsection compares the components of the conceptualmodel with OGC Web services and additional specifications to reveal similarities to the currentGeoWeb infrastructure.

4.3.1. A Service-oriented Architecture for Thematic Cartography on the Web

The description of the SOA in this section is divided into two parts. First, the componentsof the SOA are presented and identified with the steps in the generic workflow. In thesecond step, the orchestration of the specified components to perform the steps of the genericworkflow is demonstrated.

Before providing details on the implementation of the different components, an overview ofthe derived Web services is given in the following.

The first step in the generic workflow, which involves functionalities for selecting and im-porting the data, is realized in the Data Conversion Service. To provide basic functionalitiesfor analyzing and manipulating the data, five services are introduced, which are summarizedas Analysis and Manipulation Services (AMS). In addition to the AMS the CartographicProcedure Service is defined to provide specialized processing techniques for thematic map-ping. The last service, called Thematic Map Service, provides functionalities for renderingand publishing the map.

An important design aspect of the SOA is the separation of data processing and symbolization.Therefore, the services for data import, data processing, and map publishing are supplementedby the Symbology Repository for the description of map symbologies.

28

Modeling

Data Conversion Service

For the production of thematic maps, data has to be selected and imported into the mapproduction system. In the SOA, this tasks are provided by the Data Conversion Service(DCS), which supports the selection of data from online as well as local databases and stor-ages. Furthermore, the DCS converts the data from the source data type into a data typeappropriate for the layer-based workflow. This, for example, implies the conversion of multi-dimensional data sets, such as statistical data with a location, time, and attribute dimension,into two-dimensional data sets.

To handle different sources, the functionalities of the DCS are organized into so-called conver-sions. One conversion thereby provides the functionalities to select and convert the data froma specific data source. To control the transformation process the user can set parameters,which are individual to each conversion.

An example for a conversion is the selection of data from the GADM1 (Global AdministrativeAreas) Web page. The DCS therefore has to download data from the GADM Web page,according to the user-defined selection parameter, and convert the data into a user-defineddata format. Another example would be the import of statistical data from the OECD OpenData API2.

The service interface of the DCS is presented in Figure 4.2 and provides the operationsgetCapabilities, getConversionDescription, and getData.

Figure 4.2.: Data Conversion Service Interface

The implementation of the getCapabilities operation returns service metadata and follows theimplementation standard for OGC Web services.

The getConversionDescription operation provides metadata for a specific conversion. Theresponse is thereby similar to the getCapabilities operation a XML-based document, which

1http://www.gadm.org/2http://stats.oecd.org/OpenDataAPI/Index.htm

29

Modeling

contains information about available datasets, output formats, and parameters for the con-version process.

With the getData operation a specific conversion is performed. The request therefore has tospecify the conversion name, the required conversion parameters, and optionally the outputdata type. To import local data the getData request allows to upload data, which can beprocessed by a conversion.

Analysis and Manipulation Services

In the generic workflow functionalities to analyze and manipulate the data are needed inthe preparation and the mapping stage. In the SOA, the functionalities of both stages areclassified according to similar functions and are implemented with five services.

The interfaces of the analysis and manipulation services are shown in Figure 4.3. The func-tionalities of each service, with exception of the Reprojection Service, are structured intooperations and subordinated methods. To get an overview of the available operations andmethods a getCapabilities request is used, which provides service metadata similar to the DCS.Specific information for a processing method can be requested with the getMethodDescrip-tion operation. The return message thereby includes a method description, a specification ofavailable processing parameters, and possible input and output formats.

In addition to the uniform structure of all processing services, the request and responsemessage is uniform over all services to enhance interoperability and service chaining. Therequest message contains the method name, required method parameters, and the data ofone or multiple layer. Optionally the input and output data type can be specified if itis supported by the processing method. With respect to the response message, processingmethods are restricted to return two-dimensional data sets which can be processed in thelayer-based workflow.

In the following we will discuss the functionalities of the processing services. It should be notedthat the proposed operations provide the basic functionalities for thematic map production.The derivation of a complete list of processing functionalities would be beyond the scope ofthis thesis. Furthermore, the intention in this section is to show the functionalities of theprocessing services and to present a structure for a first implementation.

The Reprojection Service provides transformation operations for vector and raster data. Thespecification of the source and target reference system has thereby be provided as a methodparameter in the request message. The second processing service, the Classification Service,provides methods for data classification with the classifyData operation. In addition, theservice provides functionalities to cluster data (clusterData) and to calculate scaling parame-ters (scaleData). Methods for placing labels and symbols are implemented in the PlacementService. The last two services group functionalities with respect to spatial statistics andspatial analysis. The Spatial Statistics Service involves methods to calculate statistics, ana-lyze patterns, analyze distributions, and interpolate data. The implementation of the SpatialAnalysis Service supports methods for measuring, analyzing geometries, generalizing data,and calculating topology properties.

30

Modeling

Figure 4.3.: Interfaces of Analysis and Manipulation Services

31

Modeling

Cartographic Procedure Service

In comparison to the AMS, which provide basic and reusable methods, the CartographicProcedure Service (CPS) is designed for the implementation of specific mapping proceduresanalog to the data generation step in the generic workflow.

The interface of the CPS, which follows the same conception as the previous services, ispresented in Figure 4.4. To get service metadata and information about available methods agetCapabilities request has to be performed. Further information for a specific method canbe requested with the operation getMethodDescription. The third operation allows to executea method and uses the same specification for request and response messages as the AMS.

Figure 4.4.: Cartographic Procedure Service Interface

Thematic Map Service

The last service specification in the SOA, the Thematic Map Service (TMS), provides methodsfor the symbolization and map publishing step. The TMS is designed as an extended WMSwith additional functionalities for service chaining, symbol rendering, and legend creation.

In the SOA we can define a map by describing the map creation process, which will bediscussed in detail in the next section. For the understanding of the TMS, it is important toknow that the map description includes the mapping data for each map layer, the service chainto derive the data, and a symbology and legend description. To create the map representation,the TMS renders the vector data of each layer with the specified symbology. In addition tothe usage of the layer data in the map description, the TMS can execute the service chainspecified in the map description and derive the layer data on-the-fly.

The interface of the TMS is shown in Figure 4.5. The first three operations represent thestandard WMS implementation with the getMap operation for providing the rendered maplayers as raster images. To perform the map creation process on the user side, the mapdescription can be requested with the getMapDescription operation. The request messagethereby allows to specify distinct layers. In addition, four boolean flags can be used toinclude or exclude the layer data, the service chain information, the symbology, and thelegend description. Furthermore, the RefreshLayerData flag can be set, which will update thelayer data according to the service chain.

Beside the rendering of the map representation, the TMS provides functionalities to rendersymbols and create legends. To render a symbol of a map on the server the request messagehas to include the layer name and the id of the feature connected to the symbol. To render thesymbols for local map data, the user can include a map description in the request message.Furthermore, the request message can contain an alternative symbology and a specificationof the graphic format. The request message to create a legend is similar to the previous one

32

Modeling

and allows the specification of distinct layers, the map description, an alternative symbologydescription, and the graphic format.

Figure 4.5.: Thematic Map Service Interface

Symbology Description and Repository

Beside the derivation of the data basis for the map rendering, which can be performed with theprocessing services, the symbolization is an important element of the map creation process.In the generic workflow we mentioned that knowledge of visual variables are needed for thederivation of the symbology parameters, for the symbolization, and for the creation of thelegend. Furthermore, the symbology definition is not restricted to one layer. Instead, thesymbols of different layers have to be coordinated to provide a coherent map representation.

The symbology description therefore contains symbolizers for point, line, and area featuresas well as labels. Furthermore, the description includes metadata for variable symbolizerproperties to derive the symbology parameters. In addition, matching rules have to be pro-vided to apply the parameters in the rendering process and enable the separation of data andsymbology. The used symbology also affects the map legend. Therefore, the description hasto include a data independent legend description to provide an automated legend creation.

33

Modeling

It has to be noted that the specification of the symbology descriptions accounts for the basicfunctionalities needed for the map production in the SOA. A comprehensive discussion of thesymbology description would be beyond the scope of this thesis. Therefore, the symbologydescription for the further discussion is given by four symbolizer types (point, line, area,and labels), metadata and matching rules for the symbolizer, and one or multiple legenddescriptions.

To enable the integration of symbology descriptions in the service chain of map production,symbologies are managed with the Symbology Repository (SR). The interface of the SR ispresented in Figure 4.6.

The getCapabilities and getSymbologyDescription requests provide service metadata and in-formation for specified symbologies. These operations are implemented analog to the spec-ification of the processing services. With the getSymbology operation the description of aspecified symbology can be requested from the repository. In addition to the symbologyname, the request message allows to specify other symbologies (ParentSymbology) for inher-itance of style properties, to specify the included symbolizer types (SymbolizerType), and toselect an available legend description (LegendName).

Figure 4.6.: Symbology Repository Interface

The components of the SOA can be implemented in numerous ways depending on the neededfunctionalities and infrastructure. In the following, we will show the realization of the genericworkflow with the presented components to demonstrate the operation of the SOA. A furtherdiscussion of different implementations is given in section 4.3.3.

The schema in Figure 4.7 presents the components and interactions of the SOA implementedsimilar to the generic workflow. For the understanding of the further discussion, it is importantto known that in addition to the operations of the presented components, the system of themap creator provides basic functionalities for data management and visualization.

34

Modeling

Figure 4.7.: Service-oriented Architecture for Thematic Map Production on the Web

In the first step, the data preparation, the map creator selects and imports data from differ-ent sources with the DCS (1). The service thereby establishes a data connection to onlinedatabases and storages and converts the data to a format suitable for the mapping process. Inaddition to the usage of online data, a DCS request enables the conversion of local data. Theanalysis and manipulation of the attributive and spatial data is performed with the methodsof the AMS (2). The last step of the data preparation stage is data integration, which is imple-mented in the production system of the map creator. After combining attributive and spatialdata, the data generation step is used to derive specialized map data. The functionalities andprocedures are thereby implemented in the CPS (3a), which can utilize the AMS to perform

35

Modeling

basic processing tasks (3b). In the mapping stage the data is combined with the symbologyto render the map representation. The symbology description is thereby requested from theSR (4) and includes point, line, area, and label symbolizers as well as metadata and matchingrules for variable symbolizer properties. The methods of the AMS are used to adjust thevector data for the symbolization and derive the symbolizers properties from the vector data(2). Subsequently, the rendering of the map layers is performed with the TMS (5) or directlyin the system for map creation. For the last stage of the generic workflow, which includesmap composition and map publishing, the map creator specifies the layers and elements ofthe map in the map description. In addition, the map is published by uploading the map tothe TMS (5), which provides the request interface for the map user (6).

The presented implementation for the generic workflow covers the main components of theSOA. It should be noted that a variety of additional Web services can be utilized for the mapcreation process. Examples are georeference services, which can support the integration ofattributive and spatial data, or ontology services, which can provide additional metadata.

4.3.2. The Map Description

With the SOA it is possible to describe the layer creation process from data import to sym-bolization by specifying the order of performed service requests and the used symbology.Furthermore, a map description can be defined by specifying the service chain for layer cre-ation and the composition of layers and additional map elements. The specification of allelements of the map description would be beyond the scope of this thesis. Therefore, thefollowing discussion is limited to identifying the main elements, which have to be consideredfor the specification of the map description.

The identified elements of the map description, which are presented in Figure 4.8, are modeledin a hierarchical structure. On the highest level, five instances are specified. Each mapdescription includes one Map Information and one Map Composition element. In addition,the map description includes one or multiple Map View elements and the optional elementsLegend Composition and Map Interaction.

The first two elements, Map Information and Map Composition, are used to specify overallmap information and the setup of the map elements. For the map information examplesare the map title, the map projection, and map metadata. The Map Composition elementdefines the arrangement of the map views and additional map elements, such as the legendand imprint.

The Map View element defines the extent, the layers, and additional information for a mappedarea. The layer definition thereby includes five sub-elements for general layer information,layer properties, layer data, the layer service chain, and the layer symbology and legend de-scription. The map data for the map view is either included by providing the processed layerdata or by specifying the service chain for the derivation of the layer data. In the service chainspecification, the instances Data Conversion Service and Data Processing Service define therequest to the corresponding services. The import of preprocessed data can be establishedwith the element Source Data. In order to perform data integration and simple data manip-

36

Modeling

H Map Description

I Map Information (title, description, projection, metadata, . . . )

I Map Composition (map views, legend, impress, . . . )

I Map View*

I Map View Information (title, description, projection, metadata, . . . )

I Map View Extent

I Map View Layer

I Layer Information (title, description, projection, metadata, . . . )

I Layer Properties (layer type, visibility, transparency, ...)

I Layer Data**

I Layer Data Processing Chain**

I Source Data*/**

I Data Conversion Service*/**

I Data Integration*/**

I Data Processing Service*/**

I Data Manipulation*/**

I Additional Web Services*/**

I Layer Symbology and Legend Description

I Legend Composition*/**

I Map Interaction**

I Interactive Task*

Figure 4.8.: Elements of Map Description (* multiple instances possible, ** optional)

ulation tasks in the service chain the instances Data Integration and Data Manipulation aredefined. The last element consider the integration of additional services from the Web infras-tructure, such as georeference and ontology services. For the definition of the symbology andlegend description either the SR is specified or the symbology description is directly includedin the map description.

The map description can include multiple Legend Composition elements, which define a legendby specifying the composition of individual layer legends. The last element, Map Interaction,includes different interactive tasks to account for map interaction in the map description.

This section gave an overview of the elements which should by considered in the specificationof a map description. The specified elements can be seen as a basis for the further discussionand for further research.

37

Modeling

4.3.3. Different Implementations of the Conceptual Model

The components of the SOA can be implemented in different ways. The implementationfor a specific use case thereby depends on the system of production, the system of the mapusers, and the available infrastructure. In the following, we will discuss two configurations todemonstrate the capabilities of the SOA for different applications. In the first implementation,named as database-centered approach, we will discuss the characteristics of a highly central-ized system. The second implementation, named as map-description-centered approach, willdiscuss a decentralized implementation of the SOA components.

Figure 4.9.: Database-Centered Implementation of the SOA

The database-centered approach, presented in Figure 4.9, demonstrates a centralized imple-mentation of the functionalities of the SOA. The main component is the map productionsystem which can for example be realized as a Web server software similar to the applicationGeoServer3. The production system coordinates the components of the SOA and exposesthe functionalities for map production to the map creator. The main component of the pro-duction system is the database. The DCS and the processing services are thereby directlyimplemented at the database level. In addition to the database layer, the production systemincludes the SR and the TMS to render the map representation from the data in the database.The connection to data sources and services on the Web is directly performed by the mapproduction system. To describe the map creation process the production system utilizes the

3http://geoserver.org

38

Modeling

map description specification. The distribution of maps to the map users is enabled by theTMS interface.

The database-centered approach is designed to implement all functionalities in one environ-ment. This design provides a broad control over the components and high computationalperformance. The control over all components allow to minimize security risks by strictlycontrolling the interfaces to the map creator and the map user. The implementation of theprocessing functionalities is directly connected to the database. This enables a fast access tothe data and allows to optimize the processing functionalities to the actual data represen-tation. Another benefit of the centralized production system is that the system of the mapcreator can be reduced to functionalities for data visualization if the functionalities for dataintegration are implemented in the production system.

The disadvantage of a centralized production system is the limited flexibility. The implemen-tation of the DCS and the processing services directly at the database level make it difficult toaccess the functionalities outside the map production system and therefore difficult to reusethe functionalities in other applications.

Figure 4.10.: Map-Description-Centered Implementation of the SOA

In the map-description-centered approach, presented in Figure 4.10, the components of theSOA are implemented as decentralized Web services. Thereby, the map creator directlyinteracts with the service interfaces. To describe the map creation process the map creatorlocally generate the map description, which can be uploaded to a TMS or can be directly sentto the map user.

In the map-description-centered approach the map creator is not dependent from a productionsystem. Instead, the map creator can flexibly combine the components of the SOA, whichare implemented at different resources on the Web.

39

Modeling

The disadvantages of the decentralized approach are with respect to computational perfor-mance and service availability. In the map-description-centered approach the mapping datahas to be transferred to the individual service for each processing step. This increases thedata transfer between map creator and services and reduces computational performance as aconsequence of separating the data representation from the implementation of the processingfunctionalities. In addition, the map creation process is reliant on the availability of services,which are not managed by the map creator.

It has to be noted, that the presented approaches, which demonstrate idealized implementa-tions, does not exclude each other. The functionalities of a database-centered implementationcan be used in a map-description-centered approach by providing additional interfaces to themap creator for all implemented services. In addition, the loosely implemented services ofthe map-description-centered approach can be accessed by the map production system tointegrate new functionalities.

4.3.4. OGC Web Standards and Specifications for the Conceptual Model

In addition to the modeling presented in the previous sections, this section puts the con-ceptual model in the context of the current Web infrastructure. Therefore, we will discussthe model with respect to OGC Web standards and additional specifications. The discussionintends to demonstrate possibilities for the implementation of the components and to revealshortcomings of current standards.

The first aspect which has to be considered is the data format to model vector features forthe cartographic purpose. Thereby, the data format has to provide interoperability betweenthe components of the SOA and with a variety of services on the Web and local applications.For data representation the main OGC standard is the Geography Markup Language (GML),which is an extensive XML grammar to model geographic objects. In addition to the OGCspecification, GML is specified by the International Organization for Standardization (ISO)since the release of version 3.1.1. Furthermore, GML is supported by the majority of geospatialtools and applications as well as the implementations of OGC Web services. For the standardvector data format in the conceptual model, we therefore propose GML, with the restrictionto the subset of the Simple Feature Profile. The benefits of this profile are the restrictionof geographical objects to simple vector data representations and the prevention of featurenesting, which restricts the data representation to two-dimensional data sets suitable for thelayer-based approach in the SOA.

The DCS can be compared to the WFS implementation for vector data and the WMS im-plementation for raster data. The main difference is thereby that the requested data is notstored on the Web server. Instead, the DCS requests data from different resources on theWeb and converts the data according to the conversion parameters. The DCS can thereforeenable the import of a variety of different resources and data formats. The main benefit ofthe DCS is the uniform interface for data import which is required to define the data importin the map description file.

40

Modeling

The implementation of the AMS and the CPS can be realized with a WPS, which providesa generic specification for the implementation of processing functionalities as a service. Thedifference of the processing services in the SOA and the WPS specification, is the restrictionof request and response messages to a uniform definition for all services, which was includedto enhance interoperability.

The design of the TMS represents an extended WMS, similar to the Cartographic Web Service(CartoWS) developed in Iosifescu-Enescu (2011). The difference to the CartoWS is therebythe integration of the layer information and symbology description into the provision of themap description.

To symbolize geographic features OGC specified the XML-based description language Sym-bology Encoding (SE). The standard specification of SE is limited to the description of car-tographic representations. Therefore, the work of Iosifescu-Enescu (2011) and the study ofDietze and Zipf (2007) proposes an enhancement of SE to enable symbolization for topo-graphic and thematic maps. Another approach, which can be used to extend SE to supportcomplex thematic point symbols, is developed in Schnabel (2007) with the description lan-guage DiaML. Thereby the definition of symbolizers is performed with a XML-based syntax,which is based on a construction model for symbol generation.

For the implementation of the symbology description, symbolizers for point, line, and areafeatures as well as labels are required. An extended SE specification which allows to specifymatching rules to combine data attributes with SE Rules could provide the realization of dataindependent symbolizers. In addition to the symbolizers, the symbology description includesa specification of map legends. The legend description has thereby be correspondent to thesymbolizers of the symbology description. At the moment there is no specification availablefor the description of legend representations.

The last element of the conceptual model is the map description, which should be imple-mented with an XML-based syntax to simplify the integration of vector data in the standardformat GML and the symbology description in the SE specification. With respect to the def-inition of the service chain the established standards BPEL and BPML are important. Bothspecifications define a XML-based syntax for orchestration of Web services described withWSDL and accessed with SOAP messages. The benefits of using BPEL or BPML for the ser-vice chain description are the availability of orchestration engines to execute the service chainand the directly support of additional services described with WSDL. The disadvantages arethe complexity of both specifications and the requirement of SOAP for the service requests.

A detailed discussion on service chain description and the service interface implementationcan not be done at this point. The selection of the technology depends on the requirementsto the specific implementation. For complex systems, with requirements for service contractsand security, SOAP and established orchestration languages provide an extensive toolset. Incontrast, REST provides a simple and lightweight approach to implement service interfaces.With respect to SOAP and REST it should also be noted that RESTful services can beprovided with a interface described in WSDL, as the studies of Sancho-Jimenez et al. (2008)and Fleuren and Muller (2008) showed for OGC Web services such as WCS, WMS and WFS.

41

5. Implementation

In addition to the modeling, this chapter demonstrates a proof-of-concept by implementingan application which is based on the architecture of the conceptual model. The first sectionin this chapter provides an overview of the implemented application. In the second section,the capabilities of the system are demonstrated by explaining the creation process of threedifferent map representations.

5.1. Application Design

The main purpose of the client-side application is to demonstrate the operation of the concep-tual model. Consequently it has to be possible to import, visualize, and process attributiveand spatial data. In addition, the application should provide capabilities for service chainingand map rendering. In the following, we will discuss the implementation of the functionalitiesof the conceptual model on server- and client-side. The software packages and third-partylibraries used to implement the application are listed in section A.1.

5.1.1. Client-side Implementation

The client-side application is realized as a browser-based application which uses server-sideservices for data processing. The benefits of using browser-based technologies for the imple-mentation of the map production system are the direct integration into the Web infrastructure,which simplifies the implementation of Web service requests, and the platform independentdevelopment, which allow to run the application on a variety of devices.

With respect to the development of rich Internet applications (RIA) we can distinguish be-tween plugin-based technologies and applications based on HTML and JavaScript. The mostpopular plugin-based technologies are thereby Adobe Flex and Microsoft Silverlight, whichprovide a controlled development environment for the creation of dynamic applications. Thedisadvantage is the need for additional software on the client side to run the application. Incontrast to plugin-based technologies, HTML and JavaScript are natively supported by themajority of browsers. With the implementation of HTML5 functionalities and the efficientexecution of JavaScript code in modern Web browsers it is possible to directly provide RIA,without the need of a plugin.

42

Implementation

The application in this thesis is developed with HTML and JavaScript to provide access fora variety of users. For the implementation the JavaScript framework AngularJS1 is used,which provides a structure and functionalities for RIA. The benefits are thereby a modularimplementation and the possibilities for a test-driven development. In the following we willdiscuss the developed application by means of the implemented AngularJS modules, whichare presented in Figure 5.1.

Figure 5.1.: AngularJS Modules for the Client-side Application

The main modules of the application are the Editor and the Viewer module, which containthe business logic for the editor and the viewer. The editor is thereby used to perform the

1http://angularjs.org/

43

Implementation

map creation process and to save the map description. The viewer is designed to display amap representation which is defined by a map description.

To perform the tasks for map creation, the Editor module includes one module for datamanagement (DataStore), three modules for the user-interface, and five modules for dataimport and processing.

The user-interface for the editor is divided into three views (Figure 5.2), which are imple-mented in the modules Map, Grid, and Tools. The map view is used to visualize the maprepresentation. Therefore the Map module implements the mapping library OpenLayers 32,which provides an extensive toolset to process and render spatial data in the browser. Fordisplaying attributive data, the Grid module implements a data table with the AngularJS ex-tension ng-grid3. To perform the tasks of the map creation process, the Tools module providesfour subviews, which are implemented in the respective submodules. The first subview givesan overview of the data layers and provides functionalities for map publishing. In the inputview, different data sources can be selected and imported into the application. To processthe data, the processing view provides an user-interface to send requests to the processingservices. The symbology view provides functionalities to select a map symbology for a spatialdata layer.

Figure 5.2.: Editor in the Client-side Application

2http://ol3js.org/3http://angular-ui.github.io/ng-grid/

44

Implementation

In addition to the modules for the user-interface, five modules are implemented to get servicedescriptions, to import data, to perform service request, to manage and create map symbology,and to process the service chain.

The DescriptionService module is used to provide service information. The descriptionsare thereby directly provided by the module to simplify the implementation. In a furtherversion of the application, this module can be replaced by directly requesting the servicedescriptions from the server with the operations getCapabilites, getConversionDescription,getMethodDescription, and getSymbologyDescription as specified in section 4.3.1.

The module InputHandler implements functionalities for data import directly in the appli-cation and can be compared to the Data Conversion Service. In the current version of theapplication, it is possible to import data sets that are stored on the server. With respect to thedata format the implementation enables the import of spatial data in GML and attributivedata in JSON-stat or CSV. The different data sets are thereby defined in the DescriptionSer-vice module and are imported over the user-interface of the Input module.

To process data on the server, the WebService module is used. A service request to an Analy-sis and Manipulation Service or the Cartographic Procedure Service can thereby be performedwith the user-interface of the Processing module. The definition of available processing ser-vices is done in the DescriptionService module.

The Symbolizer module provides functionalities to manage and create the map symbology.Therefore the module imports a symbology description specified in the DescriptionServicemodule and provides the description of the point, line, area, and label symbolizers. In addi-tion, the Symbolizer module implements functionalities to match attributive values with thesymbolizer description and render the graphical representation.

To demonstrate the capabilities for automated mapping, functionalities to define and executea service chain were implemented. The individual elements of the service chain are specifiedwith five JavaScript objects, presented in section A.3, which enable to define data import, dataintegration, basic data manipulation, processing service requests, and data symbolization.

In the current version of the application the service chain definition is used to save andload a mapping project and to specify the map creation process in the map description. Tosave and open a workflow, functionalities are provided in the overview user-interface. Themap description includes the service chain elements and basic map informations and is alsospecified with a JavaScript object. A definition of the object is given in section A.3.

For the map description the service chain elements are directly transformed into XML. Thefunctionalities to derive a service chain for a created map representation as well as the con-version between JavaScript objects and XML are implemented in the ServiceChain module.

To display the map representation defined with a map description, the application includesthe viewer. The Viewer module thereby uses the functionalities of the ServiceChain moduleto convert the service chain elements from XML to JavaScript objects. The individual tasksof the service chain are executed with the functionalities of the Editor module. To displaythe map representation the Map module is included.

45

Implementation

5.1.2. Server-side Implementation

The server-side implementation includes server software to provide the application data andto manage service requests. In addition, the server-side system has to provide the processingfunctionalities for the map creation process.

For the sever software we use the platform Node.js4, which utilizes JavaScript as scriptinglanguage and therefore enables a fast development in combination with browser applicationsbased on HTML and JavaScript. Another benefit of Node.js is the non blocking input/outputmodel, which enables a parallel processing of requests.

To provide the functionalities of the processing services a REST interface was implementedon the server for the operations required to create the example maps (section A.2). The layerdata of the request is thereby processed in a PostgreSQL5 database with PostGIS6 extensionaccording to the request parameters. For the import of GML data into the database as wellas the export the functionalities of the Geospatial Data Abstraction Library (GDAL)7 areused. The benefit of the processing with PostgreSQL is the availability of basic functionalitiesfor spatial data processing which can be utilized to implement mapping procedures.

5.2. Map Creation

In this section, we will demonstrate the map creation process of three map representations anddiscuss the implemented processing functionalities as well as the symbology description. Tovisualize the map creation process the sequence diagrams according to the operations in theconceptual model are presented. It must thereby be noted that the Data Conversion Serviceand the Symbology Repository are directly implemented in the browser-based application.Furthermore, the legends for all example maps were created manually, by the reason of thelimited development time.

The source data for all example maps come from the Swiss Federal Statistical Office. At-tributive data was thereby taken from the STAT-TAB8 database. Spatial data for the Swisscantons and districts come from the GEOSTAT9 service.

5.2.1. Choropleth Maps with Standardized Data

The first map representation is the choropleth map with standardized data, which can becreated with the sequence shown in Figure 5.3. For the example map, population data andspatial data for the districts of Switzerland are imported and integrated.

4http://nodejs.org/5http://www.postgresql.org/6http://postgis.net/7http://www.gdal.org/8http://www.pxweb.bfs.admin.ch/dialog/statfile.asp?lang=19http://www.bfs.admin.ch/bfs/portal/de/index/dienstleistungen/geostat.html

46

Implementation

Figure 5.3.: Sequence Diagram Choropleth Map

Figure 5.4.: Example Choropleth Map

To derive standardized values for the population attribute, three processing steps have to beperformed. In the first, the area of each district is calculated with the measure operation ofthe Spatial Analysis Service, which is based on default PostGIS functions. The next step isperformed directly in the browser-based application by dividing the population values by thesize of each district. In the last step the data set is classified with the classifyData operationof the Classification Service. The implementation of the classification method is thereby donewith a SQL function.

47

Implementation

The symbology description for the choropleth map is specified as a JSON object to enable adirect integration in the application (see section A.4). The object defines overall symbolizerproperties, such as the line color for the areas, and variable symbolizer properties which arematched to the areas according to the derived classes. After assigning the symbolizers themap representation can be rendered as shown in Figure 5.4.

5.2.2. Proportional Symbol Maps and Diagrams

For the creation of a proportional symbol map, attributive data, containing figures for es-tablished enterprises, and spatial data for Swiss cantons are imported and integrated. In thefollowing processing step, the centroids of the areas in the spatial data set are calculatedto derive point representations for the proportional symbol map. The processing is therebyperformed with the analyzeGeometry operation of the Spatial Analysis Service. In the laststep the symbology description is imported and matched with the attributive values. Thesequence diagram for map creation is shown in Figure 5.5.

The symbology description for the diagrams of the map representation is defined in DiaML,which was developed in Schnabel (2007) and provides a XML-based syntax to define diagramrepresentations independent from the data (see section A.4). For the rendering of the map,diagrams are created in the Symbolizer module by matching the attributive data values withthe diagram description. In addition to the diagram symbols derived in the map creationprocess, the example map, shown in Figure 5.6, includes a base layer from Mapbox 10.

Figure 5.5.: Sequence Diagram Proportional Symbol Map

10https://www.mapbox.com/

48

Implementation

Figure 5.6.: Example Proportional Symbol Map

5.2.3. The Cartographic Procedure Service and Dot Maps

The last mapping process illustrates the creation of dot maps and includes the CartographicProcedure Service. The sequence diagram is therefore shown in Figure 5.7. To get the databasis for the calculation of the dot placement, population and area data for the districts ofSwitzerland are imported and integrated.

The calculation of the dot placement, implemented with the Cartographic Procedure Service,is executed with the executeMethod operation. The request message therefore includes thearea data with the attribute values, the name of the attribute which defines the dot distri-bution, and two parameters to define the unit value of one dot and the minimum distancebetween dots. The response of the procedure is a data set with point features defining thedot positions. The implementation of the processing in PostgreSQL is done with a SQL func-tion, which uses a random function to generate dots and a measuring function to guaranteea minimum dot distance.

After the calculation of the dot distribution, the map representation is rendered by usinga simple point symbolizer for the point features. In addition to the dot representation, aspatial data set containing the borders of the Swiss cantons is imported and symbolized witha polygon symbolizer. The symbology description, including both symbolizers, is definedas JSON object analog to the definition for the choropleth map in the first example. Theexample map containing both layers is shown in Figure 5.8.

49

Implementation

Figure 5.7.: Sequence Diagram Dot Map

Figure 5.8.: Example Dot Map

50

6. Evaluation and Discussion

The conceptual model presented in chapter 4 provides a decentralized approach for thematicmap production on the Web. In this chapter we will examine the capabilities of the derivedmodel with respect to the creation of standard thematic map representations and to theapplication of important concepts for thematic Web cartography.

To discuss the capabilities of the conceptual model for thematic map production, in the firstsection we will review the suitability of the generic workflow for the production process of thestandard thematic map representations. In the second section, we will evaluate the conceptualmodel with respect to the implementation of the concepts specified in the requirements. Inthe last section of this chapter, we will review the research questions and objectives to deducethe findings of this work.

6.1. Standard Thematic Map Representations and the GenericWorkflow

The generic workflow, presented in section 4.2.2, is the basis for the conceptual model andis developed with respect to the production of standard thematic map representations. Forthe modeling, the scope of thematic cartography was restricted to two-dimensional map rep-resentations based on vector data. In addition to the restrictions, it should be noted that theworkflow is designed for automated map production to support an efficient implementationof service chaining in the conceptual model.

Below we will evaluate the suitability of the standard thematic map representations withrespect to the generic workflow. A summary of the evaluation is presented in Table 6.1.

Table 6.1.: Evaluation of Standard Mapping Techniques

Mapping Technique Eval.

Choropleth Map ++Dasymetric Map +Isarithmic Map +/-Cartogramm +/-Proportional Symbol Map +Dot Map +Flow Map -

51

Evaluation and Discussion

The choropleth mapping technique does not include a data generation step in the genericworkflow. The uniform data set can directly be mapped by classifying the data and selectinga style (color scheme) for the areas. The steps of the map production process can thereby beimplemented with basic processing functionalities and easily be automated. Therefore, thegeneric workflow is highly applicable to create choropleth maps.

For the dasymetric map, source areas (areas of enumeration unit) and ancillary areas needto be combined in the data generation step. The remaining mapping process is similar tothe choropleth mapping technique. The implementation of procedures for data generationrequires additional effort, for which reason the evaluation is lower compared to choroplethmapping.

For the isarithmic mapping technique an interpolation has to be performed. The results ofthis operation can be areas, isolines, raster images or DEMs, which have to be symbolizedin the mapping stage. In the generic workflow the interpolation requires specialized imple-mentations for data generation. Furthermore, automation is more difficult if the number andcomplexity of parameters increases. Therefore, the realization of isarithmic maps with thegeneric workflow depends on the complexity of the map representation. Isarithmic maps witha simple interpolation step and a single feature type for symbolization get a positive evalua-tion, whereby maps with multiple processing steps and different features to symbolize get anegative evaluation.

Another similar map representation to choropleth maps is the cartogram. The differencethereby is the transformation of the areas before the mapping, which is based on attributivevalues. For cartogram mapping, transformation algorithms has to be implemented in the datageneration step. The implementation of an automatized workflow is thereby dependent on thecomplexity of the algorithms and the need for manual editing. Therefore, the evaluation forthe creation of cartograms is, analog to isarithmic maps, dependent on the map representation.

The parameters to create the symbols for proportional symbol maps can be derived directlyfrom the data set by classifying, clustering and scaling the data. For the symbolization ofthe point features the symbology description has to provide complex point symbolizers. Inaddition, complex maps, with a high number of map features, require a manual arrangementof symbols to solve placement conflicts. The proportional symbol mapping technique getsa positive evaluation similar to the creation of dasymetric maps. The highest evaluation isprevented by the demands for complex point symbolizers and symbol placement in complexmaps.

For a dot map the distribution of dots is computed by means of source areas, ancillary areasor a DEM. To determine the position of the dots, point features are derived in the datageneration step. In the mapping stage simple point symbolizers are used for symbolization.With the implementation of algorithms to derive point features the map creation process fordot maps is applicable for automation. Therefore, the dot map technique gets a positiveevaluation.

The processing of data in the generic workflow is restricted to vector data. The creation ofdistributive flow maps and network flow maps can thereby be based on line features combinedwith line symbolizers. In addition to the definition of complex line symbolizers, elaborate map

52

Evaluation and Discussion

representations require manual editing of line features. Radial flow maps are mapped withcomplex point symbolizers including direction and magnitude of flows. Continuous flow mapsinclude the mapping of a vector field and often require data interpolation functionalities. Thecreation of the different types of flow maps show a great variation of functionalities and theneed for manual editing. Therefore, the flow mapping technique is difficult to implement withthe generic workflow, which leads to a negative evaluation.

6.2. Implementation of the Concepts for Thematic WebCartography

The evaluation of the conceptual model in this section will discuss the implementation ofthe concepts for thematic Web cartography. The evaluation is based on the requirementswhich were the basis of the modeling process. A summary of the evaluated requirements ispresented in Table 6.2, whereby the required functionalities are assessed with respect to thesupport by the conceptual model. Directly supported functionalities are thereby implementedin the architecture of the conceptual model. Functionalities marked as indirectly supportedare considered in the service-oriented architecture (SOA) but require the implementationof additional concepts and components. Functionalities which are not considered by theconceptual model or can not be implemented are marked as not supported.

Table 6.2.: Evaluation of Requirements for Thematic Web Cartography

Functionalitydirectlysupported

indirectlysupported

notsupported

GIS functionalities • •DTM functionalities • • •Standard thematic map representations • •

Interaction with the data •Interaction with the data representation •Interaction with the temporal dimension •Contextualizing interaction •

Collaborative map production •Sharing of intermediate and end products •Sharing of functionalities •

Linking of documents and maps •Linking of data •Linking of services •

Different publishing concepts •Generation of metadata •

53

Evaluation and Discussion

To perform a comprehensive evaluation of functionalities that are used in GIS and DTMsystems would be beyond the scope of this thesis. Therefore, we will limit the discussion toprocessing functionalities, user-interface functionalities, and functionalities for data visualiza-tion.

The support of GIS functionalities with respect to processing is directly implemented inthe SOA. The AMS allow to perform basic processing and can be extended to provide themajority of GIS functionalities required for thematic mapping. With respect to user input,simple processing tasks can be specified with a plain service request. For complex processingthe user-interface has to provide additional functionalities for tasks such as feature selectionand parameter definition. In addition, the map production system has to implement a modulefor data visualization to enable efficient data analysis and manipulation.

DTM systems primarily use vector graphic formats to create map symbologies. The approachin this thesis creates map representations by matching predefined symbolizers with vector fea-tures. In addition, the model strictly separates the vector data from the symbology, whichis contrary to cartographic data models used in DTM systems. The support of DTM func-tionalities is therefore dependent on the complexity of the map symbology. Highly complexand individual map symbologies are not supported by the developed model. Nevertheless, themajority of symbolizers for thematic maps can be defined in the symbology description andare therefore directly supported. In addition components for visual symbology description arenot directly implemented in the SOA and have to be provided in a additional user-interface.

The map creation process for the standard thematic map representations was already dis-cussed in the previous section. The discussion showed that the main criteria for the mapcreation process, to be suitable for the developed system, are the restriction to vector dataand the suitability for automation.

The functionalities for providing interactive tasks were introduced in the generic workflowand can be directly applied to the conceptual model. Tasks for interaction with the datacan be directly implemented by accessing the map description and changing import andprocessing parameters in the service chain. Furthermore, the separation of vector data andsymbology description reduce the effort to exchange the map symbology and therefore toimplement interactive tasks with the data representation. Contextualizing interactions andinteraction with the temporal dimension are marked as indirectly supported, by reason of therequirements for a specialized user-interface, which provide functionalities such as arrangemultiple views or navigation.

With respect to collaboration the sharing of intermediate products, end products and func-tionalities is directly supported by the conceptual model. The provision of end products canthereby be performed with the TMS or directly with the map description file. The mapdescription can also be used to share single layers as well as the workflow for map creation.An additional intermediate product of the production process is the map symbology, wherebyan exchange can be achieved over a SR or a symbology description file. The sharing of func-tionalities is directly implemented in the model with the CPS, which enables the provision ofspecialized processing techniques with a predefined Web service interface.

54

Evaluation and Discussion

Collaborative map creation is enabled by the conceptual model through the layer-based ap-proach and the separation of feature data and symbology, which allow to separate the tasksfor map creation. In addition to the functionalities of the model, collaborative mapping re-quires a platform which makes it possible to communicate and manage the mapping process.Therefore, the functionalities for collaborative mapping are marked as indirectly supported.

The linking of documents and data is inherent to the Web infrastructure. With the conceptualmodel linking can be implemented by directly connecting the source data with the mappeddata. With respect to the semantic Web, RDF triples can be generated automatically froma vector data set with a DCS or a similar service. It has to be noted that an extensivereview of concepts for linking with respect to thematic cartography could not be done in thisthesis. Therefore, the linking of documents and maps is marked as indirectly supported forthe reason that concepts for the implementation of map and document links are not describedin the conceptual model. The linking of services is the basis of the SOA and is defined in theservice chain description. The utilization of established standards for service orchestrationcan thereby enable the integration of a variety of Web services in the map creation process.

The last two requirements involve functionalities to enhance searchability and findability. Thepublishing of additional formats to optimize the map for search engines is not directly imple-mented in the model. Therefore, additional conversion functionalities have to be implementedsimilar to the generation of RDF triples mentioned before. Furthermore, the creation of meta-data is not directly considered by the conceptual model, but is enhanced by the possibilitiesfor using additional services in the creation process.

6.3. Discussion of Research Findings

This section examines the findings of this thesis. Therefore, we will review the researchquestions and objectives formulated in the introduction with respect to the derived workflowand conceptual model as well as the implemented application.

The first research question focuses on the definition of a generic workflow for thematic mapproduction for the Web:

Q1: Can the elements and the sequences of thematic map production for the Webbe modeled in one workflow?

The modeling of the generic workflow (Figure 4.1) was based on the creation process ofthematic map representations and restricted to two-dimensional map representations. Inaddition, the data processing was limited to vector data and strictly separated from the mapsymbology to enable an automated map creation for the Web.

The discussion of thematic map representations shows that the suitability of the genericworkflow is dependent on the complexity of the representation, whereby mapping techniqueswhich rely on extensive manual editing are not applicable. Furthermore, suitable mappingtechniques have to be based on vector features for the creation of the map representation.

55

Evaluation and Discussion

Therefore, it can be concluded that it was not possible to derive a workflow which is applicableto the variety of mapping techniques for thematic cartography.

Nevertheless, the evaluation also showed that the majority of thematic mapping techniquesbased on vector data can be modeled with the presented workflow. Therefore, the derivedworkflow can be utilized as a basis for the implementation of map production functionalitiesin the Web infrastructure.

The second research question is directed to the modeling of the generic workflow with aservice-oriented architecture:

Q2: Can the thematic map production workflow be modeled with a service-orientedarchitecture?

For the development of a service-oriented architecture (SOA) for thematic map productionon the Web, the functionalities of the generic workflow were modeled with three differenttypes of Web services (Figure 4.7): The Data Conversion Service implements functionalitiesfor the import of data from different sources, the Analysis and Manipulation Services andthe Cartographic Procedure Service implement processing functionalities, and the ThematicMap Service provides publishing functionalities. In addition to the services, a SymbologyRepository was introduced to include the map symbology directly in the SOA.

The conceptual model presented in section 4.3 shows that the required functionalities for mapproduction in the generic workflow can be modeled with a SOA. In addition, the examinationof different implementations of the conceptual model in section 4.3.3 shows that the mapcreation process can be realized with decentralized services. The operability of the SOA formap production is demonstrated in the proof-of-concept. Furthermore, the proof-of-conceptdemonstrates that the concept of service chaining is applicable to the conceptual model andcan provide an automated map production process. Therefore, we reason that the genericworkflow for thematic mapping is suitable for the implementation with a SOA.

With the third research question we discuss the realization of the conceptual model:

Q3: Are the existing standards and technologies sufficient for the implementationof the service-oriented architecture?

Existing standards for the implementation of the conceptual model were discussed in sec-tion 4.3.4. Thereby, it was shown that a data independent specification for the symbologydescription as well as for the legend description is needed to fully implement the SOA. Fur-thermore, a specification of the service chain and map description is required to exchange themap creation process.

With respect to technologies for the implementation of the map production system and thecomponents of the SOA, the proof-of-concept demonstrated the map production for threedifferent map representations. The application is thereby limited to selected functionalitiesand can not provide a comprehensive demonstration of the possibilities of existing Web tech-nologies.

56

Evaluation and Discussion

Therefore, the technology question remains open at this point. In addition, further standardsand specifications are required to describe the map representation and the map symbology inparticular.

The objectives of this thesis were to develop a SOA for map creation and to deliver a proof-of-concept by implementing selected functionalities.

O1: To develop a conceptual service-oriented architecture for thematic map pro-duction on the Web which considers important concepts for Web cartography.

O2: To deliver a proof-of-concept by implementing selected functionalities of theservice-oriented architecture.

The discussion of the research questions shows that it was possible to develop a conceptualmodel which is based on a service-oriented architecture. The model thereby includes impor-tant concepts for thematic Web cartography as it was examined in section 6.2. In addition tothe modeling, the proof-of-concept presented in chapter 5 could demonstrate the capabilitiesof the SOA and shows the possibilities for automated map production.

The derivation of the conceptual model focuses on the functionalities for the production oftwo-dimensional map representations based on vector data and provides a elementary conceptfor thematic map production on the Web. Extensions of the model should therefore includefunctionalities for the processing of raster data and the support of three-dimensional maprepresentations. With respect to the implementation, an extension of the functionalities ofthe proof-of-concept could demonstrate the capabilities of map creation on the Web on alarger scale.

57

7. Conclusions and Outlook

The last chapter of this thesis concludes the main findings of the work and draws out theirimplications. In addition, we will give an outlook to further developments and possibilitiesfor research.

7.1. Conclusions

The thesis is focused on the development and examination of a concept for thematic mapproduction on the Web. The aim was thereby to develop a conceptual model, which involvesthe main components for thematic map creation and is based on a service-oriented archi-tecture suitable for the Web infrastructure. For the derivation of the model, the first stepinvolved a review of important concepts for thematic Web cartography and the productionof standard thematic map representations. Based on these findings a map creation workflowwas derived, which provided the basis for the conception of the service-oriented architecture.In the conceptual model, the required functionalities for map creation were identified withspecific Web services and extended with additional components of the map creation process.

The results of the evaluation show that the conceptual model is suitable for the creation of themajority of thematic map representations and is capable to support important concepts forWeb cartography. The main limitations of map creation are the restriction to two-dimensionalmap representations and to a creation process based on vector features. With respect to theoperability of the conceptual model, the implementation of the creation process for threeexample maps tests the capabilities of the model. Although the implementation is limited toselected functionalities, the application shows that the map creation process can be performedwith decentralized services. Furthermore, it could be demonstrated that automated mapproduction is possible. The main obstacle for the implementation is the lack of specifications.Therefore, a data independent definition of the map symbology and legend is required. Inaddition, the study shows that a description of the map representation, including the definitionof the steps for map creation, is needed to implement automated mapping and to exchangeproduction workflows.

For the field of Web cartography this thesis provides a concept for the production of thematicmaps on the Web. The work, which includes the map creation process from data import tomap publishing, can be seen as a continuation of service-oriented approaches, and therebyextends current map provision approaches by an extensive set of processing functionalities formap creation. Furthermore, this thesis provides a basis for further research on decentralizedand automated map production on the Web by outlining the functionalities and componentsrequired for thematic Web cartography.

58

Conclusions and Outlook

The findings demonstrate the capabilities of a server-oriented architecture when it comesto implementing Web based map production systems. The main benefits are the directintegration in the Web infrastructure and the capabilities with respect to the description ofthe map creation process. Thereby allowing a decentralized implementation of the componentsand enabling efficient integration of various Web based sources and services. Furthermore, adescription of the creation process enables the exchange of production workflows and offerspossibilities for automated mapping.

7.2. Outlook

With further developments in the Web infrastructure more and more services will becomeavailable on the Web supported by enhanced technologies and increased coverage and band-width. For the field of thematic Web cartography these developments bring new opportunitiesfor research and development of cartographic mapping systems.

Further research with respect to this work has to address a data independent symbologyand legend description. In addition, the derivation of an extensive map description includingconcepts for service chaining is necessary to enable automated map creation. With respect tothe extension of the approach, processing functionalities for raster data and for the creationof three-dimensional map representations has to be evaluated.

For the implementation of map production systems on the Web this study provides an elemen-tary concept. A continuation of this approach can enable a comprehensive implementationof map production with decentralized services. In addition, the adoption of the concept ona larger scale enhances the interoperability between different implementations and can pro-vide new possibilities for automated map creation. Furthermore, enhanced interoperabilitycan increase networking between cartographers for the creation of maps and the exchange offunctionalities.

59

Bibliography

Ankolekar, A., M. Krotzsch, T. Tran, and D. Vrandecic. (2008): The two cultures: Mashingup Web 2.0 and the Semantic Web. Web Semantics: Science, Services and Agents onthe World Wide Web, 6 (1), 70–75.

Asche, H. and R. Engemaier. (2012): From Concept to Implementation: Web-Based Carto-graphic Visualisation with CartoService. In: Murgante, B., O. Gervasi, S. Misra, N.Nedjah, A. M. A. C. Rocha, D. Taniar, and B. O. Apduhan (Ed.) ComputationalScience and Its Applications – ICCSA 2012. Berlin Heidelberg. Springer. 414–424.

Asche, H., S. Stankute, M. Mueller, and F. Pietruska. (2013): Towards Developing an Inte-grated Quality Map Production Environment in Commercial Cartography. In: Mur-gante, B., S. Misra, M. Carlini, C. M. Torre, H.-Q. Nguyen, D. Taniar, B. O. Ap-duhan, and O. Gervasi (Ed.) Computational Science and Its Applications – ICCSA2013. Berlin Heidelberg. Springer. 221–237.

Berners-Lee, T., J. Hendler, and O. Lassila. (2001): The Semantic Web. Scientific American,284 (5), 34–43.

Bizer, C., T. Heath, and T. Berners-Lee. (2009): Linked Data - The Story So Far. InternationalJournal on Semantic Web and Information Systems, 5 (3), 1–22.

Broder, A. (2002): A taxonomy of web search. ACM SIGIR Forum, 36 (2), 3–10.

Bar, H. R. and R. Sieber. (1999): Towards High Standard Interactive Atlases The ”GIS andMultimedia Cartography” Approach. Proceedings of the 19th International Carto-graphic Conference ICC 1999. Ottawa.

Ceri, S., A. Bozzon, M. Brambilla, E. D. Valle, P. Fraternali, and S. Quarteroni. (2013):Publishing Data on the Web. In: Carey, M. and S. Ceri (Ed.) Web InformationRetrieval. Berlin Heidelberg. Springer. 137–159.

Crampton, J. W. (2009): Cartography: maps 2.0. Progress in Human Geography, 33 (1), 91–100.

Crampton, J. W. (2002): Interactivity Types in Geographic Visualization. Cartography andGeographic Information Science, 29 (2), 85–98.

Csaba, V. (2013): Crowdsourced Semantics with Semantic Tagging. Proceedings of the 1stInternational Workshop on Crowdsourcing the Semantic Web. Sydney.

60

Bibliography

Dent, B. D., J. Torguson, and T. W Hodler. (2008): Cartography Thematic Map Design. NewYork: McGraw-Hill Higher Education, P. 368.

Dietze, L and A Zipf. (2007): Extending OGC Styled Layer Descriptor (SLD) for ThematicCartography. Proceedings of the 4th International Symposium on LBS & TeleCar-tography. Hong Kong.

Engemaier, R. and H. Asche. (2011): CartoService: A Web Service Framework for QualityOn-Demand Geovisualisation. In: Murgante, B., O. Gervasi, A. Iglesias, D. Taniar,and B. O. Apduhan (Ed.) Computational Science and Its Applications - ICCSA 2011.Berlin Heidelberg. Springer. 329–341.

Farazi, F., V. Maltese, B. Dutta, A. Ivanyukovich, and V. Rizzi. (2013): A semantic geo-catalogue for a local administration. Artificial Intelligence Review, 40 (2), 193–212.

Fleuren, T. and P. Muller. (2008): BPEL Workflows Combining Standard OGC Web Servicesand Grid-enabled OGC Web Services. Proceedings of the 34th Euromicro ConferenceSoftware Engineering and Advanced Applications. Parma.

Hake, G., D. Grunreich, and L. Meng. (2002): Kartographie: Visualisierung raum-zeitlicherInformationen. Berlin: Walter de Gruyter & Co, P. 624.

Haklay, M., A. Singleton, and C. Parker. (2008): Web Mapping 2.0: The Neogeography of theGeoWeb. Geography Compass, 2 (6), 2011–2039.

Hardy, P. and T. Kressmann. (2005): Cartography, Database and GIS: Not Enemies, butAllies! A Coruna.

Hudson-Smith, A., A. Crooks, M. Gibin, R. Milton, and M. Batty. (2009): NeoGeographyand Web 2.0: concepts, tools and applications. Journal of Location Based Services, 3(2), 118–145.

Hurni, L. and E. Hutzler. (2008): Implementation kartographischer Funktionen als AdobeIllustrator™-Plugins. KN Kartographische Nachrichten, 58 (5), 248–255.

ITU. (2013): ITU Internet Statistics. http://www.itu.int/en/ITU-D/Statistics/Pages/stat/default.aspx (visited on 12/12/2013).

Iosifescu-Enescu, I. (2011): Cartographic Web Services. Dissertation, ETH Zurich, Zurich,Switzerland.

Kiehle, C., K. Greve, and C. Heier. (2006): Standardized Geoprocessing- Taking Spatial DataInfrastructures one Step Further. Proceedings of the 9th AGILE Conference on Ge-ographic Information Science. Visegrad.

Kohlborn, T. and M. L. Rosa. (2012): SOA Approaches. In: Barros, A. and D. Oberle (Ed.)Handbook of Service Description. New York. Springer. 111–133.

61

Bibliography

Kramers, E. R. (2008): Interaction with Maps on the Internet – A User Centred DesignApproach for The Atlas of Canada. The Cartographic Journal, 45 (2), 98–107.

Lienert, C., B. Jenny, O. Schnabel, and L. Hurni. (2012): Current Trends in Vector-BasedInternet Mapping: A Technical Review. In: Peterson, M. P. (Ed.) Online Maps withAPIs and WebServices. Berlin Heidelberg. Springer. 23–36.

MacEachren, A. M. and D. R. F Taylor. (1994): Visualization in Modern Cartography. Oxford,UK: Pergamon, P. 368.

Norman, D. A. (2002): The Design of Everyday Things. New York: Basic Books, P. 192.

Perkins, B. (2010): Have you mapped your data today? http://www.computerworld.com/

s/article/350588/Have_You_Mapped_Your_Data_Today_ (visited on 12/09/2013).

Persson, D., D. G. Gartner, and D. M. Buchroithner. (2006): Towards a Typology of Interac-tivity Functions for Visual Map Exploration. In: Stefanakis, D. E., D. M. P. Peterson,D. C. Armenakis, and D. V. Delis (Ed.) Geographic Hypermedia. Berlin Heidelberg.Springer. 275–292.

Peterson, M. P. (2008): Trends in Internet and Ubiquitous Cartography. Cartographic Per-spectives, 61, 36–49.

Peterson, M. (2003): Maps and the Internet: An Introduction. In: Peterson, M. (Ed.) Mapsand the Internet. Oxford. Elsevier Science. 1–16.

Rautenbach, V., S. Coetzee, and A. Iwaniak. (2013): Orchestrating OGC web services to pro-duce thematic maps in a spatial information infrastructure. Computers, Environmentand Urban Systems, 37, 107–120.

Roth, R. E. (2012): Cartographic Interaction Primitives: Framework and Synthesis. The Car-tographic Journal, 49 (4), 376–395.

Sancho-Jimenez, G., R. Bejar, M. A. Latre, and P. R. Muro-Medrano. (2008): A Method toDerivate SOAP Interfaces and WSDL Metadata from the OGC Web Processing Ser-vice Mandatory Interfaces. In: Song, I.-Y., M. Piattini, Y.-P. P. Chen, S. Hartmann,F. Grandi, J. Trujillo, A. L. Opdahl, F. Ferri, P. Grifoni, M. C. Caschera, C. Rol-land, C. Woo, C. Salinesi, E. Zimanyi, C. Claramunt, F. Frasincar, G.-J. Houben, andP. Thiran (Ed.) Advances in Conceptual Modeling – Challenges and Opportunities.Berlin Heidelberg. Springer. 375–384.

Schnabel, O. (2007): Benutzerdefinierte Diagrammsignaturen in Karten Konzepte, Formal-isierung und Implementationen. Dissertation, ETH Zurich, Zurich, Switzerland.

Schnabel, O. and L. Hurni. (2009): Cartographic Web Applications – Developments andTrends. Proceedings of the 24th International Cartographic Conference. Santiago deChile.

62

Bibliography

Sieber, R., R. Geisthovel, and H. Lorenz. (2009): Atlas of Switzerland 3 – A Decade of Explor-ing Interactive Atlas Cartography. Proceedings of the 24th International CartographicConference. Santiago de Chile.

Sieber, R., L. Hollenstein, B. Odden, and H. Lorenz. (2011): From Classic Atlas Design toCollaborative Platforms – The SwissAtlasPlatform Project. Proceedings of the 25thInternational Cartographic Conference. Paris.

Slocum, T. A., R. B. McMaster, F. C. Kessler, and H. H. Howard. (2008): Thematic Car-tography and Geovisualization. Upper Saddle River, NJ: Pearson Prentice Hall, P.576.

Spence, C., J. Devoys, and S. Chahal. (2009): Architecting Software as a Service for theEnterprise. IT@Intel White Paper. http://www.intelcore.co.hu/content/dam/doc/white-paper/cloud-computing-intel-it-architecting-software-as-a-

service-paper.pdf (visited on 12/12/2013).

Supavetch, S. and S. Chunithipaisan. (2011): Interface Independent Geospatial Services Or-chestration. Information Technology Journal, 10 (6), 1126–1137.

Turner, A. (2006): Introduction to Neogeography. Sebastopol, CA: O’Reilly, P. 54.

63

A. Appendices

A.1. Third-party Libraries and Software

Table A.1.: Software

Software Version License Description

Node.jshttp://nodejs.org

0.11.0 MIT Server software

PostgreSQLhttp://www.postgresql.org

9.1.9 PostgreSQL(MIT)

Database software

PostGIShttp://postgis.net/

2.0.3 GPLVersion 2

Geographic functionsand objects for PostgreSQL

GDALhttp://www.gdal.org

1.9.0 MIT Geospatial DataAbstraction Library

Table A.2.: Server-side Libraries

Bibliothek Version Lizenz Beschreibung

Grunthttp://gruntjs.com

0.4.1 MIT Taskrunner, provideproduction environment

Grunt-*https://github.com/gruntjs

* MIT Various Grunt Tools,see Web page

Expresshttp://expressjs.com

3.4.4 MIT Framework for Node.js

node-postgreshttps://github.com/brianc/

node-postgres

2.8.2 MIT Library to connectwith PostgreSQL

64

Appendices

Table A.3.: Client-side Libraries

Bibliothek Version Lizenz Beschreibung

AngularJShttp://angularjs.org

1.2.0 MIT Application Framework(MVVM)

Angular UI ng-gridhttp://angular-ui.

github.io/ng-grid/

0.0.2 MIT Data gridcomponent for AngularJS

Angular UI Sortablehttps://github.com/

angular-ui/ui-sortable

0.0.1 MIT User-interface componentfor AngularJS

Angular UI Select2https://github.com/

angular-ui/ui-select2

0.0.2 MIT User-interface componentfor AngularJS

Select2http://ivaynberg.github.

io/select2

3.4.4 GPLVersion 2

Library for select inputs

Bootstraphttp://getbootstrap.com/

3.0.1 MITVersion 2

User-interface framework

OpenLayershttp://ol3js.org/

3.0.0-beta

BSD2-clause

Library formap display

jQueryhttp://jquery.com

2.0.3 MIT Library forDOM manipulation

jQuery UIhttp://jqueryui.com

1.10.3 MIT User-interface componentsfor jQuery

jQuery CSVhttps://github.com/

mirlord/jquery-csv

0.7.0 MIT Library forCSV conversion

JSON-stathttps://github.com/

badosa/JSON-stat

0.6.1 ApacheVersion 2

Library forJSON-stat conversion

X2JShttp://code.google.com/

p/x2js/

1.1.3 ApacheVersion 2

Library forXML conversion

es5-shimhttps://github.com/

kriskowal/es5-shim

2.1.0 MIT Cross-browser EcmaScript 5support

json3http://bestiejs.github.

io/json3

3.2.5 MIT Cross-browser JSONimplementation

65

Appendices

A.2. Server-side API

Table A.4.: REST Requests

Host Url Requestmethod

Parameter

/SAS/analyzeGeometry POST method=centroid

/SAS/measure POST method=areatargetColumn=(Column Name)

/CS/classifyData POST method=quantileattributeColumn=(Column Name)classCount=(Integer number)

/CPS/executeMethod POST method=dotFromAreaattributeColumn=(Column Name)dotValue=(Float number)minDotDistance=(Float number)

/TMS/saveMapDescription POST mapId=(Map Id)

/TMS/getMapDescription GET mapId=(Map Id)

SAS . . . Spatial Analysis Service CS . . . Classification ServiceCPS . . . Cartographic Procedure Service TMS . . . Thematic Map Service

66

Appendices

A.3. Service Chain Objects and Map Description

Listing A.1: Service Chain Object - Data Import

1 {2 'inputService': {3 'sourceId': 'Source Id',4 'name': 'Source Name',5 'desc': 'Source Description',6 'type' :'local' ,

7 'param': {8 'files': {9 '1' :{

10 'layerId': 'Layer Id',11 'type': 'Layer Type',12 'name': 'Layer Name',13 'path': 'File Path',14 'fileType': 'File Type'15 }16 }17 }18 },19 'config':20 {21 'layer':'Layer Id'22 }23 }

The service chain object for data import includes an input service and a configuration toselect a specific data set. In the definition in Listing A.1 a local input service is specified,whereby the data sets are defined in a file object which includes the file path.

67

Appendices

Listing A.2: Service Chain Object - Data Integration

1 {2 'mappingTable' :{3 'layers' :{4 '(Layer Id)' :{5 'layerId' :'Layer Id',6 'column' :'Column Id',7 'columnNewTable' :['Column Id','Column Id','...']8 },9 '(Layer Id)' :{

10 'layerId' :'Layer Id',11 'column' :'Layer Id',12 'columnNewTable' :['Column Id','Column Id','...']13 }14 }15 },16 'layerName' :'New Layer Name',17 'layerId' :'New Layer Id'18 }

For data integration the service chain object (Listing A.2) has to specify the new layer nameand id. In addition, the mappingTable object declares the data layers for the integration.

68

Appendices

Listing A.3: Service Chain Object - Data Manipulation

1 {2 'layerId' :'Layer Id',3 'action' :'/,*,+, or -',4 'config' :{5 'column1' :'Column Id',6 'column2' :'Column Id',7 'targetColumn' :'New Column Id',8 'targetColumnName' :'New Column Name'9 }

10 }

With the service chain object for basic data manipulation (Listing A.3) arithmetic operationscan be applied to the columns of a data layer. Therefore, the object has to declare the layerid, the arithmetic operation, and the involved columns.

69

Appendices

Listing A.4: Service Chain Object - Processing Service

1 {2 'processingService' :

3 {4 'type' :'Service Type',5 'serviceId' :'Service Id',6 'name': 'Service Name',7 'url' :'Service URL',8 'methods' :

9 {10 '(Method Id)' :{11 'methodId' :'Method Id',12 'operation' :'Operation Name',13 'method' :'Method Name',14 'methodDesc' :'Method Description'15 }16 }17 },18 'config': {19 'methodId' :'Methode Id',20 'requestData' :{21 'layersId' :['Layer Id']22 },23 'requestParam' :{24 'param1' :'Parameter 1',25 '...' :'...'26 }27 }28 }

The service chain object to perform service requests is given in Listing A.4. Thereby, theprocessing service and the available methods are specified in the processingService object.The configuration object includes the method id, the id of the layer for processing, and theparameters.

70

Appendices

Listing A.5: Service Chain Object - Symbology Description

1 {2 'symbologyRepository' :{3 'sourceId': 'Repository Id',4 'name': 'Repository Name',5 'desc': 'Description',6 'type' :'local' ,

7 'param': {8 'symbologyDescriptions': {9 '1' :{

10 'symbologyId': 'Symbology Description Id',11 'path': 'File Path'12 }13 }14 }15 },16 'config' :{17 'layerId' :'Layer Id',18 'symbologyId': 'Symbology Description Id',19 'type' :'Symbolizer Type',20 'columns' :['Column Id','Column Id','...']21 }22 }

The symbology for a data layer is specified with the service chain object presented in List-ing A.5. The object declares a local symbology repository with a symbology descriptionreferenced by a file path. The configuration object specifies the layer for symbolization, theid of the symbology description, the symbolizer type, and the columns for a variable symbol-izer.

71

Appendices

Listing A.6: Map Description Object

1 {2 'mapInfo' :{3 'title' :'Map Title',4 'imprint' :'Imprint Text',5 'id' :'Map Id',6 'map' :{7 'zoom' :'Map Zoom',8 'center' :{9 'lat' :'Latitude',

10 'lng' :'Longitude'11 }12 },13 'layer' :[

14 {15 'id' :'Layer Id',16 'type': 'Layer Type',17 'visibility': 'Boolean'18 },19 {20 '...' :'...'21 }22 ]

23 },24 'serviceChain' :[

25 {26 'id' :'Service Chain Object Id',27 'type' :'Service Chain Object Type',28 'config' :'Service Chain Object'29 },30 {31 '...' :'...'32 }33 ]

34 }

The map description object (Listing A.6) includes the map information and the service chain.The mapInfo object thereby defines meta informations, the map extent, and the map layers.To derive the layer data, the serviceChain object defines the map creation process.

72

Appendices

A.4. Symbology Descriptions for Example Maps

Listing A.7: Symbology Description Choropleth Map

1 {2 'pointSymbolizer' :{},3 'lineSymbolizer' :{},4 'polygonSymbolizer' :{5 '1' :{ // Polygon Symbolizer

6 'symbologyId' :'1', // with the name 'Sequential'7 'name' :'Sequential',8 'styleType' :'json',9 'style' :{ // Global Symbolizer style

10 'polygon-fill' :'#ffffff',11 'polygon-opacity' :0,

12 'line-color' :'#5cb85c',13 'line-width' :1

14 },15 'variableSymbology' :[ // Variable Symbolizer style

16 { // and metadata

17 'columnType' :'nominal',18 'maxValues' :5,

19 'minValues' :2,

20 'styles' :{21 '1' :{'polygon-fill' :'#FFFFD4'},22 '2' :{'polygon-fill' :'#FED98E'},23 '3' :{'polygon-fill' :'#FE9929'},24 '4' :{'polygon-fill' :'#D95F0E'},25 '5' :{'polygon-fill' :'#993404'}26 }27 }28 ]

29 }30 },31 'labelSymbolizer' :{}32 }

73

Appendices

Listing A.8: Symbology Description Dot Map

1 {2 'pointSymbolizer' :{3 '1' :{ // Point Symbolizer

4 'symbologyId' :1,

5 'name' :'Dot Map Small',6 'styleType' :'json',7 'style' :{8 'marker-type' :'ellipse',9 'marker-fill' :'#570387',

10 'marker-fill-opacity' :'0',11 'marker-width' :'4',12 'marker-height' :'4'13 }14 }15 },16 'lineSymbolizer' :{},17 'polygonSymbolizer' :{18 '1' :{ // Polygon Symbolizer

19 'symbologyId' :1,

20 'name' :'Light Boarder',21 'styleType' :'json',22 'style' :{23 'line-color' :'#000000',24 'line-width' :2,

25 'line-opacity' :0.8

26 }27 }28 },29 'labelSymbolizer' :{}30 }

74

Appendices

Listing A.9: Symbology Description Proportional Symbol Map

1 {2 'pointSymbolizer' :{3 '1' :{ // Point Symbolizer

4 'symbologyId' :1, // DiaML

5 'name' :'Two Values Grouped',6 'styleType' :'diaML',7 'diaML' :{8 'path' :'Symbology/DiaML/pie.xml',9 'type' :'diagram'

10 },11 'variableSymbology' :[ // Variable Symbolizer metadata

12 {13 'columnType' :'metric',14 'diaMLRef' :'column1'15 },16 {17 'columnType' :'metric',18 'diaMLRef' :'column2'19 },20 {21 'columnType' :'metric',22 'diaMLRef' :'column3'23 },24 {25 'columnType' :'metric',26 'diaMLRef' :'column4'27 }28 ]

29 }30 },31 'lineSymbolizer' :{},32 'polygonSymbolizer' :{},33 'labelSymbolizer' :{}34 }

Listing A.10: DiaML Pie Chart Symbolizer

1 <symbol xmlns='http://www.carto.net/schnabel/mapsymbolbrewer'2 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'3 xsi:schemaLocation='http://www.carto.net/schnabel/mapsymbolbrewer4 http://www.carto.net/schnabel/mapsymbolbrewer/schemas/diaml.xsd'>5 <style id='s0'>6 <fill>#CC7D7D</fill>

7 <fill-opacity unit='percent'>80</fill-opacity>8 <stroke>#333333</stroke>

9 <stroke-width unit='pixel'>2</stroke-width>

75

Appendices

10 </style>

11 <style id='s1'>12 <fill>#7DCC7D</fill>

13 <fill-opacity unit='percent'>80</fill-opacity>14 <stroke>#333333</stroke>

15 <stroke-width unit='pixel'>2</stroke-width>16 </style>

17 <primitive id='p0'>18 <sector proportional='area'>19 <r scale='partSum'>20,25</r>20 <angle scale='dataValue'>40,140,70,110</angle>21 </sector>

22 </primitive>

23 <diagram translationX='0' translationY='0' rotation='0'24 minSize='10' maxSize='70' areaRatio='10'>25 <diagramArrangement>

26 <polar>

27 <groups>2</groups>

28 <centerDistance>3</centerDistance>

29 <totalAngle unit='degree'>360</totalAngle>30 </polar>

31 </diagramArrangement>

32 <diagramRelation>

33 <dataRef>column1</dataRef>

34 <primitiveRef>p0</primitiveRef>

35 <styleRef>s0</styleRef>

36 </diagramRelation>

37 <diagramRelation>

38 <dataRef>column2</dataRef>

39 <primitiveRef>p0</primitiveRef>

40 <styleRef>s1</styleRef>

41 </diagramRelation>

42 <diagramRelation>

43 <dataRef>column3</dataRef>

44 <primitiveRef>p0</primitiveRef>

45 <styleRef>s1</styleRef>

46 </diagramRelation>

47 <diagramRelation>

48 <dataRef>column4</dataRef>

49 <primitiveRef>p0</primitiveRef>

50 <styleRef>s0</styleRef>

51 </diagramRelation>

52 <labelData>no</labelData>

53 </diagram>

54 </symbol>

76

B. Declaration of Originality

I hereby declare that the written work I have submitted entitled

Service-oriented Architecture for Thematic Cartography on the Web

is original work which I alone have authored and which is written in my own words.

AuthorLast name

Krimbacher

First name

Andreas

SupervisorLast name

Hurni

First name

Lorenz

SupervisorLast name

BarIosifescu EnescuStraub

First name

Hans-RudolfIonutFlorian

With the signature I declare that I have been informed regarding normal academic citationrules and that I have read and understood the information on ’Citation etiquette’1. Thecitation conventions usual to the discipline in question here have been respected.

The above written work may be tested electronically for plagiarism.

Zurich, January 27, 2014Place and Date Signature

1http://www.ethz.ch/students/exams/plagiarism_s_en.pdf

77