Evolution of a participatory GIS

Computers, Environment and Urban Systems

28 (2004) 635–651

www.elsevier.com/locate/compenvurbsys

Evolution of a participatory GIS

Angi Voss *, Ivan Denisovich, Peter Gatalsky,Kiriakos Gavouchidis, Andreas Klotz,

Stefanie Roeder, Hans Voss

Fraunhofer AIS, Schloss Birlinghoven, 53754 Sankt, Augustin, Germany

Abstract

Participatory spatial planning and decision making requires a combination of software

tools for group decision support, individual decision support and geographic analysis and

presentation. This article presents a respective approach that integrates two software tools

which were originally developed independently. One tool, Dito, is a Java application for the

World Wide Web designed to facilitate structured argumentation and discourses. The other

tool, CommonGIS, provides Java-based web-enabled services for the interactive, explorative

generation and analysis of thematic maps, and it also supports multi-criteria decision making.

The evolution of the integrated system is reviewed from first experiments in 2001, the resulting

requirements and a succession of prototypes up to the latest solution. The focus of the article

lies in the design of this solution.

� 2004 Elsevier Ltd. All rights reserved.

Keywords: Multi-criteria spatial analysis; GIS; Group decision making; Electronic discourses; Partici-

pation

1. Introduction

Spatial planning problems are often complex and require the competency of ex-perts from different fields, involve stakeholders with diverging interests, and may

affect a large number of people. The problems tend to be wicked (Kunz & Rittel,

1970), their very definition co-evolves with the exploration of options, there is no

correct or best solution, and a decision is successful to the extent that it gets

implemented and is respected in the long term. Chances for success increase as the

decision is reached consensually under the participation of all concerned parties.

* Corresponding author.

0198-9715/$ - see front matter � 2004 Elsevier Ltd. All rights reserved.

doi:10.1016/j.compenvurbsys.2003.12.003

636 A. Voss et al. / Comput., Environ. and Urban Systems 28 (2004) 635–651

Under such circumstances often a neutral third party is engaged, a facilitator, a

neutral moderator or, in case of hard conflicts, a mediator (Katsh & Rifkin, 2001).

These persons need not be domain experts, they are experts in group communica-tion. They make sure that the actors first agree on a procedure, and then follow it.

They immediately react to any disturbances, try to clarify misunderstandings or to

adapt the procedure in consensus.

The European Commission fosters the implementation of new forms of e-gov-

ernment according to the principles of transparency and public participation. Within

the challenge of the European institutional reform the Commission also promotes

the trend towards democratization of decision making by using new technology (EU-

Commission, 2000). New tools are sought to support spatial planning and decisionmaking.

Existing software tools focus on either side of the coin (Gordon & M€arker, 2003),but there is no platform that incorporates both, powerful moderation facilities and a

highly interactive software for spatial analysis. Geographic information systems

(GIS) perform reliable information management and analysis when the spatial

dimension plays a substantive role in understanding given phenomena and fore-

casting possible scenarios. GIS alone cannot solve all the problems in a planning

process, but their integration with other ICT tools seems to offer the digitalinfrastructure for developing decisional process in the Digital Age (Campagna &

Deplano, 2002).

Impulses from theoretical discussions on urban planning strengthen the role of

participation in urban planning. Combining this work with the options of computer-

and network-based technologies promises to improve the satisfaction of all actors

with the results of planning procedures (M€arker & Pipek, 2000). The Virtual Sla-

ithwaite (Kingston, Carver, Evans, & Turton, 1999) allowed users to comment se-

lected features on the map, but comments were kept private and a discussion was notsupported. The interactive landscape plan (Tiedtke & Warren-Kretzschmar, 2003)

allows for web-based exploration and discussion of contents, while the underlying

GIS and discussion forum remain separate systems.

2. Our approach

At our Fraunhofer Institute AIS two software tools have been developed inde-

pendently, a platform for electronic discourses (Dito�) and a GIS (CommonGIS) for

interactive exploration of geographic data. The idea to integrate them is almost as

old as the tools (Rinner, 1998). At that time, clickable hypermaps or Java mapping

applets with graphical annotation facilities were used for asynchronous, moderatedcommunication via the Internet, but none of them treated discussion contributions

as individual objects with well-defined relations among them, to be linked to indi-

vidual map elements. Rinner proposed an object-oriented model of geo-referenced

argumentation with argumentative relationships and their spatial visualization. In

2001 we initiated a process of evolutionary integration between Dito and Com-

monGIS. In this article we will present the latest results. After a short presentation of

A. Voss et al. / Comput., Environ. and Urban Systems 28 (2004) 635–651 637

Dito and CommonGIS we continue with an overview of the experiments and then

elaborate requirements, user interface and key design decisions. Our work at an

earlier status was described in (Voss, Voss, Gatalsky, & Oppor, 2002).

2.1. CommonGIS––our WebGIS

CommonGIS is a powerful software tool that combines traditional GIS methods

with innovative tools for visual data analysis and decision making. Fully based on

Java technology, CommonGIS can be used stand-alone on a local PC, or in theInternet or Intranet through Java applets or plug-ins. Due to its ability to process

spatial data in many standard formats CommonGIS can connect to and enhance

most commercial GIS software.

CommonGIS is particularly designed to support interactive visualization and

analysis of geo-referenced statistical data. Using knowledge-based techniques for

automating the process of thematic mapping, CommonGIS very much frees the user

from routine work, and also enables non-expert cartographers to deal with thematic

mapping (Andrienko & Andrienko, 1999; Andrienko, Andrienko, & Voss, 2003).CommonGIS offers several visual and computational decision support tools that

can be utilized by the individual for selection, prioritization, and integration of

decision options. It is possible to define cost and benefit criteria, define their relative

priorities by moving sliders or setting absolute values, compute a score and a ranking

of options by the ideal point method (IPM) or various other multi-criteria methods

(Jankowski, Andrienko, & Andrienko, 2001). CommonGIS makes it very easy to

manually investigate and edit the automatically produced rankings and to define

classes of solutions. Further visual methods for the analysis of multi-dimensionalproblems include parallel coordinate plots, utility bars, utility wheels, and dynamic

queries for constraining allowed attribute values and solutions (Andrienko &

Andrienko, 2001a; Andrienko, Andrienko, Savinov, Voss, & Wettschereck, 2001).

For group decision making CommonGIS provides a voting interface for the

interactive ranking and classification of options. Special visual tools help to analyze

the results of votes, exhibiting areas or points of conflict and consensus. It is easy and

intuitive to construct and submit a vote that corresponds to the agreed form, and the

moderator/facilitator may conveniently survey and analyze the submitted votes(Andrienko, Andrienko, & Jankowski, 2003; Andrienko & Andrienko, 2001b).

Visualization parameters of CommonGIS can be saved preserving the state of

data analysis and exploration. These preserved states of the system are called

snapshots.

2.2. Dito––our participation platform

Dito (‘‘as said’’) is an instrument for knowledge transfer through complex, text-

based discussions. Dito is used for self-guided or moderated forms of collaboration

and communication between persons that are distributed in time and space. Dito

provides all participants with the same information status, at any time and from

everywhere (Voss, 2002; Voss et al., 2003).


E-mail is the most successful medium of knowledge communication and seamless

integration of e-mail is a major feature of Dito. Like emails, Dito’s units of com-

munication, which we call contributions, have a title, a text, and possibly documentattachments. Contributions may be woven into a semantic network by creating

connections and assigning categories both to the contributions and to their con-

nections. The network can be traversed in both directions. Networks of contribu-

tions may represent argumentations, rationales, concept maps, mind maps or idea

maps, depending on the particular choice of categories for contributions and con-

nections. Contributions can be created on the web or directly via e-mail.

The semantic networks may be split into topics and the topics may be grouped

into sections. Sections are Dito’s organizational units and combine the function of e-mail archives with those of shared folders and discussion forums. All sections are

protected and offer differentiated access to users in the roles of observers, partici-

pants or moderators. With its sections Dito offers a flexible instrument for designing

goal-oriented discussions (discourses). A section may be configured to:

• introduce categories for contributions and connections (like pro and contra, orquestion, info, comment, action),

• provide additional communication channels (e-mail, chat, and polling),• structure knowledge (withdraw, publish, edit, connect, delete, close, copy or movecontributions, topics or sections),

• launch additional analyses (text mining or discourse monitoring and analysis).

A subscription procedure allows to be notified selectively. Through a personal start

page and daily reports via e-mail one can be informed about the events in all sub-

scribed sections.

2.3. Experiments

To integrate CommonGIS and Dito we took an evolutionary prototyping ap-

proach (Floyd & Z€ullighoven, 1997). Evolutionary prototyping is a continuousprocess in which the software is developed version by version and is adjusted to

changing circumstances. We alternated prototype building with experiments which

we conducted according to the ‘‘role-play’’ approach in action research (Whyte,

1991). Action research provides an opportunity to bridge theory with practice,

allowing to solve real-world problems while contributing to the construction of new

knowledge. The role-play approach is particularly attractive due to its interdisci-

plinary character. It lets us investigate process models for participatory procedures,

is a test area for usability and new features of the software, and stimulates newrequirements and ideas.

Our experiments comprise tasks of location selection and of utility allocation. In

one experiment, the participants were spatially distributed and had 3 weeks to solve

the task and in the other experiments they were together only 2 or 3 days. We report

on these experiments before we turn to our new and third integration development.


2.3.1. Wallis

The first experiment was named ‘‘The Wallis Experiment’’ since the task was to

select one out of forty locations in the Swiss region of Wallis. Each of the elevenparticipants had the same role status––they represented researchers. Their task was

to select a location in Wallis which provided possibilities for a ski-robot competition,

as well as ski and leisure activities for the researchers. The role-play was set up as a 2

day lasting mediated decision process, combining face-to-face and online sessions

(Voss, Roeder, & Wacker, 2003).

During the Wallis experiment the tools were used separately. The participants

used CommonGIS to explore the locations, to visualize the locations’ attributes, and

to weigh them according to their individual preferences for a final voting. The dis-cussion mainly took place in a Dito section, where preferences and criteria were

elaborated which resulted in the introduction of new attributes for the locations. The

decision was based on the automatic ranking of locations generated by the partici-

pants using the GIS. In the forum, where each location represented a discussion

topic, only the election of one out of the final top four locations was discussed. A

consensus was reached in a moderated face-to-face discussion, during which the

discussion referred to the locations, and the participants were able to visualize the

locations attributes according to their talk.

2.3.2. Call-A-Bike

The theme of this role-playing experiment was inspired by a franchise system for

renting bikes that DBrent, a daughter of the German railway company, plans toinstall in all major German cities. For the city of Bonn our characters, who repre-

sented the municipality, the franchise taker, the existing bike rental station near the

main train station of Bonn, the German bike club (ADFC), and citizens, should

identify a number of locations where people could pick up a bike. Via their cell

phone they will obtain an electronic key. Later they can drop the bike at any of the

locations and inform the call centre so that the correct time can be accounted for in

their monthly bill. The role-play was set up for 4 weeks: an initial, an intermediate

and a final face-to-face meeting framed intermediate weeks of online interaction(Voss, Roeder, Salz, & Hoppe, 2002).

The problem to solve in the Call-A-Bike experiment was more complex than the

Wallis problem. Since a combination of locations had to be selected, the decision

process was more discourse-oriented than analytic. There was a first integrated

version of Dito and CommonGIS which supported a geo-referenced discussion.

The software allowed annotating a point in the map with a contribution in the

discussion. Dito had a button to create a geo-reference by indicating a point in a

special annotation layer in CommonGIS. Then the users could click on a geo-reference in the map and the contribution was opened in the Dito window. The

participants chose and geo-referenced several locations for each identified demand

area. Since there had been no algorithm to visualize and rank several sets of

location combinations, the participants voted for each location, and discussed the

locations which had no consensual outcome. Fig. 1 illustrates the discussion on the

questionable locations. The Dito screenshot shows the topic and its contributions

Fig. 1. Use of the 1st prototype of the integrated system in the Call-A-Bike experiment (translation: 5:

University main building, palace church, 49: market place. . ., Eintragungen: entries).


with the labels pro, contra and question. In the map, the icons indicate �feasible’and �less feasible’ locations. These attributes were chosen according to the numberof positive and negative contributions in the discussion that referred to the loca-

tion.

2.3.3. UMTS transmitters

The third experiment was about locating UMTS transmitters in the German town

of Rodgau. By law, only the city representatives and the UMTS operator have to

agree on the locations for transmitter installations. In our role-play, city and oper-

ator wanted to involve other stakeholders in the allocation process. Through aparticipatory and consensus-driven decision process they hoped to gain a higher

acceptance within the population. Besides the city mayor and the cell phone operator

the stakeholders were: a citizen initiative, the chamber of industry and commerce, the

catholic consistory and a real-estate enterprise. The role-play took place in a com-

munication laboratory room and was set up for 3 days, with turns of on-line and on-

site work (Roeder & Jankowski, 2003).

As in the Call-A-Bike experiment, the task of the UMTS Transmitter experiment

was to solve the complex problem of choosing a combination of locations forallocating utilities. The procedure was fairly similar––only with a shorter time frame.

During this experiment, the 2nd prototype of the integrated system was used, which

is illustrated in Fig. 2. The system administrator could define parameters in Dito

which were to be transferred into the object attribute table in CommonGIS when

users created a new geo-reference. Thus, the predefined attributes of contributions

(e.g. author name, creation date, labels, etc.) were automatically stored in Com-

monGIS. One object in CommonGIS could be linked to several contributions in

Dito, which were visualized as �stacks’ in the map (see CommonGIS screenshot in

Fig. 2. Use of the 2nd prototype of the integrated system in the UMTS experiment (translation: 26: retail

trade, 30: new suggestion: sports facility is a better site, 51: support retail trade, 34: better support trading,

39: ensure independent financing of sport facility, 43: money, money, money, 45: stick to the subject, 46:

site: declaration).


Fig. 2). In the 2nd prototype area objects and point objects could be created, so that

the users could visualize the discussed demand areas.

The course of experiments indicated that the more complex the decision problemis, and the more stakeholders participate, the more intuitive, easy-to-use and tighter

the integration should be. This allows reducing the number of face-to-face meetings

in a decision process, because fewer meetings are needed to exchange facts on

locations that would be too complicated to explain only through text.

3. Requirements

From the experiments we extracted three categories of requirements: conceptual

requirements concern the possible annotation relations, while GUI requirements

concern the user interface. Technical requirements, to be supplied in Section 4,

constrain the software architecture and the implementation.


3.1. Conceptual requirements

Requirement C1: Annotation objects

An annotation is a relation between a reference (object) and a comment (object).

Users shall be able to create annotations between many kinds of objects: comments

should be objects of different grainsize (an entire discussion section or a single

contribution in Dito) and they may reference any geographic object (point or

polygon in CommonGIS). We use the term geo-reference for a reference which is a

geographic object.

Requirement C2: (n:m) annotations

A geographic object may have multiple comments, for instance from different

users or concerning different aspects, and a single comment may refer to more than

one geographic object, e.g. to compare two locations.

Requirement C3: (n:m) contexts

Different groups of actors, like citizens, stakeholders, planners and decision-makers, should be able to annotate the same map in different discussion contexts that

are accessible only to their own group. During such a discussion, a group shall be

able to refer to other maps as well, for instance, to compare the maps of two different

regions. We say that the map and the discussion are the two contexts associated with

the annotation. This requirement shall not only apply to maps, but equally to

snapshots of maps.

Requirement C4: Operational integrity

Geographic objects and discussions may be manipulated independently in the two

applications (delete, remove, copy, or access control operations). But all annotations

displayed to a user should be valid and intact: their reference and comment objects

must exist and be accessible to this user. When a snapshot is taken from a map, it

establishes a new context for discussion and any annotations of the map should not

be copied.

3.2. GUI requirements

Our user interface requirements concern the symmetry of operations in the two

applications and the analysis of annotations in the map.

Requirement G1: Symmetric display

Users who discuss a map will often switch between the discussion and the map.

More generally, they may switch between different maps that are referenced in the

same discussion, or between different discussions that comment on the same map.

To give users maximal freedom to move between contexts, a map should display

all comments from all discussions which the user is authorized to see, and a dis-

cussion should display the geo-references to all associated maps.


Requirement G2: Symmetric creation and deletion

Users should be able to create annotations by first indicating the geo-reference on

the map and then the comment in the discussion or, vice versa, by first indicating thecomment and then the geo-reference. Similarly, annotations may be deleted in any

context.

Requirement G3: On-the-fly creation of annotation objects

Users may want to annotate an existing geographic object with a comment thathas to be written yet, or refer a comment to a geographic object that yet has to be

drawn. Both of these workflows should be supported.

Requirement G4: Annotation layers

Annotations should be displayed on a special annotation layer which users may

combine or not combine with any other layer in the map. The annotation layervisualizes the different categories of contributions that occur in the discussion (e.g.

distinguish comments of type information, opinion or question, or comments of type

desired, approved or rejected). Finally, comments from different discussions should

be kept separated in the same map on different annotation layers.

Requirement G5: Annotation analysis

All analysis functions, especially temporal analyses, and specific analyses for

annotation layers shall be provided in the map in order to help ordinary users,

moderators and decision makers to reproduce the history of the discourse, to detect

conflicts and potentials for compromises.

4. Our solution

The prototypes used for the Call-A-Bike and UMTS experiments satisfied the

requirements only partially: only 1:1 annotations, only 1:1 contexts, only asymmetric

operations and potentially inconsistent data. Our new solution, to be presented

below, satisfies all requirements almost entirely. It integrates the Dito and Com-

monGIS versions as presented in Section 2. We first describe the integration from the

users’ perspective and then discuss the crucial design decisions.

4.1. User interface

4.1.1. Displaying annotations

The new solution supports n:m annotations (C2) and n:m contexts (C3). Displayof annotations is symmetric (G1), and different annotation layers for every discus-

sion context (G4) allow the users to switch conveniently between contexts.

After users have logged into Dito they may browse all discussion sections they are

authorized to see. Some of these sections may be associated to maps and contain

geo-references. The geo-references are indicated by icons next to the comments,

where different icons help to distinguish different maps. The first time a user clicks on


the icon assigned to a certain map, the associated CommonGIS applet is launched in

a new browser window and the geo-referenced objects will be highlighted. Annotated

maps can only be opened out of the context of Dito’s protected sections so that themaps are as well protected as the discussions and users always have been authenti-

cated before a map is opened. When a user clicks again on an icon for the same map

(in the same or in another section), the applet will not be started again. Instead, the

appropriate geo-references will be highlighted as soon as the user passes to the

window with the corresponding map. The geo-referenced object lies on the anno-

tation layer that is associated with the section. There may be other, non-active

annotation layers for other sections that are associated with the same map, which the

user may choose to explore. Annotation layers may contain point or polygon objectsand with additional annotation data like the category of the contribution, the creator

or the creation time of the annotation. By default, the annotation layer shows the

objects with icons that indicate the category of the comment, e.g. question marks for

questions and exclamation marks for statements.

If a user clicks on an annotation icon in the map the browser window with Dito is

activated. A list of all comments linked to the selected geographical object on the

active annotation layer is presented. By choosing a comment the user gets the entire

contribution together with all attributes, all references to other Dito resources andexternal web resources, and all its geo-references. The user may then explore the

context of the contribution in Dito.

4.1.2. Analyzing annotations on the map

In this third solution, the CommonGIS applet supports sophisticated analyses on

the different annotation layers (G5), including temporal analyses.

It is possible to apply visualizations to the available attributes just by calling the

‘‘Display wizard’’. For instance, the different categories of the contributions may be

visualized as icons, as signs or as points of different colors.

Especially promising should be the results of the time-analysis tools: animated

map, time-series graph, and diagram map. For every geo-reference, we can visualize

e.g. the number of comments per day. The general progress of a discussion in timecan easily be represented by means of a user-controlled map animation. Common-

GIS allows the user to make interactive temporal queries by choosing points and

intervals on the time axis and combining the queries with animation. For example,

users may analyze the overall discussion speed, find its ‘‘active’’ or ‘‘silent’’ phases, or

find active participants. By means of other time-analysis tools moderators or

mediators may find answers and perform other specific tasks from the area of their

interests.

4.1.3. Creating annotations

Annotations may be created symmetrically (G2). Reference and comment objects

can be created on-the-fly (G3), and annotations may be created between differenttypes of objects. As a restriction, geo-references have to be objects on annotation

layers; it is not yet possible to comment existing objects on other layers (C1).


Dito offers a command ‘‘make geo-reference’’ for each map associated with a

section. This command launches the CommonGIS applet with the corresponding

behavior; if the applet is already active the user must just switch between the win-dows. CommonGIS receives the comment information form Dito and lets the user

relate it to one or more objects on the annotation layer by mouse clicks. The user can

select an existing object or draw a new object and attach the annotation to it. When

the object(s) are selected, CommonGIS passes the geo-reference to Dito so that a

new icon can be inserted next to the comment.

The CommonGIS applet offers a new command ‘‘Annotate’’. With this command

a new annotation layer may be created and associated with existing or new-to-create

sections in Dito. Besides, the annotate command also allows to create new anno-tations to one or more selected geographical object(s) on the annotation layer. A user

may select the objects from a list or by mouse-clicks on the map. The annotate

command then activates the browser window with Dito.

In Dito the user may choose a contribution from the section or create a new

contribution in this section as a comment for the geographic objects.

4.1.4. Associating maps with sections

Before annotations can be created between a section and a map, an annotation

layer must be created in the applet and the Dito section must be associated with this

layer in the map. The association can be initiated from Dito in the ‘‘configure section

menu’’ or from the applet by creating a new annotation layer. In the annotation

layer, the user has to define the icons for the different categories of comments in the

default visualization. Icons can be designed for each specific annotation layer and

discussion section.

4.1.5. Other operations affecting annotations

In the CommonGIS applet, users can delete annotations with or without the geo-

referenced objects. In Dito sections and contributions may be deleted, removed or

copied, annotation relations may be deleted, or access rights be revised. When

geographic objects, comments or just the annotation relation is deleted in one

application, the other application will delete the respective annotation relation.

When sections are copied or when contributions are moved or copied, they will loosetheir geo-references.

4.2. Design

Several technical designs would meet the requirements from Section 3. To decide

between them, additional technical requirements have to be considered.

4.2.1. Technical requirements

CommonGIS and Dito are both fully functional stand-alone software applica-

tions which are to be integrated in order to gain a synergetic benefit. However, Dito

and CommonGIS are very different types of software. Dito is a web-based com-

munication platform, its users are focused on collaboration and communication, and


response times up to a second are fine. CommonGIS is not a tool for communica-

tion, but for highly efficient personal visualization. Response times of a second

would be very irritating. This is the reason why practically all CommonGIS func-tionality resides on the client machine, in the applet.

Requirement T1: Maximal independence. We think the most efficient way to combine

both applications is to keep them as they are and just define an interface for data

exchange.

Requirement T2: Fast response times. Exchange of annotation data between Dito and

CommonGIS must not decrease response times in the applet.

Requirement T3: Synchronization. To keep annotation data as consistent as possible

(C4), the two applications have to exchange annotation data synchronously.

Requirement T4: Non-redundant annotation data. Redundant data should be avoided,

because it is a source of inconsistencies. Section and contribution data should be kept

in Dito, maps and geographic objects in CommonGIS, while annotation data may be

kept in either application, but it should not be kept persistently in both of them.

Requirement T5: Respect firewalls. Users of Dito and CommonGIS typically work

from behind firewalls, and typically, they cannot influence the set up of the firewalls.

The communication between Dito and the applet has to function under very

restrictive firewalls. Therefore special socket connections, e.g., are not allowed.

Requirement T1 has been a guiding principle and has driven our evolutionary

development of successive prototypes. We have always tried to integrate the two

applications without affecting their different philosophies. As a consequence, and dueto the constrained communication between a web application and an applet, their

integration was always restricted to run on a single web server. Requirements T2–T4

are related. We first had annotation data in Dito, then in CommonGIS and now

again in Dito. We will now elaborate the communication and the storage of anno-

tation data because they turned out to be key issues in every integration effort.

4.2.2. Communication between CommonGIS and Dito

Dito is implemented as web application running in a servlet container on a webserver. CommonGIS is an applet, and all CommonGIS data are stored persistently

in files (or in a database). CommonGIS uses a few servlets in order to save changed

data or snapshots in files.

Due to the requirements of operational integrity (C4) and symmetric operations

(G2), which are satisfied by our new user interface, three types of contact between

the two applications have to be implemented.

• Launching the applet with initial data from Dito.• Requests to the applet issued by Dito.• Requests to Dito issued by the applet.


Applets can only communicate with their launching web server and they can only

access data on this server. This means that the CommonGIS applet cannot com-

municate directly with Dito unless when it is launched from Dito’s hosting server.This ‘‘same-server’’ solution is sketched in Fig. 3.

The Dito web application and the CommonGIS applet are hosted by the same

web server or servlet container, respectively. On the client side a browser instance

provides the user with the HTML user interface of Dito and the CommonGIS ap-

plet. Both, the HTML interface and the applet, send HTTP requests to the Dito web

application and both get its responses. To ensure that both user interfaces present

annotations consistently they have to exchange data. Since HTTP allows only to

request data and not to push them the applet has to occasionally poll the relevantdata. For example, a delete operation is processed in the Dito web application after a

user has pressed a delete button and the browser has issued an HTTP request. The

result of the deletion has to be communicated to the applet so that it can also per-

form the necessary actions. For the communication the result of the Dito operation

is stored in special data pipes for all concerned applets. Each applet is polling its pipe

to check for new data.

Dito server

Dito web application

Browser

Data pipe

File system

Dito data baseserver- Annotation data in secondaryattributes

CommonGISFiles- Applet,

Maps, etc

Dito Window

- sections

- annotations

CommonGIS applet

- Maps

- layers

HTT

P re

ques

t

HTT

P re

spon

se

HTTP response

HTTP request

http

requ

ests

& re

spon

ses

Fig. 3. Software architecture.


The data pipe is a user-specific session variable of the web application. It can be

accessed both, by the applet and by Dito. Storing the data pipe in the user sessions

means that every user has got his own data pipe. If an annotation is created, changedor deleted, Dito puts this information in every available user session. Thus all in-

stances of the applet can get this information and update their annotation layers.

4.2.3. Annotation data in Dito rather than CommonGIS

Annotation data relate comments to geo-references and supply them with meta-

data like creator and creation date. These data may reside in Dito, in the file for the

applet or they may be distributed among them.

In the Call-A-Bike approach all annotation data resided in Dito. Individual

annotations were passed to the applet for display. In the UMTS approach the map

could display all annotations on its annotation layer. To guarantee fast response

times, all annotation data were then stored with the applet and not in Dito. Con-sistently, Dito did not display any annotations. Still, the annotation data in the map

would become inconsistent when comments were deleted in Dito. Beside being

unsatisfactory, this approach does not scale to n:m contexts.

Requiring n:m contexts (C3) means especially that comments from different sec-

tions with different access policies and different categories of contributions may

annotate the same map. Of course, the user must not see any comments on the map

which they may not access in Dito, and therefore annotation data have to be stored

in Dito persistently. For quick response times in the applet (T2), they are transferredto the applet when it is launched. The applet then compares the annotation data with

its annotation layers and corrects any inconsistencies. So Dito will keep all relevant

annotation data in its data base, more precisely, as attributes of sections or contri-

butions.

CommonGIS is not the first extension of Dito; other extensions are chat, polling,

or e-mail. An extension typically needs new special attributes for Dito’s resources,

especially for sections and contributions. To this aim Dito supports additional sec-

ondary attributes which are stored as triples (resource-id, name, value) in a separatetable. These secondary attributes are used to store annotation data in the form (id of

resource in Dito, CommonGIS-annotation, value). For contributions which are

comments, the value field is composed of

• The path (URL) to the CommonGIS applet.• The identifier of the CommonGIS object (needs to be unique for the referringapplet which is identified by the path).

• The creator of the annotation, who always is a registered Dito user or Dito guest.• The creation date of the annotation.

The set of all secondary attributes with the name ‘‘CommonGIS-annotation’’

belonging to one section are passed to the CommonGIS applet in order to fill the

annotation layer corresponding to this section. This is done for each section that is

associated with the applet.


All layers presented on a map in the CommonGIS applet are described in a

configuration file. The description of an annotation layer contains properties for a

data source, the link to a data pipe to Dito, and icons for the default layout. Torestrict access to the CommonGIS configuration files they should be stored under

access control of Dito.

The new integrated solution is summarized in Table 1 with respect to all

requirements.

Table 1

How the new solution meets the requirements

Requirement Current solution

C1: annotation objects Discussion sections may be associated with maps, and in these

discussions every contributions may be a comment. In the map,

any points or polygons on special annotation layers may be

geo-referenced

C2: (n:m) annotations Yes, many comments per geographic object and many

geo-references per contribution to a discussion

C3: (n:m) contexts Yes, many maps per discussion section and many discussion sections

per map

C4: operational integrity Yes, side effects on annotations for delete, copy and other

modification operations in Dito and CommonGIS are defined

G1: symmetric display Yes, geo-references are displayed with the comments in the

discussion, and comments are displayed with the geo-references in

the map

G2: symmetric creation and

deletion

Yes, annotations can be created and deleted in the map or in the

discussion section

G3: on-the-fly creation of anno-

tation objects

Yes, comments and geo-references can be created on-the-fly, during

an annotation operation

G4: annotation layers Yes, every discussion section associated with a map is represented by

a special annotation layer in the map

G5: annotation analysis Yes, with special visualizations and tools for temporal analysis. In

particular, different types of comments may be indicated by different

icons on the annotation layer

T1: maximal independence Yes, the software architecture can be realized in Dito as an

extension. HTTP and the data pipe together solve the communica-

tion problem between applet and web application. A distributed

solution (both tools running on different servers) was considered and

rejected because it was not consistent with the lightweight applet

nature of CommonGIS

T2: fast response times Yes, display time is fast. After the applet has been launched, only the

effects of modifications (G2) have to be communicated between the

two tools. These are fast operations on the data pipe

T3: synchronization Yes, Dito and all CommonGIS applets that are simultaneously

running with the same map synchronize their annotation data in

case of modifications (G2)

T4: non-redundant annotation

data

Yes, annotation data are persistently stored in Dito. They are passed

to the applet when it is launched and then checked for consistency

(do all geo-referenced objects still exist, do all annotation layers of

associated sections still exist?)

T5: respect firewalls Yes, only the standard port for HTTP is required. Through HTTP,

applets poll the data pipe while their window is activate


5. Outlook

Our research and experiments showed that solving complex problems with mul-tiple stakeholders can be advanced significantly by electronic media. For successful

IT-support of the processes, a deep knowledge on the underlying cooperative ele-

ments, especially the communication between the concerned stakeholders, is needed.

We understand that the process and the software affect each other and form a socio-

technical system. Our work aims not only at developing useful electronic tools and

platforms, but also at establishing guidelines and best practices for good moderation.

We strongly believe in the evolutionary prototyping approach combined with

participatory (action) research. The implementation of the third integration of thesystem is currently in progress. We will apply the system again in experimental

settings, which will presumably lead to further requirements. In particular, we will

compare our solution with the candidate XML specification XIMA discussed in the

OpenGIS consortium for imagery mark-up. In the near future, we will further

cooperate with municipalities and offer solutions for group decision support and

e-participation.

Acknowledgements

This article is based on ideas, research, and developments of many colleagues in

our research divisions ‘‘Knowledge and Communication’’ and ‘‘Spatial DecisionSupport’’ at Fraunhofer AIS. We want to thank especially those colleagues who have

been involved in the integration of Dito and CommonGIS: Lothar Oppor, Natalia

Andrienko and Gennady Andrienko. Part of the work was funded in the KogiPlan

project by the German Federal Ministry of Education and Research (BMBF) under

contract number VFG0003B.

References

Andrienko, G., & Andrienko, N. (1999). Interactive maps for visual data exploration. International

Journal Geographical Information Science, 13(4), 355–374.

Andrienko, G., & Andrienko, N. (2001a). Exploring spatial data with dominant attribute map and parallel

coordinates. Computers, Environment and Urban Systems, 25, 5–15.

Andrienko, G., Andrienko, N., & Jankowski, P. (2003). Building spatial decision support tools for

individuals and groups. Journal of Decision Systems, 12(2), 193–208.

Andrienko, G., Andrienko, N., & Voss, H. (2003). GIS for everyone: The CommonGIS project and

beyond. In M. Peterson (Ed.), Maps and the Internet. Elsevier Science.

Andrienko, N., & Andrienko, G. (2001b). Intelligent support for geographic data analysis and decision

making in the web. Journal of Geographic Information and Decision Analysis, 5, 115–128.

Andrienko, N., Andrienko, G., Savinov, A., Voss, H., & Wettschereck, D. (2001). Exploratory analysis for

spatial data using interactive maps and data mining. Cartography and Geographic Information Science,

28, 151–165.

Campagna, M., & Deplano, G. (2002). Public participation GIS for re-development support in European

historic city centres. In M. Schrenk (Ed.), Computergest€utzte Raumplanung CORP. Department of

Computer Aided Planning and Architecture, Vienna University of Technology, Vienna.


EU-Commission (2000). Dialogue on Europe.

Floyd, C., & Z€ullighoven, H. (1997). Softwaretechnik. Hanser Verlag.Gordon, T., & M€arker, O. (2003). Mediation systems. In O. M€arker, & M. Tren�el (Eds.), Online-

mediation. Theorie und Praxis computer-unterst€utzter Konfliktmittlung. Sigma, Berlin.

Jankowski, P., Andrienko, N., & Andrienko, G. L. (2001). Map-centered exploratory approach to

multiple criteria spatial decision making. International journal Geographical Information Science, 15,

S.101–S.127.

Katsh, E., & Rifkin, J. (2001). Online dispute resolution. Resolving conflicts in cyberspace. Jossey-Bass.

Kingston, R., Carver, S., Evans, A., & Turton, I. (1999). Virtual decision making in spatial planning: Web-

based geographical information systems for public participation. In Environmental decision making

international conference on public participation and information technology, Portugal.

Kunz, W., & Rittel, H. W. J. (1970). Issues as elements of information systems, Stuttgart.

M€arker, O., & Pipek, V. (2000). Computer supported participation in urban planning from the viewpointof �Communicative planning theory’. In F. Galindo, & G. Quirchmayr (Eds.), Working conference on

advances in electronic government (pp. 43–58). Seminario de Inform�atica y Derecho, Universidad de

Zaragoza, Zaragoza, Spain.

Rinner, C. (1998). Online maps in GeoMed––Internet mapping, online GIS and their application. In

Collaborative spatial decision-making proceedings of GIS PlaNET’98 international conference on

geographic information, Lisbon, Portugal.

Roeder, S., & Jankowski, P. (2003). Evaluation of models and software tools for mediated participation.

In Local planning and decision making public participation GIS (PPGIS) conference, Portland, Oregon.

Tiedtke, S., & Warren-Kretzschmar, B. (2003). ‘‘Interaktiver Landschaftsplan’’: Internet und Multimedia

in der Landschaftsplanung. In M. Schrenk (Ed.), CORP (pp. 427–432). Institut f€ur EDV-gest€utzte

Methoden in Architektur und Raumplanung der TU Wien, Vienna.

Voss, A. (2002). E-discourses with Zeno DEXA, Web Based Collaboration Workshop, Aix-en-Provence.

Voss, A., Roeder, S., Salz, S. R., & Hoppe, S. (2002). Spatial discourses in participatory decision making.

In W. Pillmann, & K. Tochtermann, (Eds.), Environmental informatics (pp. 371–374). ISEP

International Socviety for Environmental Protection, Vienna.

Voss, A., Roeder, S., & Wacker, U. (2003). IT-support for mediation in decision making. A role playing

experiment. In O. M€arker, & M. Tren�el (Eds.), Online-mediation. Theorie und Praxis computer-

unterst€utzter Konfliktmittlung. Sigma, Berlin.

Voss, A., Schaefer, A., M€arker, O., Klotz, A., Roeder, S., Salz, S., & Wolff, V. (2003). Framework fordistributed problem solving with e-discourse platforms. In T. Bui, H. Sroka, S. Stanek, & J.

Gotuchowski (Eds.), DSS in the uncertainty of the internet age (pp. 421–434). Katowice: Publisher of

the University of Economics.

Voss, A., Voss, H., Gatalsky, P., Oppor, L. (2002). Prototype and further requirements of a real

participatory GIS. In 6th AGILE conference on geographic information science, Lyon, France.

Whyte, W. F. (1991). Participatory action research. Newbury Park, CA: Sage.

Evolution of a participatory GIS

Documents

Transcript of Evolution of a participatory GIS