figure img/Sigillum_Universitatis_Ludovico-Maximilianeae.png
Ludwig Maximilian University of Munich
Department for Informatics
Teaching and Research Unit Programming and Modelling Languages

Bachelor’s thesis

Cartography in a Gameful Context

Involving the crowd in drawing our future maps

Sebastian Straub

Supervisor: Prof. Dr. François Bry
Advisor: Christoph Wieser
Date: October 31, 2012
Maps shape our view of the world and help us in our everyday lives to orient in unfamiliar territory. The art of creating maps however was reserved to a privileged group of people for a long time. Today’s progresses in technology have opened it to anyone with internet access, as free crowdsourced projects have emerged, dedicated to create an open map of the world. However, editing the map and contributing data is still harder than necessary and so the existing projects did not yet hit the masses.
To solve this problem, cartography-related games are proposed in this thesis. Their goal is to unite cartographic work and gaming concepts in an easy to use abstraction layer, ready to be applied in a global, crowdsourced scale. The players should be enabled to participate immediately, without any cartographic background, and use their local knowledge to submit valuable geographic information. This approach makes it possible to create maps of unprecedented detail and actuality, which can make life easier and open whole new application ares for people with special interests (e.g. hiking, cycling) or disabilities (e.g. for blind people).
This thesis will give an overview of ludic ways to contribute geographic data and provide background information about the concerning topics cartography, human-based computation and games in general. Based on that, abstract concepts for cartography-games have been developed and three exemplary game descriptions are provided. The goal of this thesis is to discover, if cartographic work is possible and feasible in a gameful context.
Karten bestimmen unseren Blick auf die Welt und geben uns Orientierung, wenn wir uns einmal nicht auskennen. Die Kunst, Karten zu erstellen, war jedoch lange Zeit einem geschlossenen Personenkreis vorbehalten. Der technische Fortschritt ermöglicht dies heutzutage jedem, der über einen Internetanschluss verfügt, denn es wurden freie Kartographie-Projekte gegründet mit dem Ziel, eine offene Weltkarte zu erschaffen. Allerdings ist das bearbeiten dieser Karten und das Beitragen neuer Kartendaten immer noch deutlich schwieriger als es sein könnte und so konnten die bestehenden Projekte noch nicht die Massen ansprechen.
Um dieses Problem anzugehen, wird in dieser Arbeit das Konzept von Kartographie-Spielen präsentiert. Ihr Ziel ist es, kartographische Arbeit und Spielkonzepte auf einer Abstraktionsebene zu vereinen, die einfach zu nutzen ist und weltweit über Crowdsourcing angesprochen werden kann. Die Spieler sollen die Möglichkeit bekommen, sofort und ohne Hintergrundwissen teilzunehmen, um allein durch ihre Ortskenntnis wertvolle Geodaten beitragen zu können. Dieser Ansatz würde es ermöglichen, Karten zu erstellen, die in Detailgrad und Aktualität ihresgleichen suchen. Derartige Karten können für Menschen mit bestimmten Interessen (z.B. Wandern, Radfahren) oder körperlichen Einschränkungen (wie z.B. Blinde) von besonderer Bedeutung sein können.
Diese Arbeit soll ein Überblick über spielerische Möglichkeiten zum Beitragen von Kartendaten verschaffen und wichtige Hintergrundinformationen über die betreffenden Themen Kartographie, Human-based Computation und Spiele im Allgemeinen liefern. Darauf basierend werden abstrakte Konzepte für Kartographie-Spiele entwickelt, die in der Ausarbeitung dreier exemplarischer Spielbeschreibungen münden. Das Ziel dieser Arbeit ist herauszufinden, ob Kartographie auf spielerische Art möglich und tatsächlich durchführbar ist.
First of all, I want to thank my advisor Christoph Wieser, who was interested in the idea that lead to this thesis from the beginning and helped me to get this project started. Without his advocacy and constant support, I would not have brought the thesis to its current state.
I also want to thank Prof. François Bry for his endorsement of my work and the opportunity to write it at the Teaching and Research Unit for Programming and Modelling Languages. The possibility to access my own workplace and to talk with the other members at the chair was of great value to me. Also, the feedback I received during the graduate seminar and beyond showed me new directions and thereby greatly enhanced my work.
Furthermore I’d like to express my gratitude towards the initiators and all the supporters of the OpenStreetMap, which is a great project that inspired me to write this thesis.
And lastly, many thanks to my friends, who were always able to cheer me up when I got stuck, and my family, who I can always count on.
  Sebastian Straub
Table of Contents

1 Introduction

The use of maps in our society has changed drastically over the last decade. Printed maps, where the traveler had to make up his own route before departure, have been widely replaced by navigation systems where a computer voice steers you safely through almost any region of the world. As the maps became interactive, an almost unlimited depth of detail for any area could be stored on or streamed to the navigation devices, which was previously impossible due to the fixed scale and overall weight of printed maps. And with the emergence of cheap mobile internet, even real-time data could be integrated into maps.
These new technological possibilities opened a variety of new services and usage areas for maps. The users started to expect, that a navigation system knew where a detour was set up, where a traffic jam has formed, and due to the fact that navigation devices always show your exact position in high scale, every side road and field path that is not mapped became a possible cause of irritation.
The demands on actuality and level of detail became much higher than with traditional printed maps and soon it was clear that the traditional suppliers were unable to meet the new requirements in time. So in 2004, a project was founded with the goal to create a free world map that can be used and edited by anyone. This way, so the idea, the crowd would overcome the limitations of commercial suppliers and together create a world map of unprecedented detail; an impossible task for a handful of paid employees, but not for a global community of supporters. In 2006, the project went public under the name OpenStreetMap and as of October 2012, nearly 200.000 people [32] have since then contributed changes to the map.
Though independent research has shown that the map is of high quality in certain countries [18], the overall distribution of information is very inhomogeneous. Most contributions are concentrated on conurbations in developed countries, making the map really competitive only in Europe, North America and Japan (for a detailed view see chapter↓). The reason why the OpenStreetMap, though it has a comparable concept, is not as broadly successful as Wikipedia, lies for a major part in the complexity of current contribution systems. The current tools to edit the map can not be considered as beginner-friendly; a new contributor has to learn about technical details of the editing process before even having the chance to successfully submit a valid contribution that is not rejected by the system in the first place.
To reach the goal of having a globally distributed crowd of participants, new contribution techniques need to be established that are way easier to use and more inciting for the user. That’s why I propose cartography-games, a ludic way for the crowd to enhance the maps they use in their everyday life.

Topic of this Thesis

In this thesis, I will investigate, if games can be suitable for the collection of geographic data by ordinary users that don’t need to have any cartographic background. Thereby I will explore and categorize ludic ways to participate in the cartographic process and identify abstract techniques that can be applied on different game types. Based on that, I will develop general game concepts and elaborate three exemplary descriptions of possible cartography-games.
The concrete implementation and evaluation of games is not part of this thesis, but the information gathered throughout this work should give enough background to implement one of the proposed cartography-games or to design new games based on the introduced game concepts. Furthermore, I will not consider general crowdsourcing techniques to collect geographic information, like traffic monitoring with feedback from navigation devices. This thesis will be about games and game-related applications.

Content Overview

Following to this introduction, a brief overview of related work will be given. In chapter 3↓, the three main aspects of cartography-related games will be analyzed:
First cartography, the actual work that should be fulfilled by the crowd, though ideally without any background knowledge. Nevertheless, a good insight into cartographic work and modern techniques is necessary to design games that can produce valid data. The second aspect concerns human-based computation, a computer science technique that combines the specific abilities of humans and computers to fulfill complex tasks in a broad scale. This technique is the foundation of any games that fulfill, in their course, other (computational) tasks that need to be stored permanently in machine-readable form. The third aspect concerns games in general, as well as human-based computation games in particular.
After this insight into the relevant challenges, chapter 4↓ will be all about actual cartography-games. An abstract description of possible concepts will be given, as well as three concrete game descriptions (without implementations).
In the conclusion, the initial question, if cartography-games are really suitable for the collection of geographic data by non-catographers will be discussed.

2 Related Work

As already pointed out in the introduction, cartography-games unite three distinct research areas: human-based computation, cartography and games. Despite the fact that humans have been playing games throughout the very existence of mankind, genuine scientific research concerning games has only been done since the 20th century. In contrast to that, scientific work about cartography dates back into antiquity, though the drawing of maps is not half as common to humans as playing games. Other than the two, human-based computation (HBC) can be considered as very young, just like most computer science techniques.
About any of these topics alone, the interested reader will find much and more information, using a certain free encyclopedia or the search engine of choice. About all three of them combined, as of 2012 the search engines remain silent, except for some work about cartography in the design of virtual environments (i.e. for computer games), which is not the topic of this thesis.
Therefore, this related work chapter will be about the three possible pairwise combinations of the three aspects of cartography-games, in the hope to find work that can be extended to serve the cause of this thesis.
figure img/Venn_01_Maps-HBC-Cartography.png
Figure 2.1 Research areas

2.1 Cartography-related Games

Are there any games that are concerned with cartography so far? The short answer: No. But, there are some interesting games that make excessive use of the new technological possibilities that have emerged with the high availability of cheap navigation devices. These games have the potential to be altered in a way that they also support contributions of geographic information by the players.
First there are location-based games [71], these are games that take the player’s location into account and make it a part of the game. Usually these games require the players to be in possession of a mobile device that allows to submit the player’s position and to communicate with other players; all functions that can be provided by a smartphone. Examples would be Zombies vs. Humans [2], where the players are part of a end-time zombie scenario in their home, and Geocaching [72], a game where secrets are hidden around the world and players can go out and search for them.
The so called pervasive games [69] take this concept even further and describe any type of game where the gameplay is extended spatially, temporally or socially.
These games do not contribute any cartographic data, but they show that certain players are willing to go out and interact with real world objects and other players they usually don’t know, but meet as part of the game.

2.2 Human-based Computation Games

There has been done much research about human-based computation games in recent years. Scientists, game designers and entrepreneurs seem to be excited by the possibilities to get people to do actual work while having a fun time playing a game and so they think about ways to harness the tremendous parallelized power of the crowd.
Two terms are strongly connected with human-based computation games: Gamification and GWAP. The term gamification describes “the use of game design elements in non-game contexts” [46], which results in applications that are using elements of games, but can not be considered as real games. Gamified applications do not necessarily solve human-based computations, but it is possible to gamify human-based computations in order to reach more participants.
A GWAP, or game with a purpose, is a full-fledged game, that solves in its course a human-based computation. Louis von Ahn, the inventor of GWAPs, has provided theoretical backgrounds [47] as well as own working implementations like the ESP game [48] or Verbosity[49]. Other examples include Foldit [57], a puzzle about protein folding, and ARTigo [50], a tagging-game that contributes to a semantic search engine for art history.
None of these human-based computation games is about the solving of cartographic problems, but the general game concepts could be altered to support such tasks.

2.3 Cartography-related Human-based Computation

Human-based computations in combination with maps or cartography are very rare, but there are examples that can show, how cartographic tasks can be fulfilled by the crowd.
For the OpenStreetMap there are some tools that should simplify the submission of new data for inexperienced users, like YAPIS [3], an acronym for “Yet Another Point of Interest Submitter”.
An interesting cartography-related citizen science project is Galaxy Zoo [41], a web application that confronts its participants with images of galaxies taken by the Hubble space telescope. The goal is to classify these galaxies, using some simple cascading questions about the shape and other attributes that are visible in the image.
The project that comes probably closest to our desired cartography-games is
Foursquare [85], a location-based social network, where the users share their current location with their friends and are able to submit additional data about places they have visited. Though foursquare does even use some game design elements like points and badges, it can not be considered as full-fledged game and the geographic data that can be submitted is limited to existing objects (e.g. rating a restaurant).
So there are interesting projects that are focused on cartographic work, as YAPIS and Galaxy Zoo, and there is the social gamified platform foursquare, with very limited cartographic abilities and only a few game design elements, but with a commercially successful concept. Cartography-games can benefit from experiences on both sides.

3 Three Major Aspects

The three aspects of cartography-games can be combined to the a little bit bumpy term cartography-related human-based computation games. To really understand, what this term could mean and how such games might work, the three single aspects will be regarded independently in this chapter before they will be put together.
figure img/Venn_02_Cartography-HBC-Games.png
Figure 3.1 Combination of aspects
The first section will explain some basics about maps and cartography. After a definition of geographical maps, a short historical overview of cartography will finish with a view on modern cartographic methods. A categorization of general cartographic problems will be presented, followed by a section about free geographic data. The last part in the cartography-section will be about the OpenStreetMap, an excellent example of a crowdsourced cartography-project. It will explain, where the data in the OpenStreetMap comes from, how editing of data works and provide some information about the OpenStreetMap-community.
Section two will be about human-based computation (HBC), the computer science technique that enables humans to contribute massively parallel work to a single cause. After a scientific definition, a categorization system for HBC-tasks will be introduced and an overview of application areas for this technique will be given. As part of this section there will also be an insight in the topic crowdsourcing. Without the massively parallel power of the crowd, the task of creating a detailed and actual map of the world would be hopeless. At the end of this section, the results of this and the previous cartography-section will be combined to elaborate applicable types of HBC and crowdsourced tasks.
Section three will make a little exception, as it will not try to treat the large area of games and game design in general, but concentrate more on human-based computation games, the only game type that can fully serve the cartographic purpose. However, an introduction into relevant game design topics will take a good part of this section. Afterwards, the possible gaming concepts will be elaborated in more detail, based on the previous considerations about games in general.

3.1 Cartography

figure img/Venn_02_1_Cartography.png
Figure 3.2 Aspect 1: Cartography
Every child today knows what our world looks like, which continent it’s on, where the rich are living and where the poor. Except for the few people who had the privilege to see the surface of our world with own eyes from outer space, everyone knows what the world looks like from maps.
Maps shape our view of the world, and not so long ago, they tricked kings, emperors, pharaohs, consuls and other sovereigns to believe they were ruling the world. An erratic assumption, which is best disproven by the fact that throughout history, at the same time, multiple rulers thought the same about their particular realm.
The exploration and mapping of the world, which began in the 15th century from Europe, was also incited by cartographers that made observations which lead to the conclusion that the world was much bigger than they had so far assumed.
Now we know what the world looks like from far above, we have maps that show any country and almost any road on the world and there are only one or two empires left that believe they would rule the world. What good reason is there to bring this work to the next level?
Traditional usage areas for maps were and are still navigation and planning, but the world consists of so much more information with concrete reference to particular locations. As of 2012, more than 2 million articles in Wikipedia have been geocoded [11], which means that the article has been associated with geographic coordinates. Future maps will become more than just navigation aids, they will be knowledge bases and we will be able to read in them just like books. Building up this knowledge base of the world, a detailed informational representation of geographic reality, is the challenge in cartography today.

3.1.1 Geographical Maps

Maps in general describe any visual representation of elements that share a relationship in a common space. These relationships are often illustrated by nodes and edges and can address social, scientific, geographical and many more relations. The website Visualcomplexity [1] is dedicated to collect functional visualizations of complex networks in categories like art, biology, internet, music and social networks.
Cartography however is concerned with the collection, analysis and organization of geographical data (geodata), the results of cartographic work are therefore geographical maps. For practical reasons, in this thesis, the term map will be used as a synonym to geographical map.
A map, according to the International Cartographic Association (ICA), is “a symbolised representation of geographical reality, representing selected features or characteristics, resulting from the creative effort of its author’s execution of choices, and is designed for use when spatial relationships are of primary relevance” [4].
From this definition five major characteristics of maps can be extracted:
Note that geographical reality in terms of maps does not necessarily need to refer to the shape of our real world, maps can also show the reality of virtual or fantasy worlds. And an issue that has come up with the rise of the web 2.0 concerns the “author’s execution of choices”. Since there are interactive maps that allow the user not only to choose between symbolized or aerial imagery, but also which layers and elements shall be drawn (such as Google Earth [5]), it is not only the author of the map that decides over its visual representation.
Keeping these two subjects in mind, the definition of maps from the ICA will be sufficient for the requirements of this thesis.

3.1.2 Cartography

“Cartography is the discipline dealing with the conception, production, dissemination and study of maps” [4], according to the current definition of the ICA. It strongly relates cartography to the creation of maps, as well as the studying of maps in scientific terms. Historical Development

Though cartography was already an issue in the time before recorded history, as proven by murals more than 10.000 years old [6], exact, uniform and true to scale cartography is an achievement that was made in modern history. Up to the middle ages maps were mainly drawn by hand from direct sight and memory, without any specific cartographic tools.
figure img/Ptolemaeus.jpg
(a) Claudius Ptolemaeus
figure img/PtolemyWorldMap.jpg
(b) Ptolemaeus’ world map (redrawn 15th century)
Figure 3.3 Ancient Greek cartography
In the classical era there were already maps drawn of the known world. The recordings of ancient Greek mathematician, astronomer and geographer Claudius Ptolemaeus dominated cartographic teaching and work up to the 15th century. His standard geography textbook Geographica consists of detailed instructions on the drawing of maps and included a map of the known world of the first century b.c. and several detailed regional maps with about 8000 location marks. Ptolemaeus believed in a spherical earth and therefore also described projection techniques for drawing maps of spherical shaped objects, as well as a geographic coordinate system defining every position of earth as a combination of latitude and longitude. [8]
figure img/671px-L-Triangulierung.png
(a) Triangulation

figure img/Theodolit_Hassler.jpg
(b) Theodolite
Figure 3.4 Triangulation-Technique
Though the fundamental theoretical problems of cartography were already solved in antique times to a point that realistic maps of the world could have been drawn, it took up to the 17th century and the (re)discovery of triangulation, until modern land surveying was possible.
The application of the triangulation technique and the availability of modern cartographic tools like the theodolite made it possible to create true to scale maps of large parts of the earth. Together with the spreading of book printing, copies of realistic maps became more and more available. Modern Cartography

Cartography passed some major evolutionary steps since the dawn of the modern age. Though the underlying techniques and mathematics have not changed radically, its tools have. Positioning in the time of global navigation satellite systems like GPS has become cheap and easy for everyone to use, distance measurement using laser technology is more precise than any mechanical scale can be and the ability to take pictures of the world from planes or even outer space provides cartographic knowledge of regions on earth that were probably never visited by humans.
With the introduction of computer data processing in cartography in the early 1960s, one prime focus of cartographic work has been split in two different fields: the creation of a map is not anymore the primary result of a process of collecting geographical data. Nowadays, collected geodata is stored in geographic information systems, from which several kinds of different maps can be rendered, according to the choice and creative work of the map creator.
Geographic Information System (GIS)
describes an information system that stores geographical data of any kind in an efficient data structure that is not necessarily focused on the presentation of a specific part of its data to the user (as a map does). In fact, many GIS do not have a built-in graphical representation of its data at all, though most of them offer interfaces to store, edit, analyze and share its contents.
The separation of geodata and maps increases efficiency in cartographic work, as cartographers who mainly collect data do not need to bother with maps anymore and the creators of maps can concentrate on important tasks as usability, choice of features and the interpretation of geodata which has already been provided in a pure data-centric form.
Considering modern computer-based geographic information systems, the term cartography, regarding the previous definition of the ICA, could be expanded to the capturing, storing and manipulating of all types of geographical data, regardless of the representation of said information in a specific map.
This abstraction will be one key to the creation of cartography-related games. Cartographic Problems

In the process of the collection of geodata, there are several problems that need to be addressed by the cartographer. Based on ISO 19113 [9], which describes quality principles for geographic information, the following subjects will be considered in this thesis.
When designing cartography-related games, it is important to keep these issues in mind, especially because most players will probably have no knowledge any of these quality criteria.
For other cartographic tasks, like the actual drawing of maps, there are similar quality guidelines, but as we will concentrate in this thesis on the collection of geographic data by the public, these will be omitted at this point.

3.1.3 Free Geographic Information Systems

Besides government or commercial operators of GIS, there are also free projects dedicated to the collecting of free and open geodata. A free geographic information system differs from a proprietary system in the following aspects:
There is already a variety of maps available on the internet for free (without charge), so why the need for free (under free license conditions) geodata? First, the popular online maps like Google Maps or Bing Maps offer only restricted access to their maps: Users may view map tiles (images that have been rendered from geodata) under certain restrictions, like the use of a specific software or browser application. Second, the access to the geodata itself is not free, so the geodata of these providers can not be used for scientific purposes or to render new maps.
Ironically, the availability of free tiles is no mandatory condition for open GIS, as anyone with access to the geodata itself is allowed to build and redistribute his own tiles (under the free license conditions).
Under such restricted conditions, community contributions are not easy to incite, as will be elaborated later in this thesis.

3.1.4 OpenStreetMap

The OpenStreetMap is a free project that designates itself as “The Free Wiki World Map” [13]. its main purpose is the collecting of geodata on earth in a free geographic information system. As graphical front end, a free editable map of the world has been created, where anyone is invited to edit the map in a wiki-style manner. History

figure img/Openstreetmap_logo_svg.png
(a) OpenStreetMap logo

figure img/Osmdbstats1.png
(b) registered users [blue] and track points [pink]
Figure 3.5 OpenStreetMap
The OpenStreetMap project was founded in 2004 with the goal to create a free and editable map of the world. In 2006 the geographic information system, the needed software tools and server infrastructure were developed far enough to begin recording large regions of earth. At the same time, the OpenStreetMap Foundation was established to support the growth and development of the OpenStreetMap.
Since then, the number of registered users has seen a near-quadratic growth, while the amount of contributed track points increased in a more linear way on a high level, though it is hard to measure the quality of a map just by the amount of points that define it.
Soon the project received a number of notable donations of geodata that were directly imported into the GIS. Among the largest were the TIGER database with high coverage of roads, buildings and waters in the US and the CIA World DataBank II, which is used to define county borders.
In March 2012, OpenStreetMap gained public attention when Apple and Foursquare, a social media location service, changed from Google Maps to the OpenStreetMap as their primary source of geodata, as a reaction to a major price increase for the usage of the Google Maps API. [37] The use of geodata from the OpenStreetMap project today has become common even among commercial suppliers and is used in navigation devices, web applications and as data basis for many third-party projects. Cartographic Work

How does cartography with the OpenStreetMap actually work? This section will give an overview about data sources, the data structure of the OpenStreetMap’s GIS and how contributors can submit changes.
Data Sources
figure img/GPS-logger.jpg
Figure 3.6 GPS logger
Though there are donations of geodata from commercial suppliers for some regions, the OpenStreetMap project is mainly driven by voluntary contributors that record geodata in their free time. The predominant tools used by the contributors are the GPS receiver and traditional pen and paper.
The GPS receiver could be a GPS navigation device, a GPS logger, a smartphone, or any other device that can define its position on earth with sufficient accuracy, as long as it’s capable of recording the position on demand or periodically, in order to write a GPS track. These points and tracks can then be integrated in the GIS of the OpenStreetMap and be used as a basis to define the course of roads and rivers, the shore of a coastline or lake, the position of a building or facility. The integration of tracks, especially when it comes to elements with complex semantic background like traffic systems, is a nontrivial step that requires some experience of the editor, if he wants to ensure the correct functionality of navigation systems at these locations.
Where the primary goal of the GPS receiver is to cover so far not recorded regions or to update outdated data, pen and paper are used to fill this basic set of geodata with valuable information. Geographic names, house numbers, driving restrictions and special points of interest (POI) can be recorded while walking an area and in case of the POI filled with even more details.
Especially useful to the OpenStreetMap is the local knowledge of people. Local knowledge enables contributors to fill in detailed information about places just from memory, as soon as the basic infrastructure is covered, and fills maps with details that are sometimes not even covered by professional maps.
Apart from the pure self-recorded geodata, the OpenStreetMap also relies on some external sources as basis for new map data. Controversial among cartographers is the use of satellite imagery as source for geodata. In many map editors, satellite imagery can be used as background layer together with an excerpt from the OpenStreetMap GIS in the foreground. This enables the editor to use the imagery for orientation, to adjust misplaced nodes or even to create new geodata, but there are two problems with this approach: First a licensing issue, as data derived from proprietary maps or images can not be published under a free license, and second a possible lack of detail and actuality, because satellite images can be old or displaced and are generally unsuitable to provide information about a region that goes beyond what can be seen from space. At least the licensing issue has been remedied when Microsoft officially allowed the use of all aerial imagery provided by the Bing Map.
As already mentioned, parts of the OpenStreetMap’s geodata are based on donations from other databases or were integrated from GIS without restrictive licenses. Though there is geodata available for import in many regions of earth [15], partly due to donations, more often because geodata that has been collected by state officials must be given to the public domain by law in many countries, the main source of data remains the work of individual contributors.
Data Structure
figure img/Elements.png
Figure 3.7 Data structure
Geodata is represented in the OpenStreetMap as points in a two-dimensional space, which can stand alone for themselves or be connected as part of a path. These elements are combined to a directed graph. Single points or paths (open and closed) can be combined to objects. These objects can be rendered in a map as Markers for POIs (points of interest), roads, buildings and areas. [19]
The developers distinguish between nodes as the basic elements of the map, and the thereof derived ways and relations. A node is defined by latitude and longitude and can represent any object that can be defined through a single point. Ways are defined as an ordered list of between 2 and 2000 nodes, therefore ways do always have a direction, though the direction does not need to have a logical meaning (e.g. road are built as directed ways, even if they can be used in both directions; only when declared as one-way road the direction does matter). Ways can define linear features (streets, railroads, rivers) or polygons which represent areas (buildings, residential areas, lakes, forests).
Relations are ordered lists that can contain any data primitive (node, way) and other relations, where single elements can appear in more than one relation and even more than once in the same relation. Relations can be used to group distinct elements of the map that do have a certain connection in the reality which is not correctly represented in the data structure. For example one could combine certain road elements to a route, which by themselves are split in multiple parts for technical reasons, e.g. if a road contains a traffic circle, it is split at the circle, but it should be still represented as the same road before and after the circle.
Elements usually do have tags [20] associated with them. Tags consist of textual Key-Value-pairs that are combined to a dictionary for each element. Technically the tags can contain any textual values, though there is a large database of well-known keys and values that should be used if possible in order to make the details machine-readable.
A single node can mark the location of a community facility, if the key “amenity” is set. A possible value would be “cinema” which could appear on the map as special icon indicating a cinema at the specified location. For this point one could add other reasonable tags like the name of the cinema, opening hours, a phone number or a boolean value which indicates, if the entry to the building is barrier-free.
Known keys and values are documented in the OpenStreetMap-Wiki [14], the public user- and developer-knowledgebase of the OpenStreetMap. There is a list of possible values for the amenities [21] with descriptions and example images for each value and a very long page for the many more available tags [22].
Editing of Data
The public API of the OpenStreetMap’s GIS has been specified in a simple and comprehensible fashion, which led to the development of a large choice of graphical map editors that are able to contribute changesets to the OpenStreetMap. [23]
The basic functions of any editor consist of setting and manipulating of nodes, ways and relations and the tagging of these elements. The results of these functions are represented in the standard data interexchange format OSM XML [24], an XML document type that is specified to hold (besides some metadata) all data primitives and their associated tags.
In addition to the basic functions, numerous advanced data manipulation tools have been established and integrated in the popular editors to provide error correction, to simplify the work flow and to allow complex manipulation of large data sets. Though there is a large variety of editors which are compatible to the OSM API, more than 90 % of the contributions are created with two editors [25] (see also figure 3.8↓):
First, with more than 30 % of the contributions, the flash-based online editor Potlach 2 [26], which was especially designed for beginners and is the editor that appears by default when clicking the edit-button in the map view on Potlach is opened directly in the web browser and provides functions to set and manipulate the basic elements (nodes, ways, relations) and to import and edit GPS-tracks. The probably most sophisticated feature is the user-friendly tagging mechanism: A sidebar with frequently used tags makes it possible to simply drag and drop a node on the map. For each node, reasonable keys are shown, so the editor does only need to fill out a form, instead of knowing possible key-value-pairs. Potlach is not a full-fledged map editor, due to its limited functionality and extensibility, but it gives beginners a chance to get in touch with the map editing process for the OpenStreetMap.
figure img/JOSM-8.png
(a) JOSM
figure img/Potlach2-8.png
(b) Potlach 2
Figure 3.8 OpenStreetMap editors
More popular among the cartographers is JOSM [27], the Java-OpenStreetMap-Editor, with a market share of near 60 %. It is characterized by the large amount of advanced editing features and an active developer community, which provides around 100 [28, 29] plugins for a huge variety of purposes. JOSM uses a layer architecture to load different data sets from the server, aerial imagery or layers with custom contents. Nodes can be edited just like in a common vector graphics editor by dragging and dropping or with a variety of available tools. There are many advanced features like the automatic rectifying of building shapes or the aligning of elements along a path that make the mapper’s work a lot more convenient. Plugins are usually available for special tasks like the semi-automatic generation of row houses [30]. Many common (and less common) tasks have been automatized and simplified by the developers. The downside of this is the possibility to generate invalid geodata with JOSM, in contrast to Potlach, which does not allow manipulations that could create semantic errors. The inclined cartographer needs to be aware that his efforts can become worthless, if he is unable to fix the errors he has caused; the GIS will simply not accept the contribution. JOSM is a powerful tool for advanced OpenStreetMap cartographers, but for beginners it is not the easiest entry. Community

The OpenStreetMap has a rapidly growing number of contributors, with as of October 2012 more than 800,000 registered users worldwide, of which near 200,000 have actually made changes to the map. [32] Similar to the online-encyclopedia Wikipedia, where about 90 % of the contributions are made by 10 % of the contributors [33], the OpenStreetMap is dominated by an even smaller group of active mappers. According to statistics generated from the OpenStreetMap database, only 1.4 % of the contributors are responsible for more than 90% of the contributions. [34] However, more than a third of these contributions are imports of external databases. Regarding the number of human contributors that have made a node edit in the last month, the number of “active” contributors is slightly higher with about 2.5 %. [35]
Regarding the countries where changes are made by the contributors, the geographical distribution is also very inhomogeneous. About 75 % of the contributions in the course of a day are made in Europe, with a third of these for nodes inside the German borders. The next largest set of contributions is made in Russia, with about 8 % and North America with 7 %. [36] In Asia (without Russia), Africa, South America and Australia, which cover 2/3 of the earth’s land mass and are inhabited by more than 3/4 of the earth’s population, less than 10 % of the contributions are registered.
figure img/contributors.jpg
Figure 3.9 Contribution places of newest users [31]
Though significantly smaller than the number of users that have ever contributed to Wikipedia, there is a large group of people who have already contributed to the OpenStreetMap and an even larger number of registered users that seem to be interested in the project. The active and especially the inactive OpenStreetMap contributors could form an important target audience for cartography-related games.

3.2 Human-based Computation

figure img/Venn_02_2_HBC.png
Figure 3.10 Aspect 2: HBC
In the last chapter we have seen, how cartography has evolved over the centuries and how radically cartographic practice has changed in recent years due to technical progress. Cartographic tools like GPS receivers became not only cheap, but also wide spread due to the success of the smartphone, and the establishment of geographic information systems allowed the coordination and junction of massively distributed cartographic work even by amateurs, as the OpenStreetMap project has proven.
This kind of massive parallelization of work was only possible, because contributors were able to commit their changes into a repository of geodata that is managed by a computer. The idea behind human-based computation, which will be the topic of this chapter, goes beyond that separation of work between humans and computers: It integrates the human as a major part into computational processes that are practically impossible to be solved by computers alone.
In this chapter, a brief introduction in the human-based computation (HBC) technique will be given, where particular attention will be paid to the combination of HBC with modern crowdsourcing-approaches that are coordinated via the internet. Thereby it is of particular interest how tasks can be parallelized in a way that the contributors do not need to care or even know about the coordination and junction of their work.
Based on this knowledge, a general listing of possibilities to record, evaluate and integrate geodata in the context of human-based computation will be worked out, which will later form the basis for cartography-related games.

3.2.1 Human-based Computation

The core concept of human-based computation is the distribution of work between humans and computers, as best fits their specific abilities. Certain steps of an algorithm, that are hard or even impossible to solve for computers at the current state, are transferred to humans.
The reason why certain tasks are transferred from the computer to human operators is the current state of research in artificial intelligence. There are so called AI-complete tasks [38], that are almost impossible to solve for computers nowadays, but in many cases fairly easy for humans. Examples include the use of natural language, visual object recognition, but also more generic tasks like learning, reasoning or problem solving in general. Solving just one of these AI-complete task using computers only would imply that strong AI (artificial intelligence that is capable to compete with human intelligence) has been developed, which would be “equivalent to solving the entire AI problem” [38].
Sadly (or luckily?), artificial intelligence research, which was pursued with determination over the last 60 years, does not show significant signs that this change will happen in the near future. The problem that the knowledge about strong AI does currently not exist, is surpassed with human-based computation by using human intelligence and computing power to solve complex tasks, where computers are used to reduce the steps that need to be fulfilled by humans as far as possible to the AI-complete part of the problem. Roles of Human and Computer

In human-based computation, humans and computers can act in different roles: as innovators and evaluators (or selectors) [39]. When setting up these roles in a matrix, there are three different setups that involve human agents:
The fourth possible combination (computer as innovator and evaluator) is occupied by genetic algorithms, a technique where computers try to use the principle of evolution to improve algorithms and evaluate the results themselves. Due to its nature of not involving humans at all, it can hardly be considered as human-based computation technique.
At this point it should be clarified that not any task where human and computer use the role of innovator or evaluator is a human-based computation. A counter-example would be a common computer-game, where the human fulfills the role of the innovator and the computer evaluates the human actions by enforcing the game rules. A human-based computation is always a purposeful process that uses abilities of humans and computers in a planned algorithm to achieve a goal that is more than an end in it self.
On the other hand, there can be computer-games that meet these requirements, such as the so called games with a purpose, as will be discussed later in this thesis. Application Areas

Historically, human-based computation was a technique that was mainly used in computer science (e.g. in the environment of genetic algorithms), but since the triumphal sweep of social media it has become common in various areas. Regarding the three identified combinations of human and computer as innovator or evaluator, the application areas of human-based computation need to be split up respectively.
figure img/GalaxyZoo-8.png
(a) Galaxy Zoo [41]

figure img/Recaptcha.png
(b) ReCAPTCHA [42]
Figure 3.11 Applications of HBC
The human as innovator / computer as evaluator setup is a useful way to extract knowledge from or use the abilities of many human individuals under similar circumstances. A classical application would require the human agent to fulfill an AI-complete task, such as describing image contents, as part of a computer program he is using. The result of this computation could then be compared against the results of other users and the combined data could form the basis for new image recognition algorithms. This kind of human-based computation has become a common part of scientific studies and is used in web-based applications like captchas or projects where the public is invited to take part in human-based computations, like the online astronomy project Galaxy Zoo. [41]
The second combination (computer as innovator / human as evaluator) can be used to evaluate tasks that were done by computers only. Due to the fact that there is currently no strong AI, the real innovations a computer could create are very limited. This implies the understanding of “real innovation” as innovation that was computed without falling back to predefined results (or the mere combination of those). Still, there are some areas where computers are able to produce acceptable results in a limited amount of time, like optical character recognition (OCR). In general, this setup can be used to train artificial neuronal networks, which enable computers to work with complex relationships between inputs and outputs, like between the image-representation and the actual meaning of characters in the case of OCR. Another application is the concept of interactive genetic algorithms, where computers refine existing algorithms, using long heuristically enhanced trial-and-error procedures, and a human evaluator has the task to guide this process, thereby enhancing the heuristics used by the computer.
Having humans as both innovator and evaluator brings up the question, if this can be considered as human-based computation at all, if all the work is done by humans. Considering the above definition it can, if the work fulfilled by human agents has a real purpose and is part of an algorithm, that is controlled by a computer program. Where to draw the line here might be an interesting question, that will not be answered in this thesis. Is a wiki software a human-based computation framework, or is the wiki just a neutral platform for humans to work with each other? The same question could be asked for a social search platform like Reddit, or the collaborative cartography project OpenStreetMap. The common denominator is the infrastructure provided by a computer, which is mandatory for the human innovation and evaluation to work in the context of the task.
Nevertheless, the three general types of human-based computation that were identified in the last section should only be regarded as basic principles, mixtures and variations are possible and common in many cases.

3.2.2 Crowdsourcing

Human-based computation does only attain its fill potential, if it is done in parallel by a large group of people. Organizing (and paying) these masses of people in classic enterprise structures is not very efficient. With the rise of the web 2.0 a new, much more decentralized organizational form has emerged: Crowdsourcing.
Crowdsourcing is a process of problem solving by a distributed group of people that is not specified through a centralized organizational form, such as the employees of an enterprise. The task is usually given to an undefined public and often fulfilled by anonymous contributors.
Though there are several historical examples for crowdsourcing in a smaller scale, it is the combination of crowdsourcing and human-based computation via the internet that made it possible to manage contributions of millions of people. Classification of Crowdsourced Tasks

There are several distinguishable areas where the definition of crowdsourcing can be applied:
Besides these application areas it is also important to differentiate the way in which users contribute. Apart from the classic conscious contribution there are also ways where people add to a project though they do not even necessarily know if or how they are doing so. This way of contributing, sometimes referred to as implicit crowdsourcing has also become common with the dawn of social media.
Examples include the automated image recognition developed by Facebook, that relies on the image labels contributed by millions of users, or the Google search engine that is among other factors enhanced by analyzing the user’s search history and choice of search results. But here as well, the frontiers are fluent. Accessing the Crowd

With the steady rise of the social web, more and more ways are discovered to transform the time users spend on the internet into work. The combination of human-based computation and crowdsourcing is an important step in solving AI-complete tasks and the development of strong AI.
Through massive parallelization, such tasks can be solved even for large amounts of data. But winning a fair amount of people for one’s own cause is not always easy and therefore a paramount step in the planning of any human-based computation project that relies on crowdsourcing is how to create incentives for the crowd to participate.
Currently there are three major techniques recognizable, how human-based computation projects gain their user inputs:

3.2.3 Cartography-related HBC

Which of the possibilities considered throughout the chapter Human-based Computation↑ can be applied to collect and evaluate geodata in the course of a crowdsourced human-based computation? The following section shall give an overview and classification of the possibilities in the area of cartography and a small outlook of what will be the core of the further considerations. Applicable Types of HBC

At first, the types of HBC, as defined in↑, that come into question should be regarded. HBC was divided into three general types, which included humans and computers in different combination in the roles of innovator and evaluator. For all of these, cartography-related computations can be discovered.
Human  →  Computer
The human as innovator / computer as evaluator setup can be used in two general cases:
  1. when the computer has the power to decide by himself, if a human contribution is valid or not.
  2. when there are redundant human contributions on the same topic and the computer can decide, based on the other contributions, if a new contribution is likely to be valid or not.
The first approach is, due to the lack of strong AI and the extremely limited possibilities for computers to double check the semantic meaning of geographic facts, virtually bound to syntactic checks and the testing of predefined exclusion criteria.
The checks for syntactic correctness and basic semantic criteria are usually done by the map editor of choice, but in any case by the GIS before accepting any contribution, because invalid data would corrupt the whole database. Correctness is enforced by validating syntactic correctness and the absence of obvious semantic errors. Syntactic correctness does only affect the formal language the contribution is written in and is checked by a regular parser for the given language. Semantic errors, like open polygons that are declared as buildings or nodes of a road that are defined as part of a river, can be discovered in a specialized semantic analysis of the contribution.
Besides these basic rules that are fast and easy to enforce, there are more complex graph algorithms that could discover suspicious and semantically invalid geodata. Among invalid data that could be discovered are roads that intersect at ground level without having a common node, rivers that intersect other rivers or buildings that are placed on top of each other. Suspicious geodata could be found by setting up rules like “no amenity on the same ground level must be within a radius of 5 meters of another amenity” or “there must be no building with a base area of less than 10 m2”. Objects that break these rules could be individually reviewed by contributors and than be corrected or confirmed and excluded from further review.
Just regarding the road example from above it gets clear, why these checks can not be done before accepting the contribution: The algorithms that make these checks require access to data that is not necessarily included in the contribution and some of them are considered NP-complete, which makes it impossible for the computer to run them on every update. Also, some checks require individual review and cannot be used to generally reject contributions without spawning false positives (and therefore the envy of the contributors).
The second possibility, comparing redundant human contributions, is an interesting way to deal with data from insecure sources, especially from anonymous contributors, and to rate data quality in general. The goal of this rating is not to accept or reject contributions from the start, but to give a probability, based on other contributions or user reviews to deny or confirm existing geodata.
This would make it possible to enable user contributions with hardly any restrictions, like adding a POI as anonymous user with a click of a button, which would then first need to be verified by other users, before being accepted as valid. Another example could be a quality measurement of roads, based on anonymous data sent from a navigation device, which would compare the course of the road in the GIS to the actual path the navigation device has recorded. The creator of a map based on this possibly insecure geodata could then define filter settings for anonymous contributions, which would only be included if they reach a certain quality grade.
Allowing large-scale, possibly anonymous and easy to use contribution systems is an important step in encouraging masses of people to take part in a HBC project.
Computer  →  Human
The computer as innovator, with humans as evaluators, is also a setup with very limited possibilities on the side of the computer, as it is unable to go out and collect geodata by itself. Also, due to the lack of strong AI, an effective analysis of digitized images of the world is currently not possible, though there has been progress in this area.
Optical character recognition has improved drastically over the past years and Google managed to further improve it with the help of Recaptcha, a human-based computation system that lets humans type unrecognized words from scanned books. [42] Only recently, images of house numbers and signs with road names, extracted from Google’s street view, appeared in the Recaptcha service. [43]
Taking this idea into more general terms: It is possible to automatically extract valuable information from images taken on ground (like house numbers, street names, etc.) or even to trace certain features of satellite images.
In case of the aerial imagery setup, the computer would try to extract as much information from the images as possible, like the course of roads and rivers, coastlines and any other structures with sharp enough features. To train the algorithm that provides this data, the computer can fall back on huge high-quality geodata, as large parts of the world, where aerial imagery is available, are already mapped. If the algorithms are developed far enough so that new geodata can be extracted from aerial imagery, the results could be presented to human evaluators, which can then decide if it is accurate enough or even improve it manually.
Taking the ground images in account, the roles of innovator and evaluator are changing more often. It is not known, if the image parts that are delivered to Recaptcha were extracted by the computer or manually by Google’s employees. Anyway, the house numbers or street names need to be solved by humans, so here the role of the innovator switches to the human. Afterward, the final results (the house numbers in the GIS) need to be checked by humans too, so here the role of the evaluator applies again. The computer part would include the finding of the signs in the imagery (if possible) and the correct placement of the results in the GIS.
All in all, the setting with the computer as innovator in the area of cartography is still very limited, but even without the existence of strong AI, the possibilities to extract geodata from imagery are increasing.
Human Human
The humans as both innovator and selector is currently the most promising setting and the main technique that is used by large crowdsourced projects like Wikipedia or the OpenStreetMap.
The possibilities for humans to collect geodata are only restricted by the laws of physics (and property), and due to the fact that humans are living all over the world, there is always someone with local knowledge that could provide useful information. Travelers can record their tracks with GPS devices and home users can use their local knowledge or images as data sources.
Evaluation of data is also an easy task for people with local knowledge and semantic errors that are not easy to detect by computers are obvious for humans when looking at a map that results of faulty geodata.
The real obstacles in this situation is the global digital divide, which is the expression of limited access to information and communication technology in large parts of the world, and of course the prominence of the projects that are collecting geodata among the inhabitants of the world, as well as their will to participate, once they know of it.
In conclusion, the human as both innovator and evaluator setting is currently still the most promising, as various crowdsourced open data projects proven, but wherever it is possible and reasonable, it is a good idea to let the computer take over some work to give the human contributors more time to do the important task, that computers will not be able to do for a long time: going out and collecting new geodata. Applicable Areas of Crowdsourcing

In the chapter Crowdsourcing↑, there were five distinguishable areas described, where crowdsourcing could be successfully applied: wisdom, work, ideas, financing, voting.
The crowdsourced collecting of geodata is, of course, all about the wisdom of the crowd. It is an open call to the public to submit their local knowledge and their wisdom about any place on earth under a free license to a project like the OpenStreetMap, so the public may benefit of it. The only other type of crowdsourcing, that could directly apply to any cartographic HBC is voting. When evaluating the accuracy and validity of submitted geodata, the opinion of the crowd on each of these submissions is an important factor when measuring data quality.
For the organizations that stand behind these projects, also the other types of crowdsourcing become more relevant. Crowdfunding is an important source of income, seeing that private donations and corporate sponsorship make up for most of the OpenStreetMap Foundation’s income. [16] As projects like Wikipedia or the OpenStreetMap are not structured hierarchically, new ideas and technical improvements do often come from the crowd. Important decisions are always discussed in public and very controversial topics can result in a binding vote among all contributors, as the debate about the recent license change in the OpenStreetMap community has shown. [17]
Though for the cartographic process only the wisdom and the opinion of the crowd about other contributions is of major relevance, the projects themselves have need of all the power of the crowd. Applicable General User-input Motivations

Among the topics discussed in the Crowdsourcing↑-chapter were also general ideas, how human-based computation projects get input from the crowd. All of these can be addressed by cartography-related HBC, as will be shown in the following.
Just watching the mappers contributing new or improving existing geodata does not add any value, but there is some important information that can be derived from the already available data and the history of commits. On the one hand, the existing geodata can be used to improve algorithms that extract geodata from satellite images or other image sources, by feeding neuronal networks with the existing data and providing a good reference to compare computer-generated results. On the other hand, the history of commits can be used to measure data quality. Regions, where all geodata comes from a single source, tend to have less coverage and detail, whereas areas where many contributions from different sources exist, that correct and complement each other, usually are more reliable. Though this kind of rating is not always dependable, it can give hints in which regions geodata should be verified and where it might already be of high quality.
Forcing the users to contribute to the project does not seem to be a very prudent way, but Recaptcha has shown that there are use cases where it is important to force a user to do something in order to ensure that he is human, and if that work serves a good purpose, it’s only for the better. A similar approach is also conceivable for basic cartographic tasks. The user could be confronted with a small test, where he has to fulfill the human part of a HCB-task that can be resolved in a couple of seconds and where he does not need any local knowledge or cartographic background. As in Recaptcha, the correct solution would be determined by comparing the results of different users that solved the same puzzle, and by adding at least two independent tasks where the solution to one task is already known by the system. A possible test could be an aerial image, where the user has to mark the position of five buildings with the mouse. If he hits enough spots that are near to the position where other users have marked the buildings, the result is accepted. The combined results of a certain amount of different users could then be added to the GIS. Of course there are dangers to consider like low quality inputs of many users or the wrath of annoyed hackers (as Recaptcha also had to face only recently [44]), but this is already getting too far away from the topic of this thesis.
The third possibility, giving the contributors a reason to do it for free, appears to be the most promising of the three. Free and voluntary contributions are the driving force behind the largest open data projects of the world. There are various ways of working with voluntary contributors and in the following chapter 4↓ Cartography-games↓, these will be analyzed in detail.

3.3 Human-based Computation Games

figure img/Venn_02_3_Games.png
Figure 3.12 Aspect 3: Games
Looking at the aspect diagram that has accompanied us throughout this chapter, the next logical step would be to treat games in general. Unfortunately, writing a whole chapter about game theory and game design in general would go far beyond the scope of this thesis, and as we can only rely on games that can be played in the context of human-based computation, this will be instead the main focus of the following chapter. But nevertheless, also a basic introduction into game design will be given, to be able to classify the type of games that will be elaborated.

3.3.1 Definition

A human-based computation game is any game or gameful task, that solves, in its course, the human part of a human-based computation.
The idea of human-based computation games is to use the time people spend playing games to let them solve problems, that are part of a human-based computation, as natural part of the game. In a good HBC-game, the player does not need to know anything about the computational background. The game should be designed in a way that the game rules and victory conditions encourage the players to find the correct solutions on their own.

3.3.2 Possible Gaming Concepts

The above definition of human-based computation games distinguishes between games and gameful tasks in the context of human-based computation. Gameful tasks can not be considered as real games, as they are regular work that has been brought into a gameful context. The process of adding game design elements to a task is called Gamification [46]. Regular games that have been altered to support a human-based computation or even especially designed to serve a specific HBC, are referred to as Games with a purpose or short GWAPs. [47] Gamification

The human part of human-based computations is often not appealing to volunteers, which is rooted in the design of many common HBCs. They often require humans to repetitively fulfill AI-hard tasks like object recognition in images, which is not particularly difficult, but after a time it can get terribly boring and tiring.
A good definition of Gamification says: “Gamification is the use of game design elements in non-game contexts” [46], which, in the case of human-based computation, could be used to design them more pleasantly for humans and to give new incentives to participate.
Gamification does not turn any task into a game, it rather makes use of certain game design patterns like time constraints or leader boards that appeal to certain wants of the player, as competition or social recognition. A more detailed view on these game design patterns will be given in the following Common Design Criteria↓. Games with a Purpose

Games with a purpose, in contrast to gamified tasks, are created the other way around: Either there is already a known game and a human-based computation is included in it, or a new game is created that can be integrated into a specific human-based computation.
So basically there are two conditions for a GWAP: It has to a real game that could also be played in another context, and a human-based computation must be solved by the players in the course the game.
Examples include the ESP Game [48], where players are describing image contents in a competitive situation, or ARTigo [50], a game that enhances in its course a semantic search engine for art history.
The design of GWAPs will be regarded in more detail after the following discussion of common design criteria for human-based computation games.

3.3.3 Common Design Criteria

What makes a good game? How do I get players to participate in one? And what is a “game” anyways?
These are just some questions that should best be considered before starting to design a game, especially in the case of human-based computation games, where the attention of the creator might be focused a bit too much on the computational part (which is already hard enough to solve).
Unfortunately, at this point we are leaving the area of scientific consensus. Though people have been playing games since the dawn of mankind, the research of game design in scientific terms is rather young and has not led to many commonly accepted results.
The following ideas and descriptions shall be regarded as an attempt to accumulate some notable results of current research on playful experience, gameful design and game design elements. After that, two sections are dedicated to human-based computation games in specific. Here even more, literature is rare and therefore most of the considerations are own work based on general assumptions about game design and human perception of games. Game and Play

For the following considerations, it is important to distinguish between the terms game and play. According to the definition of Caillois [53], they can be arranged between two opposite poles. On the one end there is “paida”, or play, where an “almost indivisible principle, common to diversion, turbulence, free improvisation, and carefree gaiety is dominant”. On the other however stands “ludus”, the game, where “arbitrary, imperative and purposely tedious conventions” are in place and a “greater amount of effort, patience, skill or ingenuity” is required.
Both definitions describe extremes that usually do not occur in their pure form, but instead it shows that most of the activities we know as game or play contain elements from both extremes, ludus and paida.
Therefore, the following sections will give a brief insight in the essentials of playing and gaming. Playful Experiences

What kind of experiences does the player undergo during play, which does he seek, which does he avoid and which of these are needed to create an overall playful user experience? These elementary questions of user experience research are still surprisingly poorly answered and interpretative approaches are varying widely. This is partly founded in the huge variety of how people define and experience abstract concepts like fun and pleasure [54], as well as the complexity of human perception itself.
An approach to systematically collect playful experiences between the poles of ludus and paida is the pleasurable experience framework [55] by Costello and Edmonds, which was further enhanced and evaluated by Korhonen et. al. [54]. The categories they used in their research are listed in table 3.1↓.
In an experiment, they questioned players of three current commercially successful video games about their experiences while playing, and surprisingly it turned out that all 20 categories were covered by the three games taken together, with no game covering less than 16 of them. A notable result, considering categories like eroticism, subversion or even sadism.
Though the results are promising, the researchers also had to admit, that “the deeper [they] have looked into playful experiences, the richer the landscape has turned out to be” and that there are already new categories under consideration, namely disgust, humor, cuteness, identification, and tragedy. Regarding how easy the list could be expanded by adding any experiences that humans could have during play, this inevitably lead to the question, whether “playful experiences [are] any more finite than the group of human experiences?”.
The pleasurable experience framework is based purely on observation and Korhonen et. al. noted that any categorization will always remain a “somewhat arbitrary construction as a design and evaluation metaphor”, as long as it is not founded on psychological grounds.
Nevertheless, the current list of categories, though not psychologically founded, can give a good basic impression, which playful experiences are addressed by successful contemporary games and show a general direction, which human desires should be considered when designing games or playful user experiences.
# Category Description
1 Captivation Experience of forgetting one’s surroundings
2 Challenge Experience of having to develop and exercise skills in a challenging situation
3 Competition Experience of victory-oriented competition against oneself, opponent or system
4 Completion Experience of completion, finishing and closure, in relation to an earlier task or tension
5 Control Experience of power, mastery, control or virtuosity
6 Discovery Experience of discovering a new solution, place or property
7 Eroticism Experience of sexual pleasure or arousal
8 Exploration Experience of exploring or investigating a world, affordance, puzzle or situation
9 Expression Experience of creating something or expressing oneself in a creative fashion
10 Fantasy Experience of make-believe involving fantastical narratives, worlds or characters
11 Fellowship Experience of friendship, fellowship, communality or intimacy
12 Nurture Experience of nurturing, grooming or caretaking
13 Relaxation Experience of unwinding, relaxation or stress relief. Calmness during play
14 Sadism Experience of destruction and exerting power over others
15 Sensation Meaningful sensory experience
16 Simulation Experience of perceiving a representation of everyday life
17 Subversion Experience of breaking social roles, rules and norms
18 Suffering Experience of frustration, anger, boredom and disappointment typical to playing
19 Sympathy Experience of sharing emotional feelings
20 Thrill Experience of thrill derived from an actual or perceived danger or risk
Table 3.1 Definitions of PLEX Framework categories [54] Gameful Design

After looking into the complex experiences humans undergo during any kind of play, the next question is: what does really make a game? How can a game or ludus be distinguished from play in the sense of paida?
To answer this question, McGonigal [56] describes the “four defining traits of a game”:
This definition does not go into typical game design elements that enhance the game experience, like competition, rewards or teamplay (see \hyperref[sub:Game-elements]next section), but merely defines a set of features that is absolutely required to make a game.
McGonigal further states, that game and work are not two opposing extremes, but in the contrary, that games often consist of the hardest work, artificially complicated through a set of rules that all players agreed on voluntarily. During gameplay, the players concentrate their attention and energy on a specific goal, finding creative solutions for made-up obstacles, which have been placed just to increase the challenge. This observation is of particular interest in our case of human-based computation games, where the obvious question might be “who would want to work while playing?”. The better question would be: “Is the work really challenging enough, to make a good game?”.
On the other hand, McGonigal observed that the “freedom to work in the most logical and efficient way possible is the very opposite of gameplay” [56], which seems to stand in the way of typical human-based computation tasks. But adding additional rules and goals, which make the task even harder to solve, does not necessarily make the human-based computation less efficient. In the contrary, as soon as participants feel challenged and spend more time voluntarily on the game, the project as a whole benefits, even if individual contributors could work more efficiently. Game Elements

Knowing what essential parts make a game, this chapter shall be about game elements, which should be seen as “a set of building blocks or features shared by games (rather than a set of necessary conditions for a game)” [46]. As in the case of playful experiences, good game elements are hard to describe and categorize comprehensively and they differ even more from genre to genre, so the following will be more of a heuristic approach to identify relevant game characteristics.
Deterding et. al. [46] propose a system of different abstraction levels for game design elements, ordered from concrete to abstract:
On the most concrete level, there are the interface design patterns, which describe “common, successful interaction design components and design solutions for a known problem in a context, including prototypical implementations”. Typical elements would be points, levels, badges, achievements, leaderboards, rewards, bonuses and player status updates. Interface design patterns are easy to add, not only to games, but to almost every application (whether this be useful or not) and there is a growing supply of meta-gaming platforms like Steamworks [60] that allow developers to integrate achievement and reward systems into their games.
Game design patterns are concerned with reoccurring parts of the gameplay that can enhance the gameful experience. These could be time constraints, appointments (players have to come back after a while), infinite gameplay, cascading information (give the player only the necessary information he needs at a time), limited resources, turns, combos, discovery (do not reveal the whole world at the start), lottery, ownership, quests, challenges. The patterns need to be well integrated into the game design, so it is best practice to decide already in the design phase, which patterns are to be applied.
Game design principles are general hints, how a well-designed game should work or appear to the user. They are more general guidelines than concrete design solutions. Some proven principles include community collaboration, meaningful storyline, consistent reality logic, clear goals, variety of game styles, enduring play, blissful productivity.
Game models are abstract descriptions of game components or perceived game experiences, as were already discussed in the \hyperref[sub:Playful-experiences]playful experiences-chapter. Here even more, a comprehensive categorization seems impossible, as game designers have not managed to agree on certain core components of good game design. There are some formal approaches to this topic like the MDA framework [61], but in general they describe abstract impressions the player has during gameplay, like challenge, curiosity or joy, that cannot be easily produces by a certain set of design patterns.
Game design methods, at the lowest level, are an abstraction to game design itself. They describe “game design-specific practices and processes”, like playtesting, playcentric design or value conscious game design. As this topic would definitely go beyond the scope of this thesis, the interested reader shall be pointed to third party literature [62].
A further insight into the examples, where not directly quoted, can be found in the Gamification Wiki [63], run by the startup Gamify Inc., and in the works of Staffan Björk [64, 65].
This short overview of game design elements is not meant to be a manual on how to create the best game, following the “more is better”-principle. In fact, many of the design elements are even mutually exclusive and a combination of too many templates can lead to confusion and harm the design. But this set of well-established design patterns and principles can help to enhance the gameful experience in any game or gamified application. Incentives for Participation

In the special case of human-based computation games, there are also other important incentives for participation besides the experience of gameplay. Though von Ahn stated, that people play such games not because they are “personally interested in solving an instance of a computational problem but because they wish to be entertained” [47], there are application areas where the purpose might drive more people into participating than the sole game experience. So for human-based computation games, there are at least four additional incentives that need to be considered:
The Higher Purpose
Every human-based computation serves a higher purpose, and if this purpose is known to the user and of relevance to him, this might change the way how he perceives the game in this context and provide additional motivation to participate.
So an important motivation is the voluntary support of a “good cause” by playing the game. The online puzzle game Foldit [57] for example is a human-based computation game about protein folding, that asks its users to “solve puzzles for science” [58]. Protein structure prediction, which is the ultimate goal of the game, is a key factor for the development of new treatments for serious diseases.
This goes hand in hand with the human desire to improve something others can benefit from. The whole free software movement is based on the idea to be able to improve and share the work others have started, but voluntary work in general is not only based on the idea to help temporarily, but also to improve conditions in the long term.
Receiving a fair share of the result can be another motivating factor. More conceivable than any fire-and-forget contribution is work that has a direct result where the contributor himself can benefit from. This implements the idea of the feedback system, which is one of the four pillars of any game, that is often underrepresented in human-based computations. A good example would be a contribution to the OpenStreetMap: Any changes are visible after a few hours in the most popular maps based on the OpenStreetMap GIS and after the next update on many navigation devices, directly influencing the calculation of routes that are proposed by these devices.
Finally, satisfaction through completion gets a much higher value, when the results of the game do have an actual impact on the world. A sense of completion is of course only possible, if feedback is given to the contributor, be it as visible real-world result or just in the form of points and badges.
Social Exchange
Most successful games require some form of social interaction, but especially with crowdsourced human-based computation games, the social exchange between players gets even more relevance, as it can help to bind participants in the long term.
The latest GWAP from Louis von Ahn, duolingo [59], is an excellent example for this thesis, because it is chop full of social features. Duolingo offers a free platform to learn a new language, where users are translating parts of the web and thereby learning the language of the websites they are translating. While they are translating, the users are able to communicate with others that are learning the same language. They can share their progress and help others with their efforts.
These social features are enabling the players to share their knowledge with others and learn from other players as well. This kind of mutual help and exchange in the community can greatly enhance the in-game process of the players and helps to avoid situations where players get frustrated and simply give up playing.
As the players advance in the game, they get more and more recognized by other players and as in any community, a feeling of social commitment towards people they got to know arises. This binds the player further to the community and therefore the game.
Participating in a human-based computation game can unite the players in a community of people with a shared interest, like a club or association. In a time of increasing alienation, especially in urban regions, people are searching for contact with like minded people and the casual atmosphere of a game eases this first contact. More experienced players can introduce the newcomers and the whole community, as well as the project, benefits.
McGonigal puts this into context the following way: “Compared with games, reality is disconnected. Games build stronger bonds and lead to more active social networks.” [56]
Solving tasks that require some form of creativity is more appealing to humans, and same counts for playing games. Demanding creative solutions from players is an important design principle for games. In the case of human-based computation games, creative solutions of players are of great value, as they often do not only last for the game, but also have a real-world impact.
So, the solving of creative tasks is an enjoyable playful experience, but in HBC-games it is also the own creative footprint, that can further encourage players to make a special effort. The knowledge, that the own creative work will influence the final result, can be an obstacle for players that fear the judgment of the public, but it can also work as an additional motivating factor.
In any case, it should always be in the power of the player not to share the own work at the end of the game, to decrease possible pressure to perform. A human-based computation game should always maintain the casual atmosphere of any other game that has no further impact on the real world.
Paying someone just to play a game does not seem to make too much sense under normal circumstances. If the game however is more than just the gameful experience for its players, like when sponsorship agreements are involved or, as in our case, the game also solves computational problems, then compensations for players become conceivable.
Especially in the case of human-based computation games, this measure would probably raise the question, if the game design does have some serious flaws, assuming that players would only want to participate when they get paid. But throwing money at that problem is at least a short-term solution. In the long term however, it should be closely examined if a game is a reasonable way to solve the specific computation. If the players need to be paid anyway, they could also be paid to solve the computation without the game context, that way probably even faster. Ensuring Data Validity

A special problem of human-based computation games, as opposed to regular games, is to ensure data validity. The players are solving the human part of a computational problem during the game, and therefore it is important that they are solving it right, no matter if they win or lose, if they are bored or motivated, even if they are willingly trying to manipulate the game.
The basic idea is that the game rules should lead the players in a direction so they solve their tasks correctly. Correct solutions should be rewarded by the game, creating a competition for the best possible solution. Invalid solutions must be recognized, rejected and punished in some form that does not infringe the players, but gives guidelines how to do it right and encourages them to try it another way. Louis von Ahn described this by demanding, that the game rules and winning conditions are defined “in a way that [it] is in the players’ best interest to perform the intended computation.” [47]
Three major components of this solution should be regarded in detail:
First, the guidance of the players throughout the game. For game designers it is common knowledge that “most gamers never read game manuals” [56], which leads to the question how to prevent players from failing in the first place. McGonigal states that “a well designed game should be playable immediately, with no instruction whatsoever.” [56] This principle is being applied in almost every current computer game by either providing a initial learning phase (the tutorial) or increasingly by making the learning phase not a separate, but an integral part of the game itself. For human-based computation games, this learning phase should ensure in particular, that the players have all the knowledge they need to solve the computations correctly.
The second aspect concerns the recognition of incorrect solutions. The recognition process depends highly on the specific task that is being solved, but in general there are two nonexclusive ways to approach this problem: a plausibility check, done by the computer, and the comparison of multiple results. As the computer is unable to solve the human part of the computation, it is of course also impossible to definitely decide if the result is correct, but usually there are certain criteria that a correct solution must fulfill. So the plausibility check can help to eliminate solutions that cannot possibly be right in the first place. This first computerized filter process helps with the second approach, the comparison of results. As soon as a minimum of plausible solutions to a specific task is available, the distinct results of different players can be compared and extreme deviations can be sorted out, leaving the solution of the majority of the players as the most likely correct solution. This approach has already been successfully implemented by Recaptcha. [42]
But most important, by all means of trying to make the players better at solving computational problems and to ensure data validity, it needs to be ensured that the game remains fun to play. Bored or annoyed players are the death of any game and especially with human-based computation games, even a minority of annoyed players can deal serious damage to the whole project. Players that actively try to break the game can cause the acceptance of false solutions by feeding the computer with plausible, but incorrect answers, and as part of team games they can corrupt the game for all players by breaking the rules or sabotaging others.
So, designing a human-based computation that leads to valid results is an important step, but if the game is in the end not anymore appealing to the players, all the effort was meaningless.

3.3.4 Game Design

To implementing the insights of the last chapter, we will now take a deeper look at the previously described game concepts and show, how the ideas of playful experience and gameful design can be applied to concrete forms of human-based computation games. Gamification

Gamification is “the use of game design elements in non-game contexts” [46], so basically any application can be gamified. Still, it is important to keep in mind that people are not going to “play” gamified applications; this kind of participation is reserved for “real” games. People that will contribute to a gamified human-based computation are those that would want to participate in the project to support its goal, but have higher demands concerning the user experience while participating.
In order to gamify an application (or to build a new gamified application), the designer should try to turn the task as much into a game as possible. Using McGonigal’s “defining traits of a game” [56], three of the four traits are relatively easy to accomplish: every task is oriented towards a goal, so that is already given and should only be clarified, if necessary. Voluntary participation can also be assumed, if participants are not paid or attracted with other forms of compensation to take part in the project. Building an appealing feedback system is a more creative task that requires some skills in user interface design, as well as human-computer interaction, but as the task is goal-oriented, it should definitely be possible to visualize the user’s progress in some form.
The rules are the only missing part that could already make a game out of the application, but in this point gamified applications differ from regular games: Rules are limitations and unnecessary obstacles that the players of a game agreed on, to make the task more challenging. This consequently implies a decrease in efficiency, which, in the case of gamified applications, would be counterproductive. As already mentioned, gamified applications are not meant to be played, they are regular tasks users want to fulfill as efficiently as possible. Any kind of gameful experience would just add to the overall comfort while using the application, but restricting it with rules would in most cases lead to an unwanted decrease in productivity.
To create a gamified application, the common design criteria that were described in chapter 3.3.3↑ can be applied: Cover as many playful experiences as possible, use game design elements where appropriate, think of ways to ensure data validity and always remember, that people are using gamified application as tools for the solution of a task, not as full-fledged games.
Gamified applications are getting more and more common today. Especially for smartphones, there are numerous apps that encourage people to do sports and share their results with their friends in social networks. There is gamified hardware that incites people to recycle glass waste [66] and there is a gamified online platform where people can find a new job [67].
Gamified applications are generating a great deal of interest and they have the potential to change the way we do our everyday work. Games with a Purpose

Games with a purpose, as opposed to gamified applications, are full-fledged games with the “design goal of designing for gamefulness” [46]. GWAPs should appeal to players even if they don’t know anything about the computational background.
Louis von Ahn describes three “game-structure templates that generalize successful instances of human computation games”: [47]
All of these game types have in common, that they provide descriptive content about certain inputs that the computer cannot generate, and they implement a mechanism that ensures data validity as described in↑.
Furthermore, all games mentioned as examples fulfill the definition of games from McGonigal [56] and implement many common game elements as described in↑, like leaderboards, bonus rounds or time constraints. Also, many of the games refer to the special incentives that were discovered in section↑ by providing background information about the purpose of the human-based computation or by adding social features that allow the players to communicate during the game or make communication between players an integral component of the game.
All in all, games with a purpose offer a promising implementation of the human-based computation game concept, where the gameful experience for the players stands in the foreground and the integration of the computational part in the game is a non-trivial but nevertheless interesting problem for the game designers.

4 Cartography-games

Cartography-games are meant to be an easy and inciting way for anyone to participate in cartography-projects and thereby to contribute geographic data. The goal is to abstract the part of cartographic work that requires detailed background knowledge and provide a comprehensible interface so the participants can contribute valuable data as best fits their interests and abilities.
figure img/Venn_03_Cartography-HBC-Games-Filled.png
Figure 4.1 Cartography-games
To create this interface for the participants, the knowledge that was gathered in the last chapter about cartography, geographic information systems, human-based computation, crowdsourcing, game design, gamification and GWAPs will be combined.
In this chapter, the specifics of cartography-games will be addressed. It will be analyzed, which tasks can be fulfilled in cartography-games and which problems need to be considered in the game design. After the game concepts have been presented, the possible benefits of such cartography-games will be discussed and three exemplary game proposals will be portrayed.

4.1 Combination of Aspects

In chapter 3↑ we had a detailed insight in the three foundations that define the topic of this thesis. Cartography, human-based computation and games are the aspects that need to be combined in order to create games and gamified applications that can be used by masses of users to contribute to cartography-projects.
As was already shown in the Related Work↑, there are already some more or less far developed concepts that unite two of the aspects. There are human-based computations with the goal of collecting geodata, but they are no games. There are games that could be used to collect geodata, but they are not integrated into a systematic computational process that evaluates the results. And there are human-based computation games, probably the topic that is covered most in scientific terms, but they are not used to collect or evaluate geodata so far.
figure img/Venn_04_Cartography-HBC-Games-Arrows.png
Figure 4.2 Combination of aspects
Each of these combinations can be extended in a way that it reaches our desired three-way constellation, as presented by figure 4.2↑. Existing cartography-related human-based computations can be either gamified or a new GWAP can be specifically designed, which solves the human-based computation in its course. It is possible to integrate human-based computations into existing cartography-related games or to invent similar ones where the integration of the HBC is already considered in the design phase. And for existing types of human-based computation games, cartography-related application scenarios can be discovered.

4.2 Game Concept

What could a cartography-game look like? How could it even work? Becoming a professional cartographer requires at least an apprenticeship and there are whole courses of study dedicated to cartography, so how can a player with no background knowledge on cartographic work contribute valid results, without any introduction?
The OpenStreetMap↑ has shown that amateurs are well able to build up a world map that doesn’t have to hide behind its commercial competitors, but even there the contributors need to learn how to use their cartographic tools and study the internals of map making.
The solution is to give the most hard-to-accomplish and time consuming task, which luckily does not require any specific skills, to the crowd: Collecting and evaluating of geographic information. Gathering detailed information about any region in the world is an almost impossible task for a few professional cartographers (or a handful of dedicated amateurs), and checking if every piece of information is true and up to date even more. But for a distributed and globally active mass of people, who can use their local knowledge or gather information on-site it is relatively easy to produce valid data, each in his or her area.
The experts (or at least dedicated amateurs) on the other hand are still needed to watch over this process, to recognize systematical errors and to create and update complex cartographic structures that cannot be easily crowdsourced, as hardly any layperson could build a correct cartographic representation of a motorway junction or a public transportation system. Thereby, a symbiosis between power contributors and the crowd emerges.
This chapter will describe, what a cartography-game can accomplish, which tasks can be fulfilled by the crowd, which types of gameplay and game design are conceivable, who would participate and who can benefit most from detailed, free and open maps.

4.2.1 Game Goal

The goal of cartography-games (or gamified applications) is that users contribute, evaluate and update as much geographic information as possible, ideally by playing a GWAP which does not require any initial cartographic background, or by using gamified applications that encourage participants to continuously contribute and improve the database at any place they know or visit.
Real cartography-games require a good game design that is also appealing to players that are not concerned with cartography, therefore the goal of improving the GIS must step behind the game experience. Nevertheless, it is important to make the players aware of the goal to create further incentives for participation.
Gamified applications on the other hand are mainly directed at contributors that are in for the cause but like to use an appealing interface that encourages participation.
In the following, the majority of the considerations will be concentrated on games, rather than gamified applications. Nevertheless, most of the non-game specific parts are also applicable for gamified applications. So whenever the term “player” is used, it does in most cases also apply to the user of a gamified application.

4.2.2 Cartographic Work

Human-based computation games can open a complex task to a large group of contributors, but due to technical limitations and the goal to reach as much potential participants as possible, not any task can be solved in the course of a game. In this chapter, the cartographic tools that are available for many people will be listed, the common cartographic problems and their solution with special regard to games will be analyzed and based on these insights, a categorization of tasks that can be fulfilled by the players will be performed. Tools

The contributors can use a variety of the cartographic tools and strategies that were already described under Data Sources↑ in the OpenStreetMap↑-chapter. The smartphone will probably be the the most important tool to collect geodata on-site, as it allows to determine the exact position of its user via GPS and to take geotagged pictures (images that contain meta-information about the location where they have been taken). Besides, it serves as the ideal platform to play location-based games. To evaluate and correct data, it can already be sufficient to fall back on a combination of local knowledge and aerial imagery as memory support, without the need of being physically present at the concerning location. This opens the task to almost any platform that allows web access. Problems

During the game, the four cartographic problems that were described in chapter↑ (accuracy, coverage, actuality and neutrality) shall be solved by the players and participants on their own.
To achieve accuracy, it has to be ensured that the precision of the GPS device is sufficient and that the player knows, how and where exactly to capture the positioning data. The former can be solved technically by comparing the device’s identification against a database of known GPS receivers, the latter can be achieved by giving clear information on how to capture data (e.g. to capture the position of a store, the GPS device should be positioned near the front door under open sky).
Coverage is a goal that is not as easy to achieve, as two things need to be ensured: In a single region, all relevant information should be captured and evaluated, and for every region around the world there should be contributors that provide and evaluate data. To achieve high coverage in a region, there are certain application and game types conceivable, as long as enough players are available (for more detail, see next section). But finding participants around the world is a task that is not easy to accomplish, due to the limited access to modern information technology in wide parts of the world and the fact that non-technophiles are largely unaware of collaboratively edited cartography-projects. It will take time until the world is linked-up and it is the mission of cartography-projects like the OpenStreetMap to increase their global prominence.
Actuality is reached by comparing a portion of the current entries in the GIS or a resulting map that contains the relevant information against the area it shows. For areas where only basic information is available, actuality is not an issue, as a minimum of coverage needs to be achieved first. But in regions where a certain stock of geodata is available, it is important to ensure that the data is updated regularly. Currently, the contributors of the OpenStreetMap update map entries when they learn about changes, either through the news, by visiting places or just by chance, or when they edit a whole area using pen and paper and a GPS device. Games can systematize this update routine by telling the players where to look out for which kind of changes. A detailed look on concrete techniques how this can be achieved will be given in the following chapter Realization↓.
Finally, neutrality needs to be ensured, to guarantee that data is not removed or added on purpose, e.g. to serve the cause of a specific party. For cartography-games, breaking neutrality is not easy to accomplish, as the games have built-in mechanisms that should ensure data validity to a certain degree (see↑). If individual players want to manipulate geodata, they have to prevail against the other participants, which can only be accomplished if the neutral contributors are a small minority in a certain region. But even if only a single contributor sees that the map has been distorted, he can bring this topic up in the mapper-community. The revision control system of the GIS allows it to revoke any suspicious changes and to exclude the contributors that made these changes, as well as to reverse all the other changes they made. As long as the overall mapper-community favors a neutral point of view, there is only a single person in a region required which can inform the community about abuses. Thereby, even large groups of influencers can be stopped, provided that individuals are safe to speak freely about the manipulations. Tasks

The last section described, which cartographic problems are to be solved in the course of a cartography-game. How the players of a game can actually solve these problems and which techniques will lead to valid geodata shall be the topic of this section.
Collecting new geodata is the only way to solve the coverage-problem, but to determine if coverage of a topic for a certain area is achieved, additional evaluative measures must be done. Therefore, a player’s task to collect new geodata must always contain a feedback channel that allows the player to report on the status of coverage. So after each session of collecting new geodata on a certain topic, the player should at least estimate, if the concerning area is completely covered, partly covered or if there is no data at all to be collected on the topic.
The quest to collect new data should always be limited to a certain area, which allows the player to plan his choice of tools and again, makes qualitative information about coverage more useful. An abstract task description for a player could be: “Find all {POI} in {area} that are not marked on the map”. The coverage of certain POIs in the world could then be determined on a meta-level by analyzing the feedback information and the computer could decide in which areas an increase of coverage is most urgent. The game could then create incentives for the coverage of such areas with special rewards for the players.
In more general terms, rewards that depend on coverage can highly increase the motivation of players to search thoroughly. If players that find new POIs in areas with very high coverage or players who are the first to submit data in areas with very low coverage are exceptionally rewarded, this may arouse the spirit of discovery in them. Of course, this kind of task is not limited to POIs, but applies to all kind of geodata that is supported by the GIS.
There are numerous possibilities to collect new geodata, be it at home or underway. As part of a game, everyone with a GPS device can collect new data on-site, travelers can record and submit GPS logs of their journeys using a gamified application, tourists can contribute geotagged images of sights. Home users can play browser games where new geodata is extracted from their local knowledge, combined with aerial imagery or geotagged images.
To ensure the validity of geodata, there is a systematic approach necessary to evaluate the submitted data. To do this, two basic concepts are possible: some form of user rating over the submitted data or redundant submission of data by different players, as known from the output-agreement game.
In a game where several players are competing against each other in a certain area to collect new data, the redundant approach can be very useful, as different players can get the same task to fulfill. Data sets which differ significantly between each player can be rejected and players that submit data which differs in too many cases from the majority of players will be less rewarded by the game. Also, their future submissions will gain less weight compared to those of the other players.
The other option would be the rating approach, where players are asked to give their opinion about already existing geodata. The decision process should enable the player at least to say, if the specified data is correct, totally wrong, incomplete or just imprecise. Depending on the context where this kind of evaluation is asked from the player, the application could also give the player the option to correct the wrong information, instead of just rating it and waiting for someone else to fix it. Integrated clear and easy methods on how to fix errors that were found should generally be preferred over more detailed error reporting techniques.
The evaluation of geodata by the players is a solution to measure at least the problems coverage, accuracy and actuality. In addition to the coverage-rating that is already created while collecting geodata, the accuracy is measured by user feedback (correct or imprecise) and actuality can be derived from the time since the data was last confirmed as correct in a player’s evaluation. Coverage, accuracy and actuality can be combined in a rating that describes the reliability of the geodata for a certain region. Here as well, an exceptional reward for the rating of geodata in regions that were rated as to contain very unreliable data can lead to an increased homogeneity of data quality.
Manipulating and enhancing existing data is probably the most valuable tasks a player can fulfill, as extended information about geodata can usually not be found remotely (e.g. by analyzing aerial imagery) and is in many cases not covered by any commercial map supplier. It requires good local knowledge or direct access to the relevant objects.
As the enhancement of existing geodata creates a different coverage of additional information for each object, a new measure of detail is necessary. As with the collecting of new geodata, a feedback channel for the editor is necessary, so he can decide if the usual details of a specific object are covered. Therefore, it is advisable to give the players a clear form at hand, which allows them to fill in all details that are applicable for a certain object and therefore also to measure, if all of these details are really covered. A set of common details for each object type could be derived from the already existing data automatically, so based on this information a basic detail rating can be generated by the system which then of course needs to be enhanced by the contributors.
The task to enhance existing geodata will be therefore quite similar to the collecting of new data, only the single actions will require the player to visit existing locations in a certain area. The advantage is that players do not need to solve abstract tasks that require them to search for something in an area, but they can be directly guided to the desired location and asked about specifics.
When games are played in regions, where high coverage and detail is already achieved (which currently is the absolute exception, even in large projects like the OpenStreetMap), the output-agreement approach can be applied again: the game could hide some information from existing objects and ask the players to rediscover it. Does the submitted information match the known values, the reliability-rating rises, if not, other players can be sent to the location to double-check the presumed change. The actuality-rating can also benefit from modifications, as it can usually be assumed that a player who modified an object would have submitted all changes and not just a part of them, and therefore the object can count as up to date again.
The measurement of detail, combined with the reliability-rating, can finally generate a comprehensive evaluation of overall quality, which would add to the transparency of the GIS and create a detailed feedback-system for players and cartographers around the world.
Gathering knowledge
Finally, the gathering of knowledge shall be included as task which allows contributors to give more detailed feedback on anything that is of relevance to the mapper-community, but cannot be solved by a single contributor. This could be reports about vandalism or unusual activities that harm data quality. Also the problem of neutrality can be approached by offering contributors a platform where they can safely submit sensitive information.
But also a more systematic approach to certain topics is conceivable, where contributors can submit information about planned changes in reality which need to be corrected in the map. Here as well, the local knowledge of contributors about e.g. construction work in their home town can increase the actuality of the GIS.
This process of just gathering knowledge and submitting it to others who have the ability and delight to actually change it is a good example of how all these tasks should work: Contributors can submit and integrate as much information as they want, but to reach the masses it is important to create interfaces so that valuable information does not get lost, just because a contributor does not have the time to edit make the changes or does not know how to convert a recorded GPS track in an actual road. All tasks that were described in this chapter should enable the contributor to stop his work at any point, without loosing the valuable data that was submitted. In time, there might be others that continue the work. Temporary Changes in Maps

Information about temporary changes which is relevant for certain maps is especially valuable and due to a limited coverage of contributors currently not easy to achieve. Special circumstances like road works, detours or roadblocks can have major influence on map-based decisions like car routing and therefore particular attention should be paid to the question, how to gather this kind of information comprehensively.
Of course, the GIS must support the submission of temporary changes, which are characterized by two properties: they do not directly affect other geodata and they have a clearly defined start and end date of effect.
As these kind of changes are based on very current events it is not likely that a enthusiast cartographer will by chance get knowledge of the situation and therefore it must be as quick and easy as possible for anyone to submit the temporary change.
Smartphone-owners could use a very simple gamified application, where they, as soon as they e.g. come to a construction site that affects the traffic, choose out of a very basic set of predefined situations which fits best. This information is then stored, together with the current position of the GPS-enabled device, in the GIS and soon after shown on the maps generated from it. The user could then get the possibility to add additional information, e.g. how many lanes are affected, how long the site is, if there is a detour set up, etc. But the most important part is that submitting information about any temporary change should be as easy as clicking the like-button on a Facebook post, because that’s the only way to guarantee that no one is discouraged by the complexity of the task. Any piece of information is in this case more valuable than no information at all.

4.2.3 Designing Cartography-games

In chapter 3.3.3↑ Common Design Criteria↑, an abstract description on how to design human-based computation games was given. In the following, a selection of game design elements shall be highlighted which are of special relevance for cartography-related HBC-games.
The basis for the next considerations is one of the four integral parts of a game, as described in chapter↑: the feedback system. As collecting and evaluating geodata can sometimes be hard work, it is mandatory to reward the players and give them detailed graphical reports on what they have accomplished and how the overall situation has developed. The idea for a quality measurement system was already discussed in the last chapter and besides the importance for project coordination it is also the best indicator for contributors, how the quality of data has changed in their regions and which impact they had in accomplishing this result. This direct visualization of the player’s effort is of paramount importance, as McGonigal stated: “When we don’t have visible results that we can clearly link to our own efforts, it is impossible to take real satisfaction in our work” [56].
Keeping this in mind, some relevant game design elements from the three more concrete abstraction layers will be presented:
Interface Design
A good reward system starts already with the interface design. Until the results of the player’s work appear in actual map representations, several hours can pass, which is way too long for a direct feedback on a single action. Therefore, as result of single activities, the players can be rewarded with points, badges and level progress.
Each activity of the player should be rewarded with points, as long as the result is not rejected by the system. The amount of points a player gains should depend on the difficulty and meaning of the task that was fulfilled. As was already proposed in the last chapter, a calculation of points depending on the quality index of the concerning region could be especially helpful. With an increasing amount of points, the players level up and their submissions gain more weight, as it can be assumed that a player who often contributes correct solutions will also do so in the future.
Badges can both incite players to continue their work on a regular basis (e.g. “Sweet home: Find 10 new POIs in your neighborhood”) or to diversify their activity (e.g. “Discoverer: Make an edit in a location at least 100 km away from your home”). If players contribute in unusual ways, there should be a badge that rewards them for doing so.
Social features are also an important part that should be integrated in the interface design. Seeing where friends have last contributed and what other people in the player’s area have achieved gives the own work an additional meaning, knowing that the next who comes to this spot will know about the own work that was done. Also, knowing if and which players are in the same area is a condition to spontaneously start a new game session.
Design Patterns
There are many general design patterns that add to any kind of game, like clear goals or challenging situations. But there are at least two patterns which can work especially well in the context of cartography-games.
The first pattern is discovery, which many tasks in cartography-games are all about. Awakening the spirit of discovery in the players makes them much more dedicated to the game and leads to results of higher quality. Furthermore, it is more fun for the players and gives their work lasting meaning.
The second pattern is appointment, a type of gameplay that encourages players to fulfill tasks on a regular basis. This can be supported by giving extra points or badges for players that contribute geodata regularly or in form of special tasks which require players to evaluate information at given times. Dedicated players with regular contributions in a given area could e.g. achieve special ranks like “Warden of {region}” which also gives them a kind of felt responsibility over an area for a given time. But if such titles should come with actual real-world duties, they should be rather given by a vote in the community. Ranks and badges that can be achieved during gameplay should always remain without obligations.
Design Principles
The behavioral momentum is an important general design principle, that can be implemented by the previously mentioned appointment-pattern. Players that are contributing repeatedly are especially valuable in the long term. Another principle is blissful productivity, which aims at the fact that players can do hard work during games and still enjoy what they are doing. The designers of cartography-games should be willing to test, how far the players are ready to go during the game. Community collaboration is another factor that was already mentioned. Games are more enjoyable and success is more satisfying, when they are not played alone. And finally, the meaning of the task that is being fulfilled during the game can be an important motivating factor. The subsequent chapter 4.3↓ will give an overview of the benefits that can result from cartography-games.

4.2.4 Community

figure img/community.png
Figure 4.3 Mapper-community
Cartography-games can become a highly valuable source of information, but there are many tasks that cannot be solved during a game for reasons of complexity or simply because it does not fit into any real gameful context. And even if cartography-games become successful, most of the contributions will probably still be made in the conventional map editors. Also, the masses of geodata that are created by the games still need to be verified in some form, at least by taking random samples.
With a growing gamer community, also the classic cartographer-community needs to grow and adapt to the new data source. Therefore, in the following a system will be proposed that describes a unified community of gamers and mappers, with the goal to maintain the data created through games, to bind new players and support them to become skilled mappers and to create a platform for all contributors to exchange and help each other. Figure 4.3↑ tries to depict this concept.
The idea is inspired by the Stock Exchange Network [68], a collection of question and answer websites that uses a sophisticated reputation system. Users are rewarded for providing useful answers and the decision, which answer is useful, is made by the users. With increasing reputation, the user gets more privileges and influence in the community.
This approach can be transformed into a meritocratic community of mappers, where all points and levels that are earned in games are also transferred to the player’s community account. Other users who preferably use the classic map editors gain reputation based on the value of their contributions and all players can increase their reputation by helping others in the community.
In this community, there will be three stereotypes of users to find: novice users with no or hardly any cartographic experience. They are playing the cartography-games, thereby learning about cartographic work, supported by more experienced users. The amateurs are already familiar with cartography-games, they are helping the novices and some of them have already tried to work with the more powerful map editors. With increasing reputation, they can also gain the right to watch and evaluate data sets that resulted from games. The experts form the smallest group of users that is, in the case of the OpenStreetMap, responsible for more than 90 % of the contributed geodata. Their main tools are of course the full-fledged map editors and they are the ones that keep the GIS running. Experts help other contributors with all kinds of technical and cartographic problems, but will probably not regularly participate in cartography-games.
Integrating this different types of users in a community, where beginners can get in and start learning and where amateurs are supported when they are willing to contribute not only via games, the project can benefit greatly from a constant stream of new supporters.

4.2.5 Incentives for Participation

Besides the gameful experience, during↑, other incentives for players to participate were discussed compensation, creativity, social exchange and the “higher purpose”. All of them are valid for cartography-related HBC-games, as was in parts already shown on the last pages, though by far not of equal value.
Compensation remains the least useful motivation, since it is too expensive in a large scale and participants are less dedicated to what they are doing when they are paid to do it, instead of doing it voluntarily. Nevertheless, a platform where contributors are paid by interest groups to provide specific data is conceivable and could prove more efficient that paying professional cartographers. However, this will not be the topic of this thesis.
Creativity is already a far better motivating factor. The task to collect new data requires players to overcome obstacles in order to get to their goal and taking good pictures from visited location does also imply some form of creativity. The own creative footprint is not only visible to the player, but to all users of the map data resulting from his contribution.
Social exchange is also an incentive that has been discussed on the last pages. Geodata that is collected in games with multiple players is more reliable and of overall higher quality. A live Community↑ of gamers and cartographers can build a lasting project with long-term contributors as well as short-term players, as was described in the last chapter.
Probably the most important incentive is the purpose, which all efforts of the players and contributors serves: This not necessarily the abstract goal of creating a detailed and comprehensive map of the world. For some it is the contribution to a collaborative, community made map, for others it is the support of an open data project. Most of these motivations have in common, that they rely on a free GIS, which makes it pretty hard for commercial suppliers with proprietary GIS like Google or Bing maps to compete. And there are other target audiences with special interests, as the geodata that would be most useful to them does currently not even exist. Chapter 4.3.2↓ Benefits for Specific Audiences↓ will further discuss these groups. In the end, it is the support of a good cause, the desire to improve something and the reward with a fair share of the result that pushes the contributors forward.

4.2.6 Realization

Having seen which tasks can be fulfilled in a gameful context and which aspects should be considered when designing cartography-related games, the following chapter will show how actual implementations of gamified cartographic applications and actual cartography-games could look like. The different methods of combining the three important aspects of cartography-games will be implemented here.
First, gamified cartographic applications will be presented, then switching to actual cartography-games in form of classical GWAPs and the so called pervasive games. Gamified Cartographic Applications

Gamified applications have very low requirements concerning the task that is being fulfilled, as game design elements can be used in almost any context. Therefore, many usual cartographic tasks and especially all game-grade tasks that were described throughout this chapter can be fulfilled using a gamified application. Regarding the combination of aspects, gamified applications arise from already existing cartographic human-based computations and therefore the main focus is to gamify proven methods rather than inventing totally new ones.
In combination with the previous Community↑-proposal (see 4.2.4↑), gamified applications can integrate the senior members that have been contributing to cartography-projects like the OpenStreetMap for a long time and do not have too much interest in playing cartography-games. Their efforts could be put in a fair relation to the gamer’s contributions by using gamified cartography-tools.
The following classification will distinguish between location-independent (stationary) and location-based (mobile) cartography-applications.
Location-independent Applications
These applications are usually provided in form of dedicated desktop applications or browser-apps, which do not require the user to be at a specific location in order to make changes to the GIS. This implies the classic map editors for the OpenStreetMap which are designed to make changes at home, based on geodata that has been collected before by the mapper or by using third-party sources like aerial imagery.
Similar editors can be created that are more user-friendly and make use of game design elements. The OpenStreetMap editor Potlach 2, which was described in↑, does already go in that direction, by providing a well arranged user interface with clear instructions how the user can contribute, making it easy to extend with game design elements.
Reasonable elements would be interface design patterns that visualize the progress of the contributor, like points for every edit and badges for specific types of contributions. Also, an additional map layer that visualizes the overall data quality in every region would be useful for two purposes: it gives the contributor a good overview, where his input is needed most and it also makes the reward-system more transparent, if rewards are given depending on the overall quality of the location where the edit was done.
Also, the appointment-pattern could be of relevance, as it can incite contributors to come back regularly and therefore a web of frequent editors could be established. Regular participation could be motivated by giving the prospect of special badges which would also give the edits of the regular contributor in a specific area more weight (e.g. by marking own edits as trustworthy, though they have not yet been confirmed by the community) or give the contributor more rights in the community, like rating the quality of a whole area instead of just single spots. But whenever such special rights are given, it should be ensured that the users can never get powers similar to a system administrator and that the overall equality of users in the crowd is not cut down.
Location-based Applications
An example of a gamified location-based application was already presented in↑ Temporary Changes in Maps↑ Participants enter some basic information about a relevant change to the map that will not last permanently. The practical thing is that they do not need to enter any information about the location of this change, as the device which submits this data sends its location together with the user-defined problem description.
Specialized gamified application that offer its users an easy way to contribute information about places they have visited can provide the GIS with much detail about locations that would else probably not be minded that much if the contributors tried to remember details about it afterwards at home. For travelers, this kind of participation could become the medium of choice, as it is very intuitive just to choose out of a list of predefined location types what actually is at the visited place, without having to worry about any other technical issues.
Collecting new geodata with location-based applications is not only limited to single POIs, the recording of GPS tracks is also conceivable. The tracks could then be stored offline on the device for further editing, or uploaded to a private user area, where the contributor can decide if he wants to give the recorded tracks to the community for someone else to integrate it in the GIS or if it should just be stored so he can edit it by himself later. Here again, the creation of interfaces is crucial, as not any contributor has the will or knowledge to fulfill all cartographic tasks that are required for a contribution to appear in the GIS.
Location-based applications are of course not limited to the collecting of new geodata; the updating and evaluating of already existing data are also important tasks. Whenever the user makes an entry with the application, it can be compared to other already existing entries in a small radius. If there is a matching entry, the application could ask the user if his last contribution resembles this entry and if it does, he can evaluate and update the saved data, if necessary. This approach could also be reversed, so that the application draws the user’s attention, if he has been for a while in a place that was not already visited by him, and ask him to rate existing entries at his location or create a new one, if it does not already exist.
All in all, gamified cartographic applications have the potential to make contributions for hobby-mappers more intuitive and easy to accomplish, but they will probably not reach the same popularity as full-fledged games among novice contributors. Cartography-related GWAPs

This section will describe implementations of cartography-games based on the usual GWAP game types. In terms of the combination of aspects this would be the finding of cartographic usages for existing games.
Cartography-related GWAPs hat are played at home need to rely on either the local knowledge of the players, or on high-quality imagery of the concerning regions, preferably of course both. This is owed to the fact that these games do not require from the players to be at the specific location, though the game should let the players solve tasks in the same area, to be able to compare the results. The three game types that von Ahn [47] described shall be used as a basis to implement similar cartography-games.
The output-agreement game requires two players that get the same input to produce a matching output independently. For cartographic tasks, this would work well when evaluating existing data or enhancing it with additional information. Two players would, for a region they both know, get the position and basic description of a single location. They both would then write down details about this location, preferably by filling out suitable form fields, so the data is already compatible with the GIS. Forms that have been filled by both players exactly the same can be considered as reliable, the other information can be stored by the system but should be further verified by other players. Both players win, if they have submitted enough matching data, whereas one player can get more points than the other if he finishes faster or when he finds additional information that was not covered by the other player.
Abuse of this system by entering random data just to get more points than the other can be prevented by evaluating the results through other games or applications. Players who often enter false information will be punished by the game through loss of reputation and their future submissions will gain less weight. This kind of punishment must be shown transparently to the player, e.g. with a reputation index in percentages. If only one player (or an odd number of players) is available for a certain region, a computer player can jump in, giving the player locations where the GIS has already a good amount of details stored. The human player does describe this location and his input is then compared to the entries in the database. Thereby, no new information can be added to the GIS reliably, but the existing geodata can be evaluated.
The inversion-problem game involves two players, where one player gets an input and has to describe it to a second so he can find out which input the first player got. Again, this works with all sorts of nodes where basic information is already available, but the type does allow to add more detailed information. So the first player fills out details about this location which are instantly visible to the second player. This one has then, based on the information the first player gives, to mark the exact position of the described object on the map. If the correct location was chosen by the second player, the description of the first one can be considered as valid and the additional details are transferred in the GIS.
To increase the difficulty, the game could be altered so that the describing player is not free to choose which information he gives to the other player, but the game asks specific details. This way, not only general information which defines the location as fast as possible is submitted by the first player and for the second player the game is more challenging. And to solve the problem with an odd amount of players, the game can even be played in both directions, but again only to evaluate existing data: If the human player is the describer, he has the task to give information about a location that has already detailed entries in the GIS. Does the description match, the details in the database are confirmed, else they get a lower rating and will be further evaluated in other games or applications. With the human as evaluator, the computer player simply gives details about a known location and lets the human find out, where it is.
Lastly, the input-agreement game shall be considered, where two players describe their own input to each other and have to decide if they are equal. This approach is similar to the inversion-problem game, only that both players get an input and alternately describe it to the other. Again, the descriptions are stored by the system and both players make their decision based on the description of the other. The correct answer is of course known to the system, as the locations have been chosen by the computer, and therefore the reliability of the description depends on the decision of both players, if the inputs were equal or distinct. If both players answered correctly, their descriptions are considered as reliable, if both were wrong, the descriptions are ignored, and if only one of them was right, at least the description of the other player could have been correct.
For odd player numbers, the same system works as in the inversion-problem game: The computer player always gets a location with detailed entries in the GIS and describes these to the human player. If the description of the human player fits the information stored in the system, the computer answers they are equal. If both locations are really equal, the stored information has been confirmed by the human player.
These descriptions of the three general game types are by no means to be seen as exact implementation instructions for cartography-related GWAPs. They are the core components that can make both aspects of the GWAP work: the computational as well as the gameful part. It is up to the game designer to put these building blocks into an appealing context in order to make a good game and it is by no means necessary to exactly include either of the three presented game types. Pervasive Games

The only missing combination of aspects is the integration of human-based computations into existing cartography-games. But as was already shown in the Related Work↑, there are hardly any notable games that are concerned with cartography. Luckily, people are doing things and playing games in their daily lives that include work that can be well integrated into cartography-games.
Games that are played casually as a part of everyday life or in interaction with real-world objects are called pervasive games. A good definition was elaborated by Montola, Stenros, and Waern [69]: “A pervasive game is a game that has one or more salient features that expand the contractual magic circle of play spatially, temporally, or socially”. The so called “magical circle” has its roots in the statement of Huizinga [70] that games are separated from daily live. Montola et. al. defined it as “the boundary separating the ordinary from ludic and real from playful” [69].
Bringing this into the context of cartography-related human-based computation games, the relevant “salient features” are of course those of spatial nature, as these games allow the players to collect geodata by visiting real places during the game. But also the social and temporal features can greatly enhance the gameful experience during such games, which have also become known as location-based games [71].
However, this chapter shall not be an introduction in the general design of pervasive games (for a comprehensive theoretical background on this topic see the already mentioned work of Montola et. al. (2009) [69]), but an idea how pervasive games can be used in a cartography-related context. It will be shown, how human-based computations, using cartography-related tasks in particular, can be integrated into pervasive games.
The Game
The goal of location-based games is to fulfill quests that require interaction with real-world objects. Therefore, visiting different locations and fulfilling tasks on-site is a natural part of the game. In order to get to the specified locations, the players usually need a navigation device, such as a GPS-enabled smartphone. Using these devices, also additional instructions can be sent to the players. Ideally, a game guide in form of a smartphone app accompanies the players during the whole game, which explains the tasks that are to be fulfilled at the specified locations and helps the players when they get stuck.
The rules of such games cannot be generalized; sometimes they set an order in which the tasks need to be fulfilled or limit the possibilities of transportation between different locations, but usually the free approach to get as fast as possible from one place to another is enough. The tasks that need to be fulfilled on-site have their own rules included and the players need to comply on following the given instructions. For each fulfilled task the player gets points and depending on the game type one player can get more points if he fulfills the given tasks faster or better than the others or, if the overall time is limited, the player with the most fulfilled tasks wins.
The players usually know which or at least how many places need to be visited, so each completed task gives them a feedback, how far they are from achieving the goal. Additionally, the game guide application, if existent, can visualize the player’s progress and instantly compare it to the progress of the other players.
Collecting Geodata
The tasks which can be fulfilled by the players to collect and evaluate geodata were already described in↑ Tasks↑. Typical quests could be: “Find the cinema at {location}. What is its name?” or “Go to the church at {location} and take a nice picture of it”. But there are many game design elements that can make it more appealing for players to fulfill these tasks. Giving them a meaning that goes beyond the work that needs to be done or providing background information about the location where the task is to be fulfilled can further incite the players. To accomplish this, the game can use the existing information about the location and present it to the user before asking something new.
An example that provides useful background information could be: “The only Japanese restaurant in town is {name} at {location}. On which days is it open?”. To create such a statement, the specified restaurant must be already existent in the GIS, as well as the type of food it serves and the whole town must have a relatively good coverage of restaurants and the food types they serve. Here again, a working data quality index is crucial.
To prevent that players with better local knowledge get an unfair advantage, the game could require the players to first visit the location and then reveal the task. Also, the possibility that a player cannot find the location or decided to skip it shall be taken into account. As all places that are integrated into the tasks can also come from unreliable sources, the player should always have the option to finish the task with one of these two answers.
A good concept to collect more detailed information about already known locations is to ask questions incrementally, based on the data that is already stored in the GIS. For example, a player could be asked on which days a specific bar has opened. The next player could then get the information, that the bar has opened from Tuesday to Sunday and the game would ask if on any of these days the bar offers some kind of special discount. Based on this submission, the next player would get the information that this bar offers discounts on Fridays and asks the player to submit some details about the discount (e.g. “Happy Hour from 18:00 to 21:00”). This way, complex information can be collected which a single player would possibly not submit and each tasks remains plain and easy and might even give the player interesting information.
When players of a pervasive game are using a game app that tells them where to fulfill their next task and what exactly is to do, the same application can also help the players to get to the specified location. But to make the game more challenging, especially for players with good local knowledge, it can be an interesting variation not to give the players a detailed explanation where to go, but instead just some slight hints or an image that was taken near the goal. Location descriptions can be generated from a predefined set of shared features that all locations of the same type have to offer and other POIs that are nearby. So “find a place with running water south of the market place” can be a description for a fountain or a water dispenser that can be found there. The app should give the players a positive feedback when they have reached the correct location or give them more hints if they can’t find it.
Another approach could be to show a geotagged image near the desired location and describe what the players need to find “near the place on this picture”. Also, a rough statement about the distance from the current location and the direction the players have to go can prevent the frustrating moment of not knowing at all what to do. In any case, the application should intervene and give the players more precise hints, if they go in the wrong direction or it takes them too much time to find their goal.
If the players have no local knowledge at all (e.g. tourists on a sightseeing tour), the game application could, rather than making the way more hard to find, use the full potential of the GIS to guide the players from one location to the next. In an area with high coverage of public transportation, the app could even show the way to the next bus or subway station and tell the players which line to take, in order to reach their destination.
In the previous considerations, the tasks that the players have to fulfill were always designed so that a computer could generate them based on the information that is already stored in the GIS. Another possibility would be, that human organizers, or game makers, create the route and the tasks that need to be fulfilled by the players.
The advantages of this approach would be that games can also be played in areas with low data coverage and the game maker can use his local knowledge to create routes that are more appealing to players than randomly computer-generated tasks. The game maker can create custom hints that lead to the next location and make suggestions for good routes. Also, useful background information and less generic tasks can be created. This way, the overall game would feel less like a concatenation of cartographic tasks and more like a real quest.
Of course, this free approach makes it harder for the GIS to understand the information that is submitted by the players. The game maker should therefore still make sure, that the solutions of at least some tasks can be directly integrated into the GIS. As this applies for any geotagged picture and a lot of generic information that can be stored about single locations, this should not prove to be too hard. In the contrary, it would be best practice to leave a part of the task that needs to be fulfilled at the specified location for the computer to generate, so the system can decide which information is still needed and ask the players to provide it.
Game makers are, as any participant, also part of the mapper-community and therefore creating and organizing games will increase their reputation in the community. The participants of a game session should be able to rate the game afterwards, so the game makers gain more or less reputation depending on how well their game was liked. To organize new games, a platform is conceivable, where game makers make proposals and the players can have a look at the proposed games and the game maker’s experience and reputation. Based on this information, they can then decide if they want to take part. This way, there would be a certain kind of competition between the game makers in the same area and the players get the chance to estimate if there are enough participants and if the overall quality of the game is sufficient.

4.3 Benefits of Cartography-games

After having seen how cartography-games could be designed and actually realized, an important question has not yet been answered comprehensively: Which benefits result from cartography-games? And who can actually use these results? The benefits for players and contributors were already discussed in chapter↑ Incentives for Participation↑. Though already discussed implicitly in the course of this thesis, the overall advantages concerning the geodata stored in the GIS will be recapitulated. Afterwards, a look upon specific audiences will be given, which can especially profit from geodata collections and maps that are unprecedented in coverage and detail.

4.3.1 Benefits for the GIS

Any game that collects and evaluates geodata in its course is of course valuable for the GIS where the data will be finally stored.
New data is being discovered and added by the contributors, existing entries are filled with more details and updated when the stored information becomes deprecated. Additionally, the existing data gets validated by the players, which is a crucial part for any human-based computation game. This additional work is not wasted time, as it makes an overall quality rating over the coverage and reliability of certain types of geodata in a region possible. As was already pointed out in↑, a data quality rating is a good type of feedback for players and cartographers, helps to concentrate the resources of the community where they are most necessary and gives an overall impression, how reliable and actually usable the provided geodata is.
And finally, a growing community of regular contributors raises the overall actuality and reliability of the GIS. It is this global net of contributors that makes it possible to maintain a map representation of a world that is changing ever faster.

4.3.2 Benefits for Specific Audiences

Maps are rendered from the geodata stored in a GIS and though the geodata can be of very general nature, specific maps are always limited to show a subset of features. There are groups that require in their daily lives maps that are unusual to most people. The OpenSeaMap [73] for example is a part of the OpenStreetMap project that offers a map view specialized on nautical information and encourages seafarers to contribute their experiences on sea. Another project with a very specific target audience is the WheelMap [74], which is dedicated to collect information about wheelchair-accessible locations. Other than the OpenSeaMap, which is due to the required background knowledge primarily fed by contributors with nautical experience, the WheelMap invites everyone to participate by providing a simple web application that makes it possible to rate places without registration just with the click of a button.
Finding specific target audiences that can benefit greatly from specialized maps creates two new potential groups of contributors: as it is in the best interest of the target audience to increase the quality of the map, the most dedicated contributors will come from this group. Especially when the project has a social or charitable background, as in the case of the WheelMap, other supporters that are not part of the target audience might also want to contribute in order to help them.
In the following, the term self-sustaining project will be used whenever the map is designed for a target audience that is not dependent on the help of others and predominantly maintained by members of the target group. Besides the already mentioned maritime map there is a number of noticeable community-driven projects: The OpenCycleMap [75], a special map for bikers containing cycle tracks and routes, the OpenPisteMap [76], dedicated to collect information about skiing and snowboarding pistes, or Waymarked Trails [77], a map view for hikers, skaters and more. All these projects are just views of the OpenStreetMap GIS, but they encourage their target audiences with this specialized map view to contribute data about their tracks and experiences to the main project.
Further conceivable projects would include a biker-map, where motorcyclists can upload their tours and rate them, or a camper-map, where travelers can map and rate camp sites and gather information about nice travel destinations. As long as the target audience is not too small and the benefits are comprehensible, such projects can well increase the number of contributors.
On the other hand, charitable projects describe the kind where the target audience is too small or the members are handicapped or restricted in other ways so that they cannot collect and maintain all the necessary data by themselves.
Besides the already mentioned WheelMap for people with walking impairments, there are also other projects and ideas listed for blind and deaf persons [81]. A gamified application with the goal to collect valuable data for visually impaired people will be described in the subsequent 4.4.2↓ BlindMap↓.
But also humanitarian aid projects could benefit and there is already a number of notable open-data projects active, like the Humanitarian OpenStreetMap Team, a group within the OpenStreetMap community with the goal to “apply the principles of open source and open data sharing towards humanitarian response and economic development” [80]. Another project is Ushahidi [78], a non-profit software company that first draw international attention [79] with a crowdsourced project in Kenya where eyewitnesses could report acts of violence that were then visualized on an interactive map.
There is a number of useful tasks that can be fulfilled by cartographers, even remotely. In countries that are threatened by droughts, volunteers could chart the locations of wells and natural water reservoirs and then print maps for the population. Especially in politically unstable regions the availability of detailed maps is often rather low, while the risk of famines or expulsion can be high, and lack of reliable cartographic data can further hinder necessary humanitarian aid. Therefore, it can be useful to gather relevant information in time, before a possible disaster makes any cartographic work impossible.
So there are specific groups that are not particularly concerned with cartography or games in general, but would benefit a great deal from maps that are customized for their needs. And there are others who would like to help people with difficult life circumstances or people who find themselves in a humanitarian crisis. Creating easy to use and appealing cartography-projects for these groups can widen the circle of potential contributors tremendously, and cartography-games or gamified applications can be a way to address these target audiences.

4.4 Game Proposals

The last chapter of this thesis is dedicated to three selected ideas, which are to show exemplary, how cartography-games can be implemented. To remain within reasonable bounds, the following descriptions will not be full implementation instructions, but the idea and the important details of every game will be elaborated wide enough so that the inclined game designer can use them as basis for an actual implementation.
The first game will be a classical GWAP in form of a browser game, where the players mark new and edit existing Points of Interest (POI) on a map. The second application will be about the already mentioned map for blind persons and the last proposal will concern a pervasive game in form of a city rally.

4.4.1 POI Tagging Game

The POI Tagging Game is a GWAP, using the output-agreement approach, which makes its rules similar to the ESP game [48] by Louis von Ahn. It is a browser game that is meant to be played on devices with larger screens, like desktop computers, notebooks and tablets. The players can participate from any location that offers web access, and the game does not require any specific tools besides a computer and a modern web browser.
The game is usually played with two players that are randomly chosen among players that want to participate in the same region, though friend matches could also be offered by the game. The players are confronted with a map of an area of their choice and a simple interface to add and edit certain elements of the map. The goal is to find and place new POIs and add details to existing POIs in a limited amount of time. Another player has the same task to fulfill in the same region.
The progress of both players is visualized in real-time, but the visibility of the actions of the other player is delayed for a few seconds. Each player gets points for every POI that was set by him and for every detail that was added to an existing POI. A few seconds after a POI or detail has been added by the opponent, the player sees this submission on the map. If the player has submitted the same answer as his opponent in this time frame, the player with the first submission gets more points than the latter.
The player has now the possibility to confirm or reject this contribution of his opponent. No matter how he decides, the opponent will not gain any extra points, but the player gets additional points for every evaluation he has made. This way, it is ensured that each player has a reasonable motivation to vote and even more to do so honestly, as he can neither punish nor promote his opponent. Both players have also the possibility to evaluate existing POIs, though these evaluations bring less points than new or updated details and the amount of points that can be received from them is limited.
To prevent abuse through players that add just random data to gain more points, a combination of measures must be taken: On the map that is displayed to the players, not all data that is stored in the GIS is actually rendered. This way, the system can compare the results of the players against its own database. The computer can also perform some plausibility checks, regarding the density of newly added POIs, the format of added details or the time interval between two submissions.
figure img/taggame-Add_Tags.png
(a) adding new tags

figure img/taggame-Edit_Tags.png
(b) editing tags
Figure 4.4 Interface design sketch
Players that give implausible or suspicious results will lose points at the end of the game and the data that is submitted by each player is evaluated afterwards, possibly in other games by other players or even in whole different applications. If a player does often submit false data, his overall credibility decreases, which might eventually result in a ban from the game.
Figure 4.4↑ shows a draft of a possible interface design for the game. The main part of the screen is filled with a map of the area where the game is played. It shows a current snapshot of the GIS and relevant POIs are highlighted. On the top right, the nicknames of both players are displayed, as well as the points they have collected during the game. On the left side of the screen is the game menu.
Figure (a) shows, how new POIs can be added. In the menu, the player selects the correct type from a list of icons with descriptions. Alternatively, he can type it in the search field below, the list gets updated while typing in. When the right item is found, the player can drag the icon to its location on the map.
When a new POI is added, or when the player clicks on an existing POI, the tag menu opens, as depicted by figure (b). There, the player can select the type of POI and according to this type, a form with reasonable details for this location is shown. For each detail that is filled or updated, the player gets more points. The POI that is currently edited by the player is highlighted in his color. In figure (b), the Bar is highlighted in red, as this is the color of the current player. The retail store that is marked in green has been placed or edited by the opposing player a few seconds ago and the change has been made visible. The player can now evaluate this change with the little  +  and  −  buttons on the bottom right of the icon.
If for a specific region only an odd amount of players is available, the computer can also take the role of the opposing player. Here, the computer can make excessive use of the principle of not showing all details that are present in the GIS: By integrating random POIs that are not shown on the map and filling out forms that have been left blank intentionally, the computer can simulate a human player with actual local knowledge.
At the end of the game, a notification is shown that the data the player has submitted during the game will eventually become part of a map and ask him, if his contribution was made carefully and if he agrees to make the data accessible under a specific license (for free GIS, this would of course be a free license). Registered players can choose to skip this question and automatically accept this terms, but especially new users who were not sensitized for the effects of their actions in the game can choose to not submit their data and will probably contribute more valuable data next time.
figure img/01-cartographic-problems.png figure img/02-data-sources-00x0x.png figure img/03-crowdsourcing-xx00x.png figure img/04-hbc-roles-x0x.png figure img/05-gwap-x00.png
Figure 4.5 POI Tagging game: classification
Figure 4.5↑ shows how this game can be classified with respect to the observations in this thesis. In the course of the game, all four cartographic problems can be solved, as the players are able to collect new geodata, manipulate existing entries and most important, to evaluate the work of other players. The only available data sources are the local knowledge of the players and the map view or aerial imagery of the selected area. By accessing the local knowledge of the players, the wisdom of the crowd is demanded, but filling a map under time pressure with details can also be seen as a form of crowdsourced work. And by evaluating the work of other players, a form of crowdvoting is implemented. The roles of the innovator in this human-based computation is clearly on the human side. The evaluating part is shared by both humans, using the crowdsourced voting approach, and the computer, with its plausibility checks and the comparison against intentionally withheld data.

4.4.2 BlindMap

Visually impaired and blind persons have significant problems to benefit from current maps, as they are naturally unable to read maps the way they are designed, to be perceived visually, and because the coverage of information that is most relevant for the blind (e.g. footpaths and traffic signals with sound) is usually very low. This problem is only made worse by the fact that people who cannot orient themselves visually in a foreign environment are dependent on high quality maps or, as most usual today, on the help of others.
Peter Wendorff studied in his thesis of 2010 [82], how the OpenStreetMap GIS could be used to store relevant data for the blind, which specific geodata needs to be collected and which navigation systems are applicable so blind people can move independently in locations they don’t know. Based on these considerations, the following gamified application will be described.
The BlindMap is a gamified application with the goal to collect all kinds of geodata that is relevant for the navigation of visually impaired people. Two versions of this application could be implemented: a browser application that can be played location-independent, and a mobile app that will be used to collect geodata on-site.
The following geodata needs to be collected:
As blind persons would have to rely on the map if they are alone in unfamiliar territory, a working quality rating of the available geodata is crucial. So maybe even more important than the fast collecting of new geodata is a working evaluation system that guarantees data quality. Therefore the evaluation of existing geodata will be an integral part of the application.
An implementation of the location-independent BlindMap could look quite similar to the previously described POI Tagging Game↑: The main part of the screen is filled with a map view. On the edge of the screen, a variety of special editing tools can be seen that helps the user to draw footways, place traffic signals and to edit existing entries. An optional layer of aerial imagery can also be used as data basis, so the contributors do not have to rely solemnly on their local knowledge. The users can vote on the validity of existing entries and when a user has made a few submissions in an area, he is asked by the application, how he would rate the overall coverage of details in this area. Based on the per-object and overall evaluations of the users, a BlindMap-specific quality rating can be created for certain regions.
Also, as part of the screen, the feedback system is visualized. Here, a combination of the known game design elements will serve: for every action, the user gets points, with increasing points his level increases, for groups of special actions, badges can be obtained, and with increasing levels, the users gain more trust and thereby special rights and influence. The evaluations of high-level users have more weight in the calculation of the final rating and new entries by high-level users do need less positive feedback than those of new users to be accepted as valid.
The location-dependent mobile app works quite similar, but uses a different approach to collect and evaluate geodata. Here, the users have to be on-site to submit new geodata or to evaluate existing entries. Though this costs the additional effort to move to the desired location, the advantage is that the users don’t have to bother about the positioning of their contributions, as the current GPS position of the mobile device is sufficient, and the users can submit detailed information based on what they can actually see, which might result in higher data quality than geodata based on just local knowledge.
If the necessary data is already existent for the current location, the user has the possibility to update and extend it, but in any case he should be encouraged to at least rate the available data near his current position. Also very important is the possibility to submit temporary changes that prevent free passage, like detours or technical defects of traffic lights.
Regarding the applicable game design elements, the location-based application should also include a decent reward system that could be identical to the system of the previously described browser-application. Thereby, the results of both systems remain comparable and users can switch easily between the two systems.
More important is however the appointment-pattern, which should incite users to contribute regularly. Everyone has occasionally some free or waiting time on the road, maybe standing on the sidewalk and waiting for the lights to switch to green, which could be used to open the app and just look which information is currently stored at this location. If everything is fine, a simple push to approve the current entry is sufficient, else the user can select from some predefined answers to best describe the situation. If the application design is right, this task will take less time than for the lights to switch to green. Regular contributors will be rewarded with more points and special badges.
The applications that were described here still have one serious flaw: they cannot be used by blind persons themselves. This is a particular loss, as visually impaired persons know best which details need to be added to the map and which errors in the map can be a real danger for themselves. At least the location-based application could be altered in a way so that it can be used without visual perception. As was already described, the interface design of the mobile app should be held as easy as possible, so the user does only have to select from some predefined answers and the system connects them with the current phone position.
Such simple selection-based interfaces can be altered so the choices can be read to the user by the mobile device and the answers can be accessed e.g. through voice control. As soon as the user has learned the commands, the only information that is necessary to get started is if valid data is already existent for the current location. If so, it can be read out to the user to be evaluated afterwards, else he can enter some simple commands to describe the situation. This way, blind persons can participate in the enhancement of maps the same way as seeing ones could.
figure img/01-cartographic-problems.png figure img/02-data-sources-mixed.png figure img/03-crowdsourcing-xx00x.png figure img/04-hbc-roles-x0x.png
Figure 4.6 BlindMap: classification
Again, a classification of this game should be attempted, as depicted in figure 4.6↑. The game solves all four cartographic problems, as new data is collected by the contributors as well as evaluated in the same application. Regarding the data sources, the two presented games need to be differentiated: Both applications profit from the local knowledge of the users, but while the location-based app relies on the on-site perception in combination with a GPS-enabled device, the browser application works way more with local knowledge, supported by aerial imagery and the current map view. Regarding the type of crowdsourced tasks that are fulfilled by the contributors, it is mainly the wisdom that is being accessed by the application. But also the voting system is of relevance to ensure data quality and as in any gamified application, real work is fulfilled by the participants, though in a gameful context. The human part in this human-based computation is on the side of both innovator and evaluator, whereas the computer can only take the role of the evaluator by applying the usual plausibility checks before accepting any submissions.

4.4.3 City Rally

The City Rally is a pervasive game (see detailed description in chapter↑) that is mainly oriented towards tourists and people who just moved into another town, but players with good local knowledge can participate as well. It is a team game that works with at least two groups of 2-5 players. Each group requires at least one GPS-enabled smartphone where a free application is installed that guides each team throughout the game. The goal is to find locations, follow hints and fulfill tasks that are part of an overlying quest that needs to be mastered in the game.
Participants collect data by visiting places and solving tasks on-site, in a way that the solutions can be directly transferred into the GIS. Data validity is evaluated by applying an output-agreement approach between the different teams: Some tasks need to be fulfilled by both teams, so the deviation between the results can be a good indicator, if the questions were answered correctly.
The players sign up for a game on a web platform where game makers offer their rallies for specific regions. There, for each game a quest description is given and the game area is defined, as well as some additional information on game duration, the estimated walking distance and the quest difficulty. If the game maker announces that one of his games be played at a certain time, it is expected that the he or another organizer meets the players at the start location and sees that the players don’t run into problems they cannot solve, but players can also meet spontaneously and just start a game for themselves whenever they like. In this case, the player that initiated the game gets some special rights, at least to start and finish the game.
Games are usually offered by non-professionals for free, but also commercial suppliers like travel organizers can offer a participation in their tours against a fee. In professionally organized games, the players could e.g. lend a navigation device from the operator if they don’t have one themselves or contact the organizers if they got lost or don’t know how to continue. Also, special offers like an after-game meeting with a free meal can be included.
The Game
Before the game starts, the participants have time to get to know each other a little before splitting into different teams. The teams should have about equal strength concerning the fitness and local knowledge of the participants, if possible. Here already, the game maker, if available, can ensure that a fair game under equal conditions is possible by influencing the process of team making.
When all players are ready, the game maker (or initiator) starts the game and each team gets its first task on the game guide app. Depending on the difficulty of the game, the players get a detailed description of where to go first, or just some hints in which direction to walk. Each game is designed with at least two different paths, so the teams do not stick together from the start. It is up to the game designer to create different paths that are of comparable difficulty. Thereby, making slight changes to the individual tasks, and skipping or adding others are valid methods.
As soon as the players of a team reach their first destination, the task that is linked to this location is unlocked and shown in the game guide. Here, the game maker can express himself creatively and give the player any task that serves the quest and can be solved in a short amount of time. Part of a good task is of course a little bit of cartographic work that can be added to the GIS. As part of the task, the game maker can ask the players to take a picture or to submit data about a specific location. To prevent that all players submit the same data, the game maker should submit for each station a variety of possibly generic tasks.
For geotagged pictures, the game maker can set up a list of subjects, so the system will generate a task like “Take a picture of {subject}”, or he can write an abstract description like “Take a picture of at least one item at your location that you found noticeable”. Collecting geodata at the desired location is even easier for the game maker: By default the game takes all POIs in a reasonable radius around the specified location into account and asks the participants about missing information. However, the game maker can also specify the POIs that shall be taken into account.
For each solved task the team gets points, depending on whether the members reached all goals or only a part of them, and how fast they were. The team that solves its first task with the most points is set to the top of the live leaderboard that can be accessed from the game guide. After the task was solved, the way to the next location is unlocked in the game guide, if it was not yet provided through the result of the previous task. The teams continue with their quest until they have solved all tasks and finally meet again at the finish. The team with the most points at the end of the quest wins the game.
At the end of the game, each team is prompted with the option to submit the collected geodata and the images that were taken to the GIS. To protect the player’s privacy, the submission form offers an easy way to exclude individual pictures or data sets. In the case of a free GIS, the contributors also have to agree to publish their work under a free license.
If the players enjoyed an organized free game, a small gift or an invitation to a drink for the game maker is a common gesture. This is also a great possibility for the participants to have a little chat after the game and to make an appointment for the next quest.
The classification in figure 4.7↓ shows that the city rally increases the accuracy, actuality and overall coverage of the GIS, but cannot directly contribute to the neutrality of existing data due to the lack of a sophisticated feedback system. During their tasks, the players usually don’t evaluate existing geodata, but submit new (possibly redundant) information. That is also why the game, though it is not a classical GWAP, can be best compared to an output-agreement game. If the GIS has already many consistent answers to a specific question and a team answers differently, it will get less points for this answer, as it can be seen as improbable that so many others have submitted a wrong answer before. In this computation, only the human is the innovator (the players submit new data), but both human and computer are evaluators. As evaluator, the computer rejects implausible answers and stores plausible information in the GIS. The majority opinion of the contributors can be seen as the human evaluation part in this computation.
figure img/01-cartographic-problems-xxx0.png figure img/02-data-sources-xxx00.png figure img/03-crowdsourcing-xx000.png figure img/04-hbc-roles-x0x.png figure img/05-gwap-x00.png
Figure 4.7 City Rally: classification
As in most cartography-related pervasive games, the data sources include the GPS-receiver, the information the players can gather on-site and of course their present local knowledge. The tasks that are crowdsourced during this computation are the gathering of wisdom in form of geodata that is compatible to the GIS and the work the players fulfill during the game, namely the completing of tasks that require them to move to different locations and to search for correct solutions.

4.5 Estimations

The final section of this chapter about cartography-games is dedicated to the question, if cartography-games could really achieve global acceptance and makes estimations about the difficulties that need to be faced in possible implementations.

4.5.1 User acceptance

Can games be really suitable to collect geodata in a global crowdsourced scale? Especially from the global view, the answer to this question depends on the economic standard of living in the countries of the world. As the different country-specific coverage of geodata in the OpenStreetMap has shown, the quality of data is relatively high in developed countries, whereas in developing countries sometimes not even the basic road network is covered.
In order to participate in cartography-related GWAPs and similar gamified applications that can be run in a web browser, the participants need at least a computer with internet access. According to the IWS [83], 32.7 % of the world population had internet access as of December 2011, with the lowest coverage in Africa and Asia. Though the distribution is far from homogenous, the technical prerequisites should by now be given in all parts of the world to gather enough participants which can achieve at least a basic coverage.
To play pervasive games or to use gamified location-based applications, a GPS-enabled smartphone with internet access is required, which is already a higher technical hurdle. As of 2011, there were 1.18 billion active mobile broadband subscriptions worldwide [84], which allows the assumption that a good part of these subscribers is also in possession of a smartphone. Here, with 10.7 % coverage in Asia and only 3.8 % in Africa, the distribution of the necessary technical tools is still too low, whereas the amount of smartphone users in Europe and North America is high enough. But even though there are large regions of the world with a relatively low coverage, this is just the beginning of a process; the proportion of smartphone-users rises every day and even though their overall fraction on a continent is low, there are usually regions, especially in urban areas, where this is not the case.
Making sound estimations about the success of cartography-games at this point is hardly possible, as there are currently no cartography-games existent, but a look at similar games and applications might help to make a first assessment. The game Geocaching, which shares some features with pervasive cartography-games, is rather successful, with over 5 million participants worldwide, by their own account [72]. The location-based social networking website Foursquare, which uses a similar approach as the gamified cartography-applications that were described in this thesis, has more than 20 million users worldwide [85]. There are no statistics about the players of GWAPs in general available, but looking just at the language-learning GWAP Duolingo, which had a waiting list of more than 300.000 users for its private beta, it is obvious that GWAPs can be appealing for the masses. Finally, the steadily growing OpenStreetMap community, with more than 800.000 registered users as of 2012 shows that, even without the availability of games, crowdsourced cartography is a working concept.

4.5.2 Implementation

The theoretical backgrounds and concepts for cartography-games have been described in detail throughout this thesis, which allows a realistic estimation of the difficulties that might be faced in a possible implementation of one of the proposed games.
Each game needs at least access to a GIS, to read raw geodata and to contribute changes. The example of the OpenStreetMap GIS, with its comprehensible API, is already in use in a variety of projects and there are several open source implementations available that can be used as reference. At least in the case of the OpenStreetMap, the problem of the connection to the GIS is reduced to an implementation by example.
Though it is not a compulsory condition, all of the presented game concepts would benefit greatly from an appealing community integration. The so called social web has yielded more than enough social networking services that can be extended with third-party applications. Integrating a cartography-game into a social network and creating a fair ranking system can become a challenging task, but here again, working examples are not in short supply.
The probably most difficult part to implement is the quality rating system, which is crucial for any human-based computation game in order to ensure data validity and an important part of the feedback system of any cartography-game. An OpenPGP-based rating system for geodata in the OpenStreetMap named TrustOSM [87] has already been developed as part of a dissertation, but currently it has more the status of a proof of concept, rather than an active component of the OpenStreetMap. Being free software, the tool could be used as a basis for further developments, but creating a working and appealing feedback system that visualizes the progress of the contributors, as well as the overall data quality, will probably take a long time.
On the game specific side, the implementation problems keep within the usual frame of game development, as all game concepts that have been elaborated in this thesis have working precursors in other areas. Gamified applications, or rather the use of game design elements, is nothing cartography-game specific, and the design elements that have been analyzed in this thesis are widely used in other applications. GWAPs have been around for a decade now and the concepts are well documented in current scientific work. The same counts for pervasive games and location-based applications in general, which have become usual on mobile platforms.
So the real obstacle in possible implementations is the quality rating system, which is by no means a game-specific problem. To be efficient, it would have to be integrated into the GIS and with an open interface, any application and game could access it without the need for a game-specific solution. The conception and implementation of this system is a problem that will hopefully be addressed in future work.
At least for the less reliable variants of cartography-games without sophisticated evaluation-systems, implementations based on existing software and proven concepts are entirely conceivable.

5 Conclusion

During this thesis, the concept of cartography-related games has been introduced. The purpose of this kind of games is to enhance current online-maps through the contributions of players around the world, while for the players themselves the game aspect is the key incentive to participate. Cartography-games and related applications are to open up the demanding and hardly beginner-friendly map editing process to a much larger audience by providing the necessary infrastructure and tools, so anyone could take part without previous instructions.
Thereby, complex cartographic tasks can be solved, like the complete coverage and evaluation of a certain type of data in a specific area. Also, highly valuable information can be collected, which exceeds the detail of current maps by far and can open interesting usage areas, as the description of the BlindMap↑ (see p. 1↑) has shown. This kind of data, measured by coverage, reliability and actuality in a global scale, can only be collected and maintained by a global network of voluntary contributors.


In order to reach the masses, contributing cartographic data must not be any harder than editing a Wikipedia article, and cartography-games can be designed to be way easier than that. Still, the validity of contributed data has to be ensured, especially when the entry hurdles are as low as in a game. The specific problems of current public cartography-projects have been analyzed in this thesis and ways were found to solve the main cartographic problems (accuracy, coverage, actuality, neutrality), which were also verified in the exemplary game descriptions. That crowdsourced cartographic work is generally possible has already been proven by the success of the OpenStreetMap, as well as the increasing use of free and open geographic information systems by end users and enterprises.
It was shown that cartographic work as part of a human-based computation is possible, even in a massively parallelized crowdsourced scale, and that there are applicable game concepts as well. Known game design patterns and guidelines could be well applied to the concepts of gamification and games with a purpose, and the specific problems (as data validity) and benefits (like additional incentives) of those were taken into account.
figure img/Venn_03_Cartography-HBC-Games-Filled.png
Figure 5.1 Aspects of cartography-games
The elaborated background knowledge was successfully combined to create an overview of consistent game concepts with respect to the specific cartography-related problems that are existent in classic map editors and to those that might occur in games and gamified applications. Ideas about game design and community integration were developed and the three concepts of gamified cartographic applications, cartography-related GWAPs and pervasive games have been regarded in detail from an abstract point of view. Finally, each of these concepts has been transformed into concrete implementation descriptions, showing how actual cartography-related games and gamified applications could work.

Future Work

Though some of the Game Proposals↑ in chapter 4.4↑ could be implemented right ahead (with some limitations), the results of this thesis should be seen more as basic research with plenty of topics for future work. Actual field studies are necessary as well as working implementations.
Still, the estimations that were made in this thesis indicate that cartography-games do have a good chance for success: The necessary technological prerequisites are more and more available even in developing countries, location-based games like Geocaching have already millions of participants worldwide and regarding the implementation of cartography-games, the difficulties are manageable. It is for future projects to show, which game types are accepted by the players, and which ones provide the most detailed, accurate or unusual results. With the the quality rating system that was discussed in this thesis, there is an interesting and large-scale problem to solve, where not only cartography-games would benefit from. Besides that, the implementation of the game specific parts can mainly rely on already existing software and working concepts.


Cartography-games and gamified applications can bring the quality of current online maps to a new standard, by overcoming the classic limitations of commercial cartographic work and establishing a global community of supporters which relies on the best source of geographic information: local knowledge. They are meant to be a fun way for people to explore their environment, to get to know others during the game and to participate in something bigger than any single one of the players could ever accomplish. If the results of this participation help others to find a nice campsite on a holiday trip, to get to the next café with barrier-free access, to find the way back after losing the path in unfamiliar territory or to simply move a little faster from A to B, then at least for me, it was worth the effort.



[1] intends to be a unified resource space for anyone interested in the visualization of complex networks (

[2] McVicar J., Morton L., Baillie L., Komninos A., Hussain F., Abdullah Z.(2008): "Zombies vs Humans", Evaluating Player Experiences in Location Aware Games Workshop in conjunction with the 22nd annual Conference on Interaction (HCI2008), Liverpool, UK

[3] Yet Another Point of Interest Submitter (YAPIS) makes it possible for everyone, to add POIs to the OpenStreetMap (

[4] International Cartographic Association (ICA). Mission. Retrieved July 25, 2012, from

[5] Google Earth is a virtual three-dimensional globe, featuring satellite imagery, aerial photography and additional spatial information (

[6] BBC News (2000). Ice Age star map discovered. Retrieved July 27, 2012, from

[7] Part of Tabula Peutingeriana, Konrad Miller´s facsimile from 1887. Retrieved July 29, 2012, from

[8] Sprague, B. Claudius Ptolemaeus (Ptolemy): Representation, Understanding, and Mathematical Labeling of the Spherical Earth. Retrieved from Center for Spatially Integrated Social Science (

[9] ISO/IEC IS 19113:2002: Geographic information — Quality principles. International Organization for Standardization, Geneva, Switzerland.

[10] Free Software Foundation. The Free Software Definition. Retrieved August 3, 2012, from

[11] Wikipedia. WikiProjekt Georeferenzierung. Retrieved September 1, 2012, from

[12] The website Planet OSM provides regularly-updated, complete copies of the OpenStreetMap database (

[13] The OpenStreetMap is a free project that is dedicated to create and provide free geographic data (

[14] The OpenStreetMap Wiki is the knowledge base of the mappers and the primary place for exchange (

[15] Import/Catalogue. In the OpenStreetMap Wiki. Retrieved August 6, 2012, from

[16] OpenStreetMap Foundation. Finances. Retrieved August 4, 2012, from

[17] OpenStreetMap Foundation. We Are Changing The License. Retrieved August 4, 2012, from

[18] Fraunhofer Institute for Intelligent Analysis and Information Systems IAIS. OpenStreetMap. Retrieved September 1, 2012, from

[19] Elements. In the OpenStreetMap Wiki. Retrieved August 6, 2012, from

[20] Tag. In the OpenStreetMap Wiki. Retrieved August 6, 2012, from

[21] Key:amenity. In the OpenStreetMap Wiki. Retrieved August 6, 2012, from

[22] Map Features. In the OpenStreetMap Wiki. Retrieved August 7, 2012, from

[23] Editing. In the OpenStreetMap Wiki. Retrieved August 6, 2012, from

[24] OSM XML. In the OpenStreetMap Wiki. Retrieved August 7, 2012, from

[25] Editor_usage_stats. In the OpenStreetMap Wiki. Retrieved August 9, 2012, from

[26] Potlach 2. In the OpenStreetMap Wiki. Retrieved August 7, 2012, from

[27] JOSM. In the OpenStreetMap Wiki. Retrieved August 7, 2012, from

[28] JOSM/Plugins. In the OpenStreetMap Wiki. Retrieved August 8, 2012, from

[29] JOSM Wiki. Plugins for JOSM. Retrieved August 8, 2012, from

[30] JOSM/Plugins/Terracer. In the OpenStreetMap Wiki. Retrieved August 8, 2012, from

[31] Neis, P. (2012). The Newest Active OpenStreetMap Contributors. Retrieved August 10, 2012, from

[32] The website OSMstats generates reports and interactive diagrams from the current OpenStreetMap database (

[33] Breakdown of editing patterns. In Wikimedia Strategic Planning. Retrieved August 11, 2012, from

[34] Contribution of ways by contributor in the OpenStreetMap database. In the OpenStreetMap Wiki. Retrieved August 11, 2012, from

[35] % of total users contributing. In the OpenStreetMap Wiki. Retrieved August 11, 2012, from

[36] OSMstats. Yesterday’s Edits Per Country. Retrieved August 12, 2012, from

[37] Hardy, Q. (2012). Facing Fees, Some Sites Are Bypassing Google Maps. The New York Times. Retrieved from

[38] Shapiro, Stuart C. (1992). Artificial Intelligence. In Stuart C. Shapiro (Ed.), Encyclopedia of Artificial Intelligence (Second Edition, pp. 54–57). New York: John Wiley

[39] Kosorukoff, A. (2001). Human-based Genetic Algorithm. IEEE Transactions on Systems, Man, and Cybernetics, SMC-2001

[40] Wikipedia:Vandalism. In Wikipedia. Retrieved August 14, 2012, from

[41] Galaxy Zoo is an online astronomy project where users can help to classify the galaxies of the universe (

[42] von Ahn, L., Maurer, B., McMillen, C., Abraham, D., & Blum, M. (2008). reCAPTCHA: Human-Based Character Recognition via Web Security Measures. Science 12 September 2008: 1465-1468. DOI:10.1126/science.1160379
Retrieved from

[43] Perez, S. (2012). Google Now Using ReCAPTCHA To Decode Street View Addresses. In TechCrunch, retrieved August 15, 2012, from

[44] Goodin, D. (2012). How a trio of hackers brought Google’s reCAPTCHA to its knees. In arstechnica, retrieved August 15, 2012, from

[45] Amazon Mechanical Turk is a marketplace for crowdsourced work (

[46] Deterding, S., Dixon, D., Khaled, R., & Nacke, L (2011). From game design elements to gamefulness: defining “gamification”. In Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments (MindTrek ’11), 9-15. DOI:10.1145/2181037.2181040

[47] von Ahn, L., & Dabbish, L. (2008). Designing games with a purpose. Commun. ACM 51, 8 (August 2008), 58-67. DOI:10.1145/1378704.1378719

[48] von Ahn, L., & Dabbish, L. (2004). Labeling images with a computer game. In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI ’04), 319-326. DOI:10.1145/985692.985733

[49] von Ahn, L. Kedia, M., & Blum, M. (2006). Verbosity: a game for collecting common-sense facts. In Proceedings of the SIGCHI conference on Human Factors in computing systems (CHI ’06), 75-78. DOI:10.1145/1124772.1124784

[50] Bry, F., & Wieser, C. (2012). Squaring and Scripting the ESP Game: Trimming a GWAP to Deep Semantics. In Proc. of the Intl. Conf. on Serious Games Development and Applications, Bremen, Germany (26-29 September 2012).

[51] Bartholomäus Steinmayr, Christoph Wieser, Fabian Kneißl, and François Bry. Karido: A GWAP for Telling Artworks Apart. In: Proceedings of 16th International Conference on Computer Games (CGAMES2011), Louisville, KY, USA (27th - 30th July 2011).
Steinmayr, B., Wieser, C., Kneißl, F., & Bry, F (2011). Karido: A GWAP for telling artworks apart. In Proceedings of 16th International Conference on Computer Games (CGAMES2011), 193-200.

[52] E. Law and L. von Ahn. Input-agreement: A new mechanism for data collection using human computation games. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI), 2009. DOI:10.1109/CGAMES.2011.6000338

[53] Caillois, R (2001). Man, Play, and Games. University of Illinois Press, Urbana, Chicago

[54] Korhonen, H., Montola, M., & Arrasvuori, J (2009). Understanding Playful User Experiences Through Digital Games. Proc. DPPI 2009, ACM Press (2009), 274-285.

[55] Costello, B. & Edmonds, E. (2007). A study in play, pleasure and interaction design. In Proceedings of the 2007 conference on Designing pleasurable products and interfaces (DPPI ’07), 76-91. DOI:10.1145/1314161.1314168

[56] McGonigal, J (2011). Reality Is Broken: Why Games Make Us Better and How They Can Change the World. Penguin, London

[57] Cooper, S. et. al. (2010). Predicting protein structures with a multiplayer online game. Nature, 466, 756–760. doi:10.1038/nature09304

[58] Foldit is a citizen science game about protein folding (

[59] Duolingo is a language learning platform where users translate web pages while learning a foreign language (

[60] SteamWorks. API overview. Retrieved August 23, 2012, from

[61] Hunicke, R., LeBlanc, M., & Zubek, R. (2004). MDA: A formal approach to game design and game research. In Proceedings of the AAAI-04 Workshop on Challenges in Game AI, pages 1–5.

[62] Fullerton, T. (2008). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. Morgan Kaufmann

[63] The Gamification Wiki is a collection of information about Gamification and Game Mechanics (

[64] Björk, S., & Holopainen, J. (2004). Patterns in Game Design. Charles River Media

[65] Bergström, K., Björk, S. & Lundgren, S. (2010). Exploring Aesthetic Gameplay Design Patterns – Camaraderie in Four Games. Paper presentation at Mindtrek 2010. Tampere, Finland

[66] Thefuntheory. Bottle Bank Arcade Machine. Retrieved August 25, 2012, from

[67] Mangalindan, J. (2010). Game on, job seekers! CNN Money. Retrieved from

[68] Stack Exchange is a network of question and answer sites on diverse topics (

[69] Montola, M., Stenros, J., & Waern, A (2009). Pervasive Games: Theory and Design. Experiences on the Boundary Between Life and Play. Morgan Kaufmann, Amsterdam

[70] Huizinga, J. (1939). Homo Ludens. Vom Ursprung der Kultur im Spiel. Rowohlt, Reinbek

[71] Rashid, O., Mullins, I., Coulton, P., & Edwards, R. (2006). Extending cyberspace: location based games using cellular phones. Comput. Entertain. 4, 1, Article 4 (January 2006). DOI=10.1145/1111293.1111302

[72] Geocaching is a game where the participants use navigational techniques to hide and seek containers, or “geocaches” (

[73] The OpenSeaMap is a project dedicated to collect free nautical information and geodata (

[74] The WheelMap is a project dedicated to collect information about wheelchair-accessible locations (

[75] The OpenCycleMap is a special map for bikers containing cycle tracks and routes (

[76] The OpenPisteMap project displays and collects collect information about skiing and snowboarding pistes (

[77] Waymarked Trails: Hiking is a specialized map view for hikers, skaters and more (

[78] Ushahidi is a non-profit software company that develops free software in the context of maps and the visualization of geographic information (

[79] Bahree, M. (2008). Citizen Voices. Forbes Magazine (December 08, 2008), retrieved from

[80] The Humanitarian OpenStreetMap Team is an initiative within the OpenStreetMap community with the goal to support humanitarian work with cartographic knowledge (

[81] Accessibility. In the OpenStreetMap Wiki. Retrieved August 27, 2012, from

[82] Wendorff, P. (2012). Explorative Evaluierung von Navigationsassistenz für Menschen mit Behinderungen auf Basis von OpenStreetMap. Retrieved from

[83] Internet World Stats. World Internet Users and Population Stats. Retrieved August 31, 2012, from

[84] International Telecommunication Union. Key Global Telecom Indicators for the World Telecommunication Service Sector. Retrieved August 31, 2012, from

[85] Foursquare. About. Retrieved August 31, 2012, from

[86] von Ahn, L. (2012, March 30). We have a blog! Message posted to

[87] Wagner, C. (2011). Ein Bewertungssystem für OpenStreetMap. Dresden, Technische Universität

List of Figures